One document matched: draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt
Geopriv WG James Polk
Internet-Draft Cisco Systems
Expires: April 26, 2009 October 26, 2008
Intended Status: Standards Track (PS)
Geopriv Concerns about SIP Location Conveyance
Retransmission Recommendations Document
draft-polk-geopriv-sip-lo-retrans-rec-concerns-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document expresses grave concerns about the recommendations
made in the 'Implications of <retransmission-allowed>' document,
which in turn states several recommendations towards the
modification of SIP Location Conveyance. This document makes
several counterproposals to what is currently in the 'Implications
of <retransmission-allowed>' document.
Polk Expires April 26, 2009 [Page 1]
Internet-Draft Retransmission Recommendation Concerns October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Objectives of this Document . . . . . . . . . . . . . . . . . 2
3. Goals of [ID-RETRANS] . . . . . . . . . . . . . . . . . . . . 3
4. Taking Issue with use of "Authorized Recipients" . . . . . . 3
5. Issues with new Location-Routing-Allowed header . . . . . . . 3
6. Issues with B2BUA/SBC Treatment of Location . . . . . . . . 5
7. Security considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement and Intellectual Property . . . . . 9
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 RFC 2119 [1].
1. Introduction
This document expresses grave concerns and a few alternate ways
forward with respect to the recommendations made in the
Implications of <retransmission-allowed> document [ID-RETRANS],
which in turn makes several recommendations towards the
modification of SIP Location Conveyance [ID-SIP-CON]. This
document makes several counterproposals to what is currently in
[ID-RETRANS].
This document will explicitly call out certain sections of text in
[ID-RETRANS], giving the reader the ability to see the original text
- while pondering the arguments against what is said in that
document.
2. Objectives of this Document
The objectives of this document are to call out what the author
believes are undesirable consequences of [ID-RETRANS], as well as a
few alternate proposals (i.e., counter-recommendations) to what is
made in that document.
Polk Expires April 26, 2009 [Page 2]
Internet-Draft Retransmission Recommendation Concerns October 2008
3. Goals of [ID-RETRANS]
Within Section 3.1 of [ID-RETRANS] states the following
After extensive discussion in both GEOPRIV and SIP contexts,
there seems to be consensus that a solution for this problem
must enable location-based routing to work even when the
<retransmission-allowed> flag is set to "no".
This ID questions when this consensus was not thought about --
i.e., when did anyone disagree with this statement? If this was
not ever in jeopardy, why do we need to account for something that
was always planned for?
4. Taking Issue with use of "Authorized Recipients"
[ID-RETRANS] makes the argument that all receivers of a LO are
authorized recipients, and that this is subtly different from
the model envisioned by [RFC3693], the first version of Location
Conveyance was already a WG item, thus the idea was not foreign
Concept - even if not completely captured how we would have do so
today. While the author agrees this is a different model, not all
receivers of location are consumers of location. A point that is
not made in [ID-RETRANS], and one that must be crossed in order to
any security concerns to be violated.
Looking at Figure A., which SIP entities are consumers of location?
+----+ +-------+ +-------+ +----+
|UAC |------| SIP |-----------------| SIP |------|UAS |
+----+ |Server3| |Server7| +----+
| +-------+ +-------+ |
| | | |
|--INVITE ----->|----INVITE ------------->|---INVITE ->|
| (with LbyV) | (with LbyV) | (with LbyV)|
Figure A. Consumers of Location
Even if both SIP Server3 and 7 are SIP location conveyance aware,
that does not make them consumers of location. They are only
consumers of location if they view the location and either store it
or manipulate it. The author is not convinced that simple
regurgitation of a B2BUA downstream makes it a consumer of location.
5. Issues with new Location-Routing-Allowed header
[ID-RETRANS] recommends SIP create a new Location-Routing-Allowed"
header in Section 3.5 of that document. Here is the text from that
section,
Polk Expires April 26, 2009 [Page 3]
Internet-Draft Retransmission Recommendation Concerns October 2008
The discussion in Section 3.3.2 describes 3 mechanisms for
limiting the distribution of LI to specific entities. There
remains the problem of limiting the use to which LI included
by value or by reference may be put. In order to meet the
need to limit that use, this document recommends the
creation of a syntactical element in SIP to carry this
information. As an exemplary concrete proposal, we
recommend a "Location-Routing-Allowed" header as described
below.
When "Location-Routing-Allowed" is set to "Yes", the Rule
Maker is indicating permission to use the included LI for
location-based routing. When "Location-Routing-Allowed" is
set to "No", the originator is indicating that this use is
not permitted. "Location-Routing-Allowed" being set to "No"
has no protocol-level mechanism for enforcement of this
behavior; like the PIDF-LO <retransmission-allowed> being
set to "no", it is a way for the Rule Maker to express a
preference to the SIP elements which are LI recipients. It
may, however, present a significant optimization. Where a
location-by-reference is included with
"Location-Routing-Allowed" set to "No", the SIP elements
along the path know that they do not need to attempt to
dereference the location information; this is significantly
faster than attempting the dereference and being denied at
the authentication stage.
We recommend that "Location-Routing-Allowed" be made
mandatory-to-implement for elements complying with [1].
We recommend that it appear in any SIP message that
contains a location, whether by reference or by value.
We recommend that any SIP message containing a location
but no "Location-Routing-Allowed" header should be
treated as containing a "Location-Routing-Allowed" header
set to "No".
We recommend that a UA be allowed to insert a
"Location-Routing-Allowed" header even when it has not
included a location, in order to set the policy for any
locations inserted by other SIP elements.
While the author here has no issues with this optimization, this
indication clearly does not need to be a new header. That appears
to be overkill, when all that is necessary is some indication that
is well understood, visible and parsable. Therefore this document
makes an equally concrete proposal - make this indication a
Geolocation header parameter created within the document
[ID-SIP-LOC]. This indication can be the only value in a
Geolocation header (i.e., when location is not present in the
Polk Expires April 26, 2009 [Page 4]
Internet-Draft Retransmission Recommendation Concerns October 2008
header). There is no need to create a second header. And all
within section 3.4 of [ID-RETRANS] can be accomplished by this
header parameter, making implementations of this function simpler.
6. Issues with B2BUA/SBC Treatment of Location
Concerning section 3.6 of [ID-RETRANS], which deals with how SIP
B2BUAs are treated, and should be considered - here is the section
for review:
Typically, B2BUAs are described as terminating one session
and originating a new one. From that perspective, a B2BUA
receiving LI on one of its "backs" might treat itself as
terminating the flow of information and thus view itself as
a recipient for the purposes of <retransmission-allowed>.
In that case, it should originate a new information flow
containing that LI by value in the other direction only if
the PIDF-LO it receives permitted it (i.e. if
<retransmission-allowed> is set to 'yes'). If the PIDF-LO
it receives is encrypted, it can pass it onward with the
understanding that a recipient capable of decrypting it
is authorized; the B2BUA does not seem to be a recipient in
this instance.
Note that this case is also easier to handle using the
location-by-reference model. Since the passing of
location-by-reference does not properly include the location
itself, it can pass a location-by-reference pointer in the
new direction with the understanding that the dereferencing
protocol handles the determination of whether those
dereferencing the location are authorized recipients or not.
If both sides of a B2BUA speak SIP, note that failing to copy
any "Location-Routing-Allowed" header value found in the input
flow when it re-originates the flow will neglect the policies
of the Rule Maker.
This section of [ID-RETRANS] is explicitly stating that location
should not be transmitted by a B2BUA or SBC unless the
<retransmission-allowed> flag is set to 'yes', or encryption is used.
Consider the network architecture in the diagram below in Figure X.,
in what case would benefit the Internet (the goal of all IETF
documents) by adhering to the recommendations within section 3.6 of
[ID-RETRANS] where a B2BUA or SBC were between the UAC and the UAS,
if the UAC sent LbyV? Regardless of which SIP server (there are 9)
in the signaling path between the UAC and UAS, the UAC cannot
understand or learn that any one of the SIP servers are a
- transaction stateless proxy
- transaction stateful proxy
Polk Expires April 26, 2009 [Page 5]
Internet-Draft Retransmission Recommendation Concerns October 2008
- dialog stateful proxy
- back-to-back-user-agent (B2BUA)
- session border controller (SBC)
Each is defined by RFC 3261 as an instance of a SIP proxy server
(i.e., a SIP message router)(an SBC is an extension of a B2BUA).
The loan exception is for a dialog stateful proxy, who is determined
by the reception of a Record-Route (RR) header with the SIP-URI of
the server wanting to become dialog stateful. More than one server
can place a RR header in a SIP message.
+-------+
+----------| SIP |--------+
| |Server5| |
+-------+ +-------+ +-------+
| SIP | | SIP |
|Server4| |Server6|
+-------+ +-------+
| |
| |
| |
+-------+ +-------+ +-------+ +-------+
| SIP |------| SIP | | SIP |------| SIP |
|Server2| |Server3| |Server7| |Server8|
+-------+ +-------+ +-------+ +-------+
\ /
\ /
\ /
\ /
+-------+ +-------+
| SIP | | SIP |
|Server1| |Server9|
+-------+ +-------+
/ \
+---+ +---+
|UAC| |UAS|
+---+ +---+
Figure X. Affects of LbyV with B2BUA/SBC
If any of the above SIP Servers is a B2BUA or SBC, adhering to
[ID-RETRANS] would mean location conveyed by-value is only
communicated through this B2BUA/SBC SIP Server when the
<retransmission-allowed> flag is set to 'yes' -- which means the
UAC's location can be freely communicated at all entities and
databases prior to receipt by the UAS, unless it is encrypted of
course (this is mentioned in Section 3.3 of [ID-RETRANS]), or it
cannot get to the UAC's intended destination UAS.
The SIP WG (as of the summer of 2008) is considering deprecating
S/MIME from its specifications (it is not even required within SIP)
Polk Expires April 26, 2009 [Page 6]
Internet-Draft Retransmission Recommendation Concerns October 2008
because few implementations can support it (because it requires a
Public Key infrastructure - that is difficult at best to build and
maintain). Nothing is finalized in this regard, but there is a lot
of talk about this within the SIP WG, and the RAI Area in general.
Therefore the author believes any statements backing the idea of
end-to-end encryption should be taken as pretty much a non-starter.
Therefore, with LbyV not realistically (or pragmatically)
encryptable end-to-end, the only choice of a B2BUA or SBC receiving
LbyV and retransmitting further downstream on the signaling path is
with the <retransmission-allowed> flag set to 'yes'. [ID-RETRANS]
does not suggest changing the flag from 'no' to 'yes', and
recommends not allowing B2BUAs or SBCs from transmitting the SIP
request downstream. [ID-RETRANS] does not suggest or recommend
otherwise removing location from the SIP request. This will result
in providing the UAC with zero indication any SIP server removed
location information from the original SIP request, yet the author
does not understand if the SIP request containing LbyV is to
continue downstream towards the destination UAS? Does a SIP request
containing LbyV with a <retransmission-allowed> flag set to 'no'
simply stop without a reply? If there is a reply, what is it (other
than maybe a 400, which does not tell the UAC why the request
failed).
The author believes this is broken. It is broken because it is not
through local policy of a given domain that made this decision, it
is through the protocol to tell domains how they must treat this
scenario. Either that, or it expects users to inherently set their
<retransmission-allowed> flag to 'yes' whenever they want to convey
an LbyV. Any location learned locally by the user's UA, perhaps by
a GPS chip, will fall into this scenario. If the UA does its own
radio signal (tower) triangulation, this will also fall into this
scenario.
Further, see this new document [ID-MOD] claiming most SIP servers
are indeed B2BUAs, and not classical proxy servers.
Therefore, it is this author's belief this protocol rule within SIP
Location Conveyance, once RFCd, will either be ignored by
implementers, or made explicitly configurable. Neither case is
recommended by [ID-RETRANS]. Thus making Location Conveyance
partial flawed before it becomes an RFC, which should never occur
with any IETF document.
Additionally, this appears to be directly counter to the first
paragraph in section 3.2 of [ID-RETRANS], called "Core Semantics",
which states the following,
Consensus has emerged that any SIP entity which receives a
SIP message containing LI through the operation of SIP's
normal routing procedures or as a result of location-based
routing should be considered an authorized recipient of
Polk Expires April 26, 2009 [Page 7]
Internet-Draft Retransmission Recommendation Concerns October 2008
that LI. Because of this presumption, one SIP element may
pass the LI to another even if the LO it contains has
<retransmission-allowed> set to "no"; this sees the passing
of the SIP message as part of the delivery to authorized
recipients, rather than as retransmission. SIP entities
are still enjoined from passing these messages outside the
normal routing to external entities if <retransmission-allowed>
is set to "no", as it is the passing to 3rd parties that
<retransmission-allowed> is meant to control.
This document recommends an alternate to Section 3.6 of [ID-RETRANS]
that is more in line with section 3.2 of [ID-RETRANS] here:
A better way to have [ID-RETRANS] positively affect location
conveyance is to explicitly disallow any instance of a proxy
server (including B2BUAs and SBCs) from forwarding a received
LbyV to any other entity than the next hop SIP destination
entity - explicitly prohibiting retransmitting this received
SIP message containing an LbyV to a third entity.
7. Security considerations
This document poses no security considerations beyond what is in
[ID-SIP-LOC].
8. IANA considerations
This document does not have any IANA actions.
9. Acknowledgments
Your name here... or if you contribute a fair amount of text, you
can be a co-author.
10. References
10.1. Normative References
[ID-RETRANS] J. Peterson, T. Hardie, J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance",
"work in progress", Oct 2008
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance",
draft-ietf-sip-location-conveyance-11.txt, "work in
progress", Oct 2008
Polk Expires April 26, 2009 [Page 8]
Internet-Draft Retransmission Recommendation Concerns October 2008
10.2. Informative References
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004
[ID-MOD] J. Rosenberg, "A Modest Proposal for Session Initiation
Protocol (SIP) Work in the IETF", "work in progress", Oct
2008
Authors' Address
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
Polk Expires April 26, 2009 [Page 9]
Internet-Draft Retransmission Recommendation Concerns October 2008
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk Expires April 26, 2009 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 01:25:42 |