draft-ietf-dime-extended-naptr-08.txt   draft-ietf-dime-extended-naptr-09.txt 
Diameter Maintenance and Extensions M. Jones Diameter Maintenance and Extensions M. Jones
(DIME) Bridgewater Systems (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 L. Morand Intended status: Standards Track L. Morand
Expires: November 10, 2011 Orange Labs Expires: February 4, 2012 Orange Labs
May 9, 2011 August 3, 2011
Diameter S-NAPTR Usage Diameter S-NAPTR Usage
draft-ietf-dime-extended-naptr-08 draft-ietf-dime-extended-naptr-09
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 mechanisms do not reveal the Diameter applications However, these mechanisms do not reveal the Diameter applications
that each node supports. A peer outside the realm would have to that each node supports. A peer outside the realm would have to
perform a Diameter capability exchange with every node until it perform a Diameter capability exchange with every node until it
discovers one that supports the required application. This document discovers one that supports the required application. This document
updates [RFC3588] and describes an improvement using an extended updates RFC3588 "Diameter Base Protocol" and describes an improvement
format for the Straightforward-Naming Authority Pointer (S-NAPTR) using an extended format for the Straightforward-Naming Authority
Application Service Tag that allows for discovery of the supported Pointer (S-NAPTR) Application Service Tag that allows for discovery
applications without doing Diameter capability exchange beforehand. of the supported applications without doing Diameter capability
exchange 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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 10, 2011. This Internet-Draft will expire on February 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3
3.1. IETF Standard Track Diameter Applications . . . . . . . . 4 3.1. IETF Standard Track Diameter Applications . . . . . . . . 4
3.2. Vendor-specific Diameter Applications . . . . . . . . . . 4 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 5
4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5
5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5
6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 8 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 8
7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 8 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 9
7.4. Vendor-Specific Diameter Application Service Tags . . . . 9 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 9
7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 9 7.4. Vendor-Specific Diameter Application Service Tags . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 Naming Authority Pointer (NAPTR) query implementation performing a Naming Authority Pointer (NAPTR) query
[RFC3403] for a server in a particular realm. These NAPTR records [RFC3403] for a server in a particular realm. These NAPTR records
provide a mapping from a domain, to the SRV record [RFC2782] or provide a mapping from a domain, to the DNS Service Locator (SRV)
A/AAAA record [RFC1035][RFC3596] for contacting a server with the record [RFC2782] or A/AAAA record [RFC1035][RFC3596] for contacting a
specific transport protocol in the NAPTR services field. server with the specific 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 Straightforward-NAPTR (S-NAPTR) Dynamic document is based on the Straightforward-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 Protocol 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.
skipping to change at page 4, line 9 skipping to change at page 4, line 9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32 ; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character. ; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive. ; The service-parms are considered case-insensitive.
This specification refines the "iana-registered-service" tag This specification refines the "iana-registered-service" tag
definition for the discovery of Diameter agents supporting a specific definition for the discovery of Diameter agents supporting a specific
Diameter application as defined below. Diameter application as defined below.
iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM iana-registered-service =/ aaa-service
aaa-service = "aaa+ap" appln-id aaa-service = "aaa+ap" appln-id
appln-id = 1*DIGIT appln-id = 1*10DIGIT
; Application identifier expressed as a ; Application identifier expressed as
; decimal integer. ; 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 This specification also refines the "iana-registered-protocol" tag
definition for the discovery of Diameter agents supporting a specific definition for the discovery of Diameter agents supporting a specific
Diameter transport protocol as defined below. Diameter transport protocol as defined below.
iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM iana-registered-protocol =/ aaa-protocol /
aaa-protocol = "diameter." aaa-transport aaa-protocol = "diameter." aaa-transport
aaa-transport = "tcp" / "sctp" / "tls.tcp" 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 that it shares
semantics with any other specifications that create registry entries
with the same format.
The S-NAPTR Application Service and Protocol tags defined by this
specification are unrelated to the IANA Service Name and Transport
Protocol Port Number Registry (see [I-D.ietf-tsvwg-iana-ports]).
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]). of [RFC1035]).
3.1. IETF Standard Track Diameter Applications 3.1. IETF Standard Track Diameter Applications
A Diameter agent MUST be capable of using the extended S-NAPTR A Diameter agent MUST be capable of using the extended S-NAPTR
Application Service Tag for dynamic discovery of a Diameter agent Application Service Tag for dynamic discovery of a Diameter agent
supporting Standard Track applications. Therefore, every IETF supporting Standard Track applications. Therefore, every IETF
Standard Track Diameter application MUST be associated with a "aaa- Standard Track Diameter application MUST be associated with a "aaa-
skipping to change at page 7, line 11 skipping to change at page 7, line 32
this document. The Diameter implementation resolves the this document. The Diameter implementation resolves the
"replacement" field entry to a target host using the lookup method "replacement" field entry to a target host using the lookup method
appropriate for the "flags" field and attempts to connect using appropriate for the "flags" field and attempts to connect using
all supported transport protocols following the order specified in all supported transport protocols following the order specified in
section 2.1 of [RFC3588]. section 2.1 of [RFC3588].
f. If the target realm does not support NAPTR-based Diameter peer f. 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.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 that 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.stcp" ""
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.stcp" ""
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
TLS/TCP via hosts server1.ex2.example.com and server2.ex2.example.com
respectively.
6. 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 (Capabilities- communicated during Diameter capability negotiation (Capabilities-
Exchange-Request and Capabilities-Exchange-Answer message exchange). Exchange-Request and Capabilities-Exchange-Answer message exchange).
For this reason, NAPTR-based Diameter peer discovery for an For this reason, NAPTR-based Diameter peer discovery for an
application defining client/server roles should only be used by a application defining client/server roles should only be used by a
client to discover servers. client to discover servers.
skipping to change at page 9, line 41 skipping to change at page 11, line 14
Application Protocol Tag registry created by [RFC3958]. 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 |
+------------------+----------+ +------------------+----------+
Future Diameter versions which 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 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.
9. Acknowledgments 9. Acknowledgments
We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Sebastien
Morand and Sebastien Decugis for their comprehensive review comments. Decugis, Dan Romascanu, Adrian Farrel, David Harrington, Pete
Resnick, Robert Sparks, Stephen Farrell, Wesley Eddy, Ralph Droms and
Joe Touch and for their comprehensive review comments.
10. Editor's Notes 10. Editor's Notes
This section to be removed prior to publication. This section to be removed prior to publication.
This draft updates sections of RFC3588 that are also being updated by This draft updates sections of RFC3588 that are also being updated by
RFC3588bis. At the time this draft was started, it was uncertain RFC3588bis. At the time this draft was started, it was uncertain
whether RFC3588bis would be published first. The authors of this whether RFC3588bis would be published first. The authors of this
draft decided to proceed optimistically assuming this draft would be draft decided to proceed optimistically assuming this draft would be
published first with the understanding that minor updates are published first with the understanding that minor updates are
skipping to change at page 10, line 38 skipping to change at page 12, line 19
draft would come along later to add the application-specific S-NAPTR draft would come along later to add the application-specific S-NAPTR
entries (e.g."aaa+ap5:diameter.sctp"). entries (e.g."aaa+ap5:diameter.sctp").
Depending on the publication order, the S-NAPTR Application Service Depending on the publication order, the S-NAPTR Application Service
Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags
values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need
to be removed either from this draft or RFC3588bis. to be removed either from this draft or RFC3588bis.
11. Normative References 11. Normative References
[I-D.ietf-tsvwg-iana-ports]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry",
draft-ietf-tsvwg-iana-ports-10 (work in progress),
February 2011.
[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.
 End of changes. 15 change blocks. 
31 lines changed or deleted 113 lines changed or added

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