Subject: [AAA-WG]: Issue 66: Server Discovery

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 13:10:58 -0700

All,

Following the discussion some of us had last week, I have made slight changes
to the proposed text for this issue. Please note section 3.3 below, where a
reference is made to the fqdn field of the diameterIdentity sub-type. I also
added A6s.

PatC

2.6  Diameter Agent Discovery

   Allowing for dynamic Diameter agent discovery will make it possible
   for simpler and more robust deployment of AAA services.  In order to
   promote interoperable implementations of Diameter agent discovery,
   the following mechanisms are described.  These are based on existing
   IETF standards.

   There are two cases where Diameter agent discovery may be performed.
   The first is when a Diameter client needs to discover a first-hop
   Diameter agent.  The second case is when a Diameter agent needs to
   discover another agent - for further handling of a Diameter
   operation. In both cases, the following 'search order' is
   recommended:

      1. The Diameter implementation consults its list of static
         (manual) configured Diameter agent locations.  These will be
         used if they exist and respond.

      2. The Diameter implementation uses SLPv2 [28] to discover
         Diameter services.  The Diameter service template [32] is
         included in Appendix A. It is recommended that SLPv2 security
         be deployed (this requires distributing keys to SLPv2 agents.)
         This is discussed further in Appendix A.

         SLPv2 will allow Diameter implementations to discover the
         location of Diameter agents in the local site, as well as their
         characteristics.  Diameter agents with specific capabilities
         (say support for the Mobile IP application) can be requested,
         and only those will be discovered.

      3. The Diameter implementation uses DNS to request the SRV RR [33]
         for the '_diameter._sctp' and/or '_diameter._tcp' server in a
         particular domain.  The Diameter implementation has to know in
         advance which domain to look for an Diameter agent in.  This
         could be deduced, for example, from the 'realm' in a NAI that
         an Diameter implementation needed to perform an Diameter
         operation on.

        3.1 If the destination address is a numeric IP address, the
            requestor contacts the peer at the given address and the
            port number specified in the SRV record or, if not
            specified, the default port (TBD).

        3.2 The results of the query or queries are merged and ordered
            based on priority. Then, the searching technique outlined in
            [46] is used to select servers in order. The requestor
            attempts to contact each peer in the order listed, at the
            port number specified in the SRV record. If none of the
            servers can be contacted, the requestor gives up. If there
            are no SRV records, DNS address records are used, as
            described below.

        3.3 If the destination specifies a port number other than TBD or
            if there are no SRV records, the requestor queries the DNS
            server for address records for the destination address using
            the FQDN field of the DiameterIdentity derived AVP data
            format (see section 4.4). Address records include A RR's,
            AAAA RR's, A6 RR's or other similar records, chosen
            according to the requestor's network protocol capabilities.

            If the DNS server returns no address records, the requestor
            gives up. If there are address records, the same rules as in
            step 3.2 apply.

         Requestors MUST NOT cache query results except according to the
         rules in [47]. Diameter allows AAA peers to protect the
         integrity and privacy of communication as well as to perform
         end-point authentication.  Still, it is prudent to employ DNS
         Security as a precaution when using DNS SRV RRs to look up the
         location of a Diameter agent.  [34, 35, 36]

---

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 22:32:36 +0200

Pat,

>             are no SRV records, DNS address records are used, as

In any of the above, a server should be able to contact the servers found 
only if they are in the peer table, right? Otherwise there is a problem 
with finding appropriate certificates.

BTW, some clarification as to the relationship of the whole mechanism to 
the peer and/or routing table (and the forwarding and routing processes 
defined in 5.x) would be helpful. I.e. are these processes used to add 
stuff to the peer table, or to add stuff to the routing table, which then 
makes use of the pre-defined peer table?

>             according to the requestor's network protocol capabilities.

Hu? What does "the FQDN field of the DiameterIdentity derived AVP data 
format" mean? What exactly should be looked up? The Destination-Realm? The 
FQDN part of the Destination-Host?

No comprendo mucho :-/

Jacques.

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

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 13:37:41 -0700

> with finding appropriate certificates.

There are alternate means of finding certificates.

> makes use of the pre-defined peer table?

ok, let me see what I can do.

> FQDN part of the Destination-Host?
Section 4.4 includes:

      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 ] [legacy-protocol]

            scheme-name        = "diameter://"
            ; If absent, the default is "diameter://"

            fqdn               = Fully Qualified Host Name

[...]

I was talking about the fqdn portion of this, which is used in Destination-Host,
Redirect-Host, etc.

I do, however, now realize that FQDN should NOT be capitalized to reflect the
text in section 4.4

> No comprendo mucho :-/

Make more sense?

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 22:59:22 +0200

[...]

>I was talking about the fqdn portion of this, which is used in 

I had guessed so, but exactly which AVP are we talking about? 
Destination-Host? Then this is not really discovery, but pretty much direct 
use of the FQDN in there, not much different from case 1, is it?

>I do, however, now realize that FQDN should NOT be capitalized to reflect the

I don't think that was the part that was a problem...

>Make more sense?

Not yet :-(

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 13:57:51 -0700

> use of the FQDN in there, not much different from case 1, is it?

To be honest, I don't frankly get this anymore than you do, and I think I need
to ask Bernard what he had in mind. If you are discovery servers, it implies 
you don't know who they are. If you have a host name, then use DNS.

So, thinking about this some more, I don't get this either, and will punt to
Bernard.

Bernard?

PatC