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

From: David Spence <[email-masked]>
Date: Fri, 22 Feb 2002 13:54:38 -0500

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: Johan Johansson <[email-masked]>
Date: Fri, 22 Feb 2002 21:45:54 +0100

>   "transport=sctp".  So it discards the message.
Yes. I have been using transport security as my example in my concerns 
about the same problem that I have posted now and then for the last 
months. The only way to obey the spec as written is that everyone in the 
network runs the same protocol with the same security or that an 
artificial routing domain border is introduced.

>   ignored when doing routing matches against entries in the peer table.
Well, there is already a way to specify TLS. I'm not sure why he decided 
to introduce another way, but if I recall correctly it was related to 
how it was specified in sip. The effect is however the same.

I really don't see why nodes several hops would need to know how the 
next to last node connects to the last node, which is what in effect 
happens when you use sessions with state and use the Origin-Host of the 
received response as Destination-Host in subsequent requests. Making the 
URI simply that - an identifier - would at least make me happy.

j

---

From: Jacques Caron <[email-masked]>
Date: Sat, 23 Feb 2002 02:03:50 +0100

Hi,

I agree that the use of DiameterIdentity as it currently stands is a bad 
idea. See my mail from last august:

http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html

which became issue #114. The decision at the time as that the "protocol 
worked fine as it was".

I still think separating URIs (used to reference another host) and 
identities (to uniquely identify a host, e.g. for CER/CEA purposes) would 
make things a lot simpler, especially with the complexity Diameter URIs 
have gotten into...

Jacques.

>Rationale/Explanation of issue:

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: David Frascone <[email-masked]>
Date: Sat, 23 Feb 2002 00:24:10 -0600

Plus, implementations need to keep track of ipaddress+port to track incomming
connections too.  Since URIs can be spoofed, when a server gets a connection,
all it really knows is an IP address + port.  And, the IP address might
not have reverse resolution to anything meaningful :(

-Dave