Subject: [AAA-WG]: Issue 78: DiameterIdentity (host descriptor) matching & values

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 09:15:01 -0700

All,

Below is my proposed fix to close this issue.

Comments appreciated,

PatC
----
4.4  Derived AVP Data Formats

[editor's note: new text in the description following the port field,
and added a new paragraph at the end]

[...]
      DiameterIdentity
         The DiameterIdentity format is derived from the OctetString AVP
         Base Format.  It uses the UTF-8 encoding and has the same
         requirements as the UTF8String.  In addition, it must follow
         the Uniform Resource Identifiers (URI) syntax [29] rules
         specified below:

            Diameter-Identity  = [scheme-name] fqdn [ port ]
                                 [ transport ]

            scheme-name        = "aaa://" aaa-protocol "/"
            ; If absent, the default BASE for relative URI references
            ; is aaa://diameter/

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

            fqdn               = Fully Qualified Host Name

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

            transport          = ";transport=" ( "tcp" | "sctp" | "udp")
            ; If absent, the default SCTP [26] protocol is assumed.
            ; UDP is ONLY used when the protocol is set to RADIUS

            The following are examples of valid Diameter host identities:

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

         The first two forms are relative URI references, against the default
         base of aaa://diameter/.

         When comparing AVPs of this format, it is necessary to add any absent
         fields with the default values prior to the comparison. For example,
         diameter-host.abc.com would be expanded to
         aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp.

[...]

[editor's note: New last sentence]

5.4  Origin-Host AVP

   The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
   MUST be present in all Diameter messages. This AVP identifies the
   endpoint which originated the Diameter message, i.e. the access
   device, home server, or broker. Relay agents MUST NOT modify this
   AVP. The same identity used in the CER or CEA's Origin-Host AVP MUST
   be used in all subsequent messages that include an AVP containing the 
   Diameter node's identity.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 15 Jun 2001 18:42:34 +0200

Hi,

I think you need to clarify that if the server is listening on multiple 
ports/IPs/protocols, it MUST select a single identity and use it all the 
time (e.g. it should not send different identities to different peers). Cf 
the text I proposed in the issue submission.

And I don't think you actually need to add the missing parts if the 
DiameterIdentity is actually considered an opaque unique identifier (made 
unique by its syntax in the case of multiple processes on the same box) 
that should be string-matched. Mmmm... in fact it might be necessary when 
you try to look up a Redirect-Host in the peer table.

[as an aside, that leads to another interesting issue: if A sends request 
to B, B responds "redirect to C", A doesn't find C in its peer table (B 
sends a name/port/protocol different from the one(s) A knows), A connects 
to C and sends CER, C recognizes A and disconnects, then C should still 
send a CEA on the connection before closing it so that A knows that it was 
the C it already know, and A needs to add to its peer table the name of C 
that B gave him]

Actually, it might be good to clarify the two uses of the DiameterIdentity:
- as a unique opaque identifier (like Session-Id)
- as a way to designate a given Host (for the purposes of Redirect-Host, or 
in a peer/routing table config file)

Jacques.

>    Diameter node's identity.

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

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 10:58:39 -0700

> the text I proposed in the issue submission.

well, the first part isn't take care of, but the last one is. I'll add
the former.

> you try to look up a Redirect-Host in the peer table.

but if you have some local configuration, it MAY include the whole URI,
without any shortcuts, so not expanding would cause problems.

> the C it already know, and A needs to add to its peer table the name of C 

You've lost me here as to what the problem actually is, other than the CEA
is needed before you disconnect (I think that's what you are raising as an issue).

> - as a unique opaque identifier (like Session-Id)
So stating that it is unique on a given host is needed.

> in a peer/routing table config file)
I thought you opened another issue on this one, and would prefer to keep
issues separate.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 11:15:02 -0700

> So stating that it is unique on a given host is needed.

