One document matched: draft-ietf-dime-extended-naptr-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC2915 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2915.xml'>
<!ENTITY RFC3403 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml'>
<!ENTITY RFC1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY RFC2782 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml'>
<!ENTITY RFC3596 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3596.xml'>
<!ENTITY RFC3958 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml'>
<!ENTITY RFC4004 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4004.xml'>
<!ENTITY RFC4006 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml'>
<!ENTITY RFC4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY RFC4740 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4740.xml'>
<!ENTITY RFC5778 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5778.xml'>
<!ENTITY RFC5866 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5866.xml'>
]>


<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-ietf-dime-extended-naptr-03"
     ipr="pre5378Trust200902"
     updates="3588">
  <front>
    <title abbrev="dime-extended-naptr">Diameter Extended NAPTR</title>

    <author fullname="Mark Jones" initials="M" surname="Jones">
      <organization>Bridgewater Systems</organization>

      <address>
        <email>mark@azu.ca</email>
      </address>
      </author>

      <author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
         <organization>Nokia Siemens Networks</organization>
         <address>
            <email>jouni.nospam@gmail.com</email>
         </address>
      </author>

    <date year="2010" />

    <area>Operations and Management</area>

    <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>

    <keyword>NAPTR</keyword>

    <keyword>Diameter</keyword>

    <keyword>Services Field</keyword>

    <keyword>Peer Discovery</keyword>

    <abstract>
      <t>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 in order to discover which one supports
      a 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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Diameter base protocol <xref target="RFC3588"/> 
      specifies three mechanisms for the Diameter peer discovery. One of these 
      involves the Diameter implementation performing a NAPTR query <xref 
      target="RFC3403"/> for a server in a particular realm. 
      These NAPTR records provide a mapping from a domain, to the SRV record 
      <xref target="RFC2782"/> or A/AAAA record <xref target="RFC1035"/><xref target="RFC3596"/> for contacting a server with the specific
      transport protocol in the NAPTR services field. </t>
      <t>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 
      <xref target="RFC3958"/>. This document updates the Diameter peer 
      discovery procedure described in Section 11.6 of <xref target="RFC3588"/> 
      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. 
      </t>
    </section>

    <section title="Terminology">
      <t>The Diameter base protocol specification (Section 1.4 of 
      <xref target="RFC3588"/>) and the Straightforward-NAPTR (S-NAPTR) DDDS
      application (section 2.1 in <xref target="RFC3958"/>) define the terminology
      used in this document.</t>
    </section>

    <section title="Extended NAPTR Service Field Format">
    
      <t>The NAPTR Service Field format defined by the S-NAPTR DDDS application
      in <xref target="RFC3958"/> consists of a S-NAPTR Application
      Service tag and a S-NAPTR Application Protocol tag delimited by
      a single colon (":") character.</t>
      <t>The S-NAPTR Application Service Tag ABNF specification for the 
      discovery of Diameter agents supporting a specific Diameter 
      application is shown below. 
      
      <figure><artwork><![CDATA[
    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.
  ]]></artwork></figure>
      </t>
      <t>As stated in <xref target="RFC3958"/>, 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.</t>
      <t>The S-NAPTR Application Protocol Tag ABNF specification for the 
      discovery of Diameter agents supporting a specific Diameter 
      transport protocol is shown below. 
      
      <figure><artwork><![CDATA[
    appln-protocol-tag  = "diameter." app-protocol
    app-protocol        = "tcp" / "sctp" / "tls.tcp"
  ]]></artwork></figure>
      </t>    
      <t>For example, a NAPTR service field value of:
      </t>
      <t><list style="hanging">
        <t hangText="'aaa+ap6:diameter.sctp'">
          <vspace blankLines="1"/>
          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.
        </t>
      </list>
      </t>
      <t>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
         <xref target="RFC1035"/>). DNS administrators SHOULD also provision 
         legacy RFC 3588 style NAPTR records <xref target="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.
      </t>
    </section>

    <section title="Extended NAPTR-based Diameter Peer Discovery">
      <t>The Diameter Peer Discovery principles are described in
         Section 5.2 of <xref target="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.
         </t> 
      <t>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.</t>
      <t>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 <xref 
         target="RFC3588"/>.
      </t>
      <t><list style="hanging">
        <t hangText="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.
        </t>
        <t hangText="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.
           <list style="hanging">
           <t>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.
           </t>
           <t>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.
           </t>
           </list>
           </t>
        <t hangText="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 <xref target="RFC3588"/>.
           <list style="hanging">
           <t>If "X" matches a supported transport protocol, the Diameter 
           implementation continues processing the NAPTR as described in 
           <xref target="RFC3588"/> and <xref target="RFC2915"/>.
           </t>
           <t>If "X" does not match a supported transport protocol, the Diameter
           implementation abandons the peer discovery.
           </t>
           </list>
        </t>
           
        <t hangText="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 <xref target="RFC3588"/>.
        </t>
      </list>
      </t>
    </section>

    <section title="Usage Guidelines">
      <t>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.
      </t>
    </section>   

    <section anchor="IANA" title="IANA Considerations">
    
      <section anchor="ietf-apps" title="IETF Diameter Application Service Tags">

      <t>IANA is requested to reserve the following S-NAPTR Application 
      Service Tags for existing IETF Diameter applications:
      </t>
      <texttable>
      <ttcol>Tag</ttcol><ttcol>Diameter Application</ttcol>
      <c>aaa+ap1</c><c>NASREQ <xref target="RFC3588"/></c>
      <c>aaa+ap2</c><c>Mobile IPv4 <xref target="RFC4004"/></c>
      <c>aaa+ap3</c><c>Base Accounting <xref target="RFC3588"/></c>
      <c>aaa+ap4</c><c>Credit Control <xref target="RFC4006"/></c>
      <c>aaa+ap5</c><c>EAP <xref target="RFC4072"/></c>
      <c>aaa+ap6</c><c>SIP <xref target="RFC4740"/></c>
      <c>aaa+ap7</c><c>Mobile IPv6 IKE <xref target="RFC5778"/></c>
      <c>aaa+ap8</c><c>Mobile IPv6 Auth <xref target="RFC5778"/></c>
      <c>aaa+ap9</c><c>QoS <xref target="RFC5866"/></c>
      <c>aaa+ap4294967295</c><c>Relay <xref target="RFC3588"/></c>
      </texttable>

      <t>Future IETF Diameter applications MUST reserve the S-NAPTR 
      Application Service Tag corresponding to the allocated Diameter
      Application ID.</t>
      </section>
      
      <section anchor="vendor-apps" title="Vendor-Specific Diameter Application Service Tags">
      <t>
      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 
      <xref target="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.</t>
      </section>
      
      <section anchor="proto-tags" title="Diameter Application Protocol Tags">
      
      <t>IANA is requested to reserve the following S-NAPTR Application 
      Protocol Tags for the Diameter transport protocols:</t>
      <texttable>
      <ttcol>Tag</ttcol><ttcol>Protocol</ttcol>
      <c>diameter.tcp</c><c>TCP</c>
      <c>diameter.sctp</c><c>SCTP</c>      
      <c>diameter.tls.tcp</c><c>TLS/TCP</c>
      </texttable>
      </section>      
      
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC3403;
      &RFC1035;
      &RFC2782;
      &RFC3958;
      &RFC3588;
      &RFC4004;
      &RFC4006;
      &RFC4072;
      &RFC4740;
      &RFC5778;
      &RFC5866;
      &RFC3596;
    </references>
    <references title="Informative References">
      &RFC2915;
    </references>
  </back>
</rfc>