Internet Engineering Task Force (IETF) M. Barnes, Ed.
Request for Comments: 5985 Polycom
Category: Standards Track September 2010
ISSN: 2070-1721
HTTP-Enabled Location Delivery (HELD)
Abstract
This document defines a Layer 7 Location Configuration Protocol (L7
LCP) and describes the use of HTTP and HTTP/TLS as transports for the
L7 LCP. The L7 LCP is used for retrieving location information from
a server within an access network. It includes options for
retrieving location information in two forms: by value and by
reference. The protocol is an extensible application-layer protocol
that is independent of the session layer.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5985.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Barnes Standards Track [Page 1]
RFC 5985 HELD September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 6
4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 6
4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 7
4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 7
4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
5.1. Location Request . . . . . . . . . . . . . . . . . . . . . 9
5.2. Location Response . . . . . . . . . . . . . . . . . . . . 9
5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 10
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 11
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 15
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Assuring That the Proper LIS Has Been Contacted . . . . . 23
9.2. Protecting Responses from Modification . . . . . . . . . . 23
9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Examples of HTTPS Messages . . . . . . . . . . . . . . . . 25
10.2. Example of a Simple Location Request . . . . . . . . . . . 26
10.3. An Example of a Location Request for Multiple Location
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
11.3. MIME Media Type Registration for 'application/held+xml' . 29
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Barnes Standards Track [Page 2]
RFC 5985 HELD September 2010
Appendix A. HELD Compliance to IETF LCP Requirements . . . . . . 36
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 36
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 36
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 37
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 37
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 37
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 38
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 38
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 38
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 39
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 39
1. Introduction
The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document [RFC5687] provides some
scenarios in which a Device might rely on its access network to
provide location information. The Location Information Server (LIS)
service applies to access networks employing both wired technology
(e.g., DSL, cable) and wireless technology (e.g., WiMAX) with varying
degrees of Device mobility. This document describes a protocol that
can be used to acquire Location Information (LI) from a LIS within an
access network.
This specification identifies two types of location information that
may be retrieved from the LIS. Location may be retrieved from the
LIS by value; that is, the Device may acquire a literal location
object describing the location of the Device. The Device may also
request that the LIS provide a location reference in the form of a
Location URI or set of Location URIs, allowing the Device to
distribute its LI by reference. Both of these methods can be
provided concurrently from the same LIS to accommodate application
requirements for different types of location information.
This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of HTTP
and HTTP/TLS as transports for the protocol.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Barnes Standards Track [Page 3]
RFC 5985 HELD September 2010
This document uses the terms (and their acronym forms): Access
Provider (AP), Location Information (LI), Location Object (LO),
Device, Target, Location Generator (LG), Location Recipient (LR), and
Rule Maker (RM) and Rule Holder (RH) as defined in GEOPRIV
Requirements [RFC3693]. The terms Location Information Server (LIS),
Access Network, Access Provider (AP), and Access Network Provider are
used in the same context as defined in the L7 LCP Problem statement
and Requirements document [RFC5687]. The usage of the terms Civic
Location/Address and Geodetic Location follows the usage in many of
the referenced documents.
In describing the protocol, the terms "attribute" and "element" are
used according to their context in XML. The term "parameter" is used
in a more general protocol context and can refer to either an XML
"attribute" or "element".
3. Overview and Scope
This document describes an interface between a Device and a Location
Information Server (LIS). This document assumes that the LIS is
present within the same administrative domain as the Device (e.g.,
the access network). The LIS exists because not all Devices are
capable of determining LI, and because, even if a Device is able to
determine its own LI, it may be more efficient with assistance. This
document does not specify how LI is determined. An Access Provider
(AP) operates the LIS so that Devices (and Targets) can retrieve
their LI. This document assumes that the Device and Access Provider
have no prior relationship other than what is necessary for the
Device to obtain network access.
This document is based on the attribution of the LI to a Device and
not specifically a person (end user) or Target, based on the premise
that location determination technologies are generally designed to
locate a Device and not a person. It is expected that, for most
applications, LI for the Device can be used as an adequate substitute
for the end user's LI. Since revealing the location of the Device
almost invariably reveals some information about the location of the
user of the Device, the same level of privacy protection demanded by
a user is required for the Device. This approach may require either
some additional assurances about the link between Device and target,
or an acceptance of the limitation that unless the Device requires
active user authentication, there is no guarantee that any particular
individual is using the Device at that instant.
The following diagram shows the logical configuration of some of the
functional elements identified in [RFC3693] and the LIS defined in
[RFC5687]. It also shows where this protocol applies, with the Rule
Barnes Standards Track [Page 4]
RFC 5985 HELD September 2010
Maker and Target represented by the role of the Device. Note that
only the interfaces relevant to the Device are identified in the
diagram.
+---------------------------------------------+
| Access Network Provider |
| |
| +--------------------------------------+ |
| | Location Information Server | |
| | | |
| | | |
| | | |
| | | |
| +------|-------------------------------+ |
+----------|----------------------------------+
|
|
HELD
|
Rule Maker - - _ +-----------+ +-----------+
o - - | Device | | Location |
This document (RFC 5985) defines HELD messages.
Barnes Standards Track [Page 17]
RFC 5985 HELD September 2010
Barnes Standards Track [Page 18]
RFC 5985 HELD September 2010
Barnes Standards Track [Page 19]
RFC 5985 HELD September 2010
8. HTTP Binding
This section describes the use of HTTP [RFC2616] and HTTP over TLS
[RFC2818] as transport mechanisms for the HELD protocol, which a
conforming LIS and Device MUST support.
Although HELD uses HTTP as a transport, it uses a strict subset of
HTTP features, and due to the restrictions of some features, a LIS is
not a fully compliant HTTP server. It is intended that a LIS can
easily be built using an HTTP server with extensibility mechanisms
and that a HELD Device can trivially use existing HTTP libraries.
This subset of requirements helps implementors avoid ambiguity with
the many options that the full HTTP protocol offers.
A Device that conforms to this specification MAY choose not to
support HTTP authentication [RFC2617] or cookies [RFC2965]. Because
the Device and the LIS may not necessarily have a prior relationship,
the LIS SHOULD NOT require a Device to authenticate, either using the
above HTTP authentication methods or TLS client authentication.
Unless all Devices that access a LIS can be expected to be able to
authenticate in a certain fashion, denying access to location
information could prevent a Device from using location-dependent
services, such as emergency calling. Extensions to this protocol
might result in the addition of request parameters that a LIS might
use to decide to request Device authentication.
A HELD request is carried in the body of an HTTP POST request. The
Device MUST include a Host header in the request.
Barnes Standards Track [Page 20]
RFC 5985 HELD September 2010
The MIME type of HELD request and response bodies is
"application/held+xml". LIS and Device MUST provide this value in
the HTTP Content-Type and Accept header fields. If the LIS does not
receive the appropriate Content-Type and Accept header fields, the
LIS SHOULD fail the request, returning a 406 (not acceptable)
response. HELD responses SHOULD include a Content-Length header.
Devices MUST NOT use the "Expect" header or the "Range" header in
HELD requests. The LIS MAY return 501 (not implemented) errors if
either of these HTTP features are used. In the case that the LIS
receives a request from the Device containing an If-* (conditional)
header, the LIS SHOULD return a 412 (precondition failed) response.
The POST method is the only method REQUIRED for HELD. If a LIS
chooses to support GET or HEAD, it SHOULD consider the kind of
application doing the GET. Since a HELD Device only uses a POST
method, the GET or HEAD MUST be either an escaped URL (e.g., somebody
found a URL in protocol traces or log files and fed it into their
browser) or somebody doing testing/debugging. The LIS could provide
information in the HELD response indicating that the URL corresponds
to a LIS server and only responds to HELD POST requests, or the LIS
could instead try to avoid any leak of information by returning a
very generic HTTP error message such as 404 (not found).
The LIS populates the HTTP headers of responses so that they are
consistent with the contents of the message. In particular, the
"CacheControl" header SHOULD be set to disable caching of any PIDF-LO
document or Location URIs by HTTP intermediaries. Otherwise, there
is the risk of stale locations and/or the unauthorized disclosure of
the LI. This also allows the LIS to control any caching with the
HELD "expires" parameter. The HTTP status code MUST indicate a 2xx
series response for all HELD locationResponse and HELD error
messages.
The LIS MAY redirect a HELD request. A Device MUST handle redirects
by using the Location header provided by the server in a 3xx
response. When redirecting, the Device MUST observe the delay
indicated by the Retry-After header. The Device MUST authenticate
the server that returns the redirect response before following the
redirect, if a Device requires that the server is authenticated. A
Device SHOULD authenticate the LIS indicated in a redirect.
The LIS SHOULD support persistent connections and request pipelining.
If pipelining is not supported, the LIS MUST NOT allow persistent
connections. The Device MUST support termination of a response by
the closing of a connection.
Barnes Standards Track [Page 21]
RFC 5985 HELD September 2010
Implementations of HELD that implement HTTP transport MUST implement
transport over TLS [RFC2818]. TLS provides message integrity and
confidentiality between the Device and LIS. The Device MUST
implement the server authentication method described in Section 3.1
of [RFC2818], with an exception in how wildcards are handled. The
leftmost label MAY contain the wildcard string "*", which matches any
single domain name label. Additional characters in this leftmost
label are invalid (that is, "f*.example.com" is not a valid name and
does not match any domain name).
The Device uses the URI obtained during LIS discovery to authenticate
the server. The details of this authentication method are provided
in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device
SHOULD fail a request if server authentication fails, except in the
event of an emergency.
9. Security Considerations
HELD is a location acquisition protocol whereby the client requests
its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in
[RFC5687]. An in-depth discussion of the security considerations
applicable to the use of Location URIs and by-reference provision of
LI is included in [RFC5808].
By using the HELD protocol, the client and the LIS expose themselves
to two types of risk:
Accuracy: The client receives incorrect location information.
Privacy: An unauthorized entity receives location information.
The provision of an accurate and privacy- and confidentiality-
protected location to the requestor depends on the success of five
steps:
1. The client must determine the proper LIS.
2. The client must connect to the proper LIS.
3. The LIS must be able to identify the Device by its identifier (IP
address).
4. The LIS must be able to return the desired location.
5. HELD messages must be transmitted unmodified between the LIS and
the client.
Barnes Standards Track [Page 22]
RFC 5985 HELD September 2010
Of these, only steps 2, 3, and 5 are within the scope of this
document. Step 1 is based on either manual configuration or on the
LIS discovery defined in [RFC5986], in which appropriate security
considerations are already discussed. Step 4 is dependent on the
specific positioning capabilities of the LIS and is thus outside the
scope of this document.
9.1. Assuring That the Proper LIS Has Been Contacted
This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery [RFC5986]. When the HELD
transaction is conducted using TLS [RFC5246], the LIS can
authenticate its identity, either as a domain name or as an IP
address, to the client by presenting a certificate containing that
identifier as a subjectAltName (i.e., as an iPAddress or dNSName,
respectively). In the case of the HTTP binding described above, this
is exactly the authentication described by TLS [RFC2818]. If the
client has external information as to the expected identity or
credentials of the proper LIS (e.g., a certificate fingerprint),
these checks MAY be omitted. Any binding of HELD MUST be capable of
being transacted over TLS so that the client can request the above
authentication, and a LIS implementation for a binding MUST include
this feature. Note that in order for the presented certificate to be
valid at the client, the client must be able to validate the
certificate. In particular, the validation path of the certificate
must end in one of the client's trust anchors, even if that trust
anchor is the LIS certificate itself.
9.2. Protecting Responses from Modification
In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature
per Section 9.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route.
9.3. Privacy and Confidentiality
Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in Section 9.2,
transactions conducted over TLS with appropriate ciphersuites are
protected from access by unauthorized parties en route. Conversely,
in most cases, when not conducted over TLS, the response will be
accessible while en route from the LIS to the requestor.
Barnes Standards Track [Page 23]
RFC 5985 HELD September 2010
Because HELD is an LCP and identifies clients and targets by IP
addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address. The LIS MUST
verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target.
Note that this is a necessary, but not sufficient, criterion for
authorization. A LIS MAY deny requests according to any local
policy.
A prerequisite for meeting this requirement is that the LIS must have
some assurance of the identity of the client. Since the target of
the returned location is identified by an IP address, simply sending
the response to this IP address will provide sufficient assurance in
many cases. This is the default mechanism in HELD for assuring that
location is given only to authorized clients; LIS implementations
MUST support a mode of operation in which this is the only client
authentication.
Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing
attacks. A temporary spoofing of an IP address could mean that when
a Device requests a Location Object or Location URI, it receives
another Device's location because the attacker is able to receive
packets sent to the spoofed address. In addition, in cases where a
Device drops off the network for various reasons, the re-use of the
Device's IP address could result in another Device receiving the
original Device's location rather than its own location. These
exposures are limited by the following:
o Location URIs MUST have a limited lifetime, as reflected by the
value for the "expires" element in Section 6.5.2. The lifetime of
Location URIs necessarily depends on the nature of the access.
o The LIS and network SHOULD be configured so that the LIS is made
aware of Device movement within the network and addressing
changes. If the LIS detects a change in the network that results
in it no longer being able to determine the location of the
Device, then all Location URIs for that Device SHOULD be
invalidated.
The above measures are dependent on network configuration, which
SHOULD be considered. For instance, in a fixed Internet access,
providers may be able to restrict the allocation of IP addresses to a
single physical line, ensuring that spoofing is not possible; in such
an environment, additional measures may not be necessary.
Barnes Standards Track [Page 24]
RFC 5985 HELD September 2010
10. Examples
The following sections provide examples of basic HTTP/HTTPS, a simple
location request, and a location request for multiple location types,
along with the relevant location responses. To focus on important
portions of messages, the examples in Sections 10.2 and 10.3 do not
show HTTP/HTTPS headers or the XML prologue. In addition, sections
of XML not relevant to the example are replaced with comments.
10.1. Examples of HTTPS Messages
The examples in this section show complete HTTP/HTTPS messages that
include the HELD request or response document.
This example shows the most basic request for a LO. The POST
includes an empty "locationRequest" element.
POST /location HTTP/1.1
Host: lis.example.com:49152
Content-Type: application/held+xml;charset=utf-8
Content-Length: 87
Barnes Standards Track [Page 25]
RFC 5985 HELD September 2010
-34.407 150.88001
2006-01-11T03:42:28+00:00
Wiremap
2006-01-10T03:42:28+00:00
The error response to the request is an error document. The
following response shows an example error response.
HTTP/1.1 200 OK
Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private
Content-Type: application/held+xml;charset=utf-8
Content-Length: 182
Unable to determine location
10.2. Example of a Simple Location Request
The location request shown below doesn't specify any location types
or response time.
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
Barnes Standards Track [Page 26]
RFC 5985 HELD September 2010
An error response to this location request is shown below:
Location not available
10.3. An Example of a Location Request for Multiple Location Types
The following Location Request message includes a request for
geodetic, civic, and any Location URIs.
geodetic
civic
locationURI
The corresponding Location Response message includes the requested
location information, including two Location URIs.
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
-34.407242 150.882518
30
Barnes Standards Track [Page 27]
RFC 5985 HELD September 2010
AU
NSW
Wollongong
Gwynneville
Northfield Avenue
University of Wollongong
2
Andrew Corporation
2500
39
WS-183
U40
false
2007-05-25T12:35:02+10:00
Wiremap
2007-05-24T12:35:02+10:00
11. IANA Considerations
IANA has made the registrations detailed in the following sections.
11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.ietf.barnes@gmail.com).
Barnes Standards Track [Page 28]
RFC 5985 HELD September 2010
XML:
BEGIN
HELD Messages
Namespace for HELD Messages
urn:ietf:params:xml:ns:geopriv:held
See RFC 5985
END
11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.ietf.barnes@gmail.com).
Schema: The XML for this schema can be found as the entirety of
Section 7 of this document.
11.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml
MIME media type name: application
MIME subtype name: held+xml
Required parameters: (none)
Optional parameters: charset
Same as the charset parameter of "application/xml" as specified in
RFC 3023 [RFC3023], Section 3.2.
Barnes Standards Track [Page 29]
RFC 5985 HELD September 2010
Encoding considerations: Same as the encoding considerations of
"application/xml" as specified in RFC 3023 [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry
protocol data related to the location of an entity, which could
include information that is considered private. Appropriate
precautions should be taken to limit disclosure of this
information.
Interoperability considerations: This content type provides a basis
for a protocol. There are multiple interoperable implementations
of this protocol.
Published specification: RFC 5985
Applications which use this media type: Location information
providers and consumers.
Additional Information:
Magic Number(s): (none)
File extension(s): .heldxml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Mary Barnes
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations
described there also apply to application/held+xml.
11.4. Error Code Registry
As defined in this document, IANA created a new registry for the HELD
protocol including an initial registry for error codes. The error
codes are included in HELD error messages as described in Section 6.3
and defined in the schema in the 'codeType' token in the XML schema
in Section 7.
The following is a summary of the registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD
Defining RFC: RFC 5985
Barnes Standards Track [Page 30]
RFC 5985 HELD September 2010
Registration/Assignment Procedures: Following the policies outlined
in [RFC5226], the IANA policy for assigning new values for the
Error codes for HELD is Standards Action: Values are assigned only
for Standards Track RFCs approved by the IESG.
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.ietf.barnes@gmail.com).
This section registers the following eight initial error codes as
described in Section 6.3:
requestError: This code indicates that the request was badly formed
in some fashion.
xmlError: This code indicates that the XML content of the request
was either badly formed or invalid.
generalLisError: This code indicates that an unspecified error
occurred at the LIS.
locationUnknown: This code indicates that the LIS could not
determine the location of the Device.
unsupportedMessage: This code indicates that the request was not
supported or understood by the LIS. This error code is used when
a HELD request contains a document element that is not supported
by the receiver.
timeout: This code indicates that the LIS could not satisfy the
request within the time specified in the "responseTime" parameter.
cannotProvideLiType: This code indicates that the LIS was unable to
provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to
"true".
notLocatable: This code indicates that the LIS is unable to locate
the Device and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in
Section 4.1.2.
Barnes Standards Track [Page 31]
RFC 5985 HELD September 2010
12. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived.
Their contact information is included below. They made additional
contributions to the WG document, including the XML schema.
James Winterbottom
Andrew
Andrew Building (39)
University of Wollongong
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Martin Thomson
Andrew
Andrew Building (39)
University of Wollongong
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Barbara Stark
BellSouth
Room 7A43
725 W Peachtree St.
Atlanta, GA 30308
US
EMail: barbara.stark@att.com
13. Acknowledgements
The author and contributors would like to thank the participants in
the GEOPRIV WG and the following people for their constructive input
and feedback on this document (in alphabetical order): Nadine Abbott,
Bernard Aboba, Eric Arolick, Richard Barnes (in particular, the
security considerations section), Peter Blatherwick, Ben Campbell,
Barnes Standards Track [Page 32]
RFC 5985 HELD September 2010
Guy Caron, Eddy Corbett, Martin Dawson, Lisa Dusseault, Robins
George, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Justusson,
Tat Lam, Marc Linsner, Patti McCalmont, Alexey Melnikov, Roger
Marshall, Tim Polk, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric
Rescorla, Dan Romascanu, Brian Rosen, John Schnizlein, Shida
Schubert, Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes
Tschofenig, and Karl Heinz Wolf.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986,
September 2010.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
.
Barnes Standards Track [Page 33]
RFC 5985 HELD September 2010
[W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
.
14.2. Informative References
[LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery".
[LOC-CONVEY]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", Work in Progress,
July 2010.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Barnes Standards Track [Page 34]
RFC 5985 HELD September 2010
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010.
Barnes Standards Track [Page 35]
RFC 5985 HELD September 2010
Appendix A. HELD Compliance to IETF LCP Requirements
This appendix describes HELD's compliance to the requirements
specified in [RFC5687].
A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding the
latter aspect, such an identifier is only appropriate if it is from
the same realm as the one for which the location information service
maintains identifier to location mapping."
COMPLY
HELD uses the IP address of the location request message as the
primary source of identity for the requesting Device or target. This
identity can be used with other contextual network information to
provide a physical location for the Target for many network
deployments. There may be network deployments where an IP address
alone is insufficient to identify a Target in a network. However,
any necessary identity extensions for these networks is beyond the
scope of this document.
A.2. L7-2: Mobility Support
"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
broad range of mobility from Devices that can only move between
reboots, to Devices that can change attachment points with the impact
that their IP address is changed, to Devices that do not change their
IP address while roaming, to Devices that continuously move by being
attached to the same network attachment point."
COMPLY
Mobility support is inherently a characteristic of the access network
technology, and HELD is designed to be access network agnostic.
Consequently, HELD complies with this requirement. In addition, HELD
provides specific support for mobile environments by providing an
optional responseTime attribute in location request messages.
Wireless networks often have several different mechanisms at their
disposal for position determination (e.g., assisted GPS versus
determining the location based on the identity of the serving base
station), each providing different degrees of accuracy and taking
different amounts of time to yield a result. The responseTime
parameter provides the LIS with a criterion which it can use to
select a location determination technique.
Barnes Standards Track [Page 36]
RFC 5985 HELD September 2010
A.3. L7-3: ASP and Access Network Provider Relationship
"The design of the L7 LCP MUST NOT assume a business or trust
relationship between the Application Service Provider (ASP) and the
Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document."
COMPLY
HELD describes a location acquisition protocol between a Device and a
LIS. In the context of HELD, the LIS is within the Access Network.
Thus, HELD is independent of the business or trust relationship
between the Application Service Provider (ASP) and the Access Network
Provider. Location acquisition using HELD is subject to the
restrictions described in Section 9.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes
needed to determine end system locations."
COMPLY
HELD was specifically designed with this model in mind and readily
allows itself to chaining requests between operators without a change
in protocol being required. HELD is a webservices protocol which can
be bound to transports other than HTTP, such as BEEP. Using a
protocol such as BEEP offers the option of high request throughput
over a dedicated connection between an L3 provider and an L2 provider
without incurring the serial restriction imposed by HTTP. This is
less easy to do with protocols that do not decouple themselves from
the transport.
A.5. L7-5: Legacy Device Considerations
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST consider legacy residential NAT Devices and Network Termination
Equipment (NTE) in an DSL environment that cannot be upgraded to
support additional protocols, for example to pass additional
information through DHCP."
Barnes Standards Track [Page 37]
RFC 5985 HELD September 2010
COMPLY
HELD is an application protocol and operates on top of IP. A HELD
request from a host behind a residential NAT will traverse the NAT
acquiring the external address of the home router. The location
provided to the host therefore will be the address of the home router
in this circumstance. No changes are required to the home router in
order to support this function, HELD was designed specifically to
address this deployment scenario.
A.6. L7-6: VPN Awareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that at least one end of a VPN is aware of the VPN
functionality. In an enterprise scenario, the enterprise side will
provide the LIS used by the client and can thereby detect whether the
LIS request was initiated through a VPN tunnel."
COMPLY
HELD does not preclude a LIS on the far end of a VPN tunnel from
being aware that the client request is occurring over that tunnel.
It also does not preclude a client Device from accessing a LIS
serving the local physical network and subsequently using the
location information with an application that is accessed over a VPN
tunnel.
A.7. L7-7: Network Access Authentication
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume prior network access authentication."
COMPLY
HELD makes no assumptions about prior network access authentication.
HELD strongly recommends the use of TLS with server-side certificates
for communication between the endpoint and the LIS. There is no
requirement for the endpoint to authenticate with the LIS.
A.8. L7-8: Network Topology Unawareness
"The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST NOT assume end systems being aware of the access network
topology. End systems are, however, able to determine their public
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
Barnes Standards Track [Page 38]
RFC 5985 HELD September 2010
COMPLY
HELD makes no assumption about the network topology. HELD doesn't
require that the Device know its external IP address, except where
that is required for discovery of the LIS.
A.9. L7-9: Discovery Mechanism
"The L7 LCP MUST define a single mandatory to implement discovery
mechanism."
COMPLY
HELD uses the discovery mechanism in [RFC5986].
A.10. L7-10: PIDF-LO Creation
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
element into the element of the presence document
(see RFC 4479). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to the
rules outlined in [now RFC 5941]."
COMPLY
HELD protocol overview (Section 4) describes the requirements on the
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
by the LIS MUST conform to [RFC5491].
Author's Address
Mary Barnes (editor)
Polycom
EMail: mary.ietf.barnes@gmail.com
Barnes Standards Track [Page 39]
RFC, FYI, BCP