idnits 2.17.1 draft-ietf-sip-session-policy-framework-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1578. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 964 has weird spacing: '... where prox...' == Line 971 has weird spacing: '... where prox...' == Line 973 has weird spacing: '... rd c ...' -- 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 (April 27, 2008) is 5843 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 (-18) exists of draft-ietf-sipping-config-framework-15 == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-05 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-policy-package-04 ** Obsolete normative reference: RFC 2976 (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 7 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/Alcatel-Lucent 4 Intended status: Standards Track G. Camarillo 5 Expires: October 29, 2008 Ericsson 6 J. Rosenberg 7 Cisco 8 April 27, 2008 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sip-session-policy-framework-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 29, 2008. 38 Abstract 40 Proxy servers play a central role as an intermediary in the Session 41 Initiation Protocol (SIP) as they define and impact policies on call 42 routing, rendezvous, and other call features. This document 43 specifies a framework for SIP session policies that provides a 44 standard mechanism by which a proxy can define or influence policies 45 on sessions, such as the codecs or media types to be used. It 46 defines a model, an overall architecture and new protocol mechanisms 47 for session policies. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5 54 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5 55 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6 56 3.2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 7 58 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7 59 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 11 63 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 13 64 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 14 65 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 15 66 4.4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 16 67 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 19 68 4.4.4. Caching the Local Policy Server URI . . . . . . . . . 19 69 4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 20 70 4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 22 71 4.5.1. Creation and Management . . . . . . . . . . . . . . . 22 72 4.5.2. Contacting the Policy Server . . . . . . . . . . . . . 23 73 4.5.3. Using Session Policies . . . . . . . . . . . . . . . . 25 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 27 77 6.2. Registration of the "Policy-Contact" Header . . . . . . . 27 78 6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 27 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 83 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 29 84 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 30 85 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 32 86 B.3. Multiple Policy Servers for UAS . . . . . . . . . . . . . 33 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 88 Intellectual Property and Copyright Statements . . . . . . . . . . 35 90 1. Introduction 92 The Session Initiation Protocol (SIP) [RFC3261] is a signaling 93 protocol for creating, modifying and terminating multimedia sessions. 94 A central element in SIP is the proxy server. Proxy servers are 95 intermediaries that are responsible for request routing, rendezvous, 96 authentication and authorization, mobility, and other signaling 97 services. However, proxies are divorced from the actual sessions - 98 audio, video, and session-mode messaging - that SIP establishes. 99 Details of the sessions are carried in the payload of SIP messages, 100 and are usually described with the Session Description Protocol (SDP) 101 [RFC4566]. 103 Experience has shown that there is a need for SIP intermediaries to 104 impact aspects of a session. For example, SIP can be used in a 105 wireless network, which has limited resources for media traffic. 106 During periods of high activity, the wireless network provider may 107 want to restrict the amount of bandwidth available to each user. 108 With session policies, an intermediary in the wireless network can 109 inform the user agent about the bandwidth it has available. This 110 information enables the user agent to make an informed decision about 111 the number of streams, the media types, and the codecs it can 112 successfully use in a session. Similarly, a network provider can 113 have a service level agreement with a user that defines the set of 114 media types the user can use. With session policies, the network can 115 convey the current set of policies to user agents, enabling them to 116 set up sessions without inadvertently violating any of the network 117 policies. 119 In another example, a SIP user agent is using a network which is 120 connected to the public Internet through a firewall or a network 121 border device. The network provider would like to tell the user 122 agent that it needs to send its media streams to a specific IP 123 address and port on the firewall or border device to reach the public 124 Internet. Knowing this policy enables the user agent to set up 125 sessions across the firewall or the network border. In contrast to 126 other methods for inserting a media intermediary, the use of session 127 policies does not require the inspection or modification of SIP 128 message bodies. 130 Domains often have the need to enforce the session policies they have 131 in place. For example, a domain might have a policy that disallows 132 the use of video and can have an enforcement mechanism that drops all 133 packets containing a video encoding. Unfortunately, these 134 enforcement mechanisms usually do not inform the user about the 135 policies they are enforcing. Instead, they silently keep the user 136 from doing anything against them. This can lead to a malfunctioning 137 of devices that is incomprehensible to the user. With session 138 policies, the user knows about the current network policies and can 139 set up policy-compliant sessions or simply connect to a domain with 140 less stringent policies. Thus, session policies provide an important 141 combination of consent coupled with enforcement. That is, the user 142 becomes aware of the policy and needs to act on it, but the provider 143 still retains the right to enforce the policy. 145 Two types of session policies exist: session-specific policies and 146 session-independent policies. Session-specific policies are policies 147 that are created for one particular session, based on the session 148 description of this session. They enable a network intermediary to 149 examine the session description a UA is proposing and to return a 150 policy specifically for this session description. For example, an 151 intermediary could open pinholes in a firewall/NAT for each media 152 stream in the proposed session description. It can then return a 153 policy for the session description that replaces the IP addresses and 154 ports of the UA with the ones opened in the firewall/NAT that are 155 reachable from external. Since session-specific policies are 156 tailored to a session, they only apply to the session they are 157 created for. Session-specific policies are created on a session-by- 158 session basis at the time the session is established. 160 Session-independent policies on the other hand are policies that are 161 created independent of a session and generally apply to all SIP 162 sessions set up by a user agent. A session-independent policy can, 163 for example, be used to inform user agents about an existing 164 bandwidth limit or media type restrictions. Since these policies are 165 not based on a specific session description, they can be created 166 independent of an attempt to set up a session and only need to be 167 conveyed to the user agent when it initializes (e.g., at the time the 168 device is powered on) and when policies are changed. 170 This specification defines a framework for SIP session policies. It 171 specifies a model, the overall architecture and new protocol 172 mechanisms that are needed for session-independent and session- 173 specific policies. Since session-specific and session-independent 174 policies have different requirements, this specification defines two 175 different mechanisms to deliver them to user agents. These 176 mechanisms are independent of each other and, depending on whether 177 one or both types of session policies are needed, it is possible to 178 use the session-specific or the session-independent mechanism or both 179 to deliver policies to user agents. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 3. Session-Independent Policies 189 Session-independent policies are policies that are created 190 independent of a session and generally apply to all sessions a user 191 agent is setting up. They typically remain stable for a longer 192 period of time and apply to any session set up while they are valid. 193 However, it is possible for session-independent policies to change 194 over time. For example, a policy that defines a bandwidth limit for 195 a user can change during the day, defining a lower limit during peak 196 hours and allow more bandwidth off-peak. The policy server informs a 197 UA when session-independent policies change. 199 3.1. Architecture and Overview 201 +-------------+ 202 /------| policy | 203 +----+ / | server 1 | 204 | |---/ +-------------+ 205 | UA | ... 206 | |---\ +-------------+ 207 +----+ \ | policy | 208 \------| server n | 209 +-------------+ 211 Figure 1 213 A SIP UA can receive session-independent policies from one or more 214 policy servers. In a typical configuration, a UA receives session- 215 independent policies from a policy server in the local network domain 216 (i.e., the domain from which the UA receives IP service) and possibly 217 the SIP service provider domain (i.e., the domain the UA registers 218 at). The local network can have policies that support the access 219 network infrastructure. For example, in a wireless network where 220 bandwidth is scarce, a provider can restrict the bandwidth available 221 to an individual user. The SIP service provider can have policies 222 that are needed to support services or policies that reflect the 223 service level agreement with the user. Thus, in most cases, a UA 224 will receive session-independent policies from one or two policy 225 servers. 227 Setting up session-independent policies involves the following steps: 229 1. A user agent requests session-independent policies from the 230 policy servers in the local network and SIP service provider 231 domain. A user agent typically requests these policies when it 232 starts up or connects to a new network domain. 233 2. The policy server selects the policies that apply to this user 234 agent. The policy server can have general policies that apply to 235 all users or maintain separate policies for each individual user. 236 The selected policies are returned to the user agent. 237 3. The policy server can update the policies, for example, when 238 network conditions change. 240 3.2. Policy Subscription 242 3.2.1. UAC Behavior 244 A UA that supports session-independent policies MUST attempt to 245 retrieve session-independent policies from the local network and the 246 SIP service provider domain, unless the UA knows (e.g., through 247 configuration) that a domain does not provide session-independent 248 policies. In this case, the UA SHOULD NOT retrieve session- 249 independent policies from this specific domain. 251 A UA MUST support the retrieval of session-independent policies from 252 the local network and the SIP service provider domain using the "ua- 253 profile" event package defined in the Framework for SIP User Agent 254 Profile Delivery [I-D.ietf-sipping-config-framework]. The UA MAY 255 support other methods of retrieving session-independent policies from 256 local network and SIP service provider domain. 258 The "ua-profile" event package [I-D.ietf-sipping-config-framework] 259 provides a mechanism to subscribe to session-independent policies. A 260 UA subscribes to the policy server in the local network domain using 261 the procedures defined for the "local-network" profile-type. The UA 262 uses the procedures defined for the "user" profile type to subscribe 263 to the policy server in the SIP service provider domain. 265 A UA (re-)subscribes to session-independent policies when the 266 following events occur: 268 o The UA registers a new address-of-record (AoR) or removes a AoR 269 from the set of AoRs it has registered. In these cases, the UA 270 MUST establish subscriptions for each new AoR using the "user" and 271 the "local-network" profile-types. The UA MUST terminate all 272 subscriptions for AoRs it has removed. 273 o The UA changes the domain it is connected to. The UA MUST 274 terminate all existing subscriptions for the "local-network" 275 profile-type. The UA MUST then create a new subscription for each 276 AoR it maintains using the "local-network" profile-type. This 277 way, the UA stops receiving policies from the previous local 278 domain and starts to receive the policies of the new local domain. 279 The UA does not need to change the subscriptions for "user" 280 profiles. 282 If a subscriber is unable to establish a subscription, it SHOULD NOT 283 attempt to re-try this subscription, unless one of the above events 284 occurs again. This is to limit the number of SUBSCRIBE requests sent 285 within domains that do not support session-independent policies. 287 A UA compliant to this specification MUST support the User Agent 288 Profile Data Set for Media Policy 289 [I-D.ietf-sipping-media-policy-dataset]. To indicate that the UA 290 wants to receive session-independent policies, it includes the MIME 291 type "application/media-policy-dataset+xml" in the Accept header of a 292 SUBSCRIBE request. 294 A UA MUST apply the session-independent policies it has received and 295 use these policies in the session descriptions it creates. If the UA 296 decides not to use the received policies, then the UA MUST NOT set up 297 a session unless it changes the domain that provided these policies. 298 A UA MAY try to connect to another local network and/or SIP service 299 provider domain with a different set of policies. 301 If a UA receives both session-independent and session-specific 302 policies, the UA MUST apply the session-independent policies to the 303 session description before the session description is sent to the 304 session-specific policy server (see Section 4). Thus, session- 305 independent policies are always applied before session-specific 306 policies are retrieved. 308 3.2.2. UAS Behavior 310 A policy server MAY send a notification to the subscriber every time 311 the session-independent policies covered by the subscription change. 312 The definition of what causes a policy to change is at the discretion 313 of the administrator. A change in the policy can be triggered, for 314 example, by a change in the network status, by the change in the time 315 of day or by an update of the service level agreement with the 316 customer. 318 4. Session-Specific Policies 320 Session-specific policies are policies that are created specifically 321 for one particular session of a UA. Thus, session-specific policies 322 will typically be different for different sessions. The session- 323 specific policies for a session can change during the course of the 324 session. For example, a user can run out of credit during a session, 325 which will cause the network to disallow the transmission all media 326 streams from this point on. 328 4.1. Architecture 330 domain 1 331 +-----------+ 332 /------| proxy |----... 333 +----+ / +-----------+ 334 | |---/ +-----------+ 335 | | | policy | 336 | UA |============| server | 337 | | +-----------+ 338 | |**** +-----------+ 339 +----+ * | policy | 340 *******|enforcement|****... 341 +-----------+ 343 --- SIP Signaling 344 === Policy Channel 345 *** Media 347 Figure 2 349 The following entities are needed for session-specific policies (see 350 Figure 2): a user agent (UA), a proxy, a policy server and possibly a 351 policy enforcement entity. 353 The role of the proxy is to provide a rendezvous mechanism for UAs 354 and policy servers. It ensures that each UA has the URI of the 355 policy server in its domain and knows where to retrieve policies 356 from. The proxy conveys the policy server URI to UAs in case they 357 have not yet received it (e.g., in a previous call or through 358 configuration). The proxy does not deliver the actual policies to 359 UAs. 361 The policy server is a separate logical entity that can be physically 362 co-located with the proxy. The role of the policy server is to 363 deliver session policies to UAs. The policy server receives session 364 information from the UA, uses this information to determine the 365 policies that apply to the session and returns these policies to the 366 UA. The mechanism for generating policies (i.e., making policy 367 decisions) is outside of the scope of this specification. A policy 368 server can, for example, query an external entity to get policies or 369 it can directly incorporate a policy decision point and generate 370 policies locally. 372 A UA receives the URI of a policy server from a proxy. It uses this 373 URI to contact the policy server. It provides information about the 374 current session to the policy server and receives session policies in 375 response. The UA can also receive policy updates from the policy 376 server during the course of a session. 378 A network can have a policy enforcement infrastructure in place. 379 However, this specification does not make any assumptions about the 380 enforcement of session policies and the mechanisms defined here are 381 orthogonal to a policy enforcement infrastructure. 383 In principle, each domain that is traversed by SIP signaling messages 384 can define session-specific policies for a session. Each domain 385 needs to run a policy server and a proxy that is able to rendezvous a 386 UA with the policy server (as shown in Figure 2). However, it is 387 expected that session-specific policies will often only be provided 388 by the local domain of the user agent. 390 4.2. Overview 392 The protocol defined in this specification clearly separates SIP 393 signaling and the exchange of policies. SIP signaling is only used 394 to rendezvous the UA with the policy server. From this point on, UA 395 and policy server communicate directly with each other over a 396 separate policy channel. This is opposed to a piggyback model, where 397 the exchange of policy information between endpoint and a policy 398 server in the network is piggybacked onto the SIP signaling messages 399 that are exchanged between endpoints. 401 The main advantage of using a separate policy channel is that it 402 decouples signaling between endpoints from the policy exchange 403 between an endpoint and a policy server. This decoupling has a 404 number of desirable properties. It enables the use of separate 405 encryption mechanisms on the signaling path to secure the 406 communication between endpoints, and on the policy channel to secure 407 the communication between endpoint and policy server. Policies can 408 be submitted directly from the policy server to the endpoint and do 409 not travel along the signaling path, possibly crossing many domains. 410 Endpoints set up a separate policy channel to each policy server and 411 can disclose the information requested by the specific policy server 412 (e.g., offer or offer/answer). Finally, policy servers do not need 413 to rely on a SIP signaling message flowing by to send policies or 414 policy updates to an endpoint. A policy server can use the policy 415 channel at any time to update session policies as needed. A 416 disadvantage of the separate channel model is that it requires 417 additional messages for the exchange of policy information. 419 Following this model, signaling for session-specific policies 420 involves the following two fundamental tasks: 422 1. UA/policy server rendezvous: a UA setting up a session needs to 423 be able to discover the policy servers that are relevant to this 424 session. 425 2. Policy channel: once the UA has discovered the relevant policy 426 servers for a session, it needs to connect to these servers, 427 disclose session information and retrieve the policies that apply 428 to this session. 430 The communication between UA and policy server on the policy channel 431 involves the following steps: 433 1. A user agent submits information about the session it is trying 434 to establish to the policy server and asks whether a session 435 using these parameters is permissible. 436 2. The policy server generates a policy decision for this session 437 and returns the decision to the user agent. Possible policy 438 decisions are (1) to deny the session, (2) to propose changes to 439 the session parameters with which the session would be 440 acceptable, or (3) to accept the session as it was proposed. 441 3. The policy server can update the policy decision at a later time. 442 A policy decision update can, for example, propose additional 443 changes to the session (e.g., change the available bandwidth) or 444 deny a previously accepted session (i.e., disallow the 445 continuation of a session). 447 In many cases, the mechanism for session-specific policies will be 448 used to disclose session information and return session policies. 449 However, some scenarios only involve the disclosure of session 450 information to a network intermediary. If an intermediary does not 451 intend to return a policy, it can simply accept the session as it was 452 proposed. Similarly, some session-specific policies only apply to 453 the offer (and therefore only require the disclosure of the offer) 454 whereas others apply to offer and answer. Both types of policies are 455 supported by session-specific policy mechanism. 457 4.3. Examples 459 This section provides two examples to illustrate the overall 460 operation of session-specific policies. The call flows depict the 461 rendezvous mechanism between UA and policy server and indicate the 462 points at which the UA exchanges policy information with the policy 463 server. 465 The example is based on the following scenario: there are two domains 466 (domain A and domain B), which both have session-specific policies 467 for the UAs in their domain. Both domains do not provide policies to 468 the UAs outside of their domain. The two domains have a proxy (P A 469 and P B) and a policy server (PS A and PS B). The policies in both 470 domains involve the session description offer and answer. 472 4.3.1. Offer in Request 474 The first call flow shown in Figure 3 depicts an INVITE transaction 475 with the offer in the request. It is assumed that this is the first 476 INVITE request the UAC creates in this domain and that it therefore 477 does not have previous knowledge about the policy server URIs in this 478 domain. 480 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply 481 to this session and (2) returns a 488 (Not Acceptable Here) to UA A. 482 P A includes the URI of PS A in the 488 (Not Acceptable Here) 483 response. This step is needed since the UAC has no prior knowledge 484 about the URI of PS A. (3) UA A uses the URI to contact PS A, 485 discloses the session description offer to PS A and (4) receives 486 policies for the offer. (5) UA A reformulates the INVITE request 487 under consideration of the received policies and includes a Policy-Id 488 header to indicate that it has already contacted PS A. P A does not 489 reject the INVITE this time and removes the Policy-Id header when 490 forwarding the INVITE. P B adds a Policy-Contact header containing 491 the URI of PS B. (6) UA B uses this URI to contact PS B and discloses 492 the offer and the answer it is about to send. (7) UA B receives 493 policies from PS B and applies them to the offer and answer 494 respectively. (8) UA B returns the updated answer in the 200 OK. (9) 495 UA A contacts PS A with the answer and (10) retrieves answer policies 496 from PS A. 498 UA A P A P B UA B 499 | | | | 500 | INVITE offer | | | 501 |---------------->| | | (1) 502 | 488 | | | 503 | + Policy-Contact| | | 504 |<----------------| | | (2) 505 | ACK | | | 506 |---------------->| | | 507 | | PS A | | 508 | | | | 509 | PolicyChannel | | | 510 | + InfoOffer | | | 511 |------------------->| | | (3) 512 | PolicyChannel | | | 513 | + PolicyOffer | | | 514 |<-------------------| | | (4) 515 | | | | 516 | | | | 517 | INVITE offer' | INVITE offer' | INVITE offer | 518 | + Policy-Id | | + Policy-Contact| 519 |---------------->|--------------->|---------------->| (5) 520 | | | | 521 | | PS B | | 522 | | | | 523 | | | PolicyChannel | 524 | | | + InfoOffer | 525 | | | + InfoAnswer | 526 | | |<-------------------| (6) 527 | | | PolicyChannel | 528 | | | + PolicyOffer | 529 | | | + PolicyAnswer | 530 | | |------------------->| (7) 531 | | | | 532 | | | | 533 | OK answer | OK answer | OK answer | 534 |<----------------|<---------------|<----------------| (8) 535 | ACK | 536 |--------------------------------------------------->| 537 | | | | 538 | | | | 539 | PolicyChannel | | | 540 | + InfoAnswer | | | 541 |------------------->| | | (9) 542 | PolicyChannel | | | 543 | + PolicyAnswer | | | 544 |<-------------------| | | (10) 545 | | | | 546 Figure 3 548 4.3.2. Offer in Response 550 The call flow shown in Figure 4 depicts an INVITE transaction with 551 the offer in the response. 553 (1) UA A sends an INVITE without an offer to proxy P A and (2) P A 554 returns a 488 (Not Acceptable Here) response containing the URI of PS 555 A. (3),(4) UA A uses this policy server URI to set up the policy 556 channel. At this time, UA A does not disclose a session description 557 since it does not have the offer yet. (5) UA A re-sends the INVITE 558 request and includes a Policy-Id header to indicate that it has 559 contacted PS A. P A does not reject the INVITE this time and removes 560 the Policy-Id header when forwarding the INVITE. P B adds a Policy- 561 Contact header containing the URI of PS B. (6) UA B uses this URI to 562 discloses the offer to PS B. (7) UA B receives policies from PS B and 563 applies them to the offer. (8) UA B returns the updated offer the 200 564 OK. (9),(10) UA A contacts PS and discloses the offer and the answer 565 it is about to send. An important difference to the flow in the 566 previous example is that UA A performs steps (9) and (10) before 567 returning the answer in step (11). This enables UA A to return the 568 final answer in the ACK, which includes all applicable policies. 569 However, it requires that PS A immediately returns a policy to avoid 570 a delay in the transmission of the ACK. (12),(13) UA B also sends the 571 answer to PS B and applies the policies it receives to the answer 572 before using it. 574 UA A P A P B UA B 575 | | | | 576 | INVITE | | | 577 |---------------->| | | (1) 578 | 488 | | | 579 | + Policy-Contact| | | 580 |<----------------| | | (2) 581 | ACK | | | 582 |---------------->| | | 583 | | PS A | | 584 | | | | 585 | PolicyChannel | | | 586 |------------------->| | | (3) 587 | PolicyChannel | | | 588 |<-------------------| | | (4) 589 | | | | 590 | | | | 591 | INVITE | INVITE | INVITE | 592 | + Policy-Id | | + Policy-Contact| 593 |---------------->|--------------->|---------------->| (5) 594 | | | | 595 | | PS B | | 596 | | | | 597 | | | PolicyChannel | 598 | | | + InfoOffer | 599 | | |<-------------------| (6) 600 | | | PolicyChannel | 601 | | | + PolicyOffer | 602 | | |------------------->| (7) 603 | | | | 604 | | | | 605 | OK offer | OK offer | OK offer | 606 |<----------------|<---------------|<----------------| (8) 607 | | | | 608 | | | | 609 | PolicyChannel | | | 610 | + InfoOffer | | | 611 | + InfoAnswer | | | 612 |------------------->| | | (9) 613 | PolicyChannel | | | 614 | + PolicyOffer | | | 615 | + PolicyAnswer | | | 616 |<-------------------| | | (10) 617 | | | | 618 | ACK answer | 619 |--------------------------------------------------->| (11) 620 | | | | 621 | | | | 622 | | | PolicyChannel | 623 | | | + InfoAnswer | 624 | | |<-------------------| (12) 625 | | | PolicyChannel | 626 | | | + PolicyAnswer | 627 | | |------------------->| (13) 628 | | | | 630 Figure 4 632 4.4. UA/Policy Server Rendezvous 634 The first step in setting up session-specific policies is to 635 rendezvous the UAs with the relevant policy servers. This is 636 achieved by providing the URIs of all policy servers relevant for a 637 session to the UAs. 639 4.4.1. UAC Behavior 641 A UAC compliant to this specification MUST include a Supported header 642 field with the option tag "policy" into all requests that can 643 initiate an offer/answer exchange [RFC3264] (e.g., INVITE, UPDATE and 644 PRACK requests). The UA MUST include the "policy" option tag into 645 these requests even if the particular request does not contain an 646 offer or answer (e.g., an INVITE request without an offer). A UA MAY 647 include the "policy" option tag into all requests. 649 A UAC can receive a 488 (Not Acceptable Here) response that contains 650 a Policy-Contact header field. The Policy-Contact header is a new 651 header defined in this specification. It contains the URI of a 652 policy server. A 488 (Not Acceptable Here) response with this header 653 is generated by a proxy to convey the URI of the local policy server 654 to the UAC. After receiving a 488 (Not Acceptable Here) response 655 with a Policy-Contact header, a UAC compliant to this specification 656 needs to decide if it wants to continue with the session now knowing 657 that there is a policy server. If the UAC decides to continue, it 658 MUST use the policy server URI to contact the policy server using the 659 mechanism defined in Section 4.5. After receiving policies from the 660 policy server, the UAC decides if it wants to accept these policies 661 or not. If the UAC accepts these policies, the UAC MUST apply them 662 to the current request and resend the updated request. If no changes 663 are required by policies or no policies have been received, the 664 request can be resent without any policy-induced changes. If the UAC 665 decides that the list of policy servers or the received session 666 policies are unacceptable, then the UAC MUST NOT resend the request. 668 The UAC MAY resent the unchanged request if it cannot setup a policy 669 channel to the policy server, for example, because the policy server 670 is unreachable or returns an error condition that cannot be resolved 671 by the UAC (i.e., error conditions other than, for example, a 401 672 (Unauthorized) responses). This is to avoid that the failure of a 673 policy server prevents a UA from communicating. 675 To protect the integrity of the policy server URI in a Policy-Contact 676 header, the UAC SHOULD use a secured transport protocol such as TLS 677 between UAC and proxy. 679 The UAC MUST insert a Policy-Id header into requests for which it has 680 contacted a policy server and accepted the policies received. The 681 Policy-Id header is a new header that is defined in this 682 specification. The UA MUST create a Policy-Id header value for each 683 policy server it has contacted during the preparation of the request. 684 A Policy-Id header value contains two pieces of information: the 685 policy server URI and an optional token. The policy server URI is 686 the URI the UA has used to contact the policy server. The token is 687 an opaque string the UAC can receive from the policy server. A token 688 can, for example, be contained in the policy document 689 [I-D.ietf-sipping-media-policy-dataset]. If the UAC has received a 690 token from the policy server the UAC MUST include the token in the 691 Policy-Id header. The format of the Policy-Id header is defined in 692 Section 4.4.5. 694 The main purpose of the Policy-Id header is to enable a proxy to 695 determine if the UAC already knows the URI of the local policy 696 server. If the policy server URI is not yet known to the UAC, the 697 proxy can convey this URI to the UAC by rejecting the request with a 698 488 (Not Acceptable Here) response. 700 In some cases, a request can traverse multiple domains with a 701 session-policy server. Each of these domains can return a 488 (Not 702 Acceptable Here) response containing a policy server URI. Since the 703 UAC contacts a policy server after receiving a 488 (Not Acceptable 704 Here) response from a domain and before re-sending the request, 705 session policies are always applied to a request in the order in 706 which the request traverses through the domains. The UAC MUST NOT 707 change this implicit order among policy servers. 709 A UAC frequently needs to contact the policy server in the local 710 domain before setting up a session. To avoid the retransmission of 711 the local policy server URI in a 488 (Not Acceptable Here) for each 712 new request, a UA SHOULD maintain a cache that contains the URI of 713 the local policy server (see Section 4.4.4). The UAC SHOULD use the 714 cached policy server URI to contact the local policy server before 715 sending a request that initiates the offer/answer exchange for a new 716 session (e.g., an INVITE request). 718 UAs can re-negotiate the session description during a session by 719 initiating a subsequent offer/answer exchange, e.g., in an INVITE, 720 UPDATE or PRACK request. When creating such a mid-dialog request, a 721 UA SHOULD contact all policy servers to which it has established a 722 policy channel during the initial offer/answer exchange (see 723 Section 4.5) before sending the request. This avoids the 724 retransmission of all policy server URIs in 488 (Not Acceptable Here) 725 responses for mid-dialog requests. 727 4.4.2. Proxy Behavior 729 A proxy provides rendezvous functionalities for UAs and policy 730 server. This is achieved by conveying the URI of a policy server to 731 the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK 732 requests (or any other request that can initiate an offer/answer 733 exchange). 735 If an offer/answer exchange initiating request contains a Supported 736 header field with the option tag "policy", the proxy MAY reject the 737 request with a 488 (Not Acceptable Here) response to provide the 738 local policy server URI to the UAC. Before rejecting a request, the 739 proxy MUST verify that the request does not contain a Policy-Id 740 header field with the local policy server URI as a value. If the 741 request does not contain such a header or the local policy server URI 742 is not present in this header, then the proxy MAY reject the request 743 with a 488 (Not Acceptable Here). The proxy MUST insert a Policy- 744 Contact header in the 488 (Not Acceptable Here) response that 745 contains the URI of its associated policy server. The proxy MAY add 746 the header field parameter "non-cacheable" to prevent the UAC from 747 caching this policy server URI (see Section 4.4.4). 749 If the local policy server URI is present in a Policy-Id header value 750 of a request, then the proxy MUST NOT reject the request as described 751 above (it can still reject the request for other reasons). The proxy 752 SHOULD remove the Policy-Id header value of its associated policy 753 server from the Policy-Id header field before forwarding the request. 754 This value only increases message size and is not relevant to other 755 proxies on the path. It also would disclose the policy server URI to 756 subsequent proxies. 758 The Policy-Id header serves two main purposes: first and most 759 importantly, it enables the proxy to determine if a UAC already knows 760 the URI of the local policy server. The second purpose of the 761 Policy-Id header is to enable a domain to route all requests that 762 belong to the same session (i.e., the initial request and requests a 763 UA retransmits after contacting the policy server) to the same proxy 764 and policy server. This is important if a domain has multiple proxy/ 765 policy server combinations (e.g., in a proxy/policy server farm that 766 receives requests through a load balancer), which create per-session 767 state in the network. An example for such a scenario is a policy 768 server that is associated with a session border device. The policy 769 server configures the session border device after receiving a session 770 description from the UAC via the policy channel. Retransmitted 771 requests for such a session need to be routed to the same proxy/ 772 policy server as the initial request since this proxy/policy server 773 combination has configured the associated border device for the 774 session. 776 Routing all requests that belong to the same session to the same 777 proxy can be achieved by using the Policy-Id header token. It 778 requires that the policy server returns a token to the UAC that 779 uniquely identifies the specific proxy/policy server combination. 780 The UAC includes this token in the Policy-Id header and it can be 781 used (together with the policy server URI) by the proxies in this 782 domain to route the request along the desired path. The format of 783 this token does not require standardization. The only requirement is 784 that the token provides sufficient information for proxies to route 785 the message inside a domain to the desired proxy/policy server. The 786 token can, for example, be a numeric identifier or an IP address. 788 Note: it has been proposed to use the Policy-Id header to provide 789 a hint for a proxy that the UAC has actually contacted the policy 790 server. This usage also requires the policy server to return a 791 token to the UA. In addition, the policy server needs to share 792 valid tokens with the proxy. After receiving a request with a 793 Policy-Id header, the proxy can determine if the token in the 794 Policy-Id header is valid. If it is valid, the proxy knows that 795 the UA has contacted the policy server for this session. However, 796 this token does not provide any proof that the UA has actually 797 used the policies it has received from the policy server. A 798 malicious UA can simply contact the policy server, discard all 799 policies it receives but still use the token in the Policy-Id 800 header. 802 The proxy MAY insert a Policy-Contact header field into INVITE, 803 UPDATE or PRACK requests (or any other request that can initiate an 804 offer/answer exchange) in order to convey the policy server URI to 805 the UAS. If the request already contains a Policy-Contact header 806 field, the proxy MUST insert the URI after all existing values at the 807 end of the list. A proxy MUST NOT change the order of existing 808 Policy-Contact header values. 810 A proxy MUST use the Record-Route header mechanism [RFC3261] if its 811 associated policy server has session policies that apply to mid- 812 dialog requests. The Record-Route header enables a proxy to stay in 813 the signaling path and re-submit the policy server URIs to UAs during 814 mid-dialog requests that initiate an offer/answer exchange. Re- 815 submitting the policy server URI to UAs ensures that UAs keep 816 contacting the policy server for mid-dialog requests. 818 A proxy can find out if the UAS supports this extension by examining 819 the Supported header of responses. The proxy knows that the UAS 820 supports this extension if the Supported header of a response 821 contains the option tag "policy". A proxy can use this information 822 to determine if the UAS has understood the Policy-Contact header it 823 has inserted into the request. 825 To protect the integrity of the policy server URI in a Policy-Contact 826 header, the proxy SHOULD use a secured transport protocol such as TLS 827 between proxy and UAs. 829 4.4.3. UAS Behavior 831 A UAS can receive an INVITE, UPDATE or PRACK request (or another 832 request that can initiate offer/answer exchanges) that contains a 833 Policy-Contact header field with a list of policy server URIs. A UAS 834 that receives such a request needs to decide if it wants to accept 835 the session knowing that there are policy servers involved. If it 836 accepts, the UAS MUST contact all policy server URIs in a Policy- 837 Contact header. The UAS MUST contact the policy server URIs in the 838 order in which they were contained in the Policy-Contact header, 839 starting with the topmost value (i.e., the value that was inserted 840 first). 842 If a UAS decides that it does not want to accept a session because 843 there are policy servers involved or because one of the session 844 policies received from a policy server is not acceptable, the UAS 845 MUST reject the request with a 488 (Not Acceptable Here) response. 847 The UAS MAY accept a request and continue with setting up a session 848 if it cannot setup a policy channel to the policy server, for 849 example, because the policy server is unreachable or returns an error 850 condition that cannot be resolved by the UAS (i.e., error conditions 851 other than, for example, a 401 (Unauthorized) responses). This is to 852 avoid that the failure of a policy server prevents a UA from 853 communicating. Since this session may not be policy compliant 854 without the policy subscription, it may be blocked by policy 855 enforcement mechanisms if they are in place. 857 A UAS can receive a token from a policy server via the policy 858 channel. Since the UAS does not create a Policy-ID header, it can 859 simply ignore this token. 861 A UAS compliant to this specification MUST include a Supported header 862 field with the option tag "policy" into responses to requests that 863 can initiate an offer/answer exchange. It MAY include this option 864 tag in all responses. This way, a proxy that has inserted the 865 Policy-Contact header can know that the header was understood by the 866 UAS. 868 4.4.4. Caching the Local Policy Server URI 870 A UAC frequently needs to contact the policy server in the local 871 domain before setting up a session. To avoid the retransmission of 872 the local policy server URI for each session, a UA SHOULD maintain a 873 cache that contains the URI of the local policy server. 875 A UA can receive this URI in a Policy-Contact header of a request or 876 a 488 (Not Acceptable Here) response. The UA can also receive the 877 local policy server URI through configuration, for example, via the 878 configuration framework [I-D.ietf-sipping-config-framework]. If a UA 879 has received a local policy server URI through configuration and 880 receives another local policy server URI in a Policy-Contact header, 881 the UA SHOULD overwrite the configured URI with the most recent one 882 received in a Policy-Contact header. 884 Domains can prevent a UA from caching the local policy server URI. 885 This is useful, for example, if the policy server does not need to be 886 involved in all sessions or the policy server URI changes from 887 session to session. A proxy can mark the URI of such a policy server 888 as "non-cacheable". A UA MUST NOT cache a non-cacheable policy 889 server URI. The UA SHOULD remove the current URI from the cache when 890 receiving a local policy server URI that is marked as "non- 891 cacheable". This is to avoid the use of policy server URIs that are 892 outdated. 894 The UA SHOULD NOT cache policy server URIs it has received from 895 proxies outside of the local domain. These policy servers need not 896 be relevant for subsequent sessions, which can go to a different 897 destination, traversing different domains. 899 The UA MUST NOT cache tokens it has received from a policy server. A 900 token is only valid for one request. 902 4.4.5. Header Definition and Syntax 904 4.4.5.1. Policy-Id Header 906 The Policy-Id header field is inserted by the UAC into INVITE, UPDATE 907 or PRACK requests (or any other request that can be used to initiate 908 an offer/answer exchange). The Policy-Id header identifies all 909 policy servers the UAC has contacted for this request. 911 The value of a Policy-Id header consists of a policy server URI and 912 an optional token parameter. The token parameter contains a token 913 the UA may have received from the policy server. 915 The syntax of the Policy-Id header field is: 917 Policy-Id = "Policy-Id" HCOLON policyURI 918 *(COMMA policyURI) 919 policyURI = ( SIP-URI / SIPS-URI / absoluteURI ) 920 [ SEMI token-param ] *( SEMI generic-param ) 921 token-param = "token=" token 923 The BNF for SIP-URI, SIPS-URI, absoluteURI, token and generic-param 924 is defined in RFC3261 [RFC3261]. 926 4.4.5.2. Policy-Contact Header 928 The Policy-Contact header field can be inserted by a proxy into a 488 929 (Not Acceptable Here) response to INVITE, UPDATE or PRACK requests 930 (or other requests that initiate an offer/answer exchange). The 931 value of a Policy-Contact header consists of a policy server URI and 932 an optional "non-cacheable" parameter. The policy server URI 933 identifies the policy server that needs to be contacted by a UAC. 934 The "non-cacheable" parameter indicates that the policy server URI 935 should not be cached by the UAC. 937 The Policy-Contact header field can also be inserted by a proxy into 938 INVITE, UPDATE and PRACK requests (or other requests that can be used 939 to initiate an offer/answer exchange). It contains an ordered list 940 of policy server URIs that need to be contacted by the UAS. The 941 topmost value of this list identifies the policy server that is 942 contacted first. New header field values are inserted at the end. 943 With this, the Policy-Contact header field effectively forms a fist- 944 in-first-out queue. 946 The syntax of the Policy-Contact header field is: 948 Policy-Contact = "Policy-Contact" HCOLON policyContactURI 949 *(COMMA policyContactURI) 950 policyContactURI = ( SIP-URI / SIPS-URI / absoluteURI ) 951 [ SEMI "non-cacheable" ] *( SEMI generic-param ) 953 The BNF for SIP-URI, SIPS-URI, absoluteURI and generic-param is 954 defined in RFC3261 [RFC3261]. 956 Tables 1 and 2 are extensions of Tables 2 and 3 in RFC 3261 957 [RFC3261]. The column "INF" is for the INFO method [RFC2976], "PRA" 958 is for the PRACK method [RFC3262], "UPD" is for the UPDATE method 959 [RFC3311], "SUB" is for the SUBSCRIBE method [RFC3265], "NOT" is for 960 the NOTIFY method [RFC3265], "MSG" is for the MESSAGE method 961 [RFC3428], "REF" is for the REFER method [RFC3515], and "PUB" is for 962 the PUBLISH method [RFC3903]. 964 Header field where proxy ACK BYE CAN INV OPT REG UPD 965 _______________________________________________________________ 966 Policy-Id R rd - - - c - - c 967 Policy-Contact R a - - - c - - c 968 Policy-Contact 488 a - - - c - - c 969 Table 1: Policy-Id and Policy-Contact Header Fields 971 Header field where proxy PRA PUB SUB NOT INF MSG REF 972 _______________________________________________________________ 973 Policy-Id R rd c - - - - - - 974 Policy-Contact R a c - - - - - - 975 Policy-Contact 488 a c - - - - - - 976 Table 1: Policy-Id and Policy-Contact Header Fields 978 4.5. Policy Channel 980 The main task of the policy channel is to enable a UA to submit 981 information about the session it is trying to establish (i.e., the 982 offer and the answer) to a policy server and to receive the resulting 983 session-specific policies and possible updates to these policies in 984 response. 986 The Event Package for Session-Specific Session Policies 987 [I-D.ietf-sipping-policy-package] defines a SUBSCRIBE/NOTIFY-based 988 policy channel mechanism. A UA compliant to this specification MUST 989 support the Event Package for Session-Specific Session Policies 990 [I-D.ietf-sipping-policy-package]. This event package MUST be used 991 to contact a policy server if the policy server URI is a SIP-URI or 992 SIPS-URI. A UA MAY support other policy channel mechanisms. 994 4.5.1. Creation and Management 996 A UA discovers the list of policy servers relevant for a session 997 during the initial offer/answer exchange (see Section 4.4). A UA 998 compliant to this specification MUST set up a policy channel to each 999 of the discovered policy server. If the UA does not want to set up a 1000 policy channel to one of the policy servers provided, the UA MUST NOT 1001 continue with the session. This means that, the UA MUST cancel or 1002 reject a pending INVITE transaction for the session or terminate the 1003 session if it is already in progress. 1005 If setting up a policy channel to one of the discovered policy 1006 servers fails, the UA MAY continue with the initiation of a session 1007 without contacting this policy server. Setting up a policy channel 1008 can fail, for example, because the server is unreachable or returns 1009 an error condition that cannot be resolved by the UAC (i.e., error 1010 conditions other than, for example, a 401 (Unauthorized) responses). 1011 The UA SHOULD continue an ongoing session if a policy server fails 1012 after the session has been set up. The UA SHOULD consider the 1013 policies it has previously received from the failed policy server. 1014 This is to avoid that the failure of a policy server prevents a UA 1015 from communicating. 1017 A UA MUST maintain the policy channel to each discovered policy 1018 server during the lifetime of a session, unless the policy channel is 1019 closed by the policy server or the UA discovers that the policy 1020 server is no longer relevant for the session as described below. 1022 A UAC can receive a 488 (Not Acceptable Here) with a Policy-Contact 1023 header containing a new policy server URI in response to a mid-dialog 1024 request. This indicates that the set of policy servers relevant for 1025 the current session has changed. If this occurs, the UAC MUST retry 1026 sending the request as if it was the first request in a dialog (i.e., 1027 without applying any policies except the policies from the local 1028 policy server). This way, the UAC will re-discover the list of 1029 policy servers for the current session. The UAC should compare the 1030 new list with the list of policy servers to which it currently has 1031 established a policy channel. The UAC MUST set up a policy channel 1032 to each new policy server. The UAC SHOULD close policy channels to 1033 policy server that are not listed any more. The UAC MUST contact 1034 policy servers in the order in which they were discovered in the most 1035 recent request. 1037 If a UAS receives a mid-dialog request with a Policy-Contact header 1038 containing a list of policy server URIs that is different from the 1039 list of policy servers to which the UAS has currently established a 1040 policy channel, then the UAS MUST set up a policy channel to all new 1041 policy servers and contact them. The UAS SHOULD close policy 1042 channels to servers that are not listed any more. The UAS MUST use 1043 policy servers in the order in which they were contained in the most 1044 recent Policy-Contact header. 1046 A UA MUST inform the policy server when a session is terminated via 1047 the policy channel, unless a policy server indicates via the policy 1048 channel that it does not need to be contacted at the end of the 1049 session. This enables a policy server to free all resources it has 1050 allocated for this session. 1052 4.5.2. Contacting the Policy Server 1054 A UA MUST contact all policy servers to which it has established a 1055 policy channel before sending or after receiving a mid-dialog 1056 request. The UA MUST contact the policy server in the order in which 1057 they were discovered most recently. 1059 A UA that receives a SIP message containing an offer or answer SHOULD 1060 completely process the message (e.g., according to RFC3261 [RFC3261]) 1061 before contacting the policy server. The SIP processing of the 1062 message includes, for example, updating dialog state and timers as 1063 well as creating ACK or PRACK requests as necessary. This ensures 1064 that contacting a policy server does not interfere with SIP message 1065 processing and timing (e.g., by inadvertently causing timers to 1066 expire). This implies, for example, that a UAC which has received a 1067 response to an INVITE request SHOULD finish the processing of the 1068 response including transmitting the ACK before it contacts the policy 1069 server. An important exception to this rule is discussed in the next 1070 paragraph. 1072 In some cases, a UA needs to use the offer/answer it has received in 1073 a SIP message to create an ACK or PRACK response for this message, 1074 i.e., it needs to use the offer/answer before finishing the SIP 1075 machinery for this message. For example, a UAC that has received an 1076 offer in the response to an INVITE request needs to apply policies to 1077 the offer and the answer before it can send the answer in an ACK. In 1078 these cases, a UA SHOULD contact the policy server even if this is 1079 during the processing of a SIP message. This implies that a UA, 1080 which has received an offer in the response of an INVITE request, 1081 SHOULD contact the policy server and apply session policies before 1082 sending the answer in the ACK. 1084 Note: this assumes that the policy server can always respond 1085 immediately to a policy request and does not require manual 1086 intervention to create a policy. This will be the case for most 1087 policy servers. If, however, a policy server cannot respond with 1088 a policy right away, it can return a policy that temporarily 1089 denies the session and update this policy as the actual policy 1090 decision becomes available. A delay in the response from the 1091 policy server to the UA would delay the transmission of the ACK 1092 and could trigger retransmissions of the INVITE response (also see 1093 the recommendations for Flow I in RFC3725 [RFC3725]). 1095 The case of multiple policy servers providing policies to the same UA 1096 requires additional considerations. A policy returned by one policy 1097 server can contain information that needs to be shared with the other 1098 policy servers. For example, two policy servers may have the policy 1099 to insert a media intermediary by modifying the IP addresses and 1100 ports of media streams. In order for media streams to pass through 1101 both intermediaries, each intermediary needs to know the IP address 1102 and port on which the other media intermediary is expecting the 1103 stream to arrive. If media streams are flowing in both directions, 1104 this means that each intermediary needs to know IP addresses and 1105 ports of the other intermediary. 1107 UAs usually contact a policy server twice during an offer/answer 1108 exchange (unless a policy server indicates that it only needs to be 1109 contacted once). Therefore the case of multiple policy servers 1110 providing policies to a single UA does not require additional steps 1111 in most cases. However, a UAS usually contacts each policy server 1112 only once (see Figure 4). If a session policy returned by one of the 1113 policy servers requires that information is shared between multiple 1114 servers and the UAS receives policies from more than one policy 1115 server, the UAS MUST contact all policy servers a second time after 1116 contacting all servers the first time. Whether or not this second 1117 round is required is determined by the type of information returned 1118 by the policy server. The data format for session policies must 1119 explicitly state if a second round is needed for a particular data 1120 element. If a UAS supports this data format and receives such an 1121 element, it knows that it must contact policy servers a second time. 1122 If such a data element is modified during a mid-call offer/answer 1123 exchange and multiple policy servers are providing policies to a UA 1124 then all UAs MUST contact policy servers in a first and second round. 1125 An example call flow for the UAS is shown in Appendix B.3. 1127 4.5.3. Using Session Policies 1129 A UA MUST disclose the session description(s) for the current session 1130 to policy servers through the policy channel. The UA MUST apply 1131 session policies it receives to the offer and, if one is received, to 1132 the answer before using the offer/answer. If these policies are 1133 unacceptable, the UA MUST NOT continue with the session. This means 1134 that, the UA MUST cancel or reject a pending INVITE transaction for 1135 the session or terminate the session if it is already in progress. 1136 If the UA receives an unacceptable policy in an INVITE response, the 1137 UA MUST complete the INVITE transaction and then terminate the 1138 session. 1140 When a UA receives a notification about a change in the current 1141 policies, the UA MUST apply the updated policies to the current 1142 session or the UA MUST terminate the session. If the policy update 1143 causes a change in the session description of a session, then the UA 1144 needs to re-negotiate the modified session description with its peer 1145 UA, for example, using a re-INVITE or UPDATE request. For example, 1146 if a policy update disallows the use of video and video is part of 1147 the current session description, then the UA will need to create an 1148 new session description offer without video. After receiving this 1149 offer, the peer UA knows that video can't be used any more and 1150 responds with the corresponding answer. 1152 5. Security Considerations 1154 Session policies can significantly change the behavior of a user 1155 agent and can be used by an attacker to compromise a user agent. For 1156 example, session policies can be used to prevent a user agent from 1157 successfully establishing a session (e.g., by setting the available 1158 bandwidth to zero). Such a policy can be submitted to the user agent 1159 during a session, which causes the UA to terminate the session. 1161 A user agent transmits session information to a policy server for 1162 session-specific policies. This session information can contain 1163 sensitive data the user does not want an eavesdropper or an 1164 unauthorized policy server to see. Vice versa, session policies can 1165 contain sensitive information about the network or service level 1166 agreements the service provider does not want to disclose to an 1167 eavesdropper or an unauthorized user agent. 1169 It is important to secure the communication between the proxy and the 1170 user agent (for session-specific policies) as well as the user agent 1171 and the policy server. The following four discrete attributes need 1172 to be protected: 1174 1. integrity of the policy server URI (for session-specific 1175 policies), 1176 2. authentication of the policy server and, if needed, the user 1177 agent, 1178 3. confidentiality of the messages exchanged between the user agent 1179 and the policy server and 1180 4. ensuring that private information is not exchanged between the 1181 two parties, even over an confidentiality-assured and 1182 authenticated session. 1184 To protect the integrity of the policy server URI, a UA SHOULD use a 1185 secured transport protocol such as TLS between proxies and the UA. 1186 Protecting the integrity of the policy server URI is important since 1187 an attacker could intercept SIP messages between the UA and the proxy 1188 and remove the policy headers needed for session-specific policies. 1189 This would impede the rendezvous between UA and policy server and, 1190 since the UA would not contact the policy server, can prevent a UA 1191 from setting up a session. 1193 Instead of removing a policy server URI, an attacker can also modify 1194 the policy server URI and point the UA to a compromised policy 1195 server. To prevent such an attack from being effective, it is 1196 RECOMMENDED that a UA authenticates policy servers. 1198 Policy servers SHOULD authenticate UAs to protect the information 1199 that is contained in a session policy. However, a policy server can 1200 also frequently encounter UAs it cannot authenticate. In these 1201 cases, the policy server MAY provide a generic policy that does not 1202 reveal sensitive information to these UAs. 1204 It is RECOMMENDED that administrators use SIPS URIs as policy server 1205 URIs so that subscriptions to session policies are transmitted over 1206 TLS. 1208 The above security attributes are important to protect the 1209 communication between the user agent and policy server. This 1210 document does not define the protocol used for the communication 1211 between user agent and policy server and merely refers to other 1212 specifications for this purpose. The security considerations of 1213 these specifications need to address the above security aspects. 1215 6. IANA Considerations 1217 6.1. Registration of the "Policy-Id" Header 1219 Name of Header: Policy-Id 1221 Short form: none 1223 Normative description: Section 4.4.5 of this document 1225 6.2. Registration of the "Policy-Contact" Header 1227 Name of Header: Policy-Contact 1229 Short form: none 1231 Normative description: Section 4.4.5 of this document 1233 6.3. Registration of the "policy" SIP Option-Tag 1235 This specification registers a new SIP option tag, as per the 1236 guidelines in Section 27.1 of RFC3261 [RFC3261]. 1238 This document defines the SIP option tag "policy". 1240 The following row has been added to the "Option Tags" section of the 1241 SIP Parameter Registry: 1243 +------------+------------------------------------------+-----------+ 1244 | Name | Description | Reference | 1245 +------------+------------------------------------------+-----------+ 1246 | policy | This option tag is used to indicate that | this | 1247 | | a UA can process policy server URIs for | document | 1248 | | and subscribe to session-specific | | 1249 | | policies. | | 1250 +------------+------------------------------------------+-----------+ 1252 Name of option: policy 1254 Description: Support for the Policy-Contact and Policy-Id headers. 1256 SIP headers defined: Policy-Contact, Policy-Id 1258 Normative description: This document 1260 7. References 1262 7.1. Normative References 1264 [I-D.ietf-sipping-config-framework] 1265 Channabasappa, S., "A Framework for Session Initiation 1266 Protocol User Agent Profile Delivery", 1267 draft-ietf-sipping-config-framework-15 (work in progress), 1268 February 2008. 1270 [I-D.ietf-sipping-media-policy-dataset] 1271 Hilt, V., "A User Agent Profile Data Set for Media 1272 Policy", draft-ietf-sipping-media-policy-dataset-05 (work 1273 in progress), November 2007. 1275 [I-D.ietf-sipping-policy-package] 1276 Hilt, V. and G. Camarillo, "A Session Initiation Protocol 1277 (SIP) Event Package for Session-Specific Session 1278 Policies", draft-ietf-sipping-policy-package-04 (work in 1279 progress), August 2007. 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, March 1997. 1284 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1285 October 2000. 1287 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1288 A., Peterson, J., Sparks, R., Handley, M., and E. 1289 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1290 June 2002. 1292 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1293 Provisional Responses in Session Initiation Protocol 1294 (SIP)", RFC 3262, June 2002. 1296 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1297 with Session Description Protocol (SDP)", RFC 3264, 1298 June 2002. 1300 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1301 Event Notification", RFC 3265, June 2002. 1303 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1304 UPDATE Method", RFC 3311, October 2002. 1306 7.2. Informative References 1308 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1309 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1310 for Instant Messaging", RFC 3428, December 2002. 1312 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1313 Method", RFC 3515, April 2003. 1315 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1316 Camarillo, "Best Current Practices for Third Party Call 1317 Control (3pcc) in the Session Initiation Protocol (SIP)", 1318 BCP 85, RFC 3725, April 2004. 1320 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1321 for Event State Publication", RFC 3903, October 2004. 1323 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1324 Description Protocol", RFC 4566, July 2006. 1326 Appendix A. Acknowledgements 1328 Many thanks to Allison Mankin for the discussions and the suggestions 1329 for this draft. Many thanks to Roni Even, Bob Penfield, Mary Barnes, 1330 Shida Schubert and Keith Drage for reviewing the draft and to Vijay 1331 Gurbani for the contributions to the security considerations. 1333 Appendix B. Session-Specific Policies - Call Flows 1335 The following call flows illustrate the overall operation of session- 1336 specific policies including the policy channel protocol as defined in 1337 the SIP Event Package for Session-Specific Session Policies 1338 [I-D.ietf-sipping-policy-package]. 1340 The following abbreviations are used: 1342 o: offer 1343 o': offer modified by a policy 1344 po: offer policy 1345 a: answer 1346 a': answer modified by a policy 1347 pa: answer policy 1348 ps uri: policy server URI (in Policy-Contact header) 1349 ps id: policy server id (in Policy-Id header) 1351 B.1. Offer in Invite 1352 UA A P A PS A PS B P B UA B 1353 | | | | | | 1354 |(1) INV | | | | 1355 |-------->| | | | | 1356 |(2) 488 | | | | 1357 |<--------| | | | | 1358 |(3) ACK | | | | | 1359 |-------->| | | | | 1360 |(4) SUBSCRIBE | | | | 1361 |------------------>| | | | 1362 |(5) 200 OK | | | | 1363 |<------------------| | | | 1364 |(6) NOTIFY | | | | 1365 |<------------------| | | | 1366 |(7) 200 OK | | | | 1367 |------------------>| | | | 1368 |(8) INV | | | | 1369 |-------->| | | | | 1370 | |(9) INV | | | 1371 | |---------------------------->| | 1372 | | | | |(10) INV 1373 | | | | |-------->| 1374 | | | |(11) SUBSCRIBE 1375 | | | |<------------------| 1376 | | | |(12) 200 OK | 1377 | | | |------------------>| 1378 | | | |(13) NOTIFY 1379 | | | |------------------>| 1380 | | | |(14) 200 OK | 1381 | | | |<------------------| 1382 | | | | |(15) 200 OK 1383 | | | | |<--------| 1384 | |(16) 200 OK | | | 1385 | |<----------------------------| | 1386 |(17) 200 OK | | | | 1387 |<--------| | | | | 1388 |(18) ACK | | | | | 1389 |------------------------------------------------>| 1390 |(19) SUBSCRIBE | | | 1391 |------------------>| | | | 1392 |(20) 200 OK | | | | 1393 |<------------------| | | | 1394 |(21) NOTIFY | | | 1395 |<------------------| | | | 1396 |(22) 200 OK | | | | 1397 |------------------>| | | | 1398 | | | | | | 1399 | | | | | | 1401 B.2. Offer in Response 1403 UA A P A PS A PS B P B UA B 1404 | | | | | | 1405 |(1) INV | | | | | 1406 |-------->| | | | | 1407 |(2) 488 | | | | 1408 |<--------| | | | | 1409 |(3) ACK | | | | | 1410 |-------->| | | | | 1411 |(4) SUBSCRIBE | | | | 1412 |------------------>| | | | 1413 |(5) 200 OK | | | | 1414 |<------------------| | | | 1415 |(6) NOTIFY | | | | 1416 |<------------------| | | | 1417 |(7) 200 OK | | | | 1418 |------------------>| | | | 1419 |(8) INV | | | | 1420 |-------->| | | | | 1421 | |(9) INV | | | | 1422 | |---------------------------->| | 1423 | | | | |(10) INV 1424 | | | | |-------->| 1425 | | | |(11) SUBSCRIBE | 1426 | | | |<------------------| 1427 | | | |(12) 200 OK | 1428 | | | |------------------>| 1429 | | | |(13) NOTIFY | 1430 | | | |------------------>| 1431 | | | |(14) 200 OK | 1432 | | | |<------------------| 1433 | | | | |(15) 200 OK 1434 | | | | |<--------| 1435 | |(16) 200 OK | | | 1436 | |<----------------------------| | 1437 |(17) 200 OK | | | | 1438 |<--------| | | | | 1439 |(18) SUBSCRIBE | | | 1440 |------------------>| | | | 1441 |(19) 200 OK | | | | 1442 |<------------------| | | | 1443 |(20) NOTIFY | | | 1444 |<------------------| | | | 1445 |(21) 200 OK | | | | 1446 |------------------>| | | | 1447 |(22) ACK | | | | 1448 |------------------------------------------------>| 1449 | | | |(23) SUBSCRIBE 1450 | | | |<------------------| 1451 | | | |(24) 200 OK | 1452 | | | |------------------>| 1453 | | | |(25) NOTIFY 1454 | | | |------------------>| 1455 | | | |(26) 200 OK | 1456 | | | |<------------------| 1457 | | | | | | 1458 | | | | | | 1460 B.3. Multiple Policy Servers for UAS 1462 UA A P A PS A PS B P B UA B 1463 | | | | | | 1464 | | | | | | 1465 | | | | | | 1466 |(1) INV | | | | 1467 |-------->| | | | | 1468 | |(2) INV | | 1469 | |---------------------------->| | 1470 | | | | |(3) INV 1471 | | | | |-------->| 1472 | | |(4) SUBSCRIBE | 1473 | | |<----------------------------| 1474 | | |(5) 200 OK | | 1475 | | |---------------------------->| 1476 | | |(6) NOTIFY | | 1477 | | |---------------------------->| 1478 | | |(7) 200 OK | | 1479 | | |<----------------------------| 1480 | | | |(8) SUBSCRIBE 1481 | | | |<------------------| 1482 | | | |(9) 200 OK | 1483 | | | |------------------>| 1484 | | | |(10) NOTIFY 1485 | | | |------------------>| 1486 | | | |(11) 200 OK | 1487 | | | |<------------------| 1488 | | |(12) SUBSCRIBE | 1489 | | |<----------------------------| 1490 | | |(13) 200 OK | | 1491 | | |---------------------------->| 1492 | | |(14) NOTIFY | 1493 | | |---------------------------->| 1494 | | |(15) 200 OK | | 1495 | | |<----------------------------| 1496 | | | |(16) SUBSCRIBE 1497 | | | |<------------------| 1498 | | | |(17) 200 OK | 1499 | | | |------------------>| 1500 | | | |(18) NOTIFY 1501 | | | |------------------>| 1502 | | | |(19) 200 OK | 1503 | | | |<------------------| 1504 | | | | |(20) 200 OK 1505 | | | | |<--------| 1506 | |(21) 200 OK | | | 1507 | |<----------------------------| | 1508 |(22) 200 OK | | | | 1509 |<--------| | | | | 1510 |(23) ACK | | | | | 1511 |------------------------------------------------>| 1512 | | | | | | 1513 | | | | | | 1515 Authors' Addresses 1517 Volker Hilt 1518 Bell Labs/Alcatel-Lucent 1519 791 Holmdel-Keyport Rd 1520 Holmdel, NJ 07733 1521 USA 1523 Email: volkerh@bell-labs.com 1525 Gonzalo Camarillo 1526 Ericsson 1527 Hirsalantie 11 1528 Jorvas 02420 1529 Finland 1531 Email: Gonzalo.Camarillo@ericsson.com 1533 Jonathan Rosenberg 1534 Cisco 1535 Edison, NJ 1536 USA 1538 Email: jdrosen@cisco.com 1540 Full Copyright Statement 1542 Copyright (C) The IETF Trust (2008). 1544 This document is subject to the rights, licenses and restrictions 1545 contained in BCP 78, and except as set forth therein, the authors 1546 retain all their rights. 1548 This document and the information contained herein are provided on an 1549 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1550 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1551 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1552 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1553 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1556 Intellectual Property 1558 The IETF takes no position regarding the validity or scope of any 1559 Intellectual Property Rights or other rights that might be claimed to 1560 pertain to the implementation or use of the technology described in 1561 this document or the extent to which any license under such rights 1562 might or might not be available; nor does it represent that it has 1563 made any independent effort to identify any such rights. Information 1564 on the procedures with respect to rights in RFC documents can be 1565 found in BCP 78 and BCP 79. 1567 Copies of IPR disclosures made to the IETF Secretariat and any 1568 assurances of licenses to be made available, or the result of an 1569 attempt made to obtain a general license or permission for the use of 1570 such proprietary rights by implementers or users of this 1571 specification can be obtained from the IETF on-line IPR repository at 1572 http://www.ietf.org/ipr. 1574 The IETF invites any interested party to bring to its attention any 1575 copyrights, patents or patent applications, or other proprietary 1576 rights that may cover technology that may be required to implement 1577 this standard. Please address the information to the IETF at 1578 ietf-ipr@ietf.org.