draft-ietf-sipcore-locparam-03.txt   draft-ietf-sipcore-locparam-04.txt 
SIPCORE J. Winterbottom SIPCORE J. Winterbottom
Internet-Draft Winterb Consulting Services Internet-Draft Winterb Consulting Services
Updates: RFC6442 (if approved) R. Jesske Updates: 6442 (if approved) R. Jesske
Intended status: Standards Track Deutsche Telekom Intended status: Standards Track Deutsche Telekom
Expires: March 19, 2020 B. Chatras Expires: April 10, 2020 B. Chatras
Orange Labs Orange Labs
A. Hutton A. Hutton
Atos Atos
September 16, 2019 October 8, 2019
Location Source Parameter for the SIP Geolocation Header Field Location Source Parameter for the SIP Geolocation Header Field
draft-ietf-sipcore-locparam-03.txt draft-ietf-sipcore-locparam-04
Abstract Abstract
There are some circumstances where a Geolocation header field may There are some circumstances where a Geolocation header field may
contain more than one location value. Knowing the identity of the contain more than one locationValue. Knowing the identity of the
node adding the location value allows the recipient more freedom in node adding the locationValue allows the recipient more freedom in
selecting the value to look at first rather than relying solely on selecting the value to look at first rather than relying solely on
the order of the location values. This document defines the the order of the locationValues. This document defines the "loc-src"
location-source parameter so that the entity adding the location parameter so that the entity adding the locationValue to Geolocation
value to Geolocation header field can identify itself using its header field can identify itself using its hostname. This document
hostname. updates RFC 6442.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 19, 2020. This Internet-Draft will expire on April 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1. Registration of location-source parameter for Geolocation 8.1. Registration of loc-src parameter for Geolocation header
header field . . . . . . . . . . . . . . . . . . . . . . 6 field . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The SIP Geolocation specification [RFC6442] describes the The SIP Geolocation specification [RFC6442] describes the
"Geolocation" SIP header field which is used to indicate that the SIP "Geolocation" SIP header field which is used to indicate that the SIP
message is conveying location information. [RFC6442] specifies that message is conveying location information. [RFC6442] specifies that
SIP intermediaries should not add location values to a SIP request SIP intermediaries should not add locationValues to a SIP request
that already contains location value. [RFC6442] also states that if that already contains locationValue. [RFC6442] also states that if a
a SIP intermediary adds location it is fully responsible for SIP intermediary adds location it is fully responsible for addressing
addressing the concerns of any 424 (Bad Location Information) SIP the concerns of any 424 (Bad Location Information) SIP response it
response it receives. However, some communications architectures, receives. However, some communications architectures, such as 3GPP
such as 3GPP [TS23-167] and ETSI [M493], prefer to use information [TS23-167] and ETSI [M493], prefer to use information provided by
provided by edge-proxies or acquired through the use of core-network edge proxies or acquired through the use of core-network nodes,
nodes, before using information provided solely by user equipment before using information provided solely by user equipment (UE).
(UE). These solutions don't preclude the use of UE provided location These solutions don't preclude the use of UE provided location but
but require a means of being able to distinguish the identity of the require a means of being able to distinguish the identity of the node
node adding the location value to the SIP message from that provided adding the locationValue to the SIP message from that provided by the
by the UE. UE.
[RFC6442] stipulates that the order of location values in the [RFC6442] stipulates that the order of locationValues in the
Geolocation header field is the same as the order in which they were Geolocation header field is the same as the order in which they were
added to the header field. Whilst this order provides guidance to added to the header field. Whilst this order provides guidance to
the recipient as to which values were added to the message earlier in the recipient as to which values were added to the message earlier in
the communication chain, it does not provide any indication of which the communication chain, it does not identify which node added the
node actually added the location value. Knowing the identity of the locationValue. Knowing the identity of the entity that added the
entity that added the location to the message allows the recipient to location to the message allows the recipient to choose which location
choose which location to consider first rather than relying solely on to consider first rather than relying solely on the order of the
the order of the location values in the Geolocation header field. locationValues in the Geolocation header field.
This document extends the Geolocation header field, by allowing an This document extends the Geolocation header field, by allowing an
entity adding the location value to identity itself using a hostname. entity adding the locationValue to identity itself using a hostname.
This is done by defining a new geoloc-param header field parameter, This is done by defining a new geoloc-param header field parameter,
location-source."How the entity adding the location value to the "loc-src"."How the entity adding the locationValue to the header
header field obtains the location information is out of scope of this field obtains the location information is out of scope of this
document. document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Rationale 3. Rationale
The primary intent of the location-source parameter in this The primary intent of the "loc-src" parameter in this specification
specification is for use in emergency calling. There are various is for use in emergency calling. There are various architectures
architectures defined for providing emergency calling using SIP-based defined for providing emergency calling using SIP-based messaging.
messaging. Each has it own characteristics with corresponding pros
and cons. All of them allow the UE to provide location information,
however, many also attach other sources of location information to
support veracity checks, provide backup information, or to be used as
the primary location.
This document makes no attempt to comment on these various Each has it own characteristics with corresponding pros and cons.
architectures or the rationale for them wishing to include multiple All of them allow the UE to provide location information, however,
location values. It does recognize that these architectures exist many also attach other sources of location information to support
and that there is a need to identify the entity adding the location veracity checks, provide backup information, or to be used as the
information. primary location.
The location-source parameter adds the location source generating the This document does not comment on these various architectures or on
location value to increase the trustworthiness of the location the rationale for including multiple locationValues. It does
recognize that these architectures exist and that there is a need to
identify the entity adding the location information.
The "loc-src" parameter adds the location source generating the
locationValue to increase the trustworthiness of the location
information. information.
The location-source parameter is applicable within a single private The "loc-src" parameter is applicable within a single private
administrative domain or between different administrative domains administrative domain or between different administrative domains
where there is a trust relationship between the domains. Thus it is where there is a trust relationship between the domains. Thus it is
intended to use this parameter only in trust domains where Spec(T) as intended to use this parameter only in trust domains where Spec(T) as
described in [RFC3325] exists. described in [RFC3325] exists.
The location-source parameter is not included in a SIP message sent The "loc-src" parameter is not included in a SIP message sent to
to another network if there is no trust relationship. The The another network if there is no trust relationship. The "loc-src"
location-source parameter is not applicable if the administrative parameter is not applicable if the administrative domain manages
domain manages emergency calls in a way that does not require any emergency calls in a way that does not require any generation of the
generation of the location. location.
The functional architecture described within ETSI [M493] is an The functional architecture described within ETSI [M493] is an
example of architecture where this parameter makes sense to be used. example of an architecture where it makes sense to use this
parameter.
4. Mechanism 4. Mechanism
The mechanism employed adds a parameter to the location value defined The mechanism adds a geoloc-param parameter to the locationValue
in [RFC6442] that identifies the hostname of the entity adding the defined in [RFC6442] that identifies the hostname of the entity
location value to the Geolocation header field. The Augmented BNF adding the locationValue to the Geolocation header field. The
(ABNF) [RFC5234] for this parameter is shown in Figure 1. Augmented BNF (ABNF) [RFC5234] for this parameter is shown in
Figure 1.
location-source = "loc-src" EQUAL hostname location-source = "loc-src" EQUAL hostname
hostname = <defined in RFC3261> hostname = <defined in RFC3261>
Figure 1: Location Source Figure 1: Location Source
Only a fully qualified host name is valid. The syntax does not Only a fully qualified host name is valid. The syntax does not
support IP addresses, and if an entity conforming to this support IP addresses, and if an entity conforming to this
specification receives a Geolocation header field with a location- specification receives a Geolocation header field with a "loc-src"
source parameter containing an IP address then the parameter MUST be parameter containing an IP address then the parameter MUST be
removed. removed.
A SIP intermediarity conformant to this specification adding a A SIP intermediary conformant to this specification adding a
location value to a Geolocation header field SHOULD also add a locationValue to a Geolocation header field SHOULD also add a "loc-
location-source header field parameter so that it is clearly src" header field parameter so that it is clearly identified as the
identified as the node adding the location. A UA MUST NOT insert a node adding the location. A UA MUST NOT insert a "loc-src" header
location-source header field parameter. If a SIP intermediarity field parameter. If a SIP intermediary receives a message from an
receives a message from an untrusted source with the location-source untrusted source with the "loc-src" parameter set then it MUST remove
parameter set then it MUST remove the location-source parameter the "loc-src" parameter before passing the message into a trusted
before passing the message into a trusted network. network.
5. Example 5. Example
The following example shows a SIP INVITE message containing a The following example shows a SIP INVITE message containing a
Geolocation header field with two location values. The first Geolocation header field with two locationValues. The first
location value points to a PIDF-LO in the SIP body using a content- locationValue points to a PIDF-LO in the SIP body using a content-
indirection (cid:) URI per [RFC4483] and this is provided by the UE. indirection (cid:) URI per [RFC4483] and this is provided by the UE.
The second location value is an https URI the provided by a SIP The second locationValue is an https URI provided by a SIP
intermediarity which identifies itself using the location-source intermediary which identifies itself using the "loc-src" parameter.
parameter.
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com>, Geolocation: <cid:target123@atlanta.example.com>,
<https://lis.example.com:8222/y77syc7cuecbh>; <https://lis.example.com:8222/y77syc7cuecbh>;
loc-src=edgeproxy.example.com loc-src=edgeproxy.example.com
skipping to change at page 5, line 51 skipping to change at page 5, line 50
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sip:alice@atlanta.example.com> Contact: <sip:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
Figure 2: Example Location Request. Figure 2: Example Location Request.
6. Privacy Considerations 6. Privacy Considerations
This document doesn't change any of the privacy considerations This document doesn't change any of the privacy considerations
described in [RFC6442]. While the addition of the location-source described in [RFC6442]. While the addition of the "loc-src"
parameter does provide an indicator of the entity that added the parameter identifies the entity that added the location in the
location in the signaling path this provides little more exposure signaling path, this addition provides little more exposure than
than a proxy identity being added to the record-route header field. adding a proxy identity to the Record-Route header field.
7. Security Considerations 7. Security Considerations
This document introduces the ability of a SIP intermediarity to This document introduces the ability of a SIP intermediary to insert
insert a host name indicating that they added the specific location a host name indicating that they added the specific locationValue to
value to the Geolocation header field. The intent is for this field the Geolocation header field. The intent is for this field to be
to be used by the location recipient in the event that the SIP used by the location recipient in the event that the SIP message
message contains multiple location values. As a consequence this contains multiple locationValues. As a consequence this parameter
parameter should only be used by the location recipient in a trusted should only be used by the location recipient in a trusted network.
network.
As already stated in [RFC6442] securing the location hop- by-hop, As already stated in [RFC6442] securing the location hop- by-hop,
using TLS, protects the message from eavesdropping and modification using TLS, protects the message from eavesdropping and modification
in transit, but exposes the information to all SIP intermediaries on in transit, but exposes the information to all SIP intermediaries on
the path as well as the endpoint. The location-source parameter is the path as well as the endpoint. The "loc-src" parameter is
applicable within a single private administrative domain or between applicable within a single private administrative domain or between
different administrative domains where there is a trust relationship different administrative domains where there is a trust relationship
between the domains. If such trust domain is not given it is between the domains. If such trust domain is not given it is
strongly recommended to delete the location information. strongly recommended to delete the location information.
The use of this parameter is not restricted to a specific The use of this parameter is not restricted to a specific
architecture but using multiples locations and loc-src may end in architecture but using multiples locations and loc-src may end in
compatibility issues. [RFC6442] already addresses the issue of compatibility issues. [RFC6442] already addresses the issue of
multiples locations. To avoid problems of wrong interpretation of multiples locations. To avoid problems with misinterpretation of the
loc-src the value may be removed when passed to an other domain. "loc-src" parameter, the value may be removed when passed to an other
domain.
8. IANA Considerations 8. IANA Considerations
8.1. Registration of location-source parameter for Geolocation header 8.1. Registration of loc-src parameter for Geolocation header field
field
This document calls for IANA to register a new SIP header parameter The IANA is asked to add a new SIP header field parameter for the
as per the guidelines in [RFC3261], which will be added to header Geolocation header field in the "Header Field Parameters and
sub-registry under http://www.iana.org/assignments/sip-parameters. Parameter Values" subregistry (created by [RFC3968]) of the "Session
Initiation Protocol (SIP) Parameters" registry found at
https://www.iana.org/assignments/sip-parameters/.
Header Field: Geolocation Header Field: Geolocation
Parameter Name: loc-src Parameter Name: loc-src
Predefined Values: No
Reference: this RFC
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Dale Worley and Christer Holmberg for The authors would like to thank Dale Worley, Christer Holmberg and
their extensive review of the draft The authors would like to Jean Mahoney for their extensive review of the draft. The authors
acknowledge the constructive feedback provided by Paul Kyzivat and would like to acknowledge the constructive feedback provided by Paul
Robert Sparks. Kyzivat and Robert Sparks.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
DOI 10.17487/RFC3968, December 2004,
<https://www.rfc-editor.org/info/rfc3968>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011, DOI 10.17487/RFC6442, December 2011,
<https://www.rfc-editor.org/info/rfc6442>. <https://www.rfc-editor.org/info/rfc6442>.
skipping to change at page 8, line 32 skipping to change at page 8, line 37
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz Str, 3-7 Heinrich-Hertz Str, 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: r.jesske@telekom.de Email: r.jesske@telekom.de
URI: www.telekom.de URI: www.telekom.de
Bruno Chatras Bruno Chatras
Orange Labs Orange Labs
38-40 rue du General Leclerc 44, avenue de la Republique
Issy Moulineaux Cedex 9 F-92794 Chatillon F-92320
France France
Email: bruno.chatras@orange.com Email: bruno.chatras@orange.com
Andrew Hutton Andrew Hutton
Atos Atos
Mid City Place Mid City Place
London WC1V 6EA London WC1V 6EA
UK UK
 End of changes. 35 change blocks. 
107 lines changed or deleted 113 lines changed or added

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