One document matched: draft-ietf-dime-extended-naptr-02.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-02"
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>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.</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 RFC 3588)
defines most of 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
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 show 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"/>). The DNS administrator of some domain
SHOULD also provision base 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 basic Diameter Peer Discover 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 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.
</t>
<t>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.
</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 transport protocol supported by the client,
the client continues processing the NAPTR as described in
<xref target="RFC3588"/> and <xref target="RFC2915"/>.
</t>
<t>If "X" does not match a transport protocol supported by the client,
the peer discovery is abandoned.
</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>| PAFTECH AB 2003-2026 | 2026-04-24 13:40:56 |