< draft-ietf-ecrit-lost-09.txt		draft-ietf-ecrit-lost-10.txt >
	ECRIT T. Hardie		ECRIT T. Hardie
	Internet-Draft Qualcomm, Inc.		Internet-Draft Qualcomm, Inc.
	Intended status: Standards Track A. Newton		Intended status: Standards Track A. Newton
	Expires: September 29, 2008 American Registry for Internet		Expires: November 28, 2008 American Registry for Internet
	Numbers		Numbers
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	March 28, 2008		May 27, 2008
	LoST: A Location-to-Service Translation Protocol		LoST: A Location-to-Service Translation Protocol
	draft-ietf-ecrit-lost-09.txt		draft-ietf-ecrit-lost-10.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 September 29, 2008.		This Internet-Draft will expire on November 28, 2008.
	Abstract		Abstract
	This document describes an XML-based protocol for mapping service		This document describes an XML-based protocol for mapping service
	identifiers and geodetic or civic location information to service		identifiers and geodetic or civic location information to service
	contact URIs. In particular, it can be used to determine the		contact URIs. In particular, it can be used to determine the
	location-appropriate Public Safety Answering Point (PSAP) for		location-appropriate Public Safety Answering Point (PSAP) for
	emergency services.		emergency services.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43		15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43
	16. Internationalization Considerations . . . . . . . . . . . . . 50		16. Internationalization Considerations . . . . . . . . . . . . . 50
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51		17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51
	17.2. Content-type registration for 'application/lost+xml' . . . 51		17.2. Content-type registration for 'application/lost+xml' . . . 51
	17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53		17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53
	17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53		17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53
	17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54		17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 55		18. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57		19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59		20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
	20.1. Normative References . . . . . . . . . . . . . . . . . . . 59		20.1. Normative References . . . . . . . . . . . . . . . . . . . 60
	20.2. Informative References . . . . . . . . . . . . . . . . . . 60		20.2. Informative References . . . . . . . . . . . . . . . . . . 61
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 61		Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 62
	Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 75		Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
	Intellectual Property and Copyright Statements . . . . . . . . . . 77		Intellectual Property and Copyright Statements . . . . . . . . . . 78
	1. Introduction		1. Introduction
	Protocols such as NAPTR records and the Service Location Protocol		Protocols such as NAPTR records and the Service Location Protocol
	(SLP) can be used to discover servers offering a particular service.		(SLP) can be used to discover servers offering a particular service.
	However, for an important class of services the appropriate specific		However, for an important class of services the appropriate specific
	service instance depends both on the identity of the service and the		service instance depends both on the identity of the service and the
	geographic location of the entity that needs to reach it. Emergency		geographic location of the entity that needs to reach it. Emergency
	telecommunications services are an important example; here, the		telecommunications services are an important example; here, the
	service instance is a Public Safety Answering Point (PSAP) that has		service instance is a Public Safety Answering Point (PSAP) that has
	skipping to change at page 36, line 15 ¶		skipping to change at page 36, line 15 ¶
	required to forward a call to one of its neighbors; this is an		required to forward a call to one of its neighbors; this is an
	expected part of the overall emergency response system. In non-		expected part of the overall emergency response system. In non-
	emergency service use cases, the service deployment model should take		emergency service use cases, the service deployment model should take
	into account this issue as part of the provisioning model, as the		into account this issue as part of the provisioning model, as the
	combination of the data in the LoST server and the algorithm used for		combination of the data in the LoST server and the algorithm used for
	mapping determine which contact URIs are returned when shapes are		mapping determine which contact URIs are returned when shapes are
	used which overlap multiple service areas.		used which overlap multiple service areas.
	As a general guideline, any deployed matching algorithm should ensure		As a general guideline, any deployed matching algorithm should ensure
	that the algorithm used does not needlessly return NULL results if		that the algorithm used does not needlessly return NULL results if
	there are valid results for any portion of the shape.		there are valid results for any portion of the shape. If an
			authoritative server receives a query for which the area in the query
			overlaps the area for which the server has mapping information, then
			it MUST return either a mapping whose coverage area intersects the
			query area or a redirect to another server whose coverage area is a
			subset of the server's coverage area.
	When geodetic location information of this location profile is placed		When geodetic location information of this location profile is placed
	in the <serviceBoundary> element then the elements with geospatial		in the <serviceBoundary> element then the elements with geospatial
	coordinates are alternative descriptions of the same service region,		coordinates are alternative descriptions of the same service region,
	not additive geometries.		not additive geometries.
	12.3. Basic Civic Profile		12.3. Basic Civic Profile
	The basic-civic location profile is identified by the token 'civic'.		The basic-civic location profile is identified by the token 'civic'.
	Clients use this profile by placing a <civicAddress> element, defined		Clients use this profile by placing a <civicAddress> element, defined
	skipping to change at page 55, line 20 ¶		skipping to change at page 55, line 20 ¶
	attacker that can prevent the lookup of contact URIs can impair the		attacker that can prevent the lookup of contact URIs can impair the
	reachability of such services. An attacker that can eavesdrop on the		reachability of such services. An attacker that can eavesdrop on the
	communication requesting this lookup can surmise the existence of an		communication requesting this lookup can surmise the existence of an
	emergency and possibly its nature, and may be able to use this to		emergency and possibly its nature, and may be able to use this to
	launch a physical attack on the caller.		launch a physical attack on the caller.
	To avoid an attacker modifying the query or its result, TLS MUST be		To avoid an attacker modifying the query or its result, TLS MUST be
	implemented and SHOULD be used. Use is RECOMMENDED both for clients'		implemented and SHOULD be used. Use is RECOMMENDED both for clients'
	queries to servers and for queries among servers; this latter		queries to servers and for queries among servers; this latter
	recommendation is to help avoid LoST cache poisoning attacks by		recommendation is to help avoid LoST cache poisoning attacks by
	replacing answers given to caching LoST servers. The use of server		replacing answers given to caching LoST servers.
	identity checks is also RECOMMENDED, as described in [4] .
	In emergency service use cases, it is likely that deployments will		The use of server identity checks with TLS, as described in Section
	see a large number of inputs to the U-NAPTR algorithm resolving to a		3.1 of [4] is also RECOMMENDED. Omitting the server identity check
	single server. This is because local organizations will likely be		allows an attacker to masquerade as a LoST server, so this approach
	permitted or even encouraged to use LoST servers provided by the		should be used only when getting any answer, even from a potentially
	local emergency services authority. This makes the use of		malicious LoST server, is preferred over closing the connection (and
	alternatives to server identity which would check the input to the		thus not getting any answer at all). The host name compared against
	U-NAPTR algorithm against the certificates provided by the LoST		the server certificate is the host name in the URI, not the DNS name
	server impractical, as the list of organizations using it would be		used as input to NAPTR resolution.
	large, subject to rapid change, and unknown to the LoST server
	operator. The use of server identity does leave open the possibility		Note that the security considerations in [22] recommend comparing the
	of DNS cache poisoning attacks, as the NAPTR records may be altered		input of NAPTR resolution to the certificate, not the output (host
	by an attacker. U-NAPTR recommends DNSSEC [20] as protection. While		name in the URI). This approach was not chosen because in emergency
			service use cases, it is likely that deployments will see a large
			number of inputs to the U-NAPTR algorithm resolving to a single
			server, typically run by a local emergency services authority. In
			this case, checking the input to the NAPTR resolution against the
			certificates provided by the LoST server would be impractical, as the
			list of organizations using it would be large, subject to rapid
			change, and unknown to the LoST server operator.
			The use of server identity does leave open the possibility of DNS
			based attacks, as the NAPTR records may be altered by an attacker. he
			attacks include, for example, interception of DNS packets between the
			client and the recursive name server, DNS cache poisoning, and
			intentional modifications by the recursive name server; see [23] for
			more comprehensive discussion.
			DNSSEC [20] can be used to protect against these threats. While
	DNSSEC is incompletely deployed, users should be aware of the risk,		DNSSEC is incompletely deployed, users should be aware of the risk,
	particularly when they are requesting NAPTR records for domains or		particularly when they are requesting NAPTR records in environments
	from servers with which they have no previous trust relationship.		where the local recursive name server, or the network between the
			client and the local recursive name server, is not considered
			trustworthy.
			LoST deployments which are unable to use DNSSEC and unwilling to
			trust DNS resolution without DNSSEC, cannot use the NATPR-based
			discovery of LoST servers as-is. When suitable configuration
			mechanisms are available, one possibility is to configure the LoST
			server URIs (instead of the domain name to be used for NAPTR
			resolution) directly. Future specifications for applying LoST in
			non-emergency services may also specify additional discovery
			mechanisms and name matching semantics.
	Generally, LoST servers will not need to authenticate or authorize		Generally, LoST servers will not need to authenticate or authorize
	clients presenting mapping queries. If they do, an authentication of		clients presenting mapping queries. If they do, an authentication of
	the underlying transport mechanism, such as HTTP basic and digest		the underlying transport mechanism, such as HTTP basic and digest
	authentication MAY be used. Basic Authentication SHOULD only be used		authentication MAY be used. Basic Authentication SHOULD only be used
	in combination with TLS.		in combination with TLS.
	A more detailed description of threats and security requirements are		A more detailed description of threats and security requirements are
	provided in [17]. The threats and security requirements in non-		provided in [17]. The threats and security requirements in non-
	emergency service uses of LoST may be considerably different from		emergency service uses of LoST may be considerably different from
	skipping to change at page 58, line 9 ¶		skipping to change at page 58, line 9 ¶
	o Ron Watro and Richard Barnes (expiry of cached data)		o Ron Watro and Richard Barnes (expiry of cached data)
	o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James		o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James
	Winterbottom (Indication of PSAP Confidence Level)		Winterbottom (Indication of PSAP Confidence Level)
	o Martin Thomson (service boundary references)		o Martin Thomson (service boundary references)
	o Martin Thomson (service URN in LoST response message)		o Martin Thomson (service URN in LoST response message)
	o Cullen Jennings (service boundaries)
	o Clive D.W. Feather, Martin Thomson (Validation Functionality)		o Clive D.W. Feather, Martin Thomson (Validation Functionality)
	o Roger Marshall (PSAP Preference in LoST response)		o Roger Marshall (PSAP Preference in LoST response)
	o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,		o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,
	Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.		Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.
	Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-		Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-
	Francois Mule, Pierre Desjardins (Location Profiles)		Francois Mule, Pierre Desjardins (Location Profiles)
	o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,		o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,
	skipping to change at page 58, line 52 ¶		skipping to change at page 58, line 50 ¶
	o Wonsang Song		o Wonsang Song
	o Jong-Yul Kim		o Jong-Yul Kim
	o Anna Makarowska		o Anna Makarowska
	o Krzysztof Rzecki		o Krzysztof Rzecki
	o Blaszczyk Piotr		o Blaszczyk Piotr
	We would like to thank Jon Peterson for his IESG review comments.		We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault,
			and Tim Polk for their IESG review comments. Blocking IESG comments
			were also received from Pasi Eronen (succeeding Sam Hartman's review)
			and Cullen Jennings. Adjustments have been made to several pieces of
			text to satisfy these requests for changes, most notably in the
			Security Considerations and in the discussion of redirection in the
			presence of overlapping coverage areas.
	20. References		20. References
	20.1. Normative References		20.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434,		Considerations Section in RFCs", BCP 26, RFC 2434,
	skipping to change at page 61, line 5 ¶		skipping to change at page 61, line 44 ¶
	progress), September 2007.		progress), September 2007.
	[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
	[21] Rosen, B. and J. Polk, "Best Current Practice for		[21] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008.		draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008.
			[22] Daigle, L. and A. Newton, "Domain-Based Application Service
			Location Using SRV RRs and the Dynamic Delegation Discovery
			Service (DDDS)", RFC 3958, January 2005.
			[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
			System (DNS)", RFC 3833, August 2004.
	URIs		URIs
	[22] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/		[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/
	RelaxNG>		RelaxNG>
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax		Appendix A. Non-Normative RELAX NG Schema in XML Syntax
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<grammar ns="urn:ietf:params:xml:ns:lost1"		<grammar ns="urn:ietf:params:xml:ns:lost1"
	xmlns="http://relaxng.org/ns/structure/1.0"		xmlns="http://relaxng.org/ns/structure/1.0"
	xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"		xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
	datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">		datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
	skipping to change at page 76, line 7 ¶		skipping to change at page 77, line 7 ¶
	</define>		</define>
	</div>		</div>
	</grammar>		</grammar>
	Figure 21		Figure 21
	Appendix B. Examples On-line		Appendix B. Examples On-line
	The XML examples and Relax NG schemas may be found on-line [22].		The XML examples and Relax NG schemas may be found on-line [24].
	Authors' Addresses		Authors' Addresses
	Ted Hardie		Ted Hardie
	Qualcomm, Inc.		Qualcomm, Inc.
	Email: hardie@qualcomm.com		Email: hardie@qualcomm.com
	Andrew Newton		Andrew Newton
	American Registry for Internet Numbers		American Registry for Internet Numbers
End of changes. 14 change blocks.
	33 lines changed or deleted		75 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/