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

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 14 Jun 2001 17:19:51 -0500

> -----Original Message-----
> From: Jacques Caron [mailto:[email-masked]]
> 
...
> Rationale/Explanation of issue:
> 
> We need to clarify how two host descriptors are matched, e.g. in loop 
> matching. Options are:

1.
> - exact lexical match (strcmp)

2.
> - expand (add defaults such as diameter://, :port, and 
> ;transport=sctp), 
> then exact lexical match (or match on protocol+name+port+transport)

3.
> - expand name to IP addresses, and match on 
> protocol+IP+port+transport (if 
> name resolves to multiple IP addresses, any match between the two 
> expansions is a match)

The way I've implemented it is pretty much along the lines of your second
option. I have an independent match of each component, but the end result is
the same as a string compare with defaults added.  The first option is not
in the spirit of the default values, IMO.  I don't think I can provide a
real good reason as to why the third option is bad, I think I just prefer
the second.  The third may provide the most absolute identitifiability,
though.

> First is possible only if any given process picks a unique 
...
> received in CER/CEA in an AVP. It cannot work when the 
> DiameterIdentity 
> comes from another source (e.g. from a configuration file 
> listing peers).

Well, you would always get an identity from a peer once the connection was
established anyways.  If the identity they announce is different from the
one you used to locate them, you can take whatever action necessary, but if
the connection remains, the identity received from the peer should be
authoritative.

I was under the impression that the Diameter Identity was more of an
entity-distinction tool than an entity-location tool.  Not to say that it
couldn't function as both, but maybe its primary service should be the
former.

...
> Requested changes:
> 
> At the end of section 2.7, add:
>     The port and protocol listed above are those that a node uses to
>     listen for incoming connections.

More explicit, I like it.

>     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.

WRT SCTP's use of multiple addresses, this text is in 6.7:
(Doesn't correspond directly to what you're discussing, but it's related)
"All source addresses that a Diameter node expects to use with SCTP [26]
MUST be
advertised in the CER and CEA messages by including a Host-IP-Address
AVP for each address."

>     For the purposes of loop checking and other comparison 
> purposes, two
>     DiameterIdentity values match if they are lexically 
> identical (i.e.
>     the two strings are the same).

As long as you insert the relevant default values for fields where
necessary, ok.

"diameter://host.abc.com" should definitely match "host.abc.com", don't you
think?

-Brian