idnits 2.17.1 draft-hilt-sipping-policy-usecases-00.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 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 552. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 6, 2005) is 6892 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) == Outdated reference: A later version (-03) exists of draft-ietf-sipping-session-indep-policy-01 -- No information found for draft-ietf-sipping-session-spec-policy - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: December 8, 2005 G. Camarillo 5 Ericsson 6 June 6, 2005 8 Use Cases for Session-Specific Session Initiation Protocol (SIP) Session 9 Policies 10 draft-hilt-sipping-policy-usecases-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 8, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This draft describes use cases for session-specific Session 44 Initiation Protocol (SIP) sessions policies. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1 Media Intermediary . . . . . . . . . . . . . . . . . . . . 3 51 2.1.1 General Overview . . . . . . . . . . . . . . . . . . . 3 52 2.1.2 Traffic Monitoring . . . . . . . . . . . . . . . . . . 7 53 2.1.3 Enforcing SLA/Access Control . . . . . . . . . . . . . 7 54 2.1.4 Load Balancing and Traffic Shaping . . . . . . . . . . 7 55 2.1.5 QoS Marking . . . . . . . . . . . . . . . . . . . . . 8 56 2.1.6 NAT/Firewall Traversal . . . . . . . . . . . . . . . . 8 57 2.1.7 Media-level Topology Hiding . . . . . . . . . . . . . 8 58 2.1.8 IPv4/IPv6 Interworking . . . . . . . . . . . . . . . . 8 59 2.1.9 Media Encryption . . . . . . . . . . . . . . . . . . . 9 60 2.2 Limitations and Restrictions . . . . . . . . . . . . . . . 9 61 2.2.1 General Overview . . . . . . . . . . . . . . . . . . . 9 62 2.2.2 Limit Bandwidth . . . . . . . . . . . . . . . . . . . 10 63 2.2.3 Restrict Codec Usage . . . . . . . . . . . . . . . . . 11 64 2.2.4 Restrict Media Type Usage . . . . . . . . . . . . . . 11 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 5. Informative References . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . 14 71 1. Introduction 73 Some domains have policies in place, which impact the sessions 74 established using the Session Initiation Protocol (SIP) [3]. These 75 policies are often needed to support the network infrastructure or 76 for the execution of services. For example, wireless networks 77 usually have limited resources for media traffic. A wireless network 78 provider may want to restrict codec usage on the network to lower 79 rate codecs or disallow the use of high bandwidth media types such as 80 video. 82 Session policies provide a mechanism for a network domain to 83 communicate these policies to user agents. With session policies, 84 user agents know about the policies in the network and can adjust 85 their sessions so that they comply with these policies or simply 86 connect to a domain with less stringent policies. 88 There has been much discussion in the IETF about the most suitable 89 protocol for session-specific Session Initiation Protocol (SIP) 90 policies [2]. The goal of this draft is to describe common use cases 91 in which session-specific policies are expected to be used. 92 Particularly controversial in this discussion is the mechanism for 93 conveying session information from the user agent to the policy 94 server. This draft will therefore describe the session information a 95 policy server needs to know for each of the discussed use case 96 scenarios. 98 This document focuses on session-specific policies. In some of the 99 use cases it might also be possible to use session-independent 100 policies [1]. However, session-independent policies are outside of 101 the scope of this document and their use will not be discussed here. 103 2. Use Cases 105 Most of the use cases for session-specific policies are based on the 106 insertion of a media intermediary or the limitation of certain 107 aspects of a session. The two categories of use cases are discussed 108 separately in the sections below. 110 2.1 Media Intermediary 112 This section provides a general overview over the insertion of a 113 media intermediary with session policies. It then discusses use 114 cases that are based on intermediaries. 116 2.1.1 General Overview 118 In this scenario it is assumed that a UA A is located in a policy 119 enabled domain (see Figure 1), which has an outbound proxy (P A), a 120 policy server (PS A) and a media intermediary (M A). UA A places a 121 call to a UA in another domain (UA B). 123 +------+ +---------------+ +------+ 124 | |<--------->| Proxy (P A) |<-------------------->| | 125 | | +---------------+ | | 126 | | +---------------+ | | 127 | | | Policy Server | | | 128 | UA A |<=========>| (PS A) | | UA B | 129 | | +---------------+ | | 130 | | +---------------+ | | 131 | (b)<*********| (M A) Media (a)<********************| | 132 | |*********>(c) Intermediary |********************>(d) | 133 +------+ +---------------+ +------+ 135 --- SIP Signaling 136 === Policy Channel 137 *** Media 139 Figure 1 141 In step (1) in Figure 2 UA A sends out an INVITE and receives the 142 address of the policy server PS A in step (2). It discloses session 143 information (from the offer) to policy server PS A in step (3). The 144 information disclosed includes the IP address and port (b) UA A is 145 going to use for inbound streams. 147 The policy server uses this information to create an address binding 148 for inbound media streams on M A. The binding connects a port on M A 149 (port (a) in Figure 2) to the address and port provided by UA A (i.e. 150 port (b)). With this binding, M A forwards all incoming traffic on 151 port (a) to port (b) on UA A. 153 UA A must use the address of M A and port (a) in the offer (instead 154 of its own address and port). PS A therefore returns the policy 155 shown in Figure 3 to UA A in step (4). This policy contains the 156 address of M A (192.0.2.0) and port (a) (6000/6001). Using this 157 policy, UA A creates a new offer' and sends it to UA B in step (5). 158 UA B will now send its media to port (a) on M A. From there it will 159 be forwarded to port (a) on UA A. Thus, M A has been inserted into 160 the inbound media stream. 162 UA A receives an answer in step (6) and discloses the address of UA B 163 and port (d) (extracted from the answer) to the policy server PS A in 164 step (7). PS A sets up a second binding now for outbound streams on 165 the M A. This binding connects port (c) on M A to the address and 166 port that was in the answer (i.e. the address of UA B and port(d)). 168 The address of M A and port (c) is returned to UA A in a policy in 169 step (8). UA A applies this policy to the answer. Thus, UA A will 170 now send its outbound traffic to M A, which in turn forwards it to UA 171 B. M A has also been inserted into the outbound media stream. 173 Proxy P A stays in the signaling path and removes the address 174 bindings on M A when the session is terminated. 176 Media streams can be encrypted by the UAs. In many cases, media 177 intermediaries need to decrypt the encrypted streams. UA A may 178 therefore need to provide an intermediary with the encryption keys 179 for the current session. 181 Information the UA needs to disclose to the policy server on the 182 policy channel: 184 o offer: the UA discloses the IP addresses and ports of all media 185 streams in the offer. The UA may also need to disclose the 186 encryption keys used for the current session. 187 o answer: the UA discloses the IP addresses and ports of all media 188 streams in the answer. The UA may also need to disclose the 189 encryption keys used for the current session. 191 UA A P A UA B 192 | | | 193 | INVITE offer | | 194 |---------------->| | (1) 195 | 488 | | 196 | + Policy-Contact| | 197 |<----------------| | (2) 198 | ACK | | 199 |---------------->| PS A | 200 | PolicyChannel | | 201 | + InfoOffer | | 202 |------------------->| | (3) 203 | PolicyChannel | | 204 | + PolicyOffer | | 205 |<-------------------| | (4) 206 | INVITE offer' | INVITE offer' | 207 | + Policy-Id | | 208 |---------------->|---------------------------->| (5) 209 | | | 210 | OK answer | OK answer | 211 |<----------------|<----------------------------| (6) 212 | ACK | 213 |---------------------------------------------->| 214 | PolicyChannel | | 215 | + InfoAnswer | | 216 |------------------->| | (7) 217 | PolicyChannel | | 218 | + PolicyAnswer | | 219 |<-------------------| | (8) 220 | | | 222 Figure 2 224 225 226 192.0.2.0:6000 227 6001 228 none 229 230 232 Figure 3 234 In the above call flow, intermediaries are inserted by modifying the 235 address and ports of media streams. Other techniques for inserting a 236 media intermediary such as using IP tunneling or TURN are also 237 feasible but not discussed in this draft. 239 2.1.2 Traffic Monitoring 241 Traffic monitoring generally requires that an entity in the network 242 can examine the media packets of a flow. It may also require that 243 media streams can be associated with SIP sessions. 245 A media intermediary that has been inserted into a media stream as 246 described above can examine media packets as required. Media streams 247 can be associated with the session for which the policy was created. 249 2.1.3 Enforcing SLA/Access Control 251 It is often desirable to enforce policies on media streams, for 252 example, according to a Service Level Agreement (SLA). Enforcing 253 policies requires that a network entity can monitor traffic and, in 254 case policies are violated, block traffic as needed. 256 Traffic monitoring can be performed by a media intermediary. The 257 intermediary can also decide whether packets are compliant to a given 258 policy or not. It can block streams if policies are violated by 259 dropping the respective packets. 261 An intermediary can enforce many types of media-level policies. For 262 example, it can enforce limitations session aspects (e.g., codecs, 263 bandwidth, media types), ensure that the media streams correspond 264 with what has been announced in the session description and it can 265 reject traffic that is sent outside of a SIP session. The 266 intermediary can also terminate streams for other reasons, for 267 example, if the user runs out of credit. 269 2.1.4 Load Balancing and Traffic Shaping 271 Load balancing and traffic shaping typically requires that the 272 network can determine the route of media streams independent of the 273 path that would be chosen by IP routing. This type of route 274 selection can take multiple criteria into account such as current 275 traffic conditions or peering agreements. For example, a service 276 provide may be connected to another service provider through two 277 links and may want to selectively route calls over one or the other 278 link. In another example, a service provide wants to route traffic 279 through a domain that would otherwise not be traversed by the media 280 streams. 282 A media intermediary can perform traffic shaping and load balancing. 283 The intermediary receives packets from the UA and can determine the 284 next hop destination for these packets. 286 A service provider may have multiple media intermediaries at 287 strategic locations in the network. By selecting one of these 288 intermediaries for a session, it forces the corresponding media 289 streams to go through the chosen intermediary. This way, media 290 traffic can be directed through a specific link, to a certain part of 291 the network or through a certain domain. The routing decision is 292 made by simply including a specific intermediary into the path. 294 2.1.5 QoS Marking 296 Two approaches for QoS marking on media streams are feasible with 297 session policies: 299 o Hosted QoS marking: a media intermediary is inserted as described 300 above. The intermediary performs QoS marking. 301 o Endsystem-based QoS marking: the policy server returns a session 302 policy that contains the desired DSCP value (following the flow 303 described in Section 2.2). The endpoint itself performs QoS 304 marking using this DSCP value. 306 2.1.6 NAT/Firewall Traversal 308 NAT/firewall traversal requires that the NAT/firewall is inserted 309 into the media path. Each endpoint sends its traffic to the NAT/ 310 firewall, which then forwards it to the destination on the other side 311 of the NAT/firewall as permitted by NAT/firewall policies. 313 An media intermediary that is inserted into the media path as 314 described above can act as NAT/firewall. 316 2.1.7 Media-level Topology Hiding 318 Topology hiding is mostly done at the signaling level. However, 319 media-level topology may be used to hide the addresses of media 320 endpoints inside the network. 322 A media intermediary inserted into streams as described above can 323 perform media-level topology hiding. Such a media intermediary will 324 usually act as RTP mixer/translator. It can remove all internal IP 325 addresses and possibly other sensitive information carried in RTCP 326 reports. 328 2.1.8 IPv4/IPv6 Interworking 330 IPv4/v6 translation on media streams can also be performed by a media 331 intermediary. 333 2.1.9 Media Encryption 335 A media intermediary can encrypt/decrypt media traffic before 336 forwarding it. Media encryption/decription requires that the 337 intermediary has the encryption keys for the current session. 339 Media intermediaries may also need to decrypt encrypted media streams 340 in order to perform other functionalities that require a deep 341 inspection of RTP packets. 343 2.2 Limitations and Restrictions 345 This section provides a general overview over the use of session 346 policies to restrict certain aspects of a session. It provides 347 example use cases for some of these policies. 349 2.2.1 General Overview 351 The scenario is similar to Figure 1 except that there is no media 352 intermediary (in a real architecture, it may still be present to 353 perform other functionalities such as policy enforcement). 355 Steps (1) to (3) in Figure 4 are the same as above (see Figure 2). 357 After receiving offer information in step (3), the policy server 358 determines whether a policy is needed or not. If a policy is needed, 359 it is returned to UA A in step (4) (see policy examples below). The 360 UA A creates a modified offer' according to the received policies 361 (step (5)) and completes the session setup in step (6). 363 Policies that define limitations or restrictions reduce available 364 choices for session parameters. These policies only need to be 365 applied to an offer because the answer can't extend the choices 366 available in an offer. 368 The policy server PS A can asynchronously update the policy provided 369 to UA A during session setup. For example, a policy server may whish 370 to disallow a codec that was allowed by the initial session policy. 371 In step (7) PS A sends an updated policy to UA A. This policy 372 requires a change in the current session. UA A therefore updates the 373 session by sending a re-INVITE with a modified offer in step (8). 375 The information the UA needs to disclose to the policy server depends 376 on the individual use case and are described below. 378 UA A P A UA B 379 | | | 380 | INVITE offer | | 381 |---------------->| | (1) 382 | 488 | | 383 | + Policy-Contact| | 384 |<----------------| | (2) 385 | ACK | | 386 |---------------->| PS A | 387 | PolicyChannel | | 388 | + InfoOffer | | 389 |------------------->| | (3) 390 | PolicyChannel | | 391 | + PolicyOffer | | 392 |<-------------------| | (4) 393 | INVITE offer' | INVITE offer' | 394 | + Policy-Id | | 395 |---------------->|---------------------------->| (5) 396 | | | 397 | OK answer | OK answer | 398 |<----------------|<----------------------------| (6) 399 | ACK | 400 |---------------------------------------------->| 401 | | | 402 | | | 403 | PolicyChannel | | 404 | + PolicyOffer" | | 405 |<-------------------| | (7) 406 | INVITE offer" | INVITE offer" | 407 | + Policy-Id | | 408 |---------------->|---------------------------->| (8) 409 | OK answer | OK answer | 410 |<----------------|<----------------------------| 411 | ACK | 412 |---------------------------------------------->| 413 | | | 415 Figure 4 417 2.2.2 Limit Bandwidth 419 In some environments there is only a limited bandwidth available to 420 each user agent (e.g. in a wireless network). Communicating 421 bandwidth limitations to the user agent enables the user agent to 422 make an informed decisions, for example, about the codecs or media 423 types to be used in a session. 425 The following example policy informs the UA of a 80 kbit/s bandwidth 426 limit. In the context of session-specific policies, this policy is 427 returned if the offer can result in a session that exceeds the 428 allowed maximum bandwidth. The offer' that is created based on this 429 policy should not contain choices that may exceed the maximum 430 bandwidth (e.g. it could consist of one audio stream and the codecs 431 G.711 and G.729). 433 434 80 435 437 Information the UA needs to disclose to the policy server about the 438 offer on the policy channel: 440 o The UA must disclose all aspects of a session that may affect the 441 media bandwidth used. These are typically the number of streams 442 together with the media type and the codecs available on a stream. 443 Alternatively, the UA can disclose a maximum bandwidth value. 445 2.2.3 Restrict Codec Usage 447 Networks may want to impose restrictions on the codecs that can be 448 used. With session-specific policies it is possible tell the UA that 449 some of the codecs in the offer are prohibited. 451 The following example policy informs the UA that the codecs G.729 and 452 G.723 are not allowed. Offer' should therefore not include G.729 and 453 G.723. 455 456 457 G729 458 G723 459 460 462 Information the UA needs to disclose to the policy server about the 463 offer on the policy channel: 465 o The UA must disclose all codecs it has included in the offer. 467 2.2.4 Restrict Media Type Usage 469 Similar to codecs, it is possible to restrict the use of media types 470 using session-specific policies. 472 The example policy below defines that audio is required, video is 473 allowed and all other media types are disallowed. 475 476 477 audio 478 video 479 480 482 Information the UA needs to disclose to the policy server about the 483 offer on the policy channel: 485 o The UA must disclose all media types it has included in the offer. 487 3. Security Considerations 489 This draft describes the use of mechanisms defined in other drafts 490 and does not introduce additional security issues. 492 4. IANA Considerations 494 This draft does not introduce new identifiers or namespaces. 496 5. Informative References 498 [1] Hilt, V., Camarillo, G., and J. Rosenberg, "Session-Independent 499 Session Initiation Protocol (SIP) Policies - Profile Data and 500 Mechanisms", draft-ietf-sipping-session-indep-policy-01 (work in 501 progress), October 2004. 503 [2] Hilt, V., Camarillo, G., and J. Rosenberg, "A Delivery Mechanism 504 for Session-Specific Session Initiation Protocol (SIP) Session 505 Policies", draft-ietf-sipping-session-spec-policy-03 (work in 506 progress), April 2005. 508 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 509 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 510 Session Initiation Protocol", RFC 3261, June 2002. 512 Authors' Addresses 514 Volker Hilt 515 Bell Labs/Lucent Technologies 516 101 Crawfords Corner Rd 517 Holmdel, NJ 07733 518 USA 520 Email: volkerh@bell-labs.com 522 Gonzalo Camarillo 523 Ericsson 524 Hirsalantie 11 525 Jorvas 02420 526 Finland 528 Email: Gonzalo.Camarillo@ericsson.com 530 Intellectual Property Statement 532 The IETF takes no position regarding the validity or scope of any 533 Intellectual Property Rights or other rights that might be claimed to 534 pertain to the implementation or use of the technology described in 535 this document or the extent to which any license under such rights 536 might or might not be available; nor does it represent that it has 537 made any independent effort to identify any such rights. Information 538 on the procedures with respect to rights in RFC documents can be 539 found in BCP 78 and BCP 79. 541 Copies of IPR disclosures made to the IETF Secretariat and any 542 assurances of licenses to be made available, or the result of an 543 attempt made to obtain a general license or permission for the use of 544 such proprietary rights by implementers or users of this 545 specification can be obtained from the IETF on-line IPR repository at 546 http://www.ietf.org/ipr. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary 550 rights that may cover technology that may be required to implement 551 this standard. Please address the information to the IETF at 552 ietf-ipr@ietf.org. 554 Disclaimer of Validity 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 559 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 560 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 561 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 Copyright Statement 566 Copyright (C) The Internet Society (2005). This document is subject 567 to the rights, licenses and restrictions contained in BCP 78, and 568 except as set forth therein, the authors retain all their rights. 570 Acknowledgment 572 Funding for the RFC Editor function is currently provided by the 573 Internet Society.