Diameter Maintenance and                                        M. Jones
Extensions (DIME)                                    Bridgewater Systems
Internet-Draft                                               J. Korhonen
Updates: 3588 (if approved)                       Nokia Siemens Networks
Intended status: Standards Track                               L. Morand
Expires: July 10, 2011                                       Orange Labs
                                                         January 6, 2011


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

Abstract

   The Diameter base protocol specifies mechanisms whereby a given realm
   may advertise Diameter nodes and the supported transport protocol.
   However, these mechanism 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 describes an
   improvement using an extended format for the Straightfoward-NAPTR
   (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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.



Jones, et al.             Expires July 10, 2011                 [Page 1]


Internet-Draft             dime-extended-naptr              January 2011


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 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 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.




















Jones, et al.             Expires July 10, 2011                 [Page 2]


Internet-Draft             dime-extended-naptr              January 2011


Table of Contents

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





























Jones, et al.             Expires July 10, 2011                 [Page 3]


Internet-Draft             dime-extended-naptr              January 2011


1.  Introduction

   The Diameter base protocol [RFC3588] specifies three mechanisms for
   the Diameter peer discovery.  One of these involves the Diameter
   implementation performing a 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 Straightfoward-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

   The NAPTR Service Field format defined by the S-NAPTR DDDS
   application in [RFC3958] follows this ABNF:

       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.

   This specification refines the "iana-registered-service" tag



Jones, et al.             Expires July 10, 2011                 [Page 4]


Internet-Draft             dime-extended-naptr              January 2011


   definition for the discovery of Diameter agents supporting a specific
   Diameter application as defined below.

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

   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.

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

   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:



Jones, et al.             Expires July 10, 2011                 [Page 5]


Internet-Draft             dime-extended-naptr              January 2011


   '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

   DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR
   records [RFC2915] 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.  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].

   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 NAI in the User-Name AVP or
      extracted from the Destination-Realm AVP.




Jones, et al.             Expires July 10, 2011                 [Page 6]


Internet-Draft             dime-extended-naptr              January 2011


   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 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+D2X" where "X" indicates the transport protocol, the target
      realm supports the NAPTR-based Diameter peer discovery defined in
      [RFC3588].

         If "X" matches a supported transport protocol, the Diameter
         implementation continues processing the NAPTR as described in
         [RFC3588] and [RFC2915].

         If "X" does not match a supported transport protocol, the
         Diameter implementation abandons the peer discovery.

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


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


7.  IANA Considerations






Jones, et al.             Expires July 10, 2011                 [Page 7]


Internet-Draft             dime-extended-naptr              January 2011


7.1.  IETF Diameter Application Service Tags

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

             +------------------+----------------------------+
             | Tag              | Diameter Application       |
             +------------------+----------------------------+
             | aaa+ap1          | NASREQ [RFC3588]           |
             | aaa+ap2          | Mobile IPv4 [RFC4004]      |
             | aaa+ap3          | Base Accounting [RFC3588]  |
             | aaa+ap4          | Credit Control [RFC4006]   |
             | aaa+ap5          | EAP [RFC4072]              |
             | aaa+ap6          | SIP [RFC4740]              |
             | aaa+ap7          | Mobile IPv6 IKE [RFC5778]  |
             | aaa+ap8          | Mobile IPv6 Auth [RFC5778] |
             | aaa+ap9          | QoS [RFC5866]              |
             | aaa+ap4294967295 | Relay [RFC3588]            |
             +------------------+----------------------------+

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

                 +----------------+----------------------+
                 | Tag            | Diameter Application |
                 +----------------+----------------------+
                 | aaa+ap16777250 | 3GPP STa [TS29.273]  |
                 | aaa+ap16777251 | 3GPP S6a [TS29.272]  |
                 | aaa+ap16777264 | 3GPP SWm [TS29.273]  |
                 | aaa+ap16777267 | 3GPP S9 [TS29.215]   |
                 +----------------+----------------------+

   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.







Jones, et al.             Expires July 10, 2011                 [Page 8]


