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

From: Jacques Caron <[email-masked]>
Date: Wed, 27 Feb 2002 14:59:09 +0100

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:
> >
> > 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.
>
>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: David Spence <[email-masked]>
Date: Wed, 27 Feb 2002 10:58:27 -0500

Yes, this issue is about the same thing.  If this issue had been resolved as
you proposed, we wouldn't be dealing with it again now.

I do have one question about your DiameterIdentity proposal.  You included a
field for transport protocol.  I think you would have to require that the
same identity is used in all Diameter messages even if the Diameter node had
multiple peers using multiple transport protocols.  But with that
requirment, it would be o.k.  I don't have time just now to research what
the resolution to your issue was, but I do think that had the issue been
accepted, we wouldn't need to be discussing it now.

---

From: Jacques Caron <[email-masked]>
Date: Wed, 27 Feb 2002 17:06:27 +0100

Hi David,

>you proposed, we wouldn't be dealing with it again now.

Indeed. It was felt at the time that "things worked OK like they were and 
the change was not needed". Apparently it came back to bite us :-)

>accepted, we wouldn't need to be discussing it now.

The idea (which might not have been expressed clearly in the proposed 
changes) is that a process should, on startup, pick one of the connections 
it's listening on. Anyone. For some servers the choice is easy (listening 
on one single IP, one single port, one single protocol). For others which 
listen on multiple IPs, ports, or protocols, they just pick one.

Then they use that one to build their DiameterIdentity, and use it as long 
as the process exists to identify themselves, whatever the connection it's 
used on (since the goal is to identify a process, not a connection).

Jacques.

---

From: Don Zick <[email-masked]>
Date: Wed, 27 Feb 2002 11:48:39 -0500

I am not in favor of advertising a DiameterIdentity over a connection if the
DiameterIdentity does not reflect settings actually used on the connection.

I think the DiameterIdentity used to be an FQDN.  There was concern that
multiple Diameter nodes on a host could not be uniquely identified, so the
DiameterIdentity changed to be FQDN plus port plus protocol.  More recently,
transport security was added to the DiameterIdentity.

I'd like to consider changing DiameterIdentity back to being an FQDN.

Proposed Text:

A Diameter node must be uniquely identified by its DiameterIdentity, which is an
FQDN.  If multiple Diameter nodes run on the same host, each Diameter node
MUST be assigned a unique DiameterIdentity.

End Proposed Text

This solves the problem of uniquely identifying Diameter nodes running on a
single host and keeps the DiameterIdentity simple.

The URI syntax (or something similar) is still required for Diameter Peer
Discovery, but not for the DiameterIdentity.

Sorry for suggesting this at this late date, but I wonder what others think.

Don Z.

---

From: David Frascone <[email-masked]>
Date: Wed, 27 Feb 2002 10:58:15 -0600

I like this.  Much simpler.  

-- 
David Frascone

                  I failed attitude in school.

---

From: Jacques Caron <[email-masked]>
Date: Wed, 27 Feb 2002 18:04:37 +0100

>DiameterIdentity does not reflect settings actually used on the connection.

Other than the issue of checking the "validity" of the identity received, I 
think the DiameterIdentity should really be considered as an opaque unique 
identifier. The exact contents are totally irrelevant, as long as:
- the identity is unique
- the identity is constant for a given process

Anything that matches this is OK.  Really, it might just be a random number 
selected at startup, if that provided enough uniqueness. And the more 
"opaque" it looks, the less chances somebody will try to use it for what it 
isn't, but that's really cosmetic.

>MUST be assigned a unique DiameterIdentity.

This does indeed meet the requirements. Note that the identity should in my 
opinion really be just the FQDN, without any "aaa://" prefix to avoid 
confusion.

Jacques.