Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded

From: <[email-masked]>
Date: Mon, 25 Feb 2002 13:27:05 +0200

Hi David,

Thanks for the good points.  The IESG has asked us to consider the usage of
SRV records as in this document:

http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-05.txt

This document has gone through IESG review and is considered the acceptable
way to use SRV records.  

Using a mechanism like the above will create several changes:

1) AAA URI changes
2) Allow nodes to create NAPTR records, which detail the different
   transport layers they support.

I think by using NAPTR records, your problem is overcome.

If my understanding is correct, it would go something like this:

   As an example, consider a client that wishes to resolve
   aaa:[email-masked]. The client performs a NAPTR query for that
   domain, and the following NAPTR records are returned:

    ;;          order pref flags service           regexp  replacement
        IN NAPTR 50   50  "s"  "AAAS+D2T"          ""  _aaas._tcp.example.com.
        IN NAPTR 90   50  "s"  "AAA+D2T"           ""  _aaa._tcp.example.com
        IN NAPTR 100  50  "s"  "AAA+D2S"           ""  _aaa._sctp.example.com.

   This indicates that the server supports TLS over TCP, TCP, and SCTP,
   in that order. If the the client does not SCTP, TCP will be
   used, targeted to a host determined by an SRV lookup of
   _aaa._sctp.example.com. That lookup would return:

    ;;          Priority Weight Port   Target
        IN SRV  0        1      5060   server1.example.com
        IN SRV  0        2      5060   server2.example.com

Now, I have some thinking to do on this, but any questions, comments & criticisms
would be appreciated.

John

