SIP WG J. Peterson Internet-Draft NeuStar Expires: August 25, 2003 February 24, 2003 Considerations on the IEPREP requirements for SIP draft-peterson-sipping-ieprep-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IEPREP working group has provided the SIPPING WG with a framework and requirements draft for prioritized communications services in SIP. The considerations raised in that draft are examined here, and some feedback and implementation recommendations based on its requirements are provided. 1. Introduction This document offers some considerations on the IEPREP requirements [3] for the Session Initiation Protocol (SIP [1]). Support for emergency telecommunications services (ETS) and related forms of prioritized communications services is critical to the long-term Peterson Expires August 25, 2003 [Page 1] Internet-Draft SIPPING-IEPREP February 2003 success of the SIP, especially in the telephony marketplace. Finishing this work in the near-term is of the utmost importance. However, there are several aspects of the requirements that need to be clarified before a mechanism can be built to accommodate them. In the sections that follow, first the framework concepts of the IEPREP document (detailed in sections 2 through 8) are examined. Considerations specific to the requirements in section 9 and 10 follow. Finally, this document proposes some implementation conclusions based on the analysis of the IEPREP document. The initial version of this document does not reflect a consensus of the SIPPING WG or a formal response - it is merely the opinion of one author. However, the author asks the SIPPING WG to consider the recommendations in this document as a basis for ongoing analysis of the IEPREP requirements. 2. Framework The IEPREP requirements document contains a framework that provides an analysis of entities, scenarios, and architectures that might be involved in an ETS call. The selection of entities, and the scenarios under consideration seem reasonable and in keeping with SIP's philosophy. However, the prioritization requirements associated with particular entities and the envisioned network architectures require some further discussion. 2.1 SIP entity support for IEPREP From a reading of Section 3, it is not clear that either SIP user agents nor SIP proxy servers needs to have any behavior (within the stated scope of this document) in support of emergency services. However, in the 'IP end-to-end' topology presented in Section 4, it states that 'any SIP request could be subject to prioritization' - what sort of prioritization behavior would be required of SIP entities in these cases? Similarly, in the 'CSN-IP' case, in the scope of this document, it isn't clear from Section 3 how any intervening proxy servers or SIP user agents would require any prioritization behavior. In order for the need for prioritization in the IP e2e and CSN-IP cases to be motivated, some additional text would be required in Section 3 to explain how conventional SIP user agents and proxy servers would handle a priority request differently than any other request. It might be tempting to import the text in Section 7, for example, which entails that proxy servers could make different routing decisions for some calls in the presence of a priority indicator. However, since this text in Section 7 is restricted to locating a Peterson Expires August 25, 2003 [Page 2] Internet-Draft SIPPING-IEPREP February 2003 proper egress gateway, this is really only impactful in the IP-CSN and CSN-IP-CSN cases (cases in which the destination, or Request-URI, of the SIP request is a telephone number). The 'IP-CSN' case and 'CSN-IP-CSN' case are much more clear in terms of the required prioritization behavior of proxies and gateways. Prioritization information is necessary to express to the terminating gateway what priority should be applied to its own resources (as described in Section 3), as well as what priority should be communicated the CSN. The graph at the conclusion of Section 4 notes that the receiver (the destination SIP user agent) has emergency behavior, within the scope of this document, for the CSN-IP and IP e2e cases. However, the description of the receiver in Section 3 notes no applicable behavior for resources that is within the scope of this document. This merits further clarification. 2.2 Signaling encapsulation Section 4 contends that, in the CSN-IP-CSN case, SIP encapsulation of the signaling at the original CSN node is insufficient (which trickles down to REQ-5). However, the given motivation for this seems problematic. While it is true that the originating and terminating gateways may support different signaling protocols, it is also the case that: Priority systems are scoped to signaling systems. That is, if ISUP received at an originating gateway is not understood by the destination gateway of a CSN-IP-CSN request, priority information (as it is used in the originating portion of the CSN) would not be understood by the destination either (or do IEPREP's experts have evidence to the contrary?). In the CSN, it is not possible to make an emergency call, for example, from France to the United States. International ISUP gateways that bridge between different signaling systems will at best discard priority information. It's not clear that it would even be desirable for priority information to be retained when you cross network boundaries - if someone's a government official in Iraq, when they place a call to the United States, should they be afforded the status of a government official here? Some additional discussion is necessary to understand why signaling encapsulation is insufficient for CSN-IP-CSN architectures. If this amounts only to the requirement described in Section 7, then signaling encapsulation may still provide some useful properties to the terminating gateway. Peterson Expires August 25, 2003 [Page 3] Internet-Draft SIPPING-IEPREP February 2003 2.3 ETS in existing SIP networks The network models in Section 5 are very informative. It isn't clear, however, if all of these networks are considered to be in the scope of priority services. Although it is obvious, for example, that the 'pre-configured for ETS' network will respect the prioritization of calls, to what degree can more 'restrictive' network models be expected to do so? This points to a fundamental questions: Is ETS opt-in? While it may 'appear preferable' that protocol enhancements for emergency services work in SIP/RTP transparent networks or fully transparent networks, this seems highly unlikely unless support for emergency services becomes mandatory in the core SIP specification - and even then, there is no guarantee that fully compliant implementations will be ubiquitously deployed, nor configured to behave appropriately in an ETS situation. This is perhaps the most counterintuitive aspect of the IEPREP framework from the perspective of SIP as an Internet service. It is profoundly unlikely that a given SIP proxy server or user agent in the Internet will participate in a national or global framework for priority calling - only networks that develop relationships with the relevant government agencies, and are given proper configuration information by those agencies, will do so. This is especially problematic because of the stringent authentication and authorization requirements associated with emergency calling. The document gives little consideration to the possibility that some portion of a requests path might not support ETS. What are the consequences for prioritization if only part of the path understands priority calling? Is there value in having only partial support for IEPREP in the signaling path of a call? The entire requirements document would appear significantly more plausible if the only network architecture that would provide realistic quality guarantees for IEPREP were the 'pre-configured for ETS' network - the remainder are unlikely to participate in priority calling schemes. 2.4 Decoupling semantics from labels The general conclusion of section 8, that different network elements might best implement prioritization in different ways, is reasonable. However, it introduces a somewhat troublesome decoupling between syntax and semantics - when you send a prioritized request to an element, you have no concept of how it will behave (other than a general assurance that it will do the best it can). Certainly, one Peterson Expires August 25, 2003 [Page 4] Internet-Draft SIPPING-IEPREP February 2003 size doesn't fit all, but wouldn't it be possible to mandate that each of the five elements (well, four, actually, since we can't count the CSN itself) described in Section 3 specifically must implement one (or more) of the three prioritization mechanisms described at the beginning of section 8? 3. Responses to Requirements 3.1 General Requirements REQ-0 - There is a tacit REQ-0 here, which is that SIP requests will be labeled with priority information. This assumption is made in the introductory paragraph of section 9. However, this assumption might not belong in a requirements document - it dictates the mechanism that will satisfy these requirements. If this point of mechanism must be specified in the requirements draft, it should be supported with some text (the existing REQ-3 could be incorporated into this REQ-0 as motivation for the requirement that SIP needs to have this indicator, for example). REQ-2 - It isn't clear how well ETS can be expected to 'work' in networks that are not preconfigured for ETS - networks that have not established appropriate policies and behaviors for handling prioritized calls. While ETS should work in the widest possible variety of networks, it isn't clear how wide that variety can realistically be. Moreover, the effects of partial support for ETS in the path of the call are not detailed in the document. REQ-3 - If it is not plausible that a SIP/RTP-transparent network will make any use of a prioritization label, it isn't clear why out- of-band signaling for prioritization is unusable. SIP/RTP transparent networks, as stated above, may not pass IP traffic transparently (including RSVP, one plausible out-of-band prioritization protocol), but if the SIP network doesn't respect prioritization either, how is it any better? REQ-4 - The 'mapping of schemes' requirement could be taken to be strong or weak. Based on REQ-1, one might assume a weak requirement that there be a label namespace corresponding to each CSN scheme. That's fine, REQ-1 essentially says the same thing. The strong interpretation would be that there is some normalized scheme of priorities defined for SIP (a specific set of levels), and each individual CSN scheme must be mapped onto that SIP scheme and vice versa. The strong requirement could be problematic. It isn't clear which is intended here. REQ-5 - See Section 2.2. Peterson Expires August 25, 2003 [Page 5] Internet-Draft SIPPING-IEPREP February 2003 REQ-7 - The assertion about the usage of MLPP at the conclusion of this requirement might be somewhat misleading as an argument for the separation of policy from mechanism. The MLPP indicators are indeed specified in ITU-T SS7, and consequently each variant can have its own behavior for prioritization of the call when it sees the same MLPP value. However, a MLPP indicator will not cross several ISUP variants, and therefore be affected by different policies, in the course of a single call. It's never unclear within a certain network how a given element will behave when presented with a prioritization indicator. For SIP, however, this indeed seems to be the result of these requirements. REQ-8 - This requires some further explication. What methods other than INVITE require priority indicators? What priority behavior for, say, SUBSCRIBE would be implemented in any of the elements described in Section 3? What resources in these entities would be taxed by non- INVITE SIP requests? REQ-9 - This is a reasonable requirements, but the implications for the overall emergency quality of service that result from portions of the network not supporting ETS need further explication in this document. REQ-10 - Identification of gateway destinations for calls is at least one way in which the Request-URI (specifically, analysis of some sort of telephone number) could be used as part of the prioritization process. Incidentally, is this requirement attempting to rule out a solution for the prioritization indicator based on RFC3087, caller preferences or some similar URI parameter? If so, that would require some further motivation. REQ-12 - This is fine, but it does have an implication that any SIP phone, even one that is not in a pre-configured ETS network, should be capable of supporting these functions. Again, this seems implausible, if this is intended by REQ-12. REQ-14 - Does this imply that a user agent would want to know the priority capabilities of any SIP entity in a network that its request might traverse, as a way of guaranteeing that it will receive proper treatment? If so, how does it know that a given entity in the network will be in the path of an emergency request (before that request is placed)? Is this intended to apply only to first-hop connections from the UAC? REQ-16 - Is 3PCC the only indirect calling mechanism supported by IEPREP? What about REFER? REQ-17 - The proxy visibility requirement essentially entails that Peterson Expires August 25, 2003 [Page 6] Internet-Draft SIPPING-IEPREP February 2003 priority be expressed as a header, or in a URI, rather than a body. Better understanding of why proxies require visibility in IP-to-IP calls or CSN-to-IP calls would be useful motivation here. 3.2 Security Requirements SEC-5, SEC-6, SEC-7, SEC-10, SEC-11, and SEC-12 all describe security properties that all SIP implementations should possess. In fact, RFC3261 describes mechanisms and behaviors intended to meet these risks. Are there any requirements for IEPRERP that go above and beyond the baseline RFC3261 requirements relating to these properties? SEC-4 - Not revealing your credentials to a device which you are using to authenticate yourself is quite difficult. Is this a requirement for one-time passwords or some sort of variable authentication system? If so, perhaps this should say that a user should not reveal a reusable credential to the device. Using specialized authentication systems that do not correspond to standard SIP mechanisms will further reduce the applicability of ETS systems, since it will require specialized UAs and gateways (i.e. it goes against SEC-3). SEC-8 - First, optional headers like Subject and Organization should be omitted when confidentiality is at stake (per RFC3323). Second, if you want proxies to be able to use the prioritization mechanism, then they need to be able to see the prioritization header; it is part of the 'request routing information'. This information cannot realistically be made confidential given REQ-17. If it is necessary to apply cryptographic confidentiality properties to the label (to prevent authorized parties from seeing the header), then given the difficulty of applying confidentiality properties to SIP headers, this seems to rule out a header-based approach. SEC-9 - Using the 'short-term' network-asserted identity is problematic if, as you assert SEC-2, the network is not to depend on transitive trust. The NAI mechanism of RFC3324/3325 is necessarily based on transitive trust. Moreover, the RFC3325 approach essentially assumes a closed network (a case which seems to be contrary to REQ-12). Also, how important is anonymity in ETS? It seems that accountability of ETS calls is very important - would there actually be cases in which, say, a first responder wished to be anonymous to a dispatch center, or for a military official to appear anonymous to another military official? 4. Conclusions and Implementation Recommendations The largest difficulty with the IEPREP recommendations for SIP is Peterson Expires August 25, 2003 [Page 7] Internet-Draft SIPPING-IEPREP February 2003 their scope. The requirements seem oriented towards an environment in which all SIP entities will support ETS. It would be much more plausible if the document assumed that ETS was only supported in closed networks that have the necessary relationships with government agencies. The currently documented user agent and proxy server behavior associated with is thin. Section 3 offers little guidance behavioral guidance for user agents and proxy servers that support receive a prioritized request. As the requirements stand, there seems to be no way to implement the indicator/label. REQ-17 requires that the indicator be visible to proxy servers, so that it can assist in routing, but SEC-8 requires that unauthorized parties be unable to perceive the priority level of calls, or indeed that priority has even been requested. This suggests that some sort of encryption needs to be used to protect the priority indicator. There is, however, no solution to provide confidentiality properties in SIP headers - only in SIP MIME bodies. But proxy servers are not allowed to inspect MIME bodies. One of these requirements needs to be relaxed. In fact, the requirement in REQ-17 only motivates the use of the prioritization indicator by the proxy server to make a gateway routing decision (like choosing a special ETS gateway instead of a standard gateway). If gateway routing is the only requirement for proxy servers to route based on priority, and we can assume that in other cases there is no need for the proxy to inspect the label, we can perhaps make a compromise. Assuming that the confidentiality requirement in SEC-8 is relaxed, it might be possible to implement the prioritization label as either a URI parameter or a header. Given that in the gateway routing case, tel URIs can be assumed to be used in the Request-URI of the SIP request, REQ-10 seems much less strongly motivated. A tel URI based solution seems like a reasonable approach given the overall framework. 5. Security Considerations Security requirements associated with the IEPREP work are discussed in detail in Section 3.2. 6. IANA Considerations This document introduces no considerations for the IANA. Informative References Peterson Expires August 25, 2003 [Page 8] Internet-Draft SIPPING-IEPREP February 2003 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [3] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol", draft-ietf-ieprep-sip- reqs-03 (work in progress), December 2002. [4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [6] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and m. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001. [7] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP Mapping", RFC 3398, December 2002. Author's Address Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Peterson Expires August 25, 2003 [Page 9] Internet-Draft SIPPING-IEPREP February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Peterson Expires August 25, 2003 [Page 10]