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

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

All,

Following a discussion with Bernard, I now understand what he wanted
fixed in this particular issue. Please see the proposed text below,
where the change is in sub-section 3.3. The new text simply states that
if SVR records aren't found, then other record types are used.

comments appreciated,

PatC
----
2.6  Diameter Agent Discovery

[...]
      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 a Diameter agent in.  This
         could be deduced, for example, from the 'realm' in a NAI that a
         Diameter implementation needed to perform a 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
            '_diameter._sctp'.domain or '_diameter._tcp'.domain. 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.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 15 Jun 2001 16:47:02 +0200

Hi,

Stupid question: isn't all this redundant with the RFC2782? Shouldn't we 
rather just point there for the whole scheme (look up the SRV RRs, how 
selection is done, then fall back to A RRs) rather than partially 
duplicating the thing? Duplication always makes me nervous, it leads to 
inconsistencies a bit too often :-(

Also, why does 3.3 below state that "if the port is other than TBD..."? The 
whole point of SRV RRs is to be able to specify alternate ports...

And maybe part of issue 83 (Clarify relationship of server discovery (SLP, 
DNS A, DNS SRV...) with
peer table and/or routing table) should actually be handled in this issue. 
I still don't know if the use of DNS is an extension to the routing table 
(map a realm to a peer, but the peer must already be in our peer table), or 
to the routing AND peer table (map a realm to a peer created on the fly). I 
would think it's the former, but that needs to be clarified. If it's the 
latter, we have the issue of establishing a security association between 
the two hosts...

Jacques.

>if SVR records aren't found, then other record types are used.

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

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 07:46:56 -0700

> inconsistencies a bit too often :-(

Not at all. RFC 2782 is a generic mechanism for locating SRV records,
and the text on this really enhances RFC 2782. The last section (3.3) is
what to do if no SRV records are found.

> whole point of SRV RRs is to be able to specify alternate ports...

Much of this text was stolen from SIP, and now that I re-read this again,
I see that this is not required, and will be removed.

> peer table and/or routing table) should actually be handled in this issue. 

Personally, I'd prefer to keep it as a separate issue.

> latter, we have the issue of establishing a security association between 

of course. Would you like me to take a shot at fixing #83?

Thanks,

PatC

---

From: Jacques Caron <[email-masked]>
Date: Fri, 15 Jun 2001 17:15:02 +0200

>what to do if no SRV records are found.

 From RFC2782:

         else

             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A

Indeed, they look up target, not _diameter.(_sctp|_tcp).target. Maybe they 
should change that :-)

The stupid question is: do we actually need the A thing? I guess it's more 
of a backwards compatibility thing (e.g. to make sure that 
http://www.foobar.com/ goes to the A for www.foobar.com if there is no SRV 
RR for _http._tcp.www.foobar.com). Since Diameter doesn't quite need 
that... Of course there is the issue of older DNS servers that don't 
support SRV RRs, but since other stuff like DNSSEC is recommended... (and 
of course it helps in the very simple case of only one server for a given 
realm).

>of course. Would you like me to take a shot at fixing #83?

Just after I finish by e-mail on #75.

Jacques.

---

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

> of course it helps in the very simple case of only one server for a given 

Bernard's main concern, is as you state, backward compatibility with
old non-SRV compliant DNS servers. I'll let you right it out with him
if you feel so inclined :)

> Just after I finish by e-mail on #75.

Sorry, does that mean you want to try, or should I?

Thanks,

PatC