Subject: RE: [AAA-WG]: issue:236: DiameterIdentity

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 29 Nov 2001 11:36:35 -0600

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> 
> On Tue, Nov 27, 2001 at 02:03:16AM +0100, Johan Johansson wrote:
> > Of course they are, as is a shared secret and commonly a realm, but 
> > they're not part of the uri. They are configured in the surrounding 
> > peers. They also do not identify the peer and I'm not sure 
> the security 
> > does either. Can you really run both TLS and non-TLS 
> connections on the 
> > same port? Whether a node is using tcp or sctp or TLS is of 
> no interest 
> > what so ever to other than its peers, and yet it is sent in 
> all messages 
> > to other domains.

Well, I think I would disagree here.  Two Diameter entities could exist that
share an IP/port but not transport protocol.  TCP port 1812 is not the same
thing as SCTP port 1812.  However, you're correct -- TLS and non-TLS could
not simultaneously be used on a given port (for TCP or SCTP).  So, I believe
that transport protocol is an "identifying characteristic" of a diameter
entity, and does belong in the URI.

> no you cannot run both TLS and non-TLS on both ports, and the 
> base spec
> states that it requires two ports.
> 
> > Routing is done using information that is not inherently 
> more or less 
> > stable than security mechanism - supported applications - 
> and they are 
> > not part of the URI either. In fact we just devised a 
> mechanism by which 
> > this information can be updated without tearing down 
> connections and in 
> > doing so validating or invalidating routes.
> > 
> > What I am trying to get to in a rather roundabout way is 
> that there is a 
> > lot of information that you need to contact a certain node. The 
> > identifier should ... well.. identify it. Some information will 
> > inevitably need to be preconfigured or discovered by 
> surrounding peers. 
> > Note that the uri itself will need to be part of the 
> configuration of 
> > the surrounding peers, and thus the uri really only decides 
> a form that 
> > you can use to configure TLS, protocol and so on.
> > 
> > This doesn't of course stop the protocol from working, and 
> if you think 
> > you have all the parameters in it now that will ever be 
> needed - fine. 
> > As long as there's an upper bound on the length of a uri 
> I'm reasonably 
> > content.
> 
> Pardon the ignorance here... but my parser broke two 
> paragraphs ago. I believe
> what you are stating here is that the URI is not sufficient, 
> but it isn't
> clear what is missing. Folks that have implemented the 
> protocol seem to
> think that it is enough. 
> 
> Could you be a tad more specific on what you believe is missing?

I believe Johan's point is related to the fact that the presence or absence
of TLS is not an "identifying characteristic" of a Diameter node (important
because of the dual-duty the URIs perform -- connection information and
DiameterIdentity).  As you stated above, you cannot have both TLS and
non-TLS running at the same port, so knowing that the node supports TLS
would not distinguish it from one that did not.  While it's convenient to
have all of your connection parameters in one human-readable string, I think
he's trying to say that some of the parameters might not belong (on a global
scope, anyways).

e.g., compare

aaa://aaa.diameter.org:1812;transport-security=TLS

WITH

aaa://aaa.diameter.org:1812;transport-security=none

Would these URIs be equivalent or not?  Taken in the context of "is this one
diameter entity, or two different ones?"...(Ignoring the fact that they
couldn't coexist).

My feeling is that Johan has a point, the TLS-ness may be superfluous, but I
don't think it's too harmful to leave it in.  Encountering a situation like
the above would indicate some sort of fatal misconfiguration (and probably
should be noted).  And I'll restate -- the transport protocol is
significant, and *mustn't* be removed.

-Brian