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 8 skipping to change at page 58, line 8
o James Polk (error handling) o James Polk (error handling)
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 51 skipping to change at page 58, line 49
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.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/