> -----Original Message-----
> From: ext David Spence [mailto:[email-masked]]
> Sent: 22 February, 2002 20:55
> To: AAA Working Group
> Subject: [AAA-WG]: [issue] AAA URI is Overloaded
> 
> 
> Subject: [issue] AAA URI is Overloaded
> 
> Submitter name: David Spence
> Submitter email address: [email-masked]
> Date first submitted: 2/21/02
> Reference: 
> Document: Base
> Comment type: T
> Priority: S
> Section: 4.4
> Rationale/Explanation of issue:
> 
>    Some Background
>    ---------------
>    
>    The AAA URI provides two different kinds of information.
>    
>    1. It identifies a Diameter node.  A Diameter node is a Diameter 
>       process running on some host or device.  It is possible to have 
>       more than one Diameter process running on a host.
>    
>    2. It provides information about how to connect to the 
> Diameter node 
>       -- what transport protocol to use, what transport level 
> security 
>       to use, and even what AAA protocol to use (although we are only 
>       concerned about one, namely Diameter).
>       
>    The AAA URI also serves two different purposes.
>    
>    1. It is used in the peer-to-peer protocol to identify a peer and 
>       indicate certain parameters concerning how to connect to that 
>       peer.  This use requires the full URI including the prefix, the 
>       fqdn, the port number, and the options.  A URI for this purpose 
>       may be stored in a local configuration file or on a 
> remote server 
>       to enable dynamic peer discovery (see sec. 5.2).
>       
>    2. It is used in the Diameter routing and forwarding decisions to 
>       identify the Diameter node to which a Diameter message is 
>       addressed.  This use requires those portions of the URI that 
>       identify the Diameter node but does not require (and can be 
>       confused by) the information about how to connect to 
> the node as a 
>       peer.  This is the use made of the URI as transmitted 
> in all AVPs 
>       of type DiameterIdentity.
>    
>    
>    The Problem
>    -----------
>    
>    The problem is that the URI format is currently defined in 
> only one 
>    place (sec. 4.4 under the "DiameterIdentity" type) and makes no 
>    distinction between its use for the two different purposes 
> described 
>    above.
>    
>    
>    Operational Difficulties if the Problem Isn't Fixed
>    ---------------------------------------------------
>    
>    Section 4.4 states:
>       
>          Unless a Diameter node is sitting on the border of 
> two routing 
>          domains (e.g. private and public), a Diameter node MUST 
>          advertise the same identity on all connections, via the CER 
>          and CEA's Origin-Host AVP.
>          
>    Suppose a Diameter node has two peers.  It connects to the 
> first peer 
>    using SCTP.  It connects to the second peer using TCP.  In 
> order to 
>    obey this requirement, the node would have to include the string 
>    "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA 
>    message to the second peer even though it is using TCP to 
> connect to 
>    that peer.  So the identity advertised is not the identity used.  
>    This seems odd, but as we shall see, it is actually 
> necessary in order 
>    to make the routing mechanism work.
>    
>    Section 4.4 goes on to state:
>    
>          The same identity advertised in a connection's CER 
> and CEA MUST 
>          be used in any AVP of type DiameterIdentity sent on that 
>          connection.
>          
>    Now suppose an implementor misses the oddity required by the first 
>    sentence and does the obvious thing -- suppose the implementation 
>    always includes in the CER the parameters actually in use 
> on the peer 
>    connection.  Then the implementation will have a very hard time 
>    meeting this requirement too.  It would have to know how it will 
>    route the message at the time it generates the message, a horrible 
>    violation of modularity.  Supposing it does know how it will route 
>    the message and sets the value of the Origin-Host AVP in 
> the message 
>    to the same value used in the CER or CEA sent to the peer 
> to which it 
>    will route it.  Now suppose something goes wrong when sending the 
>    message to this peer, and the message is subsequently 
> retransmitted 
>    to a backup peer.  Oops.  Now the Origin-Host AVP is wrong 
> for that 
>    connection and it can't be changed.
>    
>    So we'll just have to assume that all implementors pick up on the 
>    oddity.  But wait -- we're still not out of the woods.  
> Suppose, at 
>    the time a session begins, the Diameter client supporting 
> the session 
>    uses TCP on its peer link.  So it includes the string 
> "transport=tcp" 
>    in the auth request that begins the session.  Suppose that several 
>    hours later the session is still in progress, but the client has 
>    reinitialized its peer link and is now using SCTP.  Now 
> suppose the 
>    home server sends an Abort-Session-Request message to the 
> client for 
>    this session.  The Abort-Session-Request will include a 
>    Destination-Host AVP that contains the string 
> "transport=tcp".  The 
>    message eventually reaches the peer connected to the client.  The 
>    peer matches the URI in the Destination-Host AVP with the 
> ones in its 
>    peer table.  It finds no match because "transport=tcp" 
> does not match 
>    "transport=sctp".  So it discards the message.
>    
>    
>    Interaction With Issue 273
>    --------------------------
>    
>    Another issue urges that Diameter nodes not use different port 
>    numbers for TLS versus non-TLS connections.  I am guessing 
> that issue 
>    273 is the one that encompasses this change.  The question of port 
>    number use for TLS versus non-TLS was raised by Allison Mankin in:
>    
>       http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html
>       
>    The outcome of issue 273 (if that is the issue that includes this 
>    question) is critical to the resolution of this issue as 
> well.  The 
>    reason is that we use the combination of fqdn and port number to 
>    identify a diameter node.  If more than one Diameter node 
> (Diameter 
>    daemon) runs on a host, they will use different port 
> numbers.  But if 
>    a Diameter node listens on more than one port number, then 
> it may use 
>    two different URIs and there will be no way for a peer to 
> know that 
>    the URI from the Destination-Host AVP of a message it is routing 
>    matches the URI of one of its peers if the port number differs.
>    
>    John Loughney suggested use of aaa: vs. aaas: to indicate 
> whether TLS 
>    is used in:
>    
>       http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html
>    
>    If this suggestion is adopted, then the "s" in aaas: will 
> need to be 
>    ignored when doing routing matches against entries in the 
> peer table.
> 
> 
> Requested change:
> 
>    Define the format of the URI somewhere other than section 4.4.  In 
>    the definition of the DiameterIdentity type in section 
> 4.4, specify 
>    that only the prefix, fqdn, and port number portions of 
> the URI are 
>    included in AVP value fields of this type.  The sentences 
> cited above 
>    may now be left in section 4.4 because they no longer cause a 
>    problem.
>    
>    If the resolution of issue 273 allows a Diameter node to listen on 
>    different ports for TLS vs. non-TLS connections, then section 4.4 
>    needs to emphasize that a single port number MUST be used 
> in all AVPs 
>    of type DiameterIdentity.  If the resolution of 273 
> requires use of 
>    the same port for TLS and non-TLS connections, then it 
> would still be 
>    a good idea to include text in section 4.4 following the first 
>    sentence cited above that emphasizes that the same port 
> number MUST 
>    be used in all AVPs of type DiameterIdentity even if a peer 
>    connection request was received on a different port.
>    
>    If the URI prefix may either be aaa: or aaas: depending on 
> transport 
>    security, then text should be added to section 6 stating that when 
>    matching URIs for routing purposes, the "s" in aaas: should be 
>    dropped before the compare is made.
>

