idnits 2.17.1 draft-ietf-sipping-session-policy-req-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 16, 2004) is 7375 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) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '1') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '7') (Obsoleted by RFC 5727) == Outdated reference: A later version (-08) exists of draft-ietf-mmusic-sdpng-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: August 16, 2004 February 16, 2004 6 Requirements for Session Policy for the Session Initiation Protocol 7 (SIP) 8 draft-ietf-sipping-session-policy-req-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-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 16, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 The proxy server plays a central role as an intermediary in the 39 establishment of sessions in the Session Initiation Protocol (SIP). 40 In that role, they can define and impact policies on call routing, 41 rendezvous, and other call features. However, there is no standard 42 means by which proxies can have any influence on session policies, 43 such as the codecs that are to be used. As such, ad-hoc and 44 non-conformant techniques have been deployed to allow for such policy 45 mechanisms. There is a need for a standards-based and complete 46 mechanism for session policies. This document defines a set of 47 requirements for such a mechanism. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problems with Existing Situation . . . . . . . . . . . . . . . 5 53 3. Requirements for a Solution . . . . . . . . . . . . . . . . . 7 54 3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . 7 55 3.2 Policy Requirements . . . . . . . . . . . . . . . . . . . . . 7 56 3.3 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 3.4 Consent Requirements . . . . . . . . . . . . . . . . . . . . . 9 58 3.5 Security Requirements . . . . . . . . . . . . . . . . . . . . 9 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 61 Informative References . . . . . . . . . . . . . . . . . . . . 13 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 63 Intellectual Property and Copyright Statements . . . . . . . . 15 65 1. Introduction 67 The Session Initiation Protocol [2] enables the setup and management 68 of interactive multimedia sessions on IP networks. A central element 69 in SIP is the proxy server. Proxies are responsible for request 70 routing, rendezvous, authentication and authorization, mobility, and 71 other signaling services. However, proxies are divorced from the 72 actual sessions - audio, video, and messaging - that SIP establishes. 73 Details of the sessions are carried in the payload of SIP messages, 74 and are usually described with the Session Description Protocol (SDP) 75 [1]. Indeed, SIP provides end-to-end encryption features using S/ 76 MIME, so that all information about the sessions can be hidden from 77 eavesdroppers and proxies alike. 79 However, experience has shown that there is a need for SIP 80 intermediaries to impact aspects of the session. One aspect is the 81 path that the media streams will take. Frequently, a SIP provider 82 will need or want the media to traverse some kind of intermediary, 83 such as a NAT. Indeed, the central concept of the midcom framework 84 [4] is to define a model of how this can be done. In this model, a 85 midcom agent, typically a proxy server, interacts with the middlebox 86 to open and close media pinholes, obtain NAT bindings, and so on. In 87 this role as a midcom agent, the proxy will need to examine and 88 possibly modify the session description in the body of the SIP 89 message. This modification is to achieve a specific policy objective: 90 to force the media to route through an intermediary. 92 In another application, SIP is used in a wireless network. The 93 network provider has limited resources for media traffic. During 94 periods of high activity, the provider would like to restrict codec 95 usage on the network to lower rate codecs. 97 In yet a third application, SIP is used in a network that has 98 gateways which support a single codec type (say, G.729). When 99 communicating with a partner network that uses gateways with a 100 different codec (say, G.723), the network modifies the SDP to route 101 the session through a converter that changes the G.729 to G.723. 103 The desire to impact aspects of the session inevitably occurs in 104 domains where the administrator of the SIP domain is also the owner 105 and administrator of an IP network over which it is known that the 106 sessions will traverse. This includes enterprises, Internet access 107 providers, and in some cases, backbone providers. 109 Since SIP is the protocol by which the details of these sessions are 110 negotiated, it is natural for providers to wish to impose their 111 session policies through some kind of SIP means. To date, this has 112 been accomplished through SDP editing, a process where proxies dig 113 into the bodies of SIP messages, and modify them in order to impose 114 their policies. However, this SIP editing technique has many 115 drawbacks. 117 2. Problems with Existing Situation 119 RFC 3261 explicitly disallows proxy servers from manipulating the 120 content of bodies. This is at odds with the common industry practice 121 of extensive manipulation of bodies by proxies. Although a common 122 practice, it is at odds with the SIP specification for many reasons: 124 End-to-End Encryption: SIP uses S/MIME to support end-to-end 125 security security features. Authentication, message integrity, and 126 encryption are provided. The encryption capabilities are important 127 for end-to-end privacy services, for example. The end-to-end 128 message integrity and authentication are important for preventing 129 numerous attacks, including theft of calls, eavesdropping attacks, 130 and so on. If end-to-end authentication is used, any manipulation 131 of the body will cause the message integrity check to fail. If 132 end-to-end encryption is used, the proxy won't even be able to 133 look at the SDP to modify it. In this case, media may not 134 function, and the call will fail. 136 Require Processing: A UA may require that an extension be applied 137 to the SDP body. This is accomplished by including a Require 138 header in the SIP message. Proxies do not look at such headers. If 139 the proxy processes the SDP without understanding the extension, 140 it may improperly modify the SDP, resulting in a call failure. 142 Consent: Ultimately, end users need to be in control of the media 143 they send. If a user makes a call through a SIP network, they have 144 the expectation that their media is delivered to the recipient. By 145 having proxies modify the SDP in some way, they act in ways 146 outside of expected behavior of the system. 148 Future Proofing: One of the benefits of the SIP architecture is 149 that only the endpoints need to understand sessions, session 150 descriptions, bodies, and so on. This facilitates the use of proxy 151 networks to provide communications services for future session 152 types, such as games and messaging. However, if proxies require an 153 understanding of session types and session descriptions, the SIP 154 network becomes locked in to providing features for a particular 155 set of session types. If a new session description protocol, such 156 as SDPng [10], were introduced, calls would not function even 157 though the endpoints support SDPng. Furthermore, it would be hard 158 to determine why it did not function, since the failure would 159 occur transparently in some proxy in the middle of the network. 161 Robustness: Having a proxy manipulate the body introduces a host 162 of new failure modes into the network. Firstly, the proxy itself 163 will need to have state in some form in order to properly 164 manipulate the SDP. This means that, should the proxy fail, the 165 call may not be able to continue. Secondly, proxies typically 166 won't enforce the media policy. Rather, they leave that to some 167 media middlebox somewhere on the media path. This media middlebox 168 may fail as well. Since the user does not know of its existence, 169 they may not be able to detect this failure or retry the media 170 path around it. 172 Scalability: One of the reasons SIP scales so well is that proxies 173 don't have to be aware of the details of the sessions being 174 established through them. If a proxy needs to examine and/or 175 manipulate session descriptions, this could require many 176 additional processing steps. The proxy may need to traverse a 177 multi-part body to find the SDP, in the case of SIP-T [5]. The 178 proxy will need to parse, modify, and possibly re-serialize the 179 session description. All of this requires additional processing 180 that worsens the performance of the proxies. 182 We note that many of these problems are similar to those pointed out 183 by the IAB regarding Open Pluggable Exchange Services (OPES) [6]. 184 Indeed, the problems are similar. Both have to do with the 185 involvement of intermediaries in manipulation of end-to-end content. 186 Here, the content is not in the body itself, but is a session 187 described by the body. 189 We believe a better solution is needed. 191 3. Requirements for a Solution 193 In order to prevent the continuing usage of SDP editing to achieve 194 session policies, we believe explicit protocol support is needed to 195 provide a mechanism that can overcome the limitations above. As per 196 the IETF SIP change process [7], the first step in any such activity 197 is to specify requirements for the solution. This section is an 198 enumeration of those requirements. 200 3.1 General Requirements 202 REQ-GEN-1: The solution should work even with SIP end-to-end 203 encryption and end-to-end authentication enabled. 205 REQ-GEN-2: The solution should not force a proxy to violate the SIP 206 specification or any defined extensions. 208 REQ-GEN-3: The solution should not require substantial processing 209 burden on the proxies. 211 REQ-GEN-4: The solution should not require proxies to understand a 212 specific type of session description (i.e., SDP or SDPng). 214 REQ-GEN-5: The solution should have a minimal impact on call setup 215 delays, and ideally, have no impact on call setup delays. 217 REQ-GEN-6: The solution should require minimal overhead, since it is 218 anticipated to receive wide use in wireless networks. 220 REQ-GEN-7: The solution should be extensible, supporting new session 221 policy types in the future. 223 REQ-GEN-8: The solution must not require that the proxies be in the 224 same administrative domain as the media intermediaries. 226 3.2 Policy Requirements 228 REQ-POL-1: The solution should allow specification of independent 229 policies by each proxy along the call setup path, without any 230 coordination between proxies. 232 REQ-POL-2: The solution should allow a proxy to specify media 233 policies on a stream-by-stream basis. 235 REQ-POL-3: When used in conjunction with the offer/answer model [3], 236 the solution should allow a proxy to specify independent policies 237 for the media streams in each direction. 239 REQ-POL-4: The mechanism must provide the ability to inform the UA 240 about the set of session-independent session policies when the 241 device starts up. These are session policies that do not depend on 242 a particular session. 244 REQ-POL-5: The mechanism must allow the provider to change the 245 session-independent policies at least a few times a day. 247 REQ-POL-6: The mechanism must allow the session independent policies 248 to vary on a user by user basis. 250 REQ-POL-7 The mechanism must provide a way to inform the client about 251 changes in session independent session policies when they occur. 253 3.3 Policy Types 255 REQ-POL-4: The solution should allow a proxy to request media 256 sessions to traverse through one or more intermediaries. 258 REQ-POL-5: The solution should allow a proxy to request a specific 259 source routing mechanism to be used (when applicable) in order to 260 traverse those intermediaries. The source routing technique may be 261 media-specific, or a generic technique, such as IP-in-IP [8] 263 REQ-POL-6: Intermediaries must be identifiable using either an IP 264 address or an FQDN, in order to support DNS-based load balancing 265 and failover techniques. 267 REQ-POL-7: The solution should allow a proxy to inspect the addresses 268 for the media sessions, so that it can set policies in intervening 269 firewalls. 271 REQ-POL-8: The solution should allow proxies to request that a 272 particular media stream not be used (video, for example). 274 REQ-POL-9: The solution should allow proxies to request that a 275 particular codec not be used. 277 REQ-POL-10: The solution should allow proxies to express preferences 278 for the use of particular codecs. 280 REQ-POL-11: The solution should allow proxies to request that Quality 281 of Service (QoS) should be requested for a stream. 283 REQ-POL-12: The solution should allow proxies to ask endpoints to use 284 specific parameters in their QoS reservations. 286 REQ-POL-13: The solution should allow proxies to ask endpoints to 287 provide a specific credential in their QoS requests. This 288 requirement covers the functionality currently described in [9]. 290 3.4 Consent Requirements 292 Consent plays a critical role for this problem. End users must be 293 allowed control over how they communicate with each other. Indeed, 294 with end-to-end IP connectivity, there is frequently little the 295 provider can do to force users to communicate one way or another. 296 Ultimately, any means a provider comes up with can be circumvented by 297 some creative engineering in the clients. As such, policy requests by 298 proxies are just that - requests, and are ultimately honored at the 299 discretion of the end users. The mechanism needs to recognize this, 300 and be engineered to work within this model, rather than try to work 301 around it. 303 REQ-CON-1: The mechanism should allow the UAC to know the set of 304 policies requested by the proxies along the call path. [[OPEN 305 ISSUE: Is it more important for the UAC to know about changes 306 requested for media in one direction or the other?]] 308 REQ-CON-2: The mechanism should allow the UAS to know the set of 309 policies requested by the proxies along the call path. 311 REQ-CON-3: The mechanism should allow the UAC to reject any policy 312 requests made by proxies. 314 REQ-CON-4: The mechanism should allow the UAS to reject any policy 315 requests made by proxies. 317 REQ-CON-5: The mechanism should allow the proxies to know whether or 318 not the UAC has accepted its policy requests. 320 REQ-CON-6: The mechanism should allow the proxies to know whether or 321 not the UAS has accepted its policy requests. 323 REQ-CON-7: The mechanism should allow the proxies to inform the UAC 324 and UAS of the consequences of non-compliance to the policies. 325 Potential consequences include call rejection, degraded media 326 quality, lack of connectivity for a media stream, and so on. 328 3.5 Security Requirements 329 REQ-SEC-1: The mechanism should allow user agents to verify the 330 identity of the providers requesting the session policies. 332 REQ-SEC-2: The mechanism should allow user agents to verify the 333 integrity of the session policies. 335 REQ-SEC-3: The mechanism must provide assurances to the UAC and UAS 336 that only proxies on the actual SIP signaling path have requested 337 session policies. 339 REQ-SEC-4: The mechanism should allow proxies to ensure the 340 confidentiality of the session policies, so that no one but the 341 UAC or UAS can observe them. [[OPEN ISSUE: Is this really a 342 requirement?]] 344 REQ-SEC-5: The mechanism must not enable any new denial-of-service 345 attacks to be launched. [[OPEN ISSUE: This is motherhood and apple 346 pie - does it need to be here?]] 348 REQ-SEC-6: The mechanism shall still allow for media security through 349 Secure RTP [11]. In the case of intermediaries which process the 350 RTP in some way that would invalidate any signatures, the UAs must 351 be aware of the presence of the intermediary, and perform key 352 exchanges with it. [[OPEN ISSUE: This may be an impossible 353 requirement to meet without using a B2BUA.]] 355 4. Security Considerations 357 Requirements related to security are considered in Section 3.5. 359 5. Acknowledgements 361 I would like to thank Volker Hilt, Gonzalo Camarillo, Miguel Garcia 362 and Kumiko Ono for their input. 364 Informative References 366 [1] Handley, M. and V. Jacobson, "SDP: Session Description 367 Protocol", RFC 2327, April 1998. 369 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 370 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 371 Session Initiation Protocol", RFC 3261, June 2002. 373 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 374 Session Description Protocol (SDP)", RFC 3264, June 2002. 376 [4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 377 Rayhan, "Middlebox communication architecture and framework", 378 RFC 3303, August 2002. 380 [5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for 381 Telephones (SIP-T): Context and Architectures", BCP 63, RFC 382 3372, September 2002. 384 [6] Floyd, S. and L. Daigle, "IAB Architectural and Policy 385 Considerations for Open Pluggable Edge Services", RFC 3238, 386 January 2002. 388 [7] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 389 Rosen, "Change Process for the Session Initiation Protocol 390 (SIP)", BCP 67, RFC 3427, December 2002. 392 [8] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 393 1996. 395 [9] Marshall, W., "Private Session Initiation Protocol (SIP) 396 Extensions for Media Authorization", RFC 3313, January 2003. 398 [10] Kutscher, D., Ott, J. and C. Bormann, "Session Description and 399 Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in 400 progress), October 2003. 402 [11] Baugher, M., "The Secure Real-time Transport Protocol", 403 draft-ietf-avt-srtp-09 (work in progress), July 2003. 405 Author's Address 407 Jonathan Rosenberg 408 dynamicsoft 409 600 Lanidex Plaza 410 Parsippany, NJ 07054 411 US 413 Phone: +1 973 952-5000 414 EMail: jdrosen@dynamicsoft.com 415 URI: http://www.jdrosen.net 417 Intellectual Property Statement 419 The IETF takes no position regarding the validity or scope of any 420 intellectual property or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; neither does it represent that it 424 has made any effort to identify any such rights. Information on the 425 IETF's procedures with respect to rights in standards-track and 426 standards-related documentation can be found in BCP-11. Copies of 427 claims of rights made available for publication and any assurances of 428 licenses to be made available, or the result of an attempt made to 429 obtain a general license or permission for the use of such 430 proprietary rights by implementors or users of this specification can 431 be obtained from the IETF Secretariat. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights which may cover technology that may be required to practice 436 this standard. Please address the information to the IETF Executive 437 Director. 439 Full Copyright Statement 441 Copyright (C) The Internet Society (2004). All Rights Reserved. 443 This document and translations of it may be copied and furnished to 444 others, and derivative works that comment on or otherwise explain it 445 or assist in its implementation may be prepared, copied, published 446 and distributed, in whole or in part, without restriction of any 447 kind, provided that the above copyright notice and this paragraph are 448 included on all such copies and derivative works. However, this 449 document itself may not be modified in any way, such as by removing 450 the copyright notice or references to the Internet Society or other 451 Internet organizations, except as needed for the purpose of 452 developing Internet standards in which case the procedures for 453 copyrights defined in the Internet Standards process must be 454 followed, or as required to translate it into languages other than 455 English. 457 The limited permissions granted above are perpetual and will not be 458 revoked by the Internet Society or its successors or assignees. 460 This document and the information contained herein is provided on an 461 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 462 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 463 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 464 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 465 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 Acknowledgment 469 Funding for the RFC Editor function is currently provided by the 470 Internet Society.