idnits 2.17.1 draft-ietf-sipping-session-policy-req-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 : ---------------------------------------------------------------------------- ** 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 (June 23, 2003) is 7612 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-06 == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-08 Summary: 2 errors (**), 0 flaws (~~), 4 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: December 22, 2003 June 23, 2003 6 Requirements for Session Policy for the Session Initiation Protocol 7 (SIP) 8 draft-ietf-sipping-session-policy-req-00 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 December 22, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). 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 Consent Requirements . . . . . . . . . . . . . . . . . . . . . 8 57 3.4 Security Requirements . . . . . . . . . . . . . . . . . . . . 9 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 Informative References . . . . . . . . . . . . . . . . . . . . 12 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 61 Intellectual Property and Copyright Statements . . . . . . . . 14 63 1. Introduction 65 The Session Initiation Protocol [2] enables the setup and management 66 of interactive multimedia sessions on IP networks. A central element 67 in SIP is the proxy server. Proxies are responsible for request 68 routing, rendezvous, authentication and authorization, mobility, and 69 other signaling services. However, proxies are divorced from the 70 actual sessions - audio, video, and messaging - that SIP establishes. 71 Details of the sessions are carried in the payload of SIP messages, 72 and are usually described with the Session Description Protocol (SDP) 73 [1]. Indeed, SIP provides end-to-end encryption features using S/ 74 MIME, so that all information about the sessions can be hidden from 75 eavesdroppers and proxies alike. 77 However, experience has shown that there is a need for SIP 78 intermediaries to impact aspects of the session. One aspect is the 79 path that the media streams will take. Frequently, a SIP provider 80 will need or want the media to traverse some kind of intermediary, 81 such as a NAT. Indeed, the central concept of the midcom framework 82 [4] is to define a model of how this can be done. In this model, a 83 midcom agent, typically a proxy server, interacts with the middlebox 84 to open and close media pinholes, obtain NAT bindings, and so on. In 85 this role as a midcom agent, the proxy will need to examine and 86 possibly modify the session description in the body of the SIP 87 message. This modification is to achieve a specific policy objective: 88 to force the media to route through an intermediary. 90 In another application, SIP is used in a wireless network. The 91 network provider has limited resources for media traffic. During 92 periods of high activity, the provider would like to restrict codec 93 usage on the network to lower rate codecs. 95 In yet a third application, SIP is used in a network that has 96 gateways which support a single codec type (say, G.729). When 97 communicating with a partner network that uses gateways with a 98 different codec (say, G.723), the network modifies the SDP to route 99 the session through a converter that changes the G.729 to G.723. 101 The desire to impact aspects of the session inevitably occurs in 102 domains where the administrator of the SIP domain is also the owner 103 and administrator of an IP network over which it is known that the 104 sessions will traverse. This includes enterprises, Internet access 105 providers, and in some cases, backbone providers. 107 Since SIP is the protocol by which the details of these sessions are 108 negotiated, it is natural for providers to wish to impose their 109 session policies through some kind of SIP means. To date, this has 110 been accomplished through SDP editing, a process where proxies dig 111 into the bodies of SIP messages, and modify them in order to impose 112 their policies. However, this SIP editing technique has many 113 drawbacks. 115 2. Problems with Existing Situation 117 RFC 3261 explicitly disallows proxy servers from manipulating the 118 content of bodies. This is at odds with the common industry practice 119 of extensive manipulation of bodies by proxies. Although a common 120 practice, it is at odds with the SIP specification for many reasons: 122 End-to-End Encryption: SIP uses S/MIME to support end-to-end 123 security security features. Authentication, message integrity, and 124 encryption are provided. The encryption capabilities are important 125 for end-to-end privacy services, for example. The end-to-end 126 message integrity and authentication are important for preventing 127 numerous attacks, including theft of calls, eavesdropping attacks, 128 and so on. If end-to-end authentication is used, any manipulation 129 of the body will cause the message integrity check to fail. If 130 end-to-end encryption is used, the proxy won't even be able to 131 look at the SDP to modify it. In this case, media may not 132 function, and the call will fail. 134 Require Processing: A UA may require that an extension be applied 135 to the SDP body. This is accomplished by including a Require 136 header in the SIP message. Proxies do not look at such headers. If 137 the proxy processes the SDP without understanding the extension, 138 it may improperly modify the SDP, resulting in a call failure. 140 Consent: Ultimately, end users need to be in control of the media 141 they send. If a user makes a call through a SIP network, they have 142 the expectation that their media is delivered to the recipient. By 143 having proxies modify the SDP in some way, they act in ways 144 outside of expected behavior of the system. 146 Future Proofing: One of the benefits of the SIP architecture is 147 that only the endpoints need to understand sessions, session 148 descriptions, bodies, and so on. This facilitates the use of proxy 149 networks to provide communications services for future session 150 types, such as games and messaging. However, if proxies require an 151 understanding of session types and session descriptions, the SIP 152 network becomes locked in to providing features for a particular 153 set of session types. If a new session description protocol, such 154 as SDPng [9], were introduced, calls would not function even 155 though the endpoints support SDPng. Furthermore, it would be hard 156 to determine why it did not function, since the failure would 157 occur transparently in some proxy in the middle of the network. 159 Robustness: Having a proxy manipulate the body introduces a host 160 of new failure modes into the network. Firstly, the proxy itself 161 will need to have state in some form in order to properly 162 manipulate the SDP. This means that, should the proxy fail, the 163 call may not be able to continue. Secondly, proxies typically 164 won't enforce the media policy. Rather, they leave that to some 165 media middlebox somewhere on the media path. This media middlebox 166 may fail as well. Since the user does not know of its existence, 167 they may not be able to detect this failure or retry the media 168 path around it. 170 Scalability: One of the reasons SIP scales so well is that proxies 171 don't have to be aware of the details of the sessions being 172 established through them. If a proxy needs to examine and/or 173 manipulate session descriptions, this could require many 174 additional processing steps. The proxy may need to traverse a 175 multi-part body to find the SDP, in the case of SIP-T [5]. The 176 proxy will need to parse, modify, and possibly re-serialize the 177 session description. All of this requires additional processing 178 that worsens the performance of the proxies. 180 We note that many of these problems are similar to those pointed out 181 by the IAB regarding Open Pluggable Exchange Services (OPES) [6]. 182 Indeed, the problems are similar. Both have to do with the 183 involvement of intermediaries in manipulation of end-to-end content. 184 Here, the content is not in the body itself, but is a session 185 described by the body. 187 We believe a better solution is needed. 189 3. Requirements for a Solution 191 In order to prevent the continuing usage of SDP editing to achieve 192 session policies, we believe explicit protocol support is needed to 193 provide a mechanism that can overcome the limitations above. As per 194 the IETF SIP change process [7], the first step in any such activity 195 is to specify requirements for the solution. This section is an 196 enumeration of those requirements. 198 3.1 General Requirements 200 REQ-GEN-1: The solution should work even with SIP end-to-end 201 encryption and end-to-end authentication enabled. 203 REQ-GEN-2: The solution should not force a proxy to violate the 204 SIP specification or any defined extensions. 206 REQ-GEN-3: The solution should not require substantial processing 207 burden on the proxies. 209 REQ-GEN-4: The solution should not require proxies to understand a 210 specific type of session description (i.e., SDP or SDPng). 212 REQ-GEN-5: The solution should have a minimal impact on call setup 213 delays, and ideally, have no impact on call setup delays. 215 REQ-GEN-6: The solution should require minimal overhead, since it 216 is anticipated to receive wide use in wireless networks. 218 REQ-GEN-7: The solution should be extensible, supporting new 219 session policy types in the future. 221 REQ-GEN-8: The solution must not require that the proxies be in 222 the same administrative domain as the media intermediaries. 224 3.2 Policy Requirements 226 REQ-POL-1: The solution should allow specification of independent 227 policies by each proxy along the call setup path, without any 228 coordination between proxies. 230 REQ-POL-2: The solution should allow a proxy to specify media 231 policies on a stream-by-stream basis. 233 REQ-POL-3: When used in conjunction with the offer/answer model 234 [3], the solution should allow a proxy to specify independent 235 policies for the media streams in each direction. 237 REQ-POL-4: The solution should allow a proxy to request media 238 sessions to traverse through one or more intermediaries. 240 REQ-POL-5: The solution should allow a proxy to request a specific 241 source routing mechanism to be used (when applicable) in order to 242 traverse those intermediaries. The source routing technique may be 243 media-specific, or a generic technique, such as IP-in-IP [8] 245 REQ-POL-6: Intermediaries must be identifiable using either an IP 246 address or an FQDN, in order to support DNS-based load balancing 247 and failover techniques. 249 REQ-POL-7: The solution should allow a proxy to inspect the 250 addresses for the media sessions, so that it can set policies in 251 intervening firewalls. 253 REQ-POL-8: The solution should allow proxies to request that a 254 particular media stream not be used (video, for example). 256 REQ-POL-9: The solution should allow proxies to request that a 257 particular codec not be used. 259 REQ-POL-10: The solution should allow proxies to express 260 preferences for the use of particular codecs. 262 REQ-POL-11: The solution should allow proxies to request that 263 Quality of Service (QoS) should be requested for a stream. 265 REQ-POL-12: The solution should allow proxies to ask endpoints to 266 use specific parameters in their QoS reservations. 268 REQ-POL-13: The solution should allow proxies to ask endpoints to 269 provide a specific credential in their QoS requests. This 270 requirement covers the functionality currently described in [10]. 272 3.3 Consent Requirements 274 Consent plays a critical role for this problem. End users must be 275 allowed control over how they communicate with each other. Indeed, 276 with end-to-end IP connectivity, there is frequently little the 277 provider can do to force users to communicate one way or another. 278 Ultimately, any means a provider comes up with can be circumvented by 279 some creative engineering in the clients. As such, policy requests by 280 proxies are just that - requests, and are ultimately honored at the 281 discretion of the end users. The mechanism needs to recognize this, 282 and be engineered to work within this model, rather than try to work 283 around it. 285 REQ-CON-1: The mechanism should allow the UAC to know the set of 286 policies requested by the proxies along the call path. [[OPEN 287 ISSUE: Is it more important for the UAC to know about changes 288 requested for media in one direction or the other?]] 290 REQ-CON-2: The mechanism should allow the UAS to know the set of 291 policies requested by the proxies along the call path. 293 REQ-CON-3: The mechanism should allow the UAC to reject any policy 294 requests made by proxies. 296 REQ-CON-4: The mechanism should allow the UAS to reject any policy 297 requests made by proxies. 299 REQ-CON-5: The mechanism should allow the proxies to know whether 300 or not the UAC has accepted its policy requests. 302 REQ-CON-6: The mechanism should allow the proxies to know whether 303 or not the UAS has accepted its policy requests. 305 REQ-CON-7: The mechanism should allow the proxies to inform the 306 UAC and UAS of the consequences of non-compliance to the policies. 307 Potential consequences include call rejection, degraded media 308 quality, lack of connectivity for a media stream, and so on. 310 3.4 Security Requirements 312 REQ-SEC-1: The mechanism should allow user agents to verify the 313 identity of the providers requesting the session policies. 315 REQ-SEC-2: The mechanism should allow user agents to verify the 316 integrity of the session policies. 318 REQ-SEC-3: The mechanism must provide assurances to the UAC and 319 UAS that only proxies on the actual SIP signaling path have 320 requested session policies. 322 REQ-SEC-4: The mechanism should allow proxies to ensure the 323 confidentiality of the session policies, so that no one but the 324 UAC or UAS can observe them. [[OPEN ISSUE: Is this really a 325 requirement?]] 327 REQ-SEC-5: The mechanism must not enable any new denial-of-service 328 attacks to be launched. [[OPEN ISSUE: This is motherhood and apple 329 pie - does it need to be here?]] 331 REQ-SEC-6: The mechanism shall still allow for media security 332 through Secure RTP [11]. In the case of intermediaries which 333 process the RTP in some way that would invalidate any signatures, 334 the UAs must be aware of the presence of the intermediary, and 335 perform key exchanges with it. [[OPEN ISSUE: This may be an 336 impossible requirement to meet without using a B2BUA.]] 338 4. Security Considerations 340 Requirements related to security are considered in Section 3.4. 342 Informative References 344 [1] Handley, M. and V. Jacobson, "SDP: Session Description 345 Protocol", RFC 2327, April 1998. 347 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 348 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 349 Session Initiation Protocol", RFC 3261, June 2002. 351 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 352 Session Description Protocol (SDP)", RFC 3264, June 2002. 354 [4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 355 Rayhan, "Middlebox communication architecture and framework", 356 RFC 3303, August 2002. 358 [5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for 359 Telephones (SIP-T): (SIP-T): Context and Architectures", BCP 360 63, RFC 3372, September 2002. 362 [6] Floyd, S. and L. Daigle, "IAB Architectural and Policy 363 Considerations for Open Pluggable Edge Services", RFC 3238, 364 January 2002. 366 [7] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 367 Rosen, "Change Process for the Session Initiation Protocol 368 (SIP)", BCP 67, RFC 3427, December 2002. 370 [8] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 371 1996. 373 [9] Ott, J., Bormann, C. and D. Kutscher, "Session Description and 374 Capability Negotiation", draft-ietf-mmusic-sdpng-06 (work in 375 progress), March 2003. 377 [10] Evans, D., Marshall, W. and B. Marshall, "SIP Extensions for 378 Media Authorization", draft-ietf-sip-call-auth-06 (work in 379 progress), May 2002. 381 [11] Baugher, M., "The Secure Real-time Transport Protocol", 382 draft-ietf-avt-srtp-08 (work in progress), June 2003. 384 Author's Address 386 Jonathan Rosenberg 387 dynamicsoft 388 600 Lanidex Plaza 389 Parsippany, NJ 07054 390 US 392 Phone: +1 973 952-5000 393 EMail: jdrosen@dynamicsoft.com 394 URI: http://www.jdrosen.net 396 Intellectual Property Statement 398 The IETF takes no position regarding the validity or scope of any 399 intellectual property or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; neither does it represent that it 403 has made any effort to identify any such rights. Information on the 404 IETF's procedures with respect to rights in standards-track and 405 standards-related documentation can be found in BCP-11. Copies of 406 claims of rights made available for publication and any assurances of 407 licenses to be made available, or the result of an attempt made to 408 obtain a general license or permission for the use of such 409 proprietary rights by implementors or users of this specification can 410 be obtained from the IETF Secretariat. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights which may cover technology that may be required to practice 415 this standard. Please address the information to the IETF Executive 416 Director. 418 Full Copyright Statement 420 Copyright (C) The Internet Society (2003). All Rights Reserved. 422 This document and translations of it may be copied and furnished to 423 others, and derivative works that comment on or otherwise explain it 424 or assist in its implementation may be prepared, copied, published 425 and distributed, in whole or in part, without restriction of any 426 kind, provided that the above copyright notice and this paragraph are 427 included on all such copies and derivative works. However, this 428 document itself may not be modified in any way, such as by removing 429 the copyright notice or references to the Internet Society or other 430 Internet organizations, except as needed for the purpose of 431 developing Internet standards in which case the procedures for 432 copyrights defined in the Internet Standards process must be 433 followed, or as required to translate it into languages other than 434 English. 436 The limited permissions granted above are perpetual and will not be 437 revoked by the Internet Society or its successors or assignees. 439 This document and the information contained herein is provided on an 440 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 441 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 442 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 443 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 444 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 Acknowledgement 448 Funding for the RFC Editor function is currently provided by the 449 Internet Society.