---

From: <[email-masked]>
Date: Tue, 26 Feb 2002 22:45:55 +0200

Hi David,

> Wow!  This is a big change and I don't understand where this 
> might lead well enough to know how it impacts my issue.  

This I think we need to sort out.  Essentially, section 5.2 needs
updating with regards to SRV records.  Actually, I am wondering
if the DiameterIdentity needs to be directly modified for this or not.

John

> So as you deal with your changes
> regarding how server discovery works,  keep in mind the AVPs of type
> DiameterIndentity which are used for message routing and make 
> sure their
> requirements are met, to wit:
> 
> 1) A value of type DiameterIdentity must uniquely identify a 
>   "Diameter node", which is an instance of a Diameter process running on an IP
>    host.
> 
> 2) There may be more than one "Diameter node" running on the same host
>    and sharing the same IP address.
> 
> 3) It must be possible to express a value of type 
> DiameterIdentity in a
>    canonical form so that each "Diameter node" will only have a single
>    identifier in a domain.  Thus the type must not contain 
> any parameters
>    that are specific to a particular peer-to-peer connection.
> 
> [email-masked] wrote:
> > 
> > Hi all,
> > 
> > I noticed that my example wasn't exactly correct, here is 
> an update version:
> > 
> > === updated example ====
> > 
> >    aaa:example.com. The client performs a NAPTR query for that
> >         IN NAPTR 50   50  "s"  "AAA+D2S"           ""  
> _aaa._sctp.example.com.
> >         IN NAPTR 90   50  "s"  "AAAS+D2T"          ""  
> _aaas._tcp.example.com.
> >         IN NAPTR 100  50  "s"  "AAA+D2T"           ""  
> _aaa._tcp.example.com
> > 
> >    This indicates that the server supports SCTP, TLS over 
> TCP, and TCP,
> >    in that order. Since the client supports SCTP, SCTP will be
> >         IN SRV  0        1      xxxx   server1.example.com
> >         IN SRV  0        2      xxxx   server2.example.com
> >         ;; where xxxx is replaced by the well-known port 
> for Diameter
> > 
> > John
>

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:07:41 +0200

Hi All,

>    only one place (sec. 4.4 under the "DiameterIdentity" type) and makes no 
>    described above.

I propose the following resolution for defining the aaa URI 

==> clarification, is this a AAA URI or Diameter URI or ..? <== 

2.9 Diameter URI

The Diameter URI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below:

"aaa[ transport-security ]://" fqdn [ port ] [ transport ] [ protocol ] 

transport-security = ( "" | "s" )

; If absent, the default, no transport security
; is assumed.

fqdn               = Fully Qualified Host Name

port               = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections. ; If absent,
; the default Diameter port (TBD) is
; assumed.

transport          = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default SCTP [SCTP] protocol is
; assumed. UDP MUST NOT be used when 
; the aaa-protocol field is set to
; diameter.

transport-protocol = ( "tcp" | "sctp" | "udp" )

protocol           = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is diameter.

aaa-protocol       = ( "diameter" | "radius" | "tacacs+" )

The following are examples of valid Diameter host identities:

aaa://host.abc.com;transport=tcp
aaa://host.abc.com:6666;transport=tcp
aaa://host.abc.com;protocol=diameter
aaa://host.abc.com:6666;protocol=diameter
aaa://host.abc.com:6666;transport=tcp;protocol=diameter
aaa://host.abc.com:1813;transport=udp;protocol=radius
aaas://host.abc.com;transport=tcp
aaas://host.abc.com;protocol=diameter

