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