Subject: [AAA-WG]: Why include transport-security in DiameterIdentity?

From: Don Zick <[email-masked]>
Date: Mon, 04 Feb 2002 14:34:22 -0500

transport-security ("none" or "TLS") was added to the DiameterIdentity
octetstring in the latest draft of the Diameter base protocol. Why was
this added? The text below is from section 4.4:

 Since multiple Diameter processes on a single host cannot
 listen for incoming connections on the same port on a given
 protocol, the DiameterIdentity of any process is guaranteed to
 be unique.

The FQDN, port, and transport fields in the DiameterIdentity already
uniquely identify a specific Diameter process running on a host. Isn't
the purpose of the DiameterIdentity to uniquely identify a Diameter node
(and not to provide additional information about connections)?

Section 4.4 also 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...

If a Diameter node MUST advertise the same identity on all connections
and it supports TLS and non-TLS connections, what should it advertise
for transport-security?

Please tell me why we're better off with transport-security of none or
TLS included in the DiameterIdentity.

Thanks,
Don

---

From: Johan Johansson <[email-masked]>
Date: Mon, 04 Feb 2002 22:46:24 +0000

There was an attempt at discussing this a couple of months ago but the
discussion just fizzled. Personally I agree with you completely. I think
the opposing view was that with the transport parameter you would need
no additional configuration to contact a diameter node.

If you are not allowed to advertise more than one uri an entire either
all nodes in a diameter network use TLS or no nodes do. TLS or not is
IMO a property of a connection between two nodes and not inherent in the
node itself.

j

---

From: David Frascone <[email-masked]>
Date: Mon, 4 Feb 2002 16:00:40 -0600

I think it's even a bigger problem than that.  When you advertise your
diameter identity, do you always use the parameters based on how the connection
was made?  It seems a little redundant.  

For example:  A peer connects to another server via tcp w/o TLS.  Do you
advertise your tcp parameters?  Or tls or sctp?  If not, then why send your
diameter identity at all?  The server knows how to connect to you.  With
the exception of the port, all that is already included in the message.

Perhaps you should be allowed to list several Origin-Host fields in some
order of priority?  That way, you could advertise all your possible contact
scenarios, and peers could choose to re-connect with a more appropriate
connection.

i.e. Original connection via tcp, new connection via SCTP with TLS enabled.

---

From: Don Zick <[email-masked]>
Date: Mon, 04 Feb 2002 17:45:31 -0500

Thanks for some explanation of the rationale for adding transport-security.
I hadn't thought of 'discovering' a Diameter node by examining its
DiameterIdentity.

Section 5.2 of the base draft (Diameter Peer Discovery) describes a variety
of ways in which a Diameter node can discover its peers. The base draft does
not to my knowledge suggest that peers can be discovered by examining
DiameterIdentity strings that are seen by a Diameter node.  Given that there
are other (better) ways to discover peers, I think that the protocol can be
simplified by removing transport-security from the DiameterIdentity.  The
DiameterIdentity can then simply be used to uniquely identify a Diameter
node.