One document matched: draft-ietf-dime-extended-naptr-07.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'>
<!ENTITY RFC5234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
]>
<rfc category="std"
docName="draft-ietf-dime-extended-naptr-07"
ipr="trust200902"
updates="3588">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?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"?>
<front>
<title abbrev="dime-extended-naptr">Diameter S-NAPTR Usage</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>
<author fullname="Lionel Morand" initials="L" surname="Morand">
<organization>Orange Labs</organization>
<address>
<email>lionel.morand@orange-ftgroup.com</email>
</address>
</author>
<date year="2011" />
<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 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 <xref target="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.</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 Naming Authority Pointer (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 Straightforward-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 Protocol 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 anchor="snaptr-format" title="Extended NAPTR Service Field Format">
<t>The NAPTR Service Field format defined by the S-NAPTR DDDS application
in <xref target="RFC3958"/> follows this Augmented Backus-Naur Form
(ABNF, <xref target="RFC5234"/>):
<figure><artwork><![CDATA[
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.
]]></artwork></figure>
</t>
<t>This specification refines the "iana-registered-service"
tag definition for the discovery of Diameter agents supporting
a specific Diameter application as defined below.
<figure><artwork><![CDATA[
iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM
aaa-service = "aaa+ap" appln-id
appln-id = DIGIT *DIGIT
; Application identifier expressed as a
; decimal integer.
]]></artwork></figure>
</t>
<t>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.
<figure><artwork><![CDATA[
iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp"
]]></artwork></figure>
</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"/>).
</t>
<section title="IETF Standard Track Diameter Applications ">
<t>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 <xref target="IANA"/>).
</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>
</section>
<section title="Vendor-specific Diameter Applications">
<t>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 <xref target="IANA"/>).
</t>
<t>For example, a NAPTR service field value of:
</t>
<t><list style="hanging">
<t hangText="'aaa+ap16777251:diameter.sctp'">
<vspace blankLines="1"/>
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.
</t>
</list>
</t>
</section>
</section>
<section title="Backwards Compatibility">
<t>Domain Name System (DNS) administrators SHOULD also provision
legacy RFC 3588 style NAPTR records <xref target="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.
</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.</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. 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.
</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 supported transport protocol(s),
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: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.
<list style="hanging">
<t>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.
</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 (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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="ietf-apps" title="IETF Diameter Application Service Tags">
<t>IANA is requested to reserve a value of "aaa" for Diameter in the
S-NAPTR Application Service Tag registry created by
<xref target="RFC3958"/>. IANA is also requested to reserve the
following S-NAPTR Application Service Tags for existing IETF Diameter
applications in the same registry.</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 as defined in <xref target="snaptr-format"/>.</t>
</section>
<section anchor="three-gpp-apps" title="3GPP Diameter Application Service Tags">
<t>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
<xref target="RFC3958"/>. </t>
<texttable>
<ttcol>Tag</ttcol><ttcol>Diameter Application</ttcol>
<c>aaa+ap16777250</c><c>3GPP STa <xref target="TS29.273"/></c>
<c>aaa+ap16777251</c><c>3GPP S6a <xref target="TS29.272"/></c>
<c>aaa+ap16777264</c><c>3GPP SWm <xref target="TS29.273"/></c>
<c>aaa+ap16777267</c><c>3GPP S9 <xref target="TS29.215"/></c>
</texttable>
<t>Future 3GPP Diameter applications can reserve entries in
the S-NAPTR Application Service Tag registry created by
<xref target="RFC3958"/> which correspond to the allocated
Diameter Application IDs as defined in <xref target="snaptr-format"/>.
</t>
</section>
<section anchor="wimax-apps" title="WiMAX Forum Diameter Application Service Tags">
<t>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
<xref target="RFC3958"/>.</t>
<texttable>
<ttcol>Tag</ttcol><ttcol>Diameter Application</ttcol>
<c>aaa+ap16777281</c><c>WiMAX Network Access Authentication and Authorization Diameter Application (WNAAADA) <xref target="WiMAX"/></c>
<c>aaa+ap16777282</c><c>WiMAX Network Accounting Diameter Application (WNADA) <xref target="WiMAX"/></c>
<c>aaa+ap16777283</c><c>WiMAX MIP4 Diameter Application (WM4DA) <xref target="WiMAX"/></c>
<c>aaa+ap16777284</c><c>WiMAX MIP6 Diameter Application (WM6DA) <xref target="WiMAX"/></c>
<c>aaa+ap16777285</c><c>WiMAX DHCP Diameter Application (WDDA) <xref target="WiMAX"/></c>
<c>aaa+ap16777286</c><c>WiMAX Location Authentication Authorization Diameter Application (WLAADA) <xref target="WiMAX"/></c>
<c>aaa+ap16777287</c><c>WiMAX Policy and Charging Control R3 Policies Diameter Application (WiMAX PCC-R3-P) <xref target="WiMAX"/></c>
<c>aaa+ap16777288</c><c>WiMAX Policy and Charging Control R3 Offline Charging Diameter Application (WiMAX PCC-R3-OFC) <xref target="WiMAX"/></c>
<c>aaa+ap16777289</c><c>WiMAX Policy and Charging Control R3 Offline Charging Prime Diameter Application (WiMAX PCC-R3-OFC-PRIME) <xref target="WiMAX"/></c>
<c>aaa+ap16777290</c><c>WiMAX Policy and Charging Control R3 Online Charging Diameter Application (WiMAX PCC-R3-OC) <xref target="WiMAX"/></c>
</texttable>
<t>Future WiMAX Forum Diameter applications can reserve entries in
the S-NAPTR Application Service Tag registry created by
<xref target="RFC3958"/> which correspond to the allocated
Diameter Application IDs as defined in <xref target="snaptr-format"/>.
</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 as defined in
<xref target="snaptr-format"/>.</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 in the
S-NAPTR Application Protocol Tag registry created by [RFC3958].</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>
<section title="Acknowledgments">
<t>We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel
Morand and Sebastien Decugis for their comprehensive review comments.
</t>
</section>
<section title="Editor's Notes">
<t>This section to be removed prior to publication.</t>
<t>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.
</t>
<t>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").
</t>
<t>
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.
</t>
</section> </middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3403;
&RFC1035;
&RFC2782;
&RFC3958;
&RFC3588;
&RFC4004;
&RFC4006;
&RFC4072;
&RFC4740;
&RFC5778;
&RFC5866;
&RFC3596;
&RFC5234;
<reference anchor="TS29.272" target="http://www.3gpp.org/ftp/Specs/html-info/29272.htm">
<front>
<title>
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)
</title>
<author>
<organization abbrev="3GPP">3rd Generation Partnership Project</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="TS29.273" target="http://www.3gpp.org/ftp/Specs/html-info/29273.htm">
<front>
<title>
3GPP TS 29.273;
Technical Specification Group Core Network and Terminals;
Evolved Packet System;
3GPP EPS AAA interfaces (Release 8)
</title>
<author>
<organization abbrev="3GPP">3rd Generation Partnership Project</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="TS29.215" target="http://www.3gpp.org/ftp/Specs/html-info/29215.htm">
<front>
<title>
3GPP TS 29.215;
Technical Specification Group Core Network and Terminals;
Policy and Charging Control (PCC) over S9 reference point; Stage 3 (Release 8)
</title>
<author>
<organization abbrev="3GPP">3rd Generation Partnership Project</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="WiMAX" target="http://www.wimaxforum.org/resources/documents/technical/T33">
<front>
<title>WiMAX Release 1.5</title>
<author>
<organization abbrev="3GPP">WiMAX Forum</organization>
</author>
<date/>
</front>
</reference>
</references>
<!--references title="Informative References">
&RFC2915;
</references-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 13:39:28 |