< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/