RFC 6408

Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage

Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 6408 Bridgewater Systems
Updates: 3588 J. Korhonen
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 L. Morand
Orange Labs
November 2011 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
Abstract
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 RFC 3588, "Diameter Base Protocol", 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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6408.

This specification refines the "iana-registered-service" tag
definition for the discovery of Diameter agents supporting a specific
Diameter application as defined below.
iana-registered-service =/ aaa-service
aaa-service = "aaa+ap" appln-id
appln-id = 1*10DIGIT
; Application Identifier expressed as
; a decimal integer without leading
; zeros.
The appln-id element is the Application Identifier used to identify a
specific Diameter application. The Diameter Application Identifier
is a 32-bit unsigned integer, and values are allocated by IANA as
defined in [RFC3588].
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
aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp"
The S-NAPTR application protocol tags defined by this specification
MUST NOT be parsed in any way by the querying application or
resolver. The delimiter (".") is present in the tag to improve
readability and does not imply a structure or namespace of any kind.
The choice of delimiter (".") for the application protocol tag
follows the format of existing S-NAPTR application protocol tag
registry entries, but this does not imply that it shares semantics
with any other specifications that create registry entries with the
same format.
The S-NAPTR application service and application protocol tags defined
by this specification are unrelated to the IANA "Service Name and
Transport Protocol Port Number Registry" (see [RFC6335]).
The maximum length of the NAPTR service field is 256 octets,
including a one-octet length field (see Section 4.1 of [RFC3403] and
Section 3.3 of [RFC1035]).

3.1. IETF Standards 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 Standards Track applications. Therefore, every IETF
Standards Track Diameter application MUST be associated with a
"aaa-service" tag formatted as defined in this specification and
allocated in accordance with 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 the
Stream Control Transmission Protocol (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 IANA policy (see Section 7).
For example, a NAPTR service field value of:
'aaa+ap16777251:diameter.sctp'
means that the Diameter node in the SRV or A/AAAA record supports the
Diameter Third Generation Partnership Project (3GPP) S6a application
('16777251') and SCTP as the transport protocol.
4. Backwards Compatibility
Domain Name System (DNS) administrators SHOULD also provision legacy
NAPTR records [RFC3403] in the RFC 3588 style in order to guarantee
backwards compatibility with legacy Diameter peers that are RFC 3588
compliant. 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.
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 in which realm to look for a Diameter agent, and in which
Application Identifier it is interested. For example, the realm
could be deduced from the Network Access Identifier (NAI) in the
User-Name attribute-value pair (AVP) or extracted from the
Destination-Realm AVP.
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.
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+apX" where "X" indicates the Application Identifier, the
target realm supports the extended format for NAPTR-based Diameter
peer discovery defined in this document.
If "X" contains the required Application Identifier, the
Diameter implementation resolves the "replacement" field entry
to a target host using the lookup method appropriate for the
"flags" field and attempts to connect using all supported
transport protocols following the order specified in
Section 2.1 of [RFC3588].
If "X" does not contain the required Application Identifier,
the Diameter implementation abandons the peer discovery.
d. 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.
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.
e. If the returned NAPTR service fields contain entries formatted as
"aaa", the target realm supports Diameter but does not support the
extended format for NAPTR-based Diameter peer discovery defined in
this document. The Diameter implementation resolves the
"replacement" field entry to a target host using the lookup method
appropriate for the "flags" field and attempts to connect using
all supported transport protocols following the order specified in
Section 2.1 of [RFC3588].
f. 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.1. Examples
As an example, consider a client that wishes to discover a Diameter
server in the ex1.example.com realm that supports the Credit Control
application. The client performs a NAPTR query for that domain, and
the following NAPTR records are returned:

;; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "aaa:diameter.sctp" ""
_diameter._sctp.ex1.example.com
IN NAPTR 50 50 "s" "aaa+ap1:diameter.sctp" ""
_diameter._sctp.ex1.example.com
IN NAPTR 50 50 "s" "aaa+ap4:diameter.sctp" ""
_diameter._sctp.ex1.example.com
This indicates that the server supports NASREQ (ID=1) and Credit
Control (ID=4) applications over SCTP. If the client supports SCTP,
it will be used, targeted to a host determined by an SRV lookup of
_diameter._sctp.ex1.example.com.
That SRV lookup would return:
;; Priority Weight Port Target
IN SRV 0 1 3868 server1.ex1.example.com
IN SRV 0 2 3868 server2.ex1.example.com
As an alternative example, a client wishes to discover a Diameter
server in the ex2.example.com realm that supports the NASREQ
application over SCTP. The client performs a NAPTR query for that
domain, and the following NAPTR records are returned:
;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "aaa:diameter.sctp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" ""
server2.ex2.example.com
IN NAPTR 150 50 "a" "aaa+ap1:diameter.sctp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "aaa+ap1:diameter.tls.tcp" ""
server2.ex2.example.com
This indicates that the server supports NASREQ (ID=1) over SCTP and
Transport Layer Security (TLS)/TCP via hosts server1.ex2.example.com
and server2.ex2.example.com, respectively.
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
(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.

"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 that reserves the
S-NAPTR Application Service Tag corresponding to the Vendor-Specific
Diameter Application ID as defined in Section 3.
7.5. Diameter Application Protocol Tags
IANA has reserved 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 |
+------------------+----------+
Future Diameter versions that introduce new transport protocols MUST
reserve an appropriate S-NAPTR Application Protocol Tag in the
"S-NAPTR Application Protocol Tag" registry created by [RFC3958].
8. Security Considerations
This document specifies an enhancement to the NAPTR service field
format defined in RFC 3588 and also modifications to the NAPTR
processing logic defined in RFC 3588. The enhancement 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 [RFC3588] 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 Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien
Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete
Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms,
and Joe Touch for their comprehensive review comments.