how about:

            port               = ":" 1*DIGIT
            ; One of the ports used to listen for incoming connections.
            ; If absent, the default Diameter port (TBD) is assumed.
            ; Since multiple Diameter processes on a single host cannot
            ; listen for incoming connections on the same port, the
            ; DiameterIdentity is guaranteed to be unique per host.

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

PatC

---

From: Paul Funk <[email-masked]>
Date: Fri, 15 Jun 2001 22:49:31 -0400

Pat,

The format you proposed doesn't follow the rules for generic URI syntax 
(RFC 2396). The scheme is the part that precedes the first colon, and the 
segment that follows double slash is supposed to be the fqdn, so you 
can't have a scheme like:

aaa://diameter

since "diameter" would be interpreted as an fqdn according to the 
standard rules.

Instead, how about:

	[scheme-name]  fqdn  [port]  [protocol]  [transport]

for example:

	aaa://server.acme.com;protocol=diameter;transport=sctp

This, of course, could be abbreviated to:

	server.acme.com

Note also that URIs can normally contain either an fqdn or an IP 
address. I think we want to discourage the use of IP addresses. 
Perhaps a statement like the following:

"Diameter implementations SHOULD (or MUST?) specify a host 
name in the fqdn, not an IP address. Use of IP address could 
complicate the expansion of URIs into a canonical form 
suitable for comparison."

Paul

>   Diameter node's identity.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Jacques Caron <[email-masked]>
Date: Sun, 17 Jun 2001 14:34:11 +0200

>without any shortcuts, so not expanding would cause problems.

That's valid only for matching Redirect-Hosts with existing sessions. But 
even in that case the match might not succeed.

>is needed before you disconnect (I think that's what you are raising as an 

That's an issue. The other issue is that there's a need to be able to 
associate multiple identities to a peer in the peer table, so that once A 
has discovered that the host B told it to redirect to is actually C (which 
A already knows and is connected to), it can use that information any other 
time that B tells it to redirect to it.

Let's take an example:

- diameter.isp1.net has a connection established to incoming.roaming.org 
and to diameter.isp2.net.
- diameter.isp1.net sends a requests to incoming.roaming.org.
- incoming.roaming.org replies to diameter.isp1.net: redirect to 
diameter.company.com.
- diameter.isp1.net connects to diameter.company.com, which actually is 
diameter.isp2.net, but diameter.isp1.net doesn't know it (yet)
- diameter.isp2.net receives the CER from diameter.isp1.net, and detects 
that there already is a connection [btw, imagine the first connection was 
established in the same direction: the election is a tie in this case...]. 
It sends back a CEA, and one of the two disconnects.
- diameter.isp1.net know knows that diameter.company.com == 
diameter.isp2.net. Two things here:
1. it must send the request that it wanted to send to diameter.company.com 
to diameter.isp2.net.
2. it must store the fact that diameter.company.com == diameter.isp2.net 
somewhere, so that later redirects to diameter.company.com go directly to 
diameter.isp2.net.

On a completely different note regarding the election process... What is to 
prevent a peer from sending a fake identity (knowing quite well that it is 
easy to force a win in an election) to get requests that are supposed to be 
going to another server? (even though using e2e security or things like EAP 
SRP would prevent much of the damage like stealing passwords etc, that 
still counts as a DoS attack).

It might thus be necessary to at least check that the name given resolves 
to the IP address of the remote end of the connection.

>So stating that it is unique on a given host is needed.

Yup.

>I thought you opened another issue on this one, and would prefer to keep

The issue here is just to state in the defintion of DiameterIdentity that 
there are two uses of it: one unique (which is opaque, and the format given 
here is only meant to make it unique; note that here strict string matching 
is enough), and one as an URI to point to another server (where it gets 
awfully more complex). It should be stated in 2.7, so there is no confusion 
later on.

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Sun, 17 Jun 2001 14:42:48 +0200

>             ; DiameterIdentity is guaranteed to be unique per host.

I'd rather move that to a distinct paragraph after the definition, as it 
applies not just to the port, but to the combination of transport, address, 
and port (a process might be listening on multiple different addresses 
and/or using different transports).

This is the text I had originally proposed in the issue submission:
>The port and protocol listed above are those that a node uses to listen 
>for incoming connections.
>
>When a process listens on multiple different addresses or ports or using 
>different protocols, it should select a single combination of those, and 
>always use the same value as its identity for the lifetime of all 
>connections to peers. This value should be sent in Origin-Host in CER/CEA 
>and other messages, used in Route-Record AVPs, and any other AVPs 
>containing DiameterIdentity.

However, there is an issue here with what I wrote in my previous post about 
checking that the host in the DiameterIdentity resolves correctly, in a 
scenario where a diameter proxy acts as a gateway between two routing domains.

Imagine diameter-gw.private.net is a gateway between the public Internet 
and a private network (with private addressing), for the purpose of 
proxying diameter messages.

It seems obvious that the gateway must present itself with a public 
name/address on the public side, and a private name/address on the private 
side. Which conflicts with the unique and constant identity...

Damn. Security sure is a tricky issue :-(

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 06:25:11 -0700

> and/or using different transports).

done

> Damn. Security sure is a tricky issue :-(

There is nothing in the protocol that disallows a diameter node from
advertising a different FQDN on different interfaces. The only rule is
that once you've advertised yourself, you MUST use the same identity 
throughout the connection.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 06:26:53 -0700

The proposal that I sent out followed a review by the IESG's URI advisors. 
Let me see what they think about the following, and we'll take it from
there.

Thanks,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 18 Jun 2001 15:42:54 +0200

>throughout the connection.

It's not yet in there, but that was something that I raised earlier and 
that you said you would fix. If you don't, then there is a problem to 
detect multiple connections (or loops) in some cases.

One option would be for a server to adverstise ALL its identities during 
CER/CEA exchange. And matching would be done on IP address+port+protocol, 
not string.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 06:45:53 -0700

> CER/CEA exchange. And matching would be done on IP address+port+protocol, 

Here's my preferred option (this is a fix for both issues you've raised
in this thread):

      DiameterIdentity

            port               = ":" 1*DIGIT

         The first two forms are relative URI references, against the
         default base of aaa://diameter/.

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

         A Diameter node MAY advertise different identities on each
         connection, via the CER and CEA's Origin-Host AVP, but the same
         identity MUST be used throughout the duration of a connection.

         When comparing AVPs of this format, it is necessary to add any
         absent fields with the default values prior to the comparison.
         For example, diameter-host.abc.com would be expanded to
         aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 18 Jun 2001 19:15:38 +0200

>          protocol, the DiameterIdentity is guaranteed to be unique per

The "unique per host" seems weirdish to me. I think you mean "unique for 
any process" (in the sense "no two processes can have the same identity", 
not in the sense "a process can have only one identity").

>          aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp.

Still think the identity must be the same accross all connections, not just 
contant on a single connection.

Let's step back a minute and examine exactly the needs for the 
DiamenterIdentity:

1. Provide loop checking
2. Provide duplicate connection detection
3. Provide designation of a Redirect-Host
4. Be used in Configuration files (peer tables and routing tables).
5. Not be "spoofable".

I think this resolves into the two cases I gave before:
a. a unique opaque identifier, constant for a given process accross all 
interfaces and peers (this works for 1 and 2, and also for 3 if there is a 
requirement that a redirector only send out DiameterIdentities received 
from the hosts it redirects to)
b. a general-purpose resolvable URI (for 4).

BTW, for the purposes of collision detection, you can look at RFC1771 (BGP) 
section 4.1, BGP Identifier, which deals with the same issue: it MUST be 
the same accross all interaces and peers.

a. and b. could actually be derived in two sections in the draft:
(i) a Diameter URI section, that is used to fully describe a Diameter peer 
(for configuration files...).
(ii) the DiameterIdentity AVP type, with uses the URI format since it 
provides uniqueness, with the added requirement of picking one single URI 
at startup, advertise it in CER/CEA messages, use it in Route-Record 
messages, and use only values received via CER/CEAs in redirects).

