Individual Submission
Diameter Maintenance and                                        M. Jones
Internet-Draft
Extensions (DIME)                                    Bridgewater Systems
Internet-Draft                                               J. Korhonen
Updates: 3588 (if approved)                                  J. Korhonen                       Nokia Siemens Networks
Intended status: Standards Track                  Nokia Siemens Networks                             May 4, 2010
Expires: July 2, November 5, 2010                                  December 29, 2009

                        Diameter Extended NAPTR
                   draft-ietf-dime-extended-naptr-00
                   draft-ietf-dime-extended-naptr-01

Abstract

   This document describes an extended format for the NAPTR service
   fields 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].

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.

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

   This Internet-Draft will expire on July 2, November 5, 2010.

Copyright Notice
   Copyright (c) 2009 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 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  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Extended NAPTR Service Field  . . . Format . . . . . . . . . . . . . . 4
   4.  Extended NAPTR-based Diameter Peer Discovery  . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  IETF Diameter Application Service Tags  . . . . . . . . . . 6
     5.2.  Vendor-Specific Diameter Application Service Tags . . . . . 7
     5.3.  Diameter Application Protocol Tags  . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . 7 . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8 9

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.

   Section 11.6 of RFC 3588 defines the following NAPTR service fields:

         Services Field               Protocol
         AAA+D2T                       TCP
         AAA+D2S                       SCTP

   However, foreseen network topologies require border AAA nodes that
   will be specialized by Diameter application and the

   The extended NAPTR service
   field does not allow a usage for Diameter implementation to determine the
   application supported peer discovery defined by the AAA node.  Without this information, a
   Diameter implementation must connect and perform a capability
   negotiation with each candidate AAA node.
   document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic
   Delegation Discovery System (DDDS) Application defined in [RFC3958].
   This document addresses
   this problem by specifying an extended NAPTR service field format updates the Diameter peer discovery procedure described
   in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service
   and Application Procotol Tag values that permits permit the discovery of
   Diameter peers that support a specific Diameter application. 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 Extended NAPTR service field Service Field format defined by the S-NAPTR DDDS in
   [RFC3958] 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.

         naptr-svc-field     = "AAA+D2" < protocol> [ *appln-list ]

         protocol

       appln-svc-tag           = "T" iana-appln-tag / "S"
                               ; "T" for TCP and "S" for SCTP.

         appln-list experimental-appln-tag
       iana-appln-tag          = "+AP:" "aaa+ap" appln-id [ *( ","
       experimental-appln-tag  = "x-aaa+ap" appln-id ) ]
                               ; Comma separated list of application
                               ; identifiers prefixed by "+AP:".
       appln-id                = *DIGIT
                                 ; Application identifier expressed as a
                                 ; decimal integer.

   For example, a NAPTR

   As stated in [RFC3958], application service field value of:

   'AAA+D2S+AP:6'

      Means tags that start with "x-"
   are considered experimental, and no provision is made to prevent
   duplicate use of the Diameter node in the SRV record supports the
      Diameter Session Initiation Protocol (SIP) same string.  Implementors use them at their own
   risk.

   The S-NAPTR Application ('6') and
      SCTP as Protocol Tag ABNF specification for the
   discovery of Diameter agents supporting a specific Diameter transport protocol.

   'AAA+D2S+AP:6,1,5,4294967295'
   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'),
      NASREQ Application ('1'), EAP Application ('5') ('6')
      and SCTP as the transport protocol.

   The Diameter node also provides Relay
      functionality ('4294967295').

   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]).  The DNS administrator of some domain SHOULD also
   provision base 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 NAPTR
   S-NAPTR records as defined in this specification and legacy RFC 3588
   NAPTR records, then the extended NAPTR 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].  This specification extends 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.  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+D2X+AP:Y"
      "aaa+apX:Y" where "X" indicates the transport protocol Application Identifier and "Y"
      is a comma-separated list of Application Identifiers,
      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 and
         "Y" contains the required Application Identifier, 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 or "Y" does not contain the required Application
         Identifier,
         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].

         If "X" 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 continues processing the "flags" field. NAPTR as described in
         [RFC3588] and [RFC2915].

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

5.  IANA Considerations

   Section 11.6 of [RFC3588] defines a

5.1.  IETF Diameter Application Service Tags

   IANA registry for the NAPTR
   Services Field entries.  Although this document does not define a new
   transport protocol, it is proposed requested to add reserve the following entries to
   the S-NAPTR Application
   Service Tags for existing registry IETF Diameter applications:

          +------------------+----------------------------------+
          | 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 [I-D.ietf-dime-diameter-qos] |
          | aaa+ap4294967295 | Relay [RFC3588]                  |
          +------------------+----------------------------------+

   Editor's Note: Update the table with the RFC number assigned to reflect the extended format of
   Diameter QoS Application.

   Future IETF Diameter applications MUST reserve the NAPTR
   Services Field:

         Services Field               Protocol
         AAA+D2T+AP:x                  TCP
         AAA+D2S+AP:x                  SCTP

   Editor's Note: S-NAPTR
   Application Service Tag corresponding to the allocated Diameter
   Application ID.

5.2.  Vendor-Specific Diameter Application Service Tags

   Vendor-Specific Diameter Application IDs are allocated by IANA is currently missing
   according to the registry for "First Come First Served" policy and do not require
   an IETF specification.  However, the NAPTR S-NAPTR Application Service Fields 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 [RFC3588].  This oversight will need to be
   resolved for this document
   document, an RFC of any category MUST be published which reserves the
   S-NAPTR Application Service Tag corresponding to proceed. the Vendor-Specific
   Diameter Application ID.

5.3.  Diameter Application Protocol Tags

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

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

6.  Security Considerations

   This document specifies an enhancement to the RFC 3588 Diameter base
   protocol defined NAPTR service field format defined in and also modifications to
   the Diameter base protocol 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 NAPTR 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.

7.  References

7.1.  Normative References

   [I-D.ietf-dime-diameter-qos]
              Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A.,
              and G. Zorn, "Diameter Quality of Service Application",
              draft-ietf-dime-diameter-qos-15 (work in progress),
              March 2010.

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

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

7.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
   303 Terry Fox Drive, Suite 500
   Ottawa, Ontario  K2K 3J1
   Canada

   Email: mark.jones@bridgewatersystems.com mark@azu.ca

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   FINLAND

   Email: jouni.nospam@gmail.com