draft-ietf-sipcore-locparam-00.txt | draft-ietf-sipcore-locparam-01.txt | |||
---|---|---|---|---|
SIPCORE J. Winterbottom | SIPCORE J. Winterbottom | |||
Internet-Draft Winterb Consulting Services | Internet-Draft Winterb Consulting Services | |||
Updates: RFC6442 (if approved) R. Jesske | Updates: RFC6442 (if approved) R. Jesske | |||
Intended status: Standards Track Deutsche Telekom | Intended status: Standards Track Deutsche Telekom | |||
Expires: February 3, 2019 B. Chatras | Expires: July 6, 2019 B. Chatras | |||
Orange Labs | Orange Labs | |||
A. Hutton | A. Hutton | |||
Unify | Unify | |||
August 2, 2018 | January 2, 2019 | |||
Location Source Parameter for the SIP Geolocation Header Field | Location Source Parameter for the SIP Geolocation Header Field | |||
draft-ietf-sipcore-locparam-00.txt | draft-ietf-sipcore-locparam-01.txt | |||
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 location value. Knowing the identity of the | |||
node adding the location value allows the recipient more freedom in | node adding the location value 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. | the order of the location values. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
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 February 3, 2019. | This Internet-Draft will expire on July 6, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. 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 . . . . . . . . . . . . . . . . . . . 5 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
8.1. Registration of loc-src Parameter for geolocation header | 8.1. Registration of loc-src Parameter for geolocation header | |||
field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | field . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 7 | 10.2. Informative References . . . . . . . . . . . . . . . . . 7 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | 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. The specification | message is conveying location information. The specification | |||
suggests that only one location value should be conveyed. However, | suggests that only one location value should be conveyed. However, | |||
some communications architectures, such as 3GPP [TS23-167] and ETSI | some communications architectures, such as 3GPP [TS23-167] and ETSI | |||
[M493], prefer to use information provided by edge-proxies or | [M493], prefer to use information provided by edge-proxies or | |||
acquired through the use of core-network nodes, before using | acquired through the use of core-network nodes, before using | |||
skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 39 ¶ | |||
This document adds a location-source (loc-src) parameter to the | This document adds a location-source (loc-src) parameter to the | |||
location values in [RFC6442] so that the entity adding the location | location values in [RFC6442] so that the entity adding the location | |||
value to geolocation header field can identify itself using its | value to geolocation header field can identify itself using its | |||
hostname. How the entity adding the location value to the header | hostname. How the entity adding the location value to the 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", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
3. Rationale | 3. Rationale | |||
The primary intent of the parameter defined in this specific is for | The primary intent of the parameter defined in this specific is for | |||
use in emergency calling. There are various architectures defined | use in emergency calling. There are various architectures defined | |||
for providing emergency calling using SIP-based messaging. Each has | for providing emergency calling using SIP-based messaging. Each has | |||
it own characteristics with corresponding pros and cons. All of them | it own characteristics with corresponding pros and cons. All of them | |||
allow the UE to provide location information, however, many also | allow the UE to provide location information, however, many also | |||
attach other sources of location information to support veracity | attach other sources of location information to support veracity | |||
checks, provide backup information, or to be used as the primary | checks, provide backup information, or to be used as the primary | |||
skipping to change at page 5, line 22 ¶ | skipping to change at page 5, line 24 ¶ | |||
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 location values. The first | |||
location value points to a PIDF-LO in the SIP body using a content- | location value 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 proxy | The second location value is an https URI the provided by a proxy | |||
which identifies itself using the loc-src parameter. | which identifies itself using the loc-src parameter. | |||
INVITE sips:bob@biloxi.example.com SIP/2.0 | INVITE sip:bob@biloxi.example.com SIP/2.0 | |||
Via: SIPS/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 <sips:bob@biloxi.example.com> | To: Bob <sip:bob@biloxi.example.com> | |||
From: Alice <sips: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 | |||
Geolocation-Routing: yes | Geolocation-Routing: yes | |||
Accept: application/sdp, application/pidf+xml | Accept: application/sdp, application/pidf+xml | |||
CSeq: 31862 INVITE | CSeq: 31862 INVITE | |||
Contact: <sips: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 loc-src parameter | described in [RFC6442]. While the addition of the loc-src parameter | |||
does provide an indicator of the entity that added the location in | does provide an indicator of the entity that added the location in | |||
skipping to change at page 6, line 9 ¶ | skipping to change at page 6, line 15 ¶ | |||
7. Security Considerations | 7. Security Considerations | |||
This document introduces the ability of a proxy or middle box to | This document introduces the ability of a proxy or middle box to | |||
insert a host name indicating the that they added the specific | insert a host name indicating the that they added the specific | |||
location value to the geolocation header field. The intent is for | location value to the geolocation header field. The intent is for | |||
this field to be used by the location recipient in the event that the | this field to be used by the location recipient in the event that the | |||
SIP message contains multiple location values. As a consequence this | SIP message contains multiple location values. As a consequence this | |||
parameter should only be used by the location recipient in a trusted | parameter should only be used by the location recipient in a trusted | |||
network. | network. | |||
As already stated in [RFC6442] securing the location hop- by-hop, | ||||
using TLS, protects the message from eavesdropping and modification | ||||
in transit, but exposes the information to all proxies on the path as | ||||
well as the endpoint. The service provider has to take care is | ||||
scenarios when location information is leaving it's own network that | ||||
the receiving network is trustworthy to handle the information | ||||
properly. If such trustworthines is not given it is 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 of wrong interpretation of | |||
loc-src the value may be discarded when passed to an other domain. | loc-src the value may be discarded when passed to an other domain. | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. Registration of loc-src Parameter for geolocation header field | 8.1. Registration of loc-src Parameter for geolocation header field | |||
skipping to change at page 7, line 21 ¶ | skipping to change at page 7, line 33 ¶ | |||
[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>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
10.2. Informative References | 10.2. Informative References | |||
[M493] European Telecommunications Standards Institute, | [M493] European Telecommunications Standards Institute, | |||
"Functional architecture to support European requirements | "Functional architecture to support European requirements | |||
on emergency caller location determination and transport", | on emergency caller location determination and transport", | |||
ES 203 178, V 1.1.1, Februar 2015. | ES 203 178, V 1.1.1, Februar 2015. | |||
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in | [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in | |||
Session Initiation Protocol (SIP) Messages", RFC 4483, | Session Initiation Protocol (SIP) Messages", RFC 4483, | |||
DOI 10.17487/RFC4483, May 2006, | DOI 10.17487/RFC4483, May 2006, | |||
End of changes. 14 change blocks. | ||||
15 lines changed or deleted | 30 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/ |