draft-ietf-dime-extended-naptr-03.txt   draft-ietf-dime-extended-naptr-04.txt 
Diameter Maintenance and M. Jones Diameter Maintenance and M. Jones
Extensions (DIME) Bridgewater Systems Extensions (DIME) Bridgewater Systems
Internet-Draft J. Korhonen Internet-Draft J. Korhonen
Updates: 3588 (if approved) Nokia Siemens Networks Updates: 3588 (if approved) Nokia Siemens Networks
Intended status: Standards Track November 9, 2010 Intended status: Standards Track L. Morand
Expires: May 13, 2011 Expires: July 10, 2011 Orange Labs
January 6, 2011
Diameter Extended NAPTR Diameter Extended NAPTR
draft-ietf-dime-extended-naptr-03 draft-ietf-dime-extended-naptr-04
Abstract Abstract
The Diameter base protocol specifies mechanisms whereby a given realm The Diameter base protocol specifies mechanisms whereby a given realm
may advertise Diameter nodes and the supported transport protocol. may advertise Diameter nodes and the supported transport protocol.
However, these mechanism do not reveal the Diameter applications that However, these mechanism do not reveal the Diameter applications that
each node supports. A peer outside the realm would have to perform a each node supports. A peer outside the realm would have to perform a
Diameter capability exchange with every node in order to discover Diameter capability exchange with every node until it discovers one
which one supports a required application. This document describes that supports the required application. This document describes an
an improvement using an extended format for the Straightfoward-NAPTR improvement using an extended format for the Straightfoward-NAPTR
(S-NAPTR) Application Service Tag that allows for discovery of the (S-NAPTR) Application Service Tag that allows for discovery of the
supported applications without doing Diameter capability exchange supported applications without doing Diameter capability exchange
beforehand. beforehand.
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].
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 May 13, 2011. This Internet-Draft will expire on July 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
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 Format . . . . . . . . . . . . . . 4 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 4
4. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 3.1. IETF Standard Track Diameter Applications . . . . . . . . 5
5. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
6.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 6
6.2. Vendor-Specific Diameter Application Service Tags . . . . . 7 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Diameter Application Protocol Tags . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.4. Vendor-Specific Diameter Application Service Tags . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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] or A/AAAA record domain, to the SRV record [RFC2782] or A/AAAA record
[RFC1035][RFC3596] for contacting a server with the specific [RFC1035][RFC3596] for contacting a server with the specific
transport protocol in the NAPTR services field. transport protocol in the NAPTR services field.
The extended NAPTR usage for Diameter peer discovery defined by this The extended NAPTR usage for Diameter peer discovery defined by this
document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic
Delegation Discovery System (DDDS) Application defined in [RFC3958]. Delegation Discovery System (DDDS) Application defined in [RFC3958].
This document updates the Diameter peer discovery procedure described This document updates the Diameter peer discovery procedure described
in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service
and Application Procotol Tag values that permit the discovery of and Application Protocol Tag values that permit the discovery of
Diameter peers that support a specific Diameter application and Diameter peers that support a specific Diameter application and
transport protocol. transport protocol.
2. Terminology 2. Terminology
The Diameter base protocol specification (Section 1.4 of [RFC3588]) The Diameter base protocol specification (Section 1.4 of [RFC3588])
and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1
in [RFC3958]) define the terminology used in this document. in [RFC3958]) define the terminology used in this document.
3. Extended NAPTR Service Field Format 3. Extended NAPTR Service Field Format
The NAPTR Service Field format defined by the S-NAPTR DDDS The NAPTR Service Field format defined by the S-NAPTR DDDS
application in [RFC3958] consists of a S-NAPTR Application Service application in [RFC3958] follows this ABNF:
tag and a S-NAPTR Application Protocol tag delimited by a single
colon (":") character.
The S-NAPTR Application Service Tag ABNF specification for the service-parms = [ [app-service] *(":" app-protocol)]
discovery of Diameter agents supporting a specific Diameter app-service = experimental-service / iana-registered-service
application is shown below. 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.
appln-svc-tag = iana-appln-tag / experimental-appln-tag This specification refines the "iana-registered-service" tag
iana-appln-tag = "aaa+ap" appln-id definition for the discovery of Diameter agents supporting a specific
experimental-appln-tag = "x-aaa+ap" appln-id Diameter application as defined below.
iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM
aaa-service = "aaa+ap" appln-id
appln-id = *DIGIT appln-id = *DIGIT
; Application identifier expressed as a ; Application identifier expressed as a
; decimal integer. ; decimal integer.
As stated in [RFC3958], application service tags that start with "x-" This specification also refines the "iana-registered-protocol" tag
are considered experimental, and no provision is made to prevent definition for the discovery of Diameter agents supporting a specific
duplicate use of the same string. Implementors use them at their own Diameter transport protocol as defined below.
risk.
The S-NAPTR Application Protocol Tag ABNF specification for the iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM
discovery of Diameter agents supporting a specific Diameter transport aaa-protocol = "diameter." aaa-transport
protocol is shown below. aaa-transport = "tcp" / "sctp" / "tls.tcp"
appln-protocol-tag = "diameter." app-protocol The maximum length of the NAPTR service field is 256 octets including
app-protocol = "tcp" / "sctp" / "tls.tcp" one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
of [RFC1035]).
3.1. IETF Standard 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 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 Section 7).
For example, a NAPTR service field value of: For example, a NAPTR service field value of:
'aaa+ap6:diameter.sctp' 'aaa+ap6:diameter.sctp'
Means that the Diameter node in the SRV or A/AAAA record supports Means that the Diameter node in the SRV or A/AAAA record supports
the Diameter Session Initiation Protocol (SIP) Application ('6') the Diameter Session Initiation Protocol (SIP) Application ('6')
and SCTP as the transport protocol. and SCTP as the transport protocol.
The maximum length of the NAPTR service field is 256 octets including 3.2. Vendor-specific Diameter Applications
one octet length field (see Section 4.1 of RFC 3403 and Section 3.3
of [RFC1035]). DNS administrators SHOULD also provision legacy RFC
3588 style NAPTR records [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.
4. Extended NAPTR-based Diameter Peer Discovery 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 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 3GPP S6a Application ('16777251') and SCTP as the
transport protocol.
4. Backwards Compatibility
DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR
records [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.
5. Extended NAPTR-based Diameter Peer Discovery
The Diameter Peer Discovery principles are described in Section 5.2 The Diameter Peer Discovery principles are described in Section 5.2
of [RFC3588]. This specification updates the NAPTR query procedure of [RFC3588]. This specification updates the NAPTR query procedure
in the Diameter peer discovery mechanism by allowing the querying in the Diameter peer discovery mechanism by allowing the querying
node to determine which applications are supported by resolved node to determine which applications are supported by resolved
Diameter peers. 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 or A/AAAA record for contacting a server supporting a the SRV record or A/AAAA record for contacting a server supporting a
specific transport protocol and Diameter application. The resource specific transport protocol and Diameter application. The resource
record will contain an empty regular expression and a replacement record will contain an empty regular expression and a replacement
value, which is the SRV record or the A/AAAA record for that value, which is the SRV record or the A/AAAA record for that
particular transport protocol. If the server supports multiple particular transport protocol. If the server supports multiple
transport protocols, there will be multiple NAPTR records, each with transport protocols, there will be multiple NAPTR records, each with
a different Services Field value and potentially different list of a different Services Field value and potentially different list of
supported Diameter applications. 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. For example, the
deduced, for example, from the 'realm' in a NAI that a Diameter realm could be deduced from the NAI in the User-Name AVP or
implementation needed to perform a Diameter operation on. extracted from the Destination-Realm AVP.
b. If the returned NAPTR service fields contain entries formatted as b. If the returned NAPTR service fields contain entries formatted as
"aaa+apX:Y" where "X" indicates the Application Identifier and "Y" "aaa+apX:Y" where "X" indicates the Application Identifier and "Y"
indicates the transport protocol, the target realm supports the indicates the transport protocol, the target realm supports the
extended format for NAPTR-based Diameter peer discovery defined in extended format for NAPTR-based Diameter peer discovery defined in
this document. this document.
If "X" contains the required Application Identifier and "Y" If "X" contains the required Application Identifier and "Y"
matches a supported transport protocol, the Diameter matches a supported transport protocol, the Diameter
implementation resolves the "replacement" field entry to a implementation resolves the "replacement" field entry to a
skipping to change at page 6, line 46 skipping to change at page 7, line 37
implementation continues processing the NAPTR as described in implementation continues processing the NAPTR as described in
[RFC3588] and [RFC2915]. [RFC3588] and [RFC2915].
If "X" does not match a supported transport protocol, the If "X" does not match a supported transport protocol, the
Diameter implementation abandons the peer discovery. Diameter implementation abandons the peer discovery.
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. Usage Guidelines 6. Usage Guidelines
Diameter is a peer to peer protocol whereas most of the applications Diameter is a peer to peer protocol whereas most of the applications
that extend the base protocol behave like client/server 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 The role of the peer is not advertised in the NAPTR tags and not even
communicated during Diameter capability negotiation (CER/CEA). For communicated during Diameter capability negotiation (CER/CEA). For
this reason, NAPTR-based Diameter peer discovery for an application this reason, NAPTR-based Diameter peer discovery for an application
defining client/server roles should only be used by a client to defining client/server roles should only be used by a client to
discover servers. discover servers.
6. IANA Considerations 7. IANA Considerations
7.1. IETF Diameter Application Service Tags
6.1. IETF Diameter Application Service Tags
IANA is requested to reserve the following S-NAPTR Application IANA is requested to reserve the following S-NAPTR Application
Service Tags for existing IETF Diameter applications: Service Tags for existing IETF Diameter applications in the S-NAPTR
Application Service Tag registry created by [RFC3958].
+------------------+----------------------------+ +------------------+----------------------------+
| Tag | Diameter Application | | Tag | Diameter Application |
+------------------+----------------------------+ +------------------+----------------------------+
| aaa+ap1 | NASREQ [RFC3588] | | aaa+ap1 | NASREQ [RFC3588] |
| aaa+ap2 | Mobile IPv4 [RFC4004] | | aaa+ap2 | Mobile IPv4 [RFC4004] |
| aaa+ap3 | Base Accounting [RFC3588] | | aaa+ap3 | Base Accounting [RFC3588] |
| aaa+ap4 | Credit Control [RFC4006] | | aaa+ap4 | Credit Control [RFC4006] |
| aaa+ap5 | EAP [RFC4072] | | aaa+ap5 | EAP [RFC4072] |
| aaa+ap6 | SIP [RFC4740] | | aaa+ap6 | SIP [RFC4740] |
| aaa+ap7 | Mobile IPv6 IKE [RFC5778] | | aaa+ap7 | Mobile IPv6 IKE [RFC5778] |
| aaa+ap8 | Mobile IPv6 Auth [RFC5778] | | aaa+ap8 | Mobile IPv6 Auth [RFC5778] |
| aaa+ap9 | QoS [RFC5866] | | aaa+ap9 | QoS [RFC5866] |
| aaa+ap4294967295 | Relay [RFC3588] | | aaa+ap4294967295 | Relay [RFC3588] |
+------------------+----------------------------+ +------------------+----------------------------+
Future IETF Diameter applications MUST reserve the S-NAPTR Future IETF Diameter applications MUST reserve the S-NAPTR
Application Service Tag corresponding to the allocated Diameter Application Service Tag corresponding to the allocated Diameter
Application ID. Application ID as defined in Section 3.
6.2. Vendor-Specific Diameter Application Service Tags 7.2. 3GPP Diameter Application Service Tags
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 [RFC3958].
+----------------+----------------------+
| Tag | Diameter Application |
+----------------+----------------------+
| aaa+ap16777250 | 3GPP STa [TS29.273] |
| aaa+ap16777251 | 3GPP S6a [TS29.272] |
| aaa+ap16777264 | 3GPP SWm [TS29.273] |
| aaa+ap16777267 | 3GPP S9 [TS29.215] |
+----------------+----------------------+
Future 3GPP Diameter applications can reserve entries in the S-NAPTR
Application Service Tag registry created by [RFC3958] which
correspond to the allocated Diameter Application IDs as defined in
Section 3.
7.3. WiMAX Forum Diameter Application Service Tags
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 [RFC3958].
+----------------+--------------------------------------------------+
| Tag | Diameter Application |
+----------------+--------------------------------------------------+
| aaa+ap16777281 | WiMAX Network Access Authentication and |
| | Authorization Diameter Application (WNAAADA) |
| | [WiMAX] |
| aaa+ap16777282 | WiMAX Network Accounting Diameter Application |
| | (WNADA) [WiMAX] |
| aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] |
| aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] |
| aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] |
| aaa+ap16777286 | WiMAX Location Authentication Authorization |
| | Diameter Application (WLAADA) [WiMAX] |
| aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies |
| | Diameter Application (WiMAX PCC-R3-P) [WiMAX] |
| aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Diameter Application (WiMAX PCC-R3-OFC) |
| | [WiMAX] |
| aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline |
| | Charging Prime Diameter Application (WiMAX |
| | PCC-R3-OFC-PRIME) [WiMAX] |
| aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online |
| | Charging Diameter Application (WiMAX PCC-R3-OC) |
| | [WiMAX] |
+----------------+--------------------------------------------------+
Future WiMAX Forum Diameter applications can reserve entries in the
S-NAPTR Application Service Tag registry created by [RFC3958] which
correspond to the allocated Diameter Application IDs as defined in
Section 3.
7.4. Vendor-Specific Diameter Application Service Tags
Vendor-Specific Diameter Application IDs are allocated by IANA Vendor-Specific Diameter Application IDs are allocated by IANA
according to the "First Come First Served" policy and do not require according to the "First Come First Served" policy and do not require
an IETF specification. However, the S-NAPTR Application Service Tag an IETF specification. However, the S-NAPTR Application Service Tag
registry created by [RFC3958] defines a registration policy of registry created by [RFC3958] defines a registration policy of
"Specification Required" with a further stipulation that the "Specification Required" with a further stipulation that the
"specification" is an RFC (of any category). If a Vendor-Specific "specification" is an RFC (of any category). If a Vendor-Specific
Diameter Application requires the functionality defined in this Diameter Application requires the functionality defined in this
document, an RFC of any category MUST be published which reserves the document, an RFC of any category MUST be published which reserves the
S-NAPTR Application Service Tag corresponding to the Vendor-Specific S-NAPTR Application Service Tag corresponding to the Vendor-Specific
Diameter Application ID. Diameter Application ID as defined in Section 3.
6.3. Diameter Application Protocol Tags 7.5. Diameter Application Protocol Tags
IANA is requested to reserve the following S-NAPTR Application IANA is requested to reserve the following S-NAPTR Application
Protocol Tags for the Diameter transport protocols: Protocol Tags for the Diameter transport protocols in the S-NAPTR
Application Protocol Tag registry created by [RFC3958].
+------------------+----------+ +------------------+----------+
| Tag | Protocol | | Tag | Protocol |
+------------------+----------+ +------------------+----------+
| diameter.tcp | TCP | | diameter.tcp | TCP |
| diameter.sctp | SCTP | | diameter.sctp | SCTP |
| diameter.tls.tcp | TLS/TCP | | diameter.tls.tcp | TLS/TCP |
+------------------+----------+ +------------------+----------+
7. Security Considerations 8. Security Considerations
This document specifies an enhancement to RFC 3588 Diameter base This document specifies an enhancement to RFC 3588 Diameter base
protocol defined NAPTR service field format and also modifications to protocol defined NAPTR service field format and also modifications to
the NAPTR processing logic defined. The enhancements and the NAPTR processing logic defined. The enhancements and
modifications are based on the S-NAPTR, which is actually a modifications are based on the S-NAPTR, which is actually a
simplification of the NAPTR, and therefore the same security 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 S-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.
8. References 9. Acknowledgments
8.1. Normative References We would like to thank Avi Lior, Itsuma Tanaka and Lionel Morand for
their comprehensive review comments.
10. References
10.1. Normative References
[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.
skipping to change at page 9, line 42 skipping to change at page 11, line 50
[RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
Agent to Diameter Server Interaction", RFC 5778, Agent to Diameter Server Interaction", RFC 5778,
February 2010. February 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
and G. Zorn, "Diameter Quality-of-Service Application", and G. Zorn, "Diameter Quality-of-Service Application",
RFC 5866, May 2010. RFC 5866, May 2010.
8.2. Informative References [TS29.215]
3rd Generation Partnership Project, "3GPP TS 29.215;
Technical Specification Group Core Network and Terminals;
Policy and Charging Control (PCC) over S9 reference point;
Stage 3 (Release 8)",
http://www.3gpp.org/ftp/Specs/html-info/29215.htm.
[TS29.272]
3rd Generation Partnership Project, "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)",
http://www.3gpp.org/ftp/Specs/html-info/29272.htm.
[TS29.273]
3rd Generation Partnership Project, "3GPP TS 29.273;
Technical Specification Group Core Network and Terminals;
Evolved Packet System; 3GPP EPS AAA interfaces (Release
8)", http://www.3gpp.org/ftp/Specs/html-info/29273.htm.
[WiMAX] WiMAX Forum, "WiMAX Release 1.5", http://
www.wimaxforum.org/resources/documents/technical/T33.
10.2. Informative References
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000. (NAPTR) DNS Resource Record", RFC 2915, September 2000.
Authors' Addresses Authors' Addresses
Mark Jones Mark Jones
Bridgewater Systems Bridgewater Systems
Email: mark@azu.ca Email: mark@azu.ca
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
Lionel Morand
Orange Labs
Email: lionel.morand@orange-ftgroup.com
 End of changes. 30 change blocks. 
69 lines changed or deleted 201 lines changed or added

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