draft-ietf-dime-extended-naptr-00.txt   draft-ietf-dime-extended-naptr-01.txt 
Individual Submission M. Jones Diameter Maintenance and M. Jones
Internet-Draft Bridgewater Systems Extensions (DIME) Bridgewater Systems
Updates: 3588 (if approved) J. Korhonen Internet-Draft J. Korhonen
Intended status: Standards Track Nokia Siemens Networks Updates: 3588 (if approved) Nokia Siemens Networks
Expires: July 2, 2010 December 29, 2009 Intended status: Standards Track May 4, 2010
Expires: November 5, 2010
Diameter Extended NAPTR Diameter Extended NAPTR
draft-ietf-dime-extended-naptr-00 draft-ietf-dime-extended-naptr-01
Abstract Abstract
This document describes an extended format for the NAPTR service This document describes an extended format for the S-NAPTR
fields used in dynamic Diameter agent discovery. The extended format Application Service Tag used in dynamic Diameter agent discovery.
allows NAPTR queries to contain Diameter Application-Id information. The extended format allows NAPTR queries to contain Diameter
Application-Id information.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 45 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2010. This Internet-Draft will expire on November 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended NAPTR Service Field . . . . . . . . . . . . . . . . . 4 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . . 4
4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5.1. IETF Diameter Application Service Tags . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 5.2. Vendor-Specific Diameter Application Service Tags . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Diameter Application Protocol Tags . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Diameter base protocol [RFC3588] specifies three mechanisms for The Diameter base protocol [RFC3588] specifies three mechanisms for
the Diameter peer discovery. One of these involves the Diameter the Diameter peer discovery. One of these involves the Diameter
implementation performing a NAPTR query [RFC3403] for a server in a implementation performing a NAPTR query [RFC3403] for a server in a
particular realm. These NAPTR records provide a mapping from a particular realm. These NAPTR records provide a mapping from a
domain, to the SRV record [RFC2782] for contacting a server with the domain, to the SRV record [RFC2782] or A/AAAA record
specific transport protocol in the NAPTR services field. [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 The extended NAPTR usage for Diameter peer discovery defined by this
will be specialized by Diameter application and the NAPTR service document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic
field does not allow a Diameter implementation to determine the Delegation Discovery System (DDDS) Application defined in [RFC3958].
application supported by the AAA node. Without this information, a This document updates the Diameter peer discovery procedure described
Diameter implementation must connect and perform a capability in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service
negotiation with each candidate AAA node. This document addresses and Application Procotol Tag values that permit the discovery of
this problem by specifying an extended NAPTR service field format Diameter peers that support a specific Diameter application and
that permits discovery of Diameter peers that support a specific transport protocol.
Diameter application.
2. Terminology 2. Terminology
The Diameter base protocol specification (Section 1.4 of RFC 3588) The Diameter base protocol specification (Section 1.4 of RFC 3588)
defines most of the terminology used in this document. defines most of the terminology used in this document.
3. Extended NAPTR Service Field 3. Extended NAPTR Service Field Format
The Extended NAPTR service field ABNF specification for the discovery
of Diameter agents supporting a specific Diameter application is show
below.
naptr-svc-field = "AAA+D2" < protocol> [ *appln-list ] The NAPTR 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.
protocol = "T" / "S" The S-NAPTR Application Service Tag ABNF specification for the
; "T" for TCP and "S" for SCTP. discovery of Diameter agents supporting a specific Diameter
application is show below.
appln-list = "+AP:" appln-id [ *( "," appln-id ) ] appln-svc-tag = iana-appln-tag / experimental-appln-tag
; Comma separated list of application iana-appln-tag = "aaa+ap" appln-id
; identifiers prefixed by "+AP:". experimental-appln-tag = "x-aaa+ap" appln-id
appln-id = *DIGIT
; Application identifier expressed as a
; decimal integer.
appln-id = *DIGIT As stated in [RFC3958], application service tags that start with "x-"
; Application identifier expressed as a are considered experimental, and no provision is made to prevent
; decimal integer. duplicate use of the same string. Implementors use them at their own
risk.
For example, a NAPTR service field value of: The S-NAPTR Application Protocol Tag ABNF specification for the
discovery of Diameter agents supporting a specific Diameter transport
protocol is shown below.
'AAA+D2S+AP:6' appln-protocol-tag = "diameter." app-protocol
app-protocol = "tcp" / "sctp" / "tls.tcp"
Means that the Diameter node in the SRV record supports the For example, a NAPTR service field value of:
Diameter Session Initiation Protocol (SIP) Application ('6') and
SCTP as the transport protocol.
'AAA+D2S+AP:6,1,5,4294967295' 'aaa+ap6:diameter.sctp'
Means that the Diameter node in the SRV record supports the Means that the Diameter node in the SRV or A/AAAA record supports
Diameter Session Initiation Protocol (SIP) Application ('6'), the Diameter Session Initiation Protocol (SIP) Application ('6')
NASREQ Application ('1'), EAP Application ('5') and SCTP as the and SCTP as the transport protocol.
transport protocol. The Diameter node also provides Relay
functionality ('4294967295').
The maximum length of the NAPTR service field is 256 octets including 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 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 of [RFC1035]). The DNS administrator of some domain SHOULD also
provision base RFC 3588 style NAPTR records in order to guarantee provision base RFC 3588 style NAPTR records [RFC2915] in order to
backwards compatibility with legacy RFC 3588 compliant Diameter guarantee backwards compatibility with legacy RFC 3588 compliant
peers. If the DNS administrator provisions both extended NAPTR Diameter peers. If the DNS administrator provisions both extended
records as defined in this specification and legacy RFC 3588 NAPTR S-NAPTR records as defined in this specification and legacy RFC 3588
records, then the extended NAPTR records MUST have higher priority NAPTR records, then the extended S-NAPTR records MUST have higher
(e.g. lower order and/or preference values) than legacy NAPTR priority (e.g. lower order and/or preference values) than legacy
records. NAPTR records.
4. Extended NAPTR-based Diameter Peer Discovery 4. Extended NAPTR-based Diameter Peer Discovery
The basic Diameter Peer Discover principles are described in Section The basic Diameter Peer Discover principles are described in Section
5.2 of [RFC3588]. This specification extends the NAPTR query 5.2 of [RFC3588]. This specification updates the NAPTR query
procedure in the Diameter peer discovery mechanism by allowing the procedure in the Diameter peer discovery mechanism by allowing the
querying node to determine which applications are supported by querying node to determine which applications are supported by
resolved Diameter peers. resolved Diameter peers.
The extended format NAPTR records provide a mapping from a domain, to The extended format NAPTR records provide a mapping from a domain, to
the SRV record for contacting a server supporting a specific the SRV record or A/AAAA record for contacting a server supporting a
transport protocol and Diameter application. The resource record specific transport protocol and Diameter application. The resource
will contain an empty regular expression and a replacement value, record will contain an empty regular expression and a replacement
which is the SRV record for that particular transport protocol. If value, which is the SRV record or the A/AAAA record for that
the server supports multiple transport protocols, there will be particular transport protocol. If the server supports multiple
multiple NAPTR records, each with a different Services Field value transport protocols, there will be multiple NAPTR records, each with
and potentially different list of supported Diameter applications. a different Services Field value and potentially different list of
supported Diameter applications.
The assumption for this mechanism to work is that the DNS The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS administrator of the queried domain has first provisioned the DNS
with extended format NAPTR entries. The steps below replace the with extended format NAPTR entries. The steps below replace the
NAPTR query procedure steps in Section 5.2 of [RFC3588]. NAPTR query procedure steps in Section 5.2 of [RFC3588].
a. The Diameter implementation performs a NAPTR query for a server in a. The Diameter implementation performs a NAPTR query for a server in
a particular realm. The Diameter implementation has to know in a particular realm. The Diameter implementation has to know in
advance which realm to look for a Diameter agent in and which advance which realm to look for a Diameter agent in and which
Application Identifier it is interested in. The realm could be Application Identifier it is interested in. The realm could be
deduced, for example, from the 'realm' in a NAI that a Diameter deduced, for example, from the 'realm' in a NAI that a Diameter
implementation needed to perform a Diameter operation on. implementation needed to perform a Diameter operation on.
b. If the returned NAPTR service fields contain entries formatted as b. If the returned NAPTR service fields contain entries formatted as
"AAA+D2X+AP:Y" where "X" indicates the transport protocol and "Y" "aaa+apX:Y" where "X" indicates the Application Identifier and "Y"
is a comma-separated list of Application Identifiers, the target indicates the transport protocol, the target realm supports the
realm supports the extended format for NAPTR-based Diameter peer extended format for NAPTR-based Diameter peer discovery defined in
discovery defined in this document. this document.
If "X" matches a transport protocol supported by the client and If "X" contains the required Application Identifier and "Y"
"Y" contains the required Application Identifier, the client matches a transport protocol supported by the client, the
resolves the "replacement" field entry to a target host using client resolves the "replacement" field entry to a target host
the lookup method appropriate for the "flags" field. using the lookup method appropriate for the "flags" field.
If "X" does not match a transport protocol supported by the If "X" does not contain the required Application Identifier or
client or "Y" does not contain the required Application "Y" does not match a transport protocol supported by the
Identifier, the peer discovery is abandoned. client, the peer discovery is abandoned.
c. If the returned NAPTR service fields contain entries formatted as c. If the returned NAPTR service fields contain entries formatted as
"AAA+D2X" where "X" indicates the transport protocol, the target "AAA+D2X" where "X" indicates the transport protocol, the target
realm supports the NAPTR-based Diameter peer discovery defined in realm supports the NAPTR-based Diameter peer discovery defined in
[RFC3588]. [RFC3588].
If "X" matches a transport protocol supported by the client, If "X" matches a transport protocol supported by the client,
the client resolves the "replacement" field entry to a target the client continues processing the NAPTR as described in
host using the lookup method appropriate for the "flags" field. [RFC3588] and [RFC2915].
If "X" does not match a transport protocol supported by the If "X" does not match a transport protocol supported by the
client, the peer discovery is abandoned. client, the peer discovery is abandoned.
d. If the target realm does not support NAPTR-based Diameter peer d. If the target realm does not support NAPTR-based Diameter peer
discovery, the client proceeds with the next peer discovery discovery, the client proceeds with the next peer discovery
mechanism described in Section 5.2 of [RFC3588]. mechanism described in Section 5.2 of [RFC3588].
5. IANA Considerations 5. IANA Considerations
Section 11.6 of [RFC3588] defines a IANA registry for the NAPTR 5.1. IETF Diameter Application Service Tags
Services Field entries. Although this document does not define a new
transport protocol, it is proposed to add the following entries to
the existing registry to reflect the extended format of the NAPTR
Services Field:
Services Field Protocol IANA is requested to reserve the following S-NAPTR Application
AAA+D2T+AP:x TCP Service Tags for existing IETF Diameter applications:
AAA+D2S+AP:x SCTP
Editor's Note: IANA is currently missing the registry for the NAPTR +------------------+----------------------------------+
Service Fields defined in [RFC3588]. This oversight will need to be | Tag | Diameter Application |
resolved for this document to proceed. +------------------+----------------------------------+
| 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 the
Diameter QoS Application.
Future IETF Diameter applications MUST reserve the 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
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 [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.
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 6. Security Considerations
This document specifies an enhancement to the NAPTR service field This document specifies an enhancement to RFC 3588 Diameter base
format defined in the Diameter base protocol and the same security 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. considerations described in RFC 3588 are applicable to this document.
No further extensions are required beyond the security mechanisms No further extensions are required beyond the security mechanisms
offered by RFC 3588. However, a malicious host doing NAPTR queries offered by RFC 3588. However, a malicious host doing S-NAPTR queries
learns applications supported by Diameter agents in a certain realm learns applications supported by Diameter agents in a certain realm
faster, which might help the malicious host to scan potential targets faster, which might help the malicious host to scan potential targets
for an attack more efficiently when some applications have known for an attack more efficiently when some applications have known
vulnerabilities. vulnerabilities.
7. Normative References 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 [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002. RFC 3403, October 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 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 Authors' Addresses
Mark Jones Mark Jones
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive, Suite 500
Ottawa, Ontario K2K 3J1
Canada
Email: mark.jones@bridgewatersystems.com Email: mark@azu.ca
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 36 change blocks. 
109 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/