Diameter S-NAPTR Usage
draft-ietf-dime-extended-naptr-08

Abstract

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates [RFC3588] and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 10, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Extended NAPTR Service Field Format
• 3.1. IETF Standard Track Diameter Applications
• 3.2. Vendor-specific Diameter Applications
• 4. Backwards Compatibility
• 5. Extended NAPTR-based Diameter Peer Discovery
• 6. Usage Guidelines
• 7. IANA Considerations
• 7.1. IETF Diameter Application Service Tags
• 7.2. 3GPP Diameter Application Service Tags
• 7.3. WiMAX Forum Diameter Application Service Tags
• 7.4. Vendor-Specific Diameter Application Service Tags
• 7.5. Diameter Application Protocol Tags
• 8. Security Considerations
• 9. Acknowledgments
• 10. Editor's Notes
• 11. References
• Authors' Addresses

1. Introduction

The Diameter base protocol [RFC3588] specifies three mechanisms for the Diameter peer discovery. One of these involves the Diameter implementation performing a Naming Authority Pointer (NAPTR) query [RFC3403] for a server in a particular realm. These NAPTR records provide a mapping from a domain, to the SRV record [RFC2782] or A/AAAA record [RFC1035][RFC3596] for contacting a server with the specific transport protocol in the NAPTR services field.

The extended NAPTR usage for Diameter peer discovery defined by this document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic Delegation Discovery System (DDDS) Application defined in [RFC3958]. This document updates the Diameter peer discovery procedure described in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service and Application Protocol Tag values that permit the discovery of Diameter peers that support a specific Diameter application and transport protocol.

2. Terminology

The Diameter base protocol specification (Section 1.4 of [RFC3588]) and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 in [RFC3958]) define the terminology used in this document.

3. Extended NAPTR Service Field Format

    service-parms = [ [app-service] *(":" app-protocol)]
    app-service   = experimental-service  / iana-registered-service
    app-protocol  = experimental-protocol / iana-registered-protocol
    experimental-service      = "x-" 1*30ALPHANUMSYM
    experimental-protocol     = "x-" 1*30ALPHANUMSYM
    iana-registered-service   = ALPHA *31ALPHANUMSYM
    iana-registered-protocol  = ALPHA *31ALPHANUMSYM
    ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
    DIGIT         =  %x30-39 ; 0-9
    SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
    ALPHANUMSYM   =  ALPHA / DIGIT / SYM
    ; The app-service and app-protocol tags are limited to 32
    ; characters and must start with an alphabetic character.
    ; The service-parms are considered case-insensitive.
  

The NAPTR Service Field format defined by the S-NAPTR DDDS application in [RFC3958] follows this Augmented Backus-Naur Form (ABNF, [RFC5234]):

    iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM
    aaa-service             = "aaa+ap" appln-id
    appln-id                = 1*DIGIT
                              ; Application identifier expressed as a
                              ; decimal integer.
  

This specification refines the "iana-registered-service" tag definition for the discovery of Diameter agents supporting a specific Diameter application as defined below.

    iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
    aaa-protocol             = "diameter." aaa-transport
    aaa-transport            = "tcp" / "sctp" / "tls.tcp"
  

This specification also refines the "iana-registered-protocol" tag definition for the discovery of Diameter agents supporting a specific Diameter transport protocol as defined below.

The maximum length of the NAPTR service field is 256 octets including one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 of [RFC1035]).

3.1. IETF Standard Track Diameter Applications

A Diameter agent MUST be capable of using the extended S-NAPTR Application Service Tag for dynamic discovery of a Diameter agent supporting Standard Track applications. Therefore, every IETF Standard Track Diameter application MUST be associated with a "aaa-service" tag formatted as defined in this specification and allocated in accordance with the IANA policy (see Section 7).

For example, a NAPTR service field value of:

'aaa+ap6:diameter.sctp'

Means that the Diameter node in the SRV or A/AAAA record supports the Diameter Session Initiation Protocol (SIP) Application ('6') and SCTP as the transport protocol.

3.2. Vendor-specific Diameter Applications

S-NAPTR Application Service and Application Protocol Tag values can also be used to discover Diameter peers that support a vendor-specific Diameter application. In this case, the vendor-specific Diameter application MUST be associated with a "aaa-service" tag formatted as defined in this specification and allocated in accordance with the IANA policy (see Section 7).

For example, a NAPTR service field value of:

'aaa+ap16777251:diameter.sctp'

Means that the Diameter node in the SRV or A/AAAA record supports the Diameter 3GPP S6a Application ('16777251') and SCTP as the transport protocol.

4. Backwards Compatibility

Domain Name System (DNS) administrators SHOULD also provision legacy RFC 3588 style NAPTR records [RFC3403] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers. If the DNS administrator provisions both extended S-NAPTR records as defined in this specification and legacy RFC 3588 NAPTR records, then the extended S-NAPTR records MUST have higher priority (e.g. lower order and/or preference values) than legacy NAPTR records.

5. Extended NAPTR-based Diameter Peer Discovery

The Diameter Peer Discovery principles are described in Section 5.2 of [RFC3588]. This specification updates the NAPTR query procedure in the Diameter peer discovery mechanism by allowing the querying node to determine which applications are supported by resolved Diameter peers.

The extended format NAPTR records provide a mapping from a domain to the SRV record or A/AAAA record for contacting a server supporting a specific transport protocol and Diameter application. The resource record will contain an empty regular expression and a replacement value, which is the SRV record or the A/AAAA record for that particular transport protocol.

The assumption for this mechanism to work is that the DNS administrator of the queried domain has first provisioned the DNS with extended format NAPTR entries. The steps below replace the NAPTR query procedure steps in Section 5.2 of [RFC3588].

