Diameter Extended NAPTR
draft-ietf-dime-extended-naptr-02

Abstract

This document describes an extended format for the S-NAPTR Application Service Tag used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 March 6, 2011.

Copyright Notice

Copyright (c) 2010 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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
2.  Terminology
3.  Extended NAPTR Service Field Format
4.  Extended NAPTR-based Diameter Peer Discovery
5.  Usage Guidelines
6.  IANA Considerations
    6.1.  IETF Diameter Application Service Tags
    6.2.  Vendor-Specific Diameter Application Service Tags
    6.3.  Diameter Application Protocol Tags
7.  Security Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

The Diameter base protocol [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) specifies three mechanisms for the Diameter peer discovery. One of these involves the Diameter implementation performing a NAPTR query [RFC3403] (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) for a server in a particular realm. These NAPTR records provide a mapping from a domain, to the SRV record [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) or A/AAAA record [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)[RFC3596] (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.) 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 Straightfoward-NAPTR (S-NAPTR) Dynamic Delegation Discovery System (DDDS) Application defined in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.). This document updates the Diameter peer discovery procedure described in Section 11.6 of [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) and defines S-NAPTR Application Service and Application Procotol 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 RFC 3588) defines most of the terminology used in this document.

3.  Extended NAPTR Service Field Format

The NAPTR Service Field format defined by the S-NAPTR DDDS in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) consists of a S-NAPTR Application Service tag and a S-NAPTR Application Protocol tag delimited by a single colon (":") character.

The S-NAPTR Application Service Tag ABNF specification for the discovery of Diameter agents supporting a specific Diameter application is show below.

    appln-svc-tag           = iana-appln-tag / experimental-appln-tag
    iana-appln-tag          = "aaa+ap" appln-id
    experimental-appln-tag  = "x-aaa+ap" appln-id
    appln-id                = *DIGIT
                              ; Application identifier expressed as a
                              ; decimal integer.

As stated in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.), application service tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk.

The S-NAPTR Application Protocol Tag ABNF specification for the discovery of Diameter agents supporting a specific Diameter transport protocol is shown below.

    appln-protocol-tag  = "diameter." app-protocol
    app-protocol        = "tcp" / "sctp" / "tls.tcp"

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.

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] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)). The DNS administrator of some domain SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] (Mealling, M. and R. Daniel, “The Naming Authority Pointer (NAPTR) DNS Resource Record,” September 2000.) 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.

4.  Extended NAPTR-based Diameter Peer Discovery

The basic Diameter Peer Discover principles are described in Section 5.2 of [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). 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. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different Services Field value and potentially different list of supported Diameter applications.

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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

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. The realm could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on.

b.

If the returned NAPTR service fields contain entries formatted as "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" indicates the transport protocol, 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 transport protocol supported by the client, the client 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 transport protocol supported by the client, the peer discovery is abandoned.

c.

If the returned NAPTR service fields contain entries formatted as "AAA+D2X" where "X" indicates the transport protocol, the target realm supports the NAPTR-based Diameter peer discovery defined in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

If "X" matches a transport protocol supported by the client, the client continues processing the NAPTR as described in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) and [RFC2915] (Mealling, M. and R. Daniel, “The Naming Authority Pointer (NAPTR) DNS Resource Record,” September 2000.).

If "X" does not match a transport protocol supported by the client, the peer discovery is abandoned.

d.

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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).

5.  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 (CER/CEA). 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.

6.  IANA Considerations

6.1.  IETF Diameter Application Service Tags

IANA is requested to reserve the following S-NAPTR Application Service Tags for existing IETF Diameter applications:

Future IETF Diameter applications MUST reserve the S-NAPTR Application Service Tag corresponding to the allocated Diameter Application ID.

6.2.  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] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) 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.

6.3.  Diameter Application Protocol Tags

IANA is requested to reserve the following S-NAPTR Application Protocol Tags for the Diameter transport protocols:

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

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses