idnits 2.17.1 draft-peterson-sipping-ieprep-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 344 has weird spacing: '...ed with is th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2003) is 7731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 401, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 408, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-ieprep-sip-reqs is -02, but you're referring to -03. Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: August 25, 2003 February 24, 2003 6 Considerations on the IEPREP requirements for SIP 7 draft-peterson-sipping-ieprep-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 25, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The IEPREP working group has provided the SIPPING WG with a framework 39 and requirements draft for prioritized communications services in 40 SIP. The considerations raised in that draft are examined here, and 41 some feedback and implementation recommendations based on its 42 requirements are provided. 44 1. Introduction 46 This document offers some considerations on the IEPREP requirements 47 [3] for the Session Initiation Protocol (SIP [1]). Support for 48 emergency telecommunications services (ETS) and related forms of 49 prioritized communications services is critical to the long-term 50 success of the SIP, especially in the telephony marketplace. 51 Finishing this work in the near-term is of the utmost importance. 52 However, there are several aspects of the requirements that need to 53 be clarified before a mechanism can be built to accommodate them. 55 In the sections that follow, first the framework concepts of the 56 IEPREP document (detailed in sections 2 through 8) are examined. 57 Considerations specific to the requirements in section 9 and 10 58 follow. Finally, this document proposes some implementation 59 conclusions based on the analysis of the IEPREP document. 61 The initial version of this document does not reflect a consensus of 62 the SIPPING WG or a formal response - it is merely the opinion of one 63 author. However, the author asks the SIPPING WG to consider the 64 recommendations in this document as a basis for ongoing analysis of 65 the IEPREP requirements. 67 2. Framework 69 The IEPREP requirements document contains a framework that provides 70 an analysis of entities, scenarios, and architectures that might be 71 involved in an ETS call. The selection of entities, and the 72 scenarios under consideration seem reasonable and in keeping with 73 SIP's philosophy. However, the prioritization requirements 74 associated with particular entities and the envisioned network 75 architectures require some further discussion. 77 2.1 SIP entity support for IEPREP 79 From a reading of Section 3, it is not clear that either SIP user 80 agents nor SIP proxy servers needs to have any behavior (within the 81 stated scope of this document) in support of emergency services. 82 However, in the 'IP end-to-end' topology presented in Section 4, it 83 states that 'any SIP request could be subject to prioritization' - 84 what sort of prioritization behavior would be required of SIP 85 entities in these cases? Similarly, in the 'CSN-IP' case, in the 86 scope of this document, it isn't clear from Section 3 how any 87 intervening proxy servers or SIP user agents would require any 88 prioritization behavior. In order for the need for prioritization in 89 the IP e2e and CSN-IP cases to be motivated, some additional text 90 would be required in Section 3 to explain how conventional SIP user 91 agents and proxy servers would handle a priority request differently 92 than any other request. 94 It might be tempting to import the text in Section 7, for example, 95 which entails that proxy servers could make different routing 96 decisions for some calls in the presence of a priority indicator. 97 However, since this text in Section 7 is restricted to locating a 98 proper egress gateway, this is really only impactful in the IP-CSN 99 and CSN-IP-CSN cases (cases in which the destination, or Request-URI, 100 of the SIP request is a telephone number). The 'IP-CSN' case and 101 'CSN-IP-CSN' case are much more clear in terms of the required 102 prioritization behavior of proxies and gateways. Prioritization 103 information is necessary to express to the terminating gateway what 104 priority should be applied to its own resources (as described in 105 Section 3), as well as what priority should be communicated the CSN. 107 The graph at the conclusion of Section 4 notes that the receiver (the 108 destination SIP user agent) has emergency behavior, within the scope 109 of this document, for the CSN-IP and IP e2e cases. However, the 110 description of the receiver in Section 3 notes no applicable behavior 111 for resources that is within the scope of this document. This merits 112 further clarification. 114 2.2 Signaling encapsulation 116 Section 4 contends that, in the CSN-IP-CSN case, SIP encapsulation of 117 the signaling at the original CSN node is insufficient (which 118 trickles down to REQ-5). However, the given motivation for this 119 seems problematic. While it is true that the originating and 120 terminating gateways may support different signaling protocols, it is 121 also the case that: 123 Priority systems are scoped to signaling systems. That is, if 124 ISUP received at an originating gateway is not understood by the 125 destination gateway of a CSN-IP-CSN request, priority information 126 (as it is used in the originating portion of the CSN) would not be 127 understood by the destination either (or do IEPREP's experts have 128 evidence to the contrary?). In the CSN, it is not possible to 129 make an emergency call, for example, from France to the United 130 States. International ISUP gateways that bridge between different 131 signaling systems will at best discard priority information. 133 It's not clear that it would even be desirable for priority 134 information to be retained when you cross network boundaries - if 135 someone's a government official in Iraq, when they place a call to 136 the United States, should they be afforded the status of a 137 government official here? 139 Some additional discussion is necessary to understand why signaling 140 encapsulation is insufficient for CSN-IP-CSN architectures. If this 141 amounts only to the requirement described in Section 7, then 142 signaling encapsulation may still provide some useful properties to 143 the terminating gateway. 145 2.3 ETS in existing SIP networks 147 The network models in Section 5 are very informative. It isn't 148 clear, however, if all of these networks are considered to be in the 149 scope of priority services. Although it is obvious, for example, 150 that the 'pre-configured for ETS' network will respect the 151 prioritization of calls, to what degree can more 'restrictive' 152 network models be expected to do so? 154 This points to a fundamental questions: Is ETS opt-in? While it may 155 'appear preferable' that protocol enhancements for emergency services 156 work in SIP/RTP transparent networks or fully transparent networks, 157 this seems highly unlikely unless support for emergency services 158 becomes mandatory in the core SIP specification - and even then, 159 there is no guarantee that fully compliant implementations will be 160 ubiquitously deployed, nor configured to behave appropriately in an 161 ETS situation. 163 This is perhaps the most counterintuitive aspect of the IEPREP 164 framework from the perspective of SIP as an Internet service. It is 165 profoundly unlikely that a given SIP proxy server or user agent in 166 the Internet will participate in a national or global framework for 167 priority calling - only networks that develop relationships with the 168 relevant government agencies, and are given proper configuration 169 information by those agencies, will do so. This is especially 170 problematic because of the stringent authentication and authorization 171 requirements associated with emergency calling. 173 The document gives little consideration to the possibility that some 174 portion of a requests path might not support ETS. What are the 175 consequences for prioritization if only part of the path understands 176 priority calling? Is there value in having only partial support for 177 IEPREP in the signaling path of a call? 179 The entire requirements document would appear significantly more 180 plausible if the only network architecture that would provide 181 realistic quality guarantees for IEPREP were the 'pre-configured for 182 ETS' network - the remainder are unlikely to participate in priority 183 calling schemes. 185 2.4 Decoupling semantics from labels 187 The general conclusion of section 8, that different network elements 188 might best implement prioritization in different ways, is reasonable. 189 However, it introduces a somewhat troublesome decoupling between 190 syntax and semantics - when you send a prioritized request to an 191 element, you have no concept of how it will behave (other than a 192 general assurance that it will do the best it can). Certainly, one 193 size doesn't fit all, but wouldn't it be possible to mandate that 194 each of the five elements (well, four, actually, since we can't count 195 the CSN itself) described in Section 3 specifically must implement 196 one (or more) of the three prioritization mechanisms described at the 197 beginning of section 8? 199 3. Responses to Requirements 201 3.1 General Requirements 203 REQ-0 - There is a tacit REQ-0 here, which is that SIP requests will 204 be labeled with priority information. This assumption is made in the 205 introductory paragraph of section 9. However, this assumption might 206 not belong in a requirements document - it dictates the mechanism 207 that will satisfy these requirements. If this point of mechanism 208 must be specified in the requirements draft, it should be supported 209 with some text (the existing REQ-3 could be incorporated into this 210 REQ-0 as motivation for the requirement that SIP needs to have this 211 indicator, for example). 213 REQ-2 - It isn't clear how well ETS can be expected to 'work' in 214 networks that are not preconfigured for ETS - networks that have not 215 established appropriate policies and behaviors for handling 216 prioritized calls. While ETS should work in the widest possible 217 variety of networks, it isn't clear how wide that variety can 218 realistically be. Moreover, the effects of partial support for ETS 219 in the path of the call are not detailed in the document. 221 REQ-3 - If it is not plausible that a SIP/RTP-transparent network 222 will make any use of a prioritization label, it isn't clear why out- 223 of-band signaling for prioritization is unusable. SIP/RTP 224 transparent networks, as stated above, may not pass IP traffic 225 transparently (including RSVP, one plausible out-of-band 226 prioritization protocol), but if the SIP network doesn't respect 227 prioritization either, how is it any better? 229 REQ-4 - The 'mapping of schemes' requirement could be taken to be 230 strong or weak. Based on REQ-1, one might assume a weak requirement 231 that there be a label namespace corresponding to each CSN scheme. 232 That's fine, REQ-1 essentially says the same thing. The strong 233 interpretation would be that there is some normalized scheme of 234 priorities defined for SIP (a specific set of levels), and each 235 individual CSN scheme must be mapped onto that SIP scheme and vice 236 versa. The strong requirement could be problematic. It isn't clear 237 which is intended here. 239 REQ-5 - See Section 2.2. 241 REQ-7 - The assertion about the usage of MLPP at the conclusion of 242 this requirement might be somewhat misleading as an argument for the 243 separation of policy from mechanism. The MLPP indicators are indeed 244 specified in ITU-T SS7, and consequently each variant can have its 245 own behavior for prioritization of the call when it sees the same 246 MLPP value. However, a MLPP indicator will not cross several ISUP 247 variants, and therefore be affected by different policies, in the 248 course of a single call. It's never unclear within a certain network 249 how a given element will behave when presented with a prioritization 250 indicator. For SIP, however, this indeed seems to be the result of 251 these requirements. 253 REQ-8 - This requires some further explication. What methods other 254 than INVITE require priority indicators? What priority behavior for, 255 say, SUBSCRIBE would be implemented in any of the elements described 256 in Section 3? What resources in these entities would be taxed by non- 257 INVITE SIP requests? 259 REQ-9 - This is a reasonable requirements, but the implications for 260 the overall emergency quality of service that result from portions of 261 the network not supporting ETS need further explication in this 262 document. 264 REQ-10 - Identification of gateway destinations for calls is at least 265 one way in which the Request-URI (specifically, analysis of some sort 266 of telephone number) could be used as part of the prioritization 267 process. Incidentally, is this requirement attempting to rule out a 268 solution for the prioritization indicator based on RFC3087, caller 269 preferences or some similar URI parameter? If so, that would require 270 some further motivation. 272 REQ-12 - This is fine, but it does have an implication that any SIP 273 phone, even one that is not in a pre-configured ETS network, should 274 be capable of supporting these functions. Again, this seems 275 implausible, if this is intended by REQ-12. 277 REQ-14 - Does this imply that a user agent would want to know the 278 priority capabilities of any SIP entity in a network that its request 279 might traverse, as a way of guaranteeing that it will receive proper 280 treatment? If so, how does it know that a given entity in the network 281 will be in the path of an emergency request (before that request is 282 placed)? Is this intended to apply only to first-hop connections from 283 the UAC? 285 REQ-16 - Is 3PCC the only indirect calling mechanism supported by 286 IEPREP? What about REFER? 288 REQ-17 - The proxy visibility requirement essentially entails that 289 priority be expressed as a header, or in a URI, rather than a body. 290 Better understanding of why proxies require visibility in IP-to-IP 291 calls or CSN-to-IP calls would be useful motivation here. 293 3.2 Security Requirements 295 SEC-5, SEC-6, SEC-7, SEC-10, SEC-11, and SEC-12 all describe security 296 properties that all SIP implementations should possess. In fact, 297 RFC3261 describes mechanisms and behaviors intended to meet these 298 risks. Are there any requirements for IEPRERP that go above and 299 beyond the baseline RFC3261 requirements relating to these 300 properties? 302 SEC-4 - Not revealing your credentials to a device which you are 303 using to authenticate yourself is quite difficult. Is this a 304 requirement for one-time passwords or some sort of variable 305 authentication system? If so, perhaps this should say that a user 306 should not reveal a reusable credential to the device. Using 307 specialized authentication systems that do not correspond to standard 308 SIP mechanisms will further reduce the applicability of ETS systems, 309 since it will require specialized UAs and gateways (i.e. it goes 310 against SEC-3). 312 SEC-8 - First, optional headers like Subject and Organization should 313 be omitted when confidentiality is at stake (per RFC3323). Second, 314 if you want proxies to be able to use the prioritization mechanism, 315 then they need to be able to see the prioritization header; it is 316 part of the 'request routing information'. This information cannot 317 realistically be made confidential given REQ-17. If it is necessary 318 to apply cryptographic confidentiality properties to the label (to 319 prevent authorized parties from seeing the header), then given the 320 difficulty of applying confidentiality properties to SIP headers, 321 this seems to rule out a header-based approach. 323 SEC-9 - Using the 'short-term' network-asserted identity is 324 problematic if, as you assert SEC-2, the network is not to depend on 325 transitive trust. The NAI mechanism of RFC3324/3325 is necessarily 326 based on transitive trust. Moreover, the RFC3325 approach 327 essentially assumes a closed network (a case which seems to be 328 contrary to REQ-12). Also, how important is anonymity in ETS? It 329 seems that accountability of ETS calls is very important - would 330 there actually be cases in which, say, a first responder wished to be 331 anonymous to a dispatch center, or for a military official to appear 332 anonymous to another military official? 334 4. Conclusions and Implementation Recommendations 336 The largest difficulty with the IEPREP recommendations for SIP is 337 their scope. The requirements seem oriented towards an environment 338 in which all SIP entities will support ETS. It would be much more 339 plausible if the document assumed that ETS was only supported in 340 closed networks that have the necessary relationships with government 341 agencies. 343 The currently documented user agent and proxy server behavior 344 associated with is thin. Section 3 offers little guidance 345 behavioral guidance for user agents and proxy servers that support 346 receive a prioritized request. 348 As the requirements stand, there seems to be no way to implement the 349 indicator/label. REQ-17 requires that the indicator be visible to 350 proxy servers, so that it can assist in routing, but SEC-8 requires 351 that unauthorized parties be unable to perceive the priority level of 352 calls, or indeed that priority has even been requested. This 353 suggests that some sort of encryption needs to be used to protect the 354 priority indicator. There is, however, no solution to provide 355 confidentiality properties in SIP headers - only in SIP MIME bodies. 356 But proxy servers are not allowed to inspect MIME bodies. One of 357 these requirements needs to be relaxed. 359 In fact, the requirement in REQ-17 only motivates the use of the 360 prioritization indicator by the proxy server to make a gateway 361 routing decision (like choosing a special ETS gateway instead of a 362 standard gateway). If gateway routing is the only requirement for 363 proxy servers to route based on priority, and we can assume that in 364 other cases there is no need for the proxy to inspect the label, we 365 can perhaps make a compromise. 367 Assuming that the confidentiality requirement in SEC-8 is relaxed, it 368 might be possible to implement the prioritization label as either a 369 URI parameter or a header. Given that in the gateway routing case, 370 tel URIs can be assumed to be used in the Request-URI of the SIP 371 request, REQ-10 seems much less strongly motivated. A tel URI based 372 solution seems like a reasonable approach given the overall 373 framework. 375 5. Security Considerations 377 Security requirements associated with the IEPREP work are discussed 378 in detail in Section 3.2. 380 6. IANA Considerations 382 This document introduces no considerations for the IANA. 384 Informative References 386 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 387 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 388 Session Initiation Protocol", RFC 3261, May 2002. 390 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 391 levels", RFC 2119, March 1997. 393 [3] Schulzrinne, H., "Requirements for Resource Priority Mechanisms 394 for the Session Initiation Protocol", draft-ietf-ieprep-sip- 395 reqs-03 (work in progress), December 2002. 397 [4] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 398 the Session Initiation Protocol (SIP) for Asserted Identity 399 within Trusted Networks", RFC 3325, November 2002. 401 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 402 Protocol (SIP)", RFC 3323, November 2002. 404 [6] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 405 Watson, M. and m. Zonoun, "MIME media types for ISUP and QSIG 406 objects", RFC 3204, December 2001. 408 [7] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP 409 Mapping", RFC 3398, December 2002. 411 Author's Address 413 Jon Peterson 414 NeuStar, Inc. 415 1800 Sutter St 416 Suite 570 417 Concord, CA 94520 418 US 420 Phone: +1 925/363-8720 421 EMail: jon.peterson@neustar.biz 422 URI: http://www.neustar.biz/ 424 Full Copyright Statement 426 Copyright (C) The Internet Society (2003). All Rights Reserved. 428 This document and translations of it may be copied and furnished to 429 others, and derivative works that comment on or otherwise explain it 430 or assist in its implementation may be prepared, copied, published 431 and distributed, in whole or in part, without restriction of any 432 kind, provided that the above copyright notice and this paragraph are 433 included on all such copies and derivative works. However, this 434 document itself may not be modified in any way, such as by removing 435 the copyright notice or references to the Internet Society or other 436 Internet organizations, except as needed for the purpose of 437 developing Internet standards in which case the procedures for 438 copyrights defined in the Internet Standards process must be 439 followed, or as required to translate it into languages other than 440 English. 442 The limited permissions granted above are perpetual and will not be 443 revoked by the Internet Society or its successors or assigns. 445 This document and the information contained herein is provided on an 446 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 447 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 448 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 449 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 450 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 452 Acknowledgement 454 Funding for the RFC Editor function is currently provided by the 455 Internet Society.