a.

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 and which Application Identifier it is interested in. For example, the realm could be deduced from the Network Access Identifier (NAI) in the User-Name AVP or extracted from the Destination-Realm AVP.

b.

If the returned NAPTR service fields contain entries formatted as "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" indicates the supported transport protocol(s), the target realm supports the extended format for NAPTR-based Diameter peer discovery defined in this document.

If "X" contains the required Application Identifier and "Y" matches a supported transport protocol, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field.

If "X" does not contain the required Application Identifier or "Y" does not match a supported transport protocol, the Diameter implementation abandons the peer discovery.

c.

If the returned NAPTR service fields contain entries formatted as "aaa+apX" where "X" indicates the Application Identifier, the target realm supports the extended format for NAPTR-based Diameter peer discovery defined in this document.

If "X" contains the required Application Identifier, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using all supported transport protocols following the order specified in section 2.1 of [RFC3588].

If "X" does not contain the required Application Identifier, the Diameter implementation abandons the peer discovery.

d.

If the returned NAPTR service fields contain entries formatted as "aaa:X" where "X" indicates the supported transport protocol(s), the target realm supports Diameter but does not support the extended format for NAPTR-based Diameter peer discovery defined in this document.

If "X" matches a supported transport protocol, the Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field.

e.

If the returned NAPTR service fields contain entries formatted as "aaa", the target realm supports Diameter but does not support the extended format for NAPTR-based Diameter peer discovery defined in this document. The Diameter implementation resolves the "replacement" field entry to a target host using the lookup method appropriate for the "flags" field and attempts to connect using all supported transport protocols following the order specified in section 2.1 of [RFC3588].

f.

If the target realm does not support NAPTR-based Diameter peer discovery, the client proceeds with the next peer discovery mechanism described in Section 5.2 of [RFC3588].

6. Usage Guidelines

Diameter is a peer to peer protocol whereas most of the applications that extend the base protocol behave like client/server applications. The role of the peer is not advertised in the NAPTR tags and not even communicated during Diameter capability negotiation (Capabilities-Exchange-Request and Capabilities-Exchange-Answer message exchange). For this reason, NAPTR-based Diameter peer discovery for an application defining client/server roles should only be used by a client to discover servers.

7. IANA Considerations

7.1. IETF Diameter Application Service Tags

IANA is requested to reserve a value of "aaa" for Diameter in the S-NAPTR Application Service Tag registry created by [RFC3958]. IANA is also requested to reserve the following S-NAPTR Application Service Tags for existing IETF Diameter applications in the same registry.

Future IETF Diameter applications MUST reserve the S-NAPTR Application Service Tag corresponding to the allocated Diameter Application ID as defined in Section 3.

7.2. 3GPP Diameter Application Service Tags

IANA is requested to reserve the following S-NAPTR Application Service Tags for existing 3GPP Diameter applications in the S-NAPTR Application Service Tag registry created by [RFC3958].

Future 3GPP Diameter applications can reserve entries in the S-NAPTR Application Service Tag registry created by [RFC3958] which correspond to the allocated Diameter Application IDs as defined in Section 3.

7.3. WiMAX Forum Diameter Application Service Tags

IANA is requested to reserve the following S-NAPTR Application Service Tags for existing WiMAX Forum Diameter applications in the S-NAPTR Application Service Tag registry created by [RFC3958].

Future WiMAX Forum Diameter applications can reserve entries in the S-NAPTR Application Service Tag registry created by [RFC3958] which correspond to the allocated Diameter Application IDs as defined in Section 3.

7.4. Vendor-Specific Diameter Application Service Tags

Vendor-Specific Diameter Application IDs are allocated by IANA according to the "First Come First Served" policy and do not require an IETF specification. However, the S-NAPTR Application Service Tag registry created by [RFC3958] defines a registration policy of "Specification Required" with a further stipulation that the "specification" is an RFC (of any category). If a Vendor-Specific Diameter Application requires the functionality defined in this document, an RFC of any category MUST be published which reserves the S-NAPTR Application Service Tag corresponding to the Vendor-Specific Diameter Application ID as defined in Section 3.

7.5. Diameter Application Protocol Tags

IANA is requested to reserve the following S-NAPTR Application Protocol Tags for the Diameter transport protocols in the S-NAPTR Application Protocol Tag registry created by [RFC3958].

8. Security Considerations

This document specifies an enhancement to RFC 3588 Diameter base protocol defined NAPTR service field format and also modifications to the NAPTR processing logic defined. The enhancements and modifications are based on the S-NAPTR, which is actually a simplification of the NAPTR, and therefore the same security considerations described in RFC 3588 are applicable to this document. No further extensions are required beyond the security mechanisms offered by RFC 3588. However, a malicious host doing S-NAPTR queries learns applications supported by Diameter agents in a certain realm faster, which might help the malicious host to scan potential targets for an attack more efficiently when some applications have known vulnerabilities.

9. Acknowledgments

We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel Morand and Sebastien Decugis for their comprehensive review comments.

10. Editor's Notes

This section to be removed prior to publication.

This draft updates sections of RFC3588 that are also being updated by RFC3588bis. At the time this draft was started, it was uncertain whether RFC3588bis would be published first. The authors of this draft decided to proceed optimistically assuming this draft would be published first with the understanding that minor updates are required if this is not the case.

The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa:diameter.sctp") were also contributed to RFC3588bis to ensure that it would be functionally complete if it got published first and this draft would come along later to add the application-specific S-NAPTR entries (e.g."aaa+ap5:diameter.sctp").

Depending on the publication order, the S-NAPTR Application Service Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need to be removed either from this draft or RFC3588bis.

11. References

Authors' Addresses