idnits 2.17.1 draft-ietf-sipping-session-policy-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 401. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 417), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 19, 2004) is 7220 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 17, 2005 July 19, 2004 5 Requirements for Session Policy for the Session Initiation Protocol 6 (SIP) 7 draft-ietf-sipping-session-policy-req-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 17, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 The proxy server plays a central role as an intermediary in the 41 establishment of sessions in the Session Initiation Protocol (SIP). 42 In that role, they can define and impact policies on call routing, 43 rendezvous, and other call features. However, there is no standard 44 means by which proxies can have any influence on session policies, 45 such as the codecs that are to be used. As such, ad-hoc and 46 non-conformant techniques have been deployed to allow for such policy 47 mechanisms. There is a need for a standards-based and complete 48 mechanism for session policies. This document defines a set of 49 requirements for such a mechanism. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problems with Existing Situation . . . . . . . . . . . . . . . 5 55 3. Requirements for a Solution . . . . . . . . . . . . . . . . . 7 56 3.1 General Requirements . . . . . . . . . . . . . . . . . . . 7 57 3.2 Policy Requirements . . . . . . . . . . . . . . . . . . . 7 58 3.3 Policy Types . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.4 Consent Requirements . . . . . . . . . . . . . . . . . . . 8 60 3.5 Security Requirements . . . . . . . . . . . . . . . . . . 9 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 63 6. Informative References . . . . . . . . . . . . . . . . . . . . 11 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . 13 67 1. Introduction 69 The Session Initiation Protocol [2] enables the setup and management 70 of interactive multimedia sessions on IP networks. A central element 71 in SIP is the proxy server. Proxies are responsible for request 72 routing, rendezvous, authentication and authorization, mobility, and 73 other signaling services. However, proxies are divorced from the 74 actual sessions - audio, video, and messaging - that SIP establishes. 75 Details of the sessions are carried in the payload of SIP messages, 76 and are usually described with the Session Description Protocol (SDP) 77 [1]. Indeed, SIP provides end-to-end encryption features using S/ 78 MIME, so that all information about the sessions can be hidden from 79 eavesdroppers and proxies alike. 81 However, experience has shown that there is a need for SIP 82 intermediaries to impact aspects of the session. One aspect is the 83 path that the media streams will take. Frequently, a SIP provider 84 will need or want the media to traverse some kind of intermediary, 85 such as a NAT. Indeed, the central concept of the midcom framework 86 [4] is to define a model of how this can be done. In this model, a 87 midcom agent, typically a proxy server, interacts with the middlebox 88 to open and close media pinholes, obtain NAT bindings, and so on. In 89 this role as a midcom agent, the proxy will need to examine and 90 possibly modify the session description in the body of the SIP 91 message. This modification is to achieve a specific policy 92 objective: to force the media to route through an intermediary. 94 In another application, SIP is used in a wireless network. The 95 network provider has limited resources for media traffic. During 96 periods of high activity, the provider would like to restrict codec 97 usage on the network to lower rate codecs. 99 In yet a third application, SIP is used in a network that has 100 gateways which support a single codec type (say, G.729). When 101 communicating with a partner network that uses gateways with a 102 different codec (say, G.723), the network modifies the SDP to route 103 the session through a converter that changes the G.729 to G.723. 105 The desire to impact aspects of the session inevitably occurs in 106 domains where the administrator of the SIP domain is also the owner 107 and administrator of an IP network over which it is known that the 108 sessions will traverse. This includes enterprises, Internet access 109 providers, and in some cases, backbone providers. 111 Since SIP is the protocol by which the details of these sessions are 112 negotiated, it is natural for providers to wish to impose their 113 session policies through some kind of SIP means. To date, this has 114 been accomplished through SDP editing, a process where proxies dig 115 into the bodies of SIP messages, and modify them in order to impose 116 their policies. However, this SIP editing technique has many 117 drawbacks. 119 2. Problems with Existing Situation 121 RFC 3261 explicitly disallows proxy servers from manipulating the 122 content of bodies. This is at odds with the common industry practice 123 of extensive manipulation of bodies by proxies. Although a common 124 practice, it is at odds with the SIP specification for many reasons: 125 End-to-End Encryption: SIP uses S/MIME to support end-to-end 126 security security features. Authentication, message integrity, 127 and encryption are provided. The encryption capabilities are 128 important for end-to-end privacy services, for example. The 129 end-to-end message integrity and authentication are important for 130 preventing numerous attacks, including theft of calls, 131 eavesdropping attacks, and so on. If end-to-end authentication is 132 used, any manipulation of the body will cause the message 133 integrity check to fail. If end-to-end encryption is used, the 134 proxy won't even be able to look at the SDP to modify it. In this 135 case, media may not 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. 139 If the proxy processes the SDP without understanding the 140 extension, it may improperly modify the SDP, resulting in a call 141 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. 147 Future Proofing: One of the benefits of the SIP architecture is 148 that only the endpoints need to understand sessions, session 149 descriptions, bodies, and so on. This facilitates the use of 150 proxy networks to provide communications services for future 151 session types, such as games and messaging. However, if proxies 152 require an understanding of session types and session 153 descriptions, the SIP network becomes locked in to providing 154 features for a particular set of session types. If a new session 155 description protocol, such as SDPng [10], were introduced, calls 156 would not function even though the endpoints support SDPng. 157 Furthermore, it would be hard to determine why it did not 158 function, since the failure would occur transparently in some 159 proxy in the middle of the network. 160 Robustness: Having a proxy manipulate the body introduces a host 161 of new failure modes into the network. Firstly, the proxy itself 162 will need to have state in some form in order to properly 163 manipulate the SDP. This means that, should the proxy fail, the 164 call may not be able to continue. Secondly, proxies typically 165 won't enforce the media policy. Rather, they leave that to some 166 media middlebox somewhere on the media path. This media middlebox 167 may fail as well. Since the user does not know of its existence, 168 they may not be able to detect this failure or retry the media 169 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 199 REQ-GEN-1: The solution should work even with SIP end-to-end 200 encryption and end-to-end authentication enabled. 201 REQ-GEN-2: The solution should not force a proxy to violate the SIP 202 specification or any defined extensions. 203 REQ-GEN-3: The solution should not require substantial processing 204 burden on the proxies. 205 REQ-GEN-4: The solution should not require proxies to understand a 206 specific type of session description (i.e., SDP or SDPng). 207 REQ-GEN-5: The solution should have a minimal impact on call setup 208 delays, and ideally, have no impact on call setup delays. 209 REQ-GEN-6: The solution should require minimal overhead, since it is 210 anticipated to receive wide use in wireless networks. 211 REQ-GEN-7: The solution should be extensible, supporting new session 212 policy types in the future. 213 REQ-GEN-8: The solution must not require that the proxies be in the 214 same administrative domain as the media intermediaries. 216 3.2 Policy Requirements 217 REQ-POL-1: The solution should allow specification of independent 218 policies by each proxy along the call setup path, without any 219 coordination between proxies. 220 REQ-POL-2: The solution should allow a proxy to specify media 221 policies on a stream-by-stream basis. 222 REQ-POL-3: When used in conjunction with the offer/answer model [3], 223 the solution should allow a proxy to specify independent policies 224 for the media streams in each direction. 225 REQ-POL-4: The mechanism must provide the ability to inform the UA 226 about the set of session-independent session policies when the 227 device starts up. These are session policies that do not depend 228 on a particular session. 229 REQ-POL-5: The mechanism must allow the provider to change the 230 session-independent policies at least a few times a day. 231 REQ-POL-6: The mechanism must allow the session independent policies 232 to vary on a user by user basis. 233 REQ-POL-7 The mechanism must provide a way to inform the client about 234 changes in session independent session policies when they occur. 236 3.3 Policy Types 237 REQ-POL-4: The solution should allow a proxy to request media 238 sessions to traverse through one or more intermediaries. 239 REQ-POL-5: The solution should allow a proxy to request a specific 240 source routing mechanism to be used (when applicable) in order to 241 traverse those intermediaries. The source routing technique may 242 be media-specific, or a generic technique, such as IP-in-IP [8] 243 REQ-POL-6: Intermediaries must be identifiable using either an IP 244 address or an FQDN, in order to support DNS-based load balancing 245 and failover techniques. 246 REQ-POL-7: The solution should allow a proxy to inspect the addresses 247 for the media sessions, so that it can set policies in intervening 248 firewalls. 249 REQ-POL-8: The solution should allow proxies to request that a 250 particular media stream not be used (video, for example). 251 REQ-POL-9: The solution should allow proxies to request that a 252 particular codec not be used. 253 REQ-POL-10: The solution should allow proxies to express preferences 254 for the use of particular codecs. 255 REQ-POL-11: The solution should allow proxies to request that Quality 256 of Service (QoS) should be requested for a stream. 257 REQ-POL-12: The solution should allow proxies to ask endpoints to use 258 specific parameters in their QoS reservations. 259 REQ-POL-13: The solution should allow proxies to ask endpoints to 260 provide a specific credential in their QoS requests. This 261 requirement covers the functionality currently described in [9]. 263 3.4 Consent Requirements 265 Consent plays a critical role for this problem. End users must be 266 allowed control over how they communicate with each other. Indeed, 267 with end-to-end IP connectivity, there is frequently little the 268 provider can do to force users to communicate one way or another. 269 Ultimately, any means a provider comes up with can be circumvented by 270 some creative engineering in the clients. As such, policy requests 271 by proxies are just that - requests, and are ultimately honored at 272 the discretion of the end users. The mechanism needs to recognize 273 this, and be engineered to work within this model, rather than try to 274 work around it. 275 REQ-CON-1: The mechanism should allow the UAC to know the set of 276 policies requested by the proxies along the call path. [[OPEN 277 ISSUE: Is it more important for the UAC to know about changes 278 requested for media in one direction or the other?]] 279 REQ-CON-2: The mechanism should allow the UAS to know the set of 280 policies requested by the proxies along the call path. 282 REQ-CON-3: The mechanism should allow the UAC to reject any policy 283 requests made by proxies. 284 REQ-CON-4: The mechanism should allow the UAS to reject any policy 285 requests made by proxies. 286 REQ-CON-5: The mechanism should allow the proxies to know whether or 287 not the UAC has accepted its policy requests. 288 REQ-CON-6: The mechanism should allow the proxies to know whether or 289 not the UAS has accepted its policy requests. 290 REQ-CON-7: The mechanism should allow the proxies to inform the UAC 291 and UAS of the consequences of non-compliance to the policies. 292 Potential consequences include call rejection, degraded media 293 quality, lack of connectivity for a media stream, and so on. 295 3.5 Security Requirements 296 REQ-SEC-1: The mechanism should allow user agents to verify the 297 identity of the providers requesting the session policies. 298 REQ-SEC-2: The mechanism should allow user agents to verify the 299 integrity of the session policies. 300 REQ-SEC-3: The mechanism must provide assurances to the UAC and UAS 301 that only proxies on the actual SIP signaling path have requested 302 session policies. 303 REQ-SEC-4: The mechanism should allow proxies to ensure the 304 confidentiality of the session policies, so that no one but the 305 UAC or UAS can observe them. [[OPEN ISSUE: Is this really a 306 requirement?]] 307 REQ-SEC-5: The mechanism must not enable any new denial-of-service 308 attacks to be launched. [[OPEN ISSUE: This is motherhood and 309 apple pie - does it need to be here?]] 310 REQ-SEC-6: The mechanism shall still allow for media security through 311 Secure RTP [11]. In the case of intermediaries which process the 312 RTP in some way that would invalidate any signatures, the UAs must 313 be aware of the presence of the intermediary, and perform key 314 exchanges with it. [[OPEN ISSUE: This may be an impossible 315 requirement to meet without using a B2BUA.]] 317 4. Security Considerations 319 Requirements related to security are considered in Section 3.5. 321 5. Acknowledgements 323 I would like to thank Volker Hilt, Gonzalo Camarillo, Miguel Garcia 324 and Kumiko Ono for their input. 326 6 Informative References 328 [1] Handley, M. and V. Jacobson, "SDP: Session Description 329 Protocol", RFC 2327, April 1998. 331 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 332 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 333 Session Initiation Protocol", RFC 3261, June 2002. 335 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 336 Session Description Protocol (SDP)", RFC 3264, June 2002. 338 [4] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 339 Rayhan, "Middlebox communication architecture and framework", 340 RFC 3303, August 2002. 342 [5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for 343 Telephones (SIP-T): Context and Architectures", BCP 63, RFC 344 3372, September 2002. 346 [6] Floyd, S. and L. Daigle, "IAB Architectural and Policy 347 Considerations for Open Pluggable Edge Services", RFC 3238, 348 January 2002. 350 [7] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 351 Rosen, "Change Process for the Session Initiation Protocol 352 (SIP)", BCP 67, RFC 3427, December 2002. 354 [8] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 355 1996. 357 [9] Marshall, W., "Private Session Initiation Protocol (SIP) 358 Extensions for Media Authorization", RFC 3313, January 2003. 360 [10] Kutscher, D., Ott, J. and C. Bormann, "Session Description and 361 Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in 362 progress), October 2003. 364 [11] Baugher, M., "The Secure Real-time Transport Protocol", 365 draft-ietf-avt-srtp-09 (work in progress), July 2003. 367 Author's Address 369 Jonathan Rosenberg 370 dynamicsoft 371 600 Lanidex Plaza 372 Parsippany, NJ 07054 373 US 375 Phone: +1 973 952-5000 376 EMail: jdrosen@dynamicsoft.com 377 URI: http://www.jdrosen.net 379 Intellectual Property Statement 381 The IETF takes no position regarding the validity or scope of any 382 Intellectual Property Rights or other rights that might be claimed to 383 pertain to the implementation or use of the technology described in 384 this document or the extent to which any license under such rights 385 might or might not be available; nor does it represent that it has 386 made any independent effort to identify any such rights. Information 387 on the procedures with respect to rights in RFC documents can be 388 found in BCP 78 and BCP 79. 390 Copies of IPR disclosures made to the IETF Secretariat and any 391 assurances of licenses to be made available, or the result of an 392 attempt made to obtain a general license or permission for the use of 393 such proprietary rights by implementers or users of this 394 specification can be obtained from the IETF on-line IPR repository at 395 http://www.ietf.org/ipr. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights that may cover technology that may be required to implement 400 this standard. Please address the information to the IETF at 401 ietf-ipr@ietf.org. 403 Disclaimer of Validity 405 This document and the information contained herein are provided on an 406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 408 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 409 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 410 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 Copyright Statement 415 Copyright (C) The Internet Society (2004). This document is subject 416 to the rights, licenses and restrictions contained in BCP 78, and 417 except as set forth therein, the authors retain all their rights. 419 Acknowledgment 421 Funding for the RFC Editor function is currently provided by the 422 Internet Society.