Subject: [AAA-WG]: Issue 273 Resolution

From: <[email-masked]>
Date: Wed, 27 Feb 2002 13:10:27 +0200

Hi all,

Here is my proposed resolution on issue 27.  Please note that the IESG has review Diameter's use of SRV records and found them to be incorrect.  This is based on the currently approved method for using SRV records (see the SIP SRV document).

5.2  Diameter Peer Discovery

 . . . . 

3. The Diameter implementation performs a NAPTR query for a server in a particular realm.  The Diameter implementation has to know in advance which realm 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 The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "AAA+D2x" and "AAAS+D2X", where x is a letter that   corresponds to a transport protocol supported by the domain. This specification defines D2T for TCP and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transport protocol mappings.

These NAPTR records provide a mapping from a domain, to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports  multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [NAPTR], the client discards any records whose services fields are not applicable. For the purposes of this specification, several rules are defined. 

3.1 First, a client resolving a AAAS URI MUST discard any services that do not contain "AAAS" as the protocol in the service field. The converse is not true, however. A client resolving an AAA URI SHOULD retain records with "AAAS" as the protocol, if the client supports TLS. Second, a client MUST discard any service fields that identify a resolution  service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preference for its usage.

The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query.

3.3 If no NAPTR records are found, the requester queries for those address records for the destination address, '_diameters._sctp'.realm or '_diameters._tcp'.realm when using TLS or '_diameter._sctp'.realm or '_diameter._tcp'.realm when not using TLS. Address records include A RR's, AAAA 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. 

For NAPTR records with AAAS protocol fields, if the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack.

A dynamically discovered peer causes an entry in the Peer Table (see section 2.7) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.8) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value.

Add to references:

[NAPTR]	M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," Request for Comments 2915, Internet Engineering Task Force, Sept. 2000.
[TLSSCTP]	M. Tuexen, et al. "TLS over SCTP" IETF Work in Progress, November 2001.

Appendix B: NAPTR Example

As an example, consider a client that wishes to resolve aaa:example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
  
     ;;          order pref flags service           regexp  replacement
         IN NAPTR 20   50  "s"  "AAAS+D2S"          ""  _diameters._sctp.example.com.
         IN NAPTR 50   50  "s"  "AAA+D2S"           ""  _diameter._sctp.example.com.
         IN NAPTR 90   50  "s"  "AAAS+D2T"          ""  _diameters._tcp.example.com.
         IN NAPTR 100  50  "s"  "AAA+D2T"           ""  _diameter._tcp.example.com

This indicates that the server supports TLS over SCTP, SCTP, TLS over TCP, and TCP,  in that order. If the client supports TLS over SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of _diameters._sctp.example.com. That lookup would return:

     ;;          Priority Weight Port   Target
         IN SRV  0        1      5060   server1.example.com
         IN SRV  0        2      5060   server2.example.com