Internet-Draft             dime-extended-naptr              January 2011


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

   +----------------+--------------------------------------------------+
   | Tag            | Diameter Application                             |
   +----------------+--------------------------------------------------+
   | aaa+ap16777281 | WiMAX Network Access Authentication and          |
   |                | Authorization Diameter Application (WNAAADA)     |
   |                | [WiMAX]                                          |
   | aaa+ap16777282 | WiMAX Network Accounting Diameter Application    |
   |                | (WNADA) [WiMAX]                                  |
   | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX]  |
   | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX]  |
   | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX]   |
   | aaa+ap16777286 | WiMAX Location Authentication Authorization      |
   |                | Diameter Application (WLAADA) [WiMAX]            |
   | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies    |
   |                | Diameter Application (WiMAX PCC-R3-P) [WiMAX]    |
   | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline     |
   |                | Charging Diameter Application (WiMAX PCC-R3-OFC) |
   |                | [WiMAX]                                          |
   | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline     |
   |                | Charging Prime Diameter Application (WiMAX       |
   |                | PCC-R3-OFC-PRIME) [WiMAX]                        |
   | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online      |
   |                | Charging Diameter Application (WiMAX PCC-R3-OC)  |
   |                | [WiMAX]                                          |
   +----------------+--------------------------------------------------+

   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



Jones, et al.             Expires July 10, 2011                 [Page 9]


Internet-Draft             dime-extended-naptr              January 2011


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

                      +------------------+----------+
                      | Tag              | Protocol |
                      +------------------+----------+
                      | diameter.tcp     | TCP      |
                      | diameter.sctp    | SCTP     |
                      | diameter.tls.tcp | TLS/TCP  |
                      +------------------+----------+


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 Avi Lior, Itsuma Tanaka and Lionel Morand for
   their comprehensive review comments.


10.  References

10.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Jones, et al.             Expires July 10, 2011                [Page 10]


Internet-Draft             dime-extended-naptr              January 2011


   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC4004]  Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
              P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
              August 2005.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application", RFC 4072,
              August 2005.

   [RFC4740]  Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
              Canales-Valenzuela, C., and K. Tammi, "Diameter Session
              Initiation Protocol (SIP) Application", RFC 4740,
              November 2006.

   [RFC5778]  Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
              and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
              Agent to Diameter Server Interaction", RFC 5778,
              February 2010.

   [RFC5866]  Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
              and G. Zorn, "Diameter Quality-of-Service Application",
              RFC 5866, May 2010.

   [TS29.215]
              3rd Generation Partnership Project, "3GPP TS 29.215;
              Technical Specification Group Core Network and Terminals;



Jones, et al.             Expires July 10, 2011                [Page 11]


Internet-Draft             dime-extended-naptr              January 2011


              Policy and Charging Control (PCC) over S9 reference point;
              Stage 3 (Release 8)",
               http://www.3gpp.org/ftp/Specs/html-info/29215.htm.

   [TS29.272]
              3rd Generation Partnership Project, "3GPP TS 29.272;
              Technical Specification Group Core Network and Terminals;
              Evolved Packet System;  Mobility Management Entity (MME)
              and Serving GPRS Support Node (SGSN) Related Interfaces
              Based on Diameter Protocol (Release 8)",
               http://www.3gpp.org/ftp/Specs/html-info/29272.htm.

   [TS29.273]
              3rd Generation Partnership Project, "3GPP TS 29.273;
              Technical Specification Group Core Network and Terminals;
              Evolved Packet System;  3GPP EPS AAA interfaces (Release
              8)",  http://www.3gpp.org/ftp/Specs/html-info/29273.htm.

   [WiMAX]    WiMAX Forum, "WiMAX Release 1.5",  http://
              www.wimaxforum.org/resources/documents/technical/T33.

10.2.  Informative References

   [RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
              (NAPTR) DNS Resource Record", RFC 2915, September 2000.


Authors' Addresses

   Mark Jones
   Bridgewater Systems

   Email: mark@azu.ca


   Jouni Korhonen
   Nokia Siemens Networks

   Email: jouni.nospam@gmail.com


   Lionel Morand
   Orange Labs

   Email: lionel.morand@orange-ftgroup.com






Jones, et al.             Expires July 10, 2011                [Page 12]