The only problem is 5 (the unspoofability). I think the only option here is 
some certification mechanism that can ensure that a host is who he pretends 
to be (at the application layer, as opposed to at the IP layer, which is 
provided by IPsec -- maybe TLS can help here, I'm not familiar with it 
enough to say). Something like a CA-signed DiameterIdentity may be needed.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 10:12:56 -0700

> not in the sense "a process can have only one identity").

unique per host means that no two processes, threads, or any other programming
technique, will allow two instances to advertise exactly the same thing. Unique
for any process means that two different processes could advertise the same
identity, and this would require that they somehow listen on the same port,
of the same transport, which is not possible.

> messages, and use only values received via CER/CEAs in redirects).

ok, but let's be clear that a single identity per process (across all 
interfaces) *will* not work in the NAT case that you provided earlier. In
these cases, a host would have different personalities based on whether
the connection was established on the internal vs. external network.

> enough to say). Something like a CA-signed DiameterIdentity may be needed.

TLS will help here.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 18 Jun 2001 23:50:22 +0200

>of the same transport, which is not possible.

Why just "unique per host" and not simply "unique"?

>the connection was established on the internal vs. external network.

It will work (really, consider it as a unique opaque identifier. It might 
be a random number, it would work the same) unless one wishes to check that 
the address provided matches back (a la reverse + forward DNS checking), 
which raises the issue below.

> > enough to say). Something like a CA-signed DiameterIdentity may be needed.

Looks like I have some more reading to stack up on my pile :-(

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 07:00:27 -0700

> Why just "unique per host" and not simply "unique"?

Does anyone else favor Jacques proposed of changing "unique per host" to "unique"?

> which raises the issue below.

sure, it could be random, but a port number is guaranteed to be unique, so 
why bother with a perhaps conflicting random number???

PatC

---

From: David Frascone <[email-masked]>
Date: Tue, 19 Jun 2001 09:21:16 -0500

On Tue, Jun 19, 2001 at 07:00:27AM -0700, Pat Calhoun wrote:
> > > > >          protocol, the DiameterIdentity is guaranteed to be unique per> > > > >          host.
> > > >
> > > > The "unique per host" seems weirdish to me. I think you mean "unique for> > > > any process" (in the sense "no two processes can have the same identity",
> > >for any process means that two different processes could advertise the same> > >identity, and this would require that they somehow listen on the same port,> > >of the same transport, which is not possible.
> > 

I'm against the change.  "unique" implies that it is unique everywhere, which
is impossible to implement.

-Dave

---

From: Jacques Caron <[email-masked]>
Date: Tue, 19 Jun 2001 16:54:16 +0200

>why bother with a perhaps conflicting random number???

I didn't say we should use a random number. I was just pointing out the 
nature of the identifier: unique and opaque. Its uniqueness is derived from 
its syntax, but the syntax has no particular meaning otherwise in this 
context, so it is completely irrelevant whether the remote host 
"understands it". It would only be a problem if there was some way to 
actually check it, but since this will be done using crypto rather than IP 
addressing/routing, it's not an issue.

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Tue, 19 Jun 2001 16:58:29 +0200

>is impossible to implement.

It is unique if we assume the FQDN is unique for any given host. Indeed it 
might not be, but that's the original intent, otherwise the whole thing 
just doesn't work. The diameteridentity, as used in CER/CEA and 
Route-Record MUST be globally unique.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 07:50:27 -0700

> addressing/routing, it's not an issue.

So I can close this one, right?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 07:52:09 -0700

> Route-Record MUST be globally unique.

true an FQDN is unique, but some clustering or fault-torelant systems
may employ clever schemes to make a multiple boxes look like a single one.
So, unique (or even unique per host) is relative.

:(

PatC