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 ' 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 ' 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 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 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 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 . 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 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 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 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 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 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 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 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 is set to "no", as it is the passing to 3rd parties that 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]