John

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 15:28:23 +0200

Hi,

I am a bit confused here as according to the proposed specification
        aaa[ transport-security ]://abc.com 
is a valid DiameterIdentity as [transport-security] is placed within quoted string.

aaa-token fqdn [ port ] [ transport ] [ protocol ] 

aaa-token = aaa | aaa-security
aaa = "aaa://" 
; No transport security
aaa-security = "aaas://"
; Transport security used

I feel that the above change keeping the remaining part as proposed by John will be more clear.

Regards,
Kishore

-----Original Message-----
From: Loughney John (NRC/Helsinki) 
Sent: 27. February 2002 13:08
To: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded

Hi All,

2.9 Diameter URI

port               = ":" 1*DIGIT

John

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 16:02:52 +0200

Hi Kishore,

> proposed by John will be more clear.

If that notation is more clear, then I am all for it.

John

---

From: <[email-masked]>
Date: Wed, 27 Feb 2002 16:28:25 +0200

Hi Jacques,

Can you comment on what I have proposed?  Is my seperation OK?

John

> From: ext Jacques Caron [mailto:[email-masked]]
> Sent: 27 February, 2002 15:59
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Hi John,
> Indeed, the URI (used in config files and in redirects to 
> find another 
> diameter server, possibly via DNS NAPTR, SRV etc.) and the 
> Identity (used 
> to uniquely identify a host for loop and duplicate connection 
> detection) 
> are two entirely different things.
> 
> You may want to look at the issue I filed a long time ago, 
> which proposes 
> the separation of the two, with a proposed DiameterIdentity format:
> 
> http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html
> 
> Of course, some of the text changes are not in sync with the 
> current text 
> anymore :-(
> 
> Jacques.
> 
> At 12:36 27/02/2002, [email-masked] wrote:
> >David,
> >
> > > So as you deal with your changes regarding how server 
> discovery works,
> > > keep in mind the AVPs of type DiameterIndentity which are 
> used for message
> > > routing and make sure their requirements are met, to wit:
> > >
> > >    "Diameter node", which is an instance of a Diameter 
> process running
> > >    on an IP host.
> > >
> > >    identifier in a domain.  Thus the type must not 
> contain any parameters
> >Thinking deeply about this, I have come to the conclusing 
> that the Diameter
> >URI, DNS discovery and DiameterIdentity are not the same 
> thing.  Therefore,
> >while these are related, we may need to seperate these 
> within the draft.
> >
> >Please comment on the text that I have sent to the list.
> >
> >John
> 
> 
> 
> _________________________________________________________
> 
> Do You Yahoo!?
> 
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 28 Feb 2002 21:26:32 +0200

Hi Jacques,

> What is the URI stuff doing here? It's not a URI, just a FQDN all by 
> itself. If you need the reference to [URI] just for the definition of 
> "fqdn" I think it's really ambiguous.

I'll remove the URI stuff then.

John

---

From: <[email-masked]>
Date: Thu, 28 Feb 2002 21:26:35 +0200

Hi Jacques,

> Right. Anything that "points to" a Diameter node is an URI. 
> Anything that  identifies a node is Identity.

Good point.

> Redirect-Host should be an URI, and actually be renamed 
> Redirect-URI for consistency.

I've changed the Redirect-host to be of type DiameterURI.

I'm leaving this name as Redirect-Host - at this point, I think it
is unnescessary to change the name & all associated names, and
probably will be more confusing.
 
> Route-Record, Origin-Host, Destination-Host and Proxy-Host should be 
> identities.

Agreed.
 
> Apparently Alternate-Host and Source-Route are no longer with 
> us, but if they come back, the first one is an URI and the second 
> an Identity.

Hopefully not.

John

---

From: <[email-masked]>
Date: Thu, 28 Feb 2002 21:26:34 +0200

Hi Jacques,

> "If a Diameter node can be identified by several FQDNs, one 
> single FQDN 
> should be picked at startup, and used as the only 
> DiameterIdentity for that 
> node, whatever the connection it is sent on."
> 
> It might not be a bad idea to add a sentence to explain what 
> it's used for, such as:
> "The DiameterIdentity value is used to uniquely identify a 
> Diameter node 
> for purposes of duplicate connection and routing loop detection".

I've added the text.

John

---

From: <[email-masked]>
Date: Thu, 28 Feb 2002 23:17:02 +0200

Hi David,

I think the change works for me.

John

> Sent: 28 February, 2002 23:15
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded
> 
> 
> I certainly do not want to add text specifying what operators 
> can do.  I am
> only interested in the protocol.  In this case, my concern is 
> that you don't
> over-specify the protocol in such a way as to unnecessarily limit an
> operator's options.  What I do request is that if there is no protocol
> requirement to resolve the fqdn, then you should relax the 
> requirement and
> specify that it "contains the fqdn of the Diameter node" 
> rather than that it
> "is the fqdn of the Diameter node".  Then operators can do 
> what they want.
> 
> > Hi Jacques & David,
> > I agree with Jacques. David, if you can carefully craft
> > text that fits your exact meaning, please do so.  Otherwise
> > lets leave the text as fqdn & if needed, provide additional
> > details in a BCP doc or something, as we are getting into
> > operation details.
> > 
> > John
> > 
> > > Sent: 28 February, 2002 02:56
> > > To: David Spence
> > > Cc: Loughney John (NRC/Helsinki); [email-masked];
> > > [email-masked]
> > > Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded
> > >
> > >
> > > Then you're really adding something to the "real" FQDN that
> > > is functionally
> > > equivalent to a port number :-)
> > >
> > > If you manage to write some text that explains that clearly and
> > > unambiguously, why not. But I think it's easier to stick to
> > > "real" FQDNs.
> > > It's never hurt anyone to register a couple of addresses 
> in the DNS.
> > >
> > > As an alternative, if the Identity is considered fully
> > > opaque, nothing
> > > prevents us to change it to FQDN;<anything-unique to the 
> host>. Where
> > > <anything unique to the host> may be a PID, a port number, a
> > > configuration
> > > file path name, or any other arbitrary string.
> > >
> > > Jacques.
> > >
> > > At 01:12 28/02/2002, David Spence wrote:
> > > >Actually, my idea was that the portion of the identity
> > > string following the
> > > >first dot would be a real host name registered to the host
> > > on which the
> > > >server was running.  In my example below, both servers were
> > > running on
> > > >srv.interlinknetworks.com, which is the real name of the
> > > host.  diam1 and
> > > >diam2 would be unregistered prefixes to a registered host name.
> > > >
> > > >Jacques Caron wrote:
> > > > >
> > > > > Even though the full name need not necessarily be in the
> > > DNS (though this
> > > > > might have other consequences?), it is necessary that it
> > > is based on a
> > > > > domain name that is registered and owned by the
> > > administrator of the
> > > > > server. Otherwise we'll end up with a bunch of
> > > "diameter.example.com" all
> > > > > over which are definitely not unique :-(
> > > > >
> > > > > I think it's easier if the fqdn is really registered,
> > > just for the purposes
> > > > > of ensuring uniqueness.
> > > > >
> > > > > Jacques.
> > > > >
> > > > > At 22:59 27/02/2002, David Spence wrote:
> > > > > >One question: Does it make any difference whether there
> > > is an A record for
> > > > > >the fqdn in the DNS, i.e., does the fqdn actually need to be
> > > > registered?  I
> > > > > >think not.  And if it doesn't, that makes it easier for
> > > administrators.
> > > > > >Suppose I run two Diameter servers on
> > > srv.interlinknetworks.com.  Then I
> > > > > >could configure one to call itself
> > > diam1.srv.interlinknetworks.com, and I
> > > > > >could configue the other to call itself
> > > diam2.srv.interlinknetworks.com.
> > > > > >Voila!  I have guaranteed uniqueness without having to
> > > register a domain
> > > > > >name.  If this is agreeable, it might be worth stating
> > > in the draft
> > > > that the
> > > > > >term fqdn does not imply that the name be registered,
> > > only that it be
> > > > > >unique.
> > > > >