idnits 2.17.1 draft-ietf-sip-session-policy-framework-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1063 has weird spacing: '... where prox...' == Line 1070 has weird spacing: '... where prox...' == Line 1072 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 (February 19, 2011) is 4807 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 (-16) exists of draft-ietf-sipping-media-policy-dataset-11 ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 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: August 23, 2011 Ericsson 6 J. Rosenberg 7 jdrosen.net 8 February 19, 2011 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sip-session-policy-framework-10 13 Abstract 15 Proxy servers play a central role as an intermediary in the Session 16 Initiation Protocol (SIP) as they define and impact policies on call 17 routing, rendezvous, and other call features. This document 18 specifies a framework for SIP session policies that provides a 19 standard mechanism by which a proxy can define or influence policies 20 on sessions, such as the codecs or media types to be used. It 21 defines a model, an overall architecture and new protocol mechanisms 22 for session policies. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 23, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 6 61 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 6 62 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.2. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 9 65 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 9 66 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 12 70 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 14 71 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 16 72 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 16 73 4.4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 18 74 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 20 75 4.4.4. Caching the Local Policy Server URI . . . . . . . . . 21 76 4.4.5. Header Field Definition and Syntax . . . . . . . . . . 22 77 4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 24 78 4.5.1. Creation and Management . . . . . . . . . . . . . . . 24 79 4.5.2. Contacting the Policy Server . . . . . . . . . . . . . 25 80 4.5.3. Using Session Policies . . . . . . . . . . . . . . . . 27 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 83 6.1. Registration of the "Policy-Id" Header Field . . . . . . . 29 84 6.2. Registration of the "Policy-Contact" Header Field . . . . 30 85 6.3. Registration of the "non-cacheable" Policy-Contact 86 Header Field Parameter . . . . . . . . . . . . . . . . . . 30 87 6.4. Registration of the "policy" SIP Option-Tag . . . . . . . 30 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 90 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 92 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 33 93 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 33 94 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 35 95 B.3. Multiple Policy Servers for UAS . . . . . . . . . . . . . 36 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 99 1. Introduction 101 The Session Initiation Protocol (SIP) [RFC3261] is a signaling 102 protocol for creating, modifying and terminating multimedia sessions. 103 A central element in SIP is the proxy server. Proxy servers are 104 intermediaries that are responsible for request routing, rendezvous, 105 authentication and authorization, mobility, and other signaling 106 services. However, proxies are divorced from the actual sessions - 107 audio, video, and session-mode messaging - that SIP establishes. 108 Details of the sessions are carried in the payload of SIP messages, 109 and are usually described with the Session Description Protocol (SDP) 110 [RFC4566]. 112 Experience has shown that there is a need for SIP intermediaries to 113 impact aspects of a session. For example, SIP can be used in a 114 wireless network, which has limited resources for media traffic. 115 During periods of high activity, the wireless network provider could 116 want to restrict the amount of bandwidth available to each user. 117 With session policies, an intermediary in the wireless network can 118 inform the user agent about the bandwidth it has available. This 119 information enables the user agent to make an informed decision about 120 the number of streams, the media types, and the codecs it can 121 successfully use in a session. Similarly, a network provider can 122 have a service level agreement with a user that defines the set of 123 media types the user can use. With session policies, the network can 124 convey the current set of policies to user agents, enabling them to 125 set up sessions without inadvertently violating any of the network 126 policies. 128 In another example, a SIP user agent is using a network which is 129 connected to the public Internet through a firewall or a network 130 border device. The network provider would like to tell the user 131 agent that it needs to send its media streams to a specific IP 132 address and port on the firewall or border device to reach the public 133 Internet. Knowing this policy enables the user agent to set up 134 sessions across the firewall or the network border. In contrast to 135 other methods for inserting a media intermediary, the use of session 136 policies does not require the inspection or modification of SIP 137 message bodies. 139 Domains often have the need to enforce the session policies they have 140 in place. For example, a domain might have a policy that disallows 141 the use of video and can have an enforcement mechanism that drops all 142 packets containing a video encoding. Unfortunately, these 143 enforcement mechanisms usually do not inform the user about the 144 policies they are enforcing. Instead, they silently keep the user 145 from doing anything against them. This can lead to a malfunctioning 146 of devices that is incomprehensible to the user. With session 147 policies, the user knows about the current network policies and can 148 set up policy-compliant sessions or simply connect to a domain with 149 less stringent policies. Thus, session policies provide an important 150 combination of consent coupled with enforcement. That is, the user 151 becomes aware of the policy and needs to act on it, but the provider 152 still retains the right to enforce the policy. 154 Two types of session policies exist: session-specific policies and 155 session-independent policies. Session-specific policies are policies 156 that are created for one particular session, based on the session 157 description of this session. They enable a network intermediary to 158 examine the session description a UA is proposing and to return a 159 policy specifically for this session description. For example, an 160 intermediary could open pinholes in a firewall/NAT for each media 161 stream in the proposed session description. It can then return a 162 policy for the session description that replaces the IP addresses and 163 ports of the UA with the ones opened in the firewall/NAT that are 164 reachable from external. Session-specific policies provide 165 information about a specific session to a domain, which can be used 166 to implement policies for opening pinholes on a firewall/NAT. Since 167 session-specific policies are tailored to a session, they only apply 168 to the session they are created for. Session-specific policies are 169 created on a session-by-session basis at the time the session is 170 established. 172 Session-independent policies on the other hand are policies that are 173 created independent of a session and generally apply to all SIP 174 sessions set up by a user agent. A session-independent policy can, 175 for example, be used to inform user agents about an existing 176 bandwidth limit or media type restrictions. Since these policies are 177 not based on a specific session description, they can be created 178 independent of an attempt to set up a session and only need to be 179 conveyed to the user agent when it initializes (e.g., at the time the 180 device is powered on) and when policies are changed. 182 This specification defines a framework for SIP session policies. It 183 specifies a model, the overall architecture and new protocol 184 mechanisms that are needed for session-independent and session- 185 specific policies. Since session-specific and session-independent 186 policies have different requirements, this specification defines two 187 different mechanisms to deliver them to user agents. These 188 mechanisms are independent of each other and, depending on whether 189 one or both types of session policies are needed, it is possible to 190 use the session-specific or the session-independent mechanism or both 191 to deliver policies to user agents. 193 It is RECOMMENDED that UAs and intermediaries use the mechanisms 194 defined in this specification for signaling session policies to 195 endpoints. To ensure backwards compatibility with UAs that do not 196 support this specification, intermediaries may choose to resort to 197 existing mechanisms such as rejecting sessions that are not policy 198 compliant with a 488 response as a fallback solution if a UA does not 199 indicate support for session policies. UAs that do not support 200 session policies will receive the same user experience as they would 201 today. As these techniques are known to have many drawbacks it is 202 RECOMMENDED that UAs and intermediaries use explicit signaling of 203 policies using the mechanisms defined in this specification. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [RFC2119]. 211 3. Session-Independent Policies 213 Session-independent policies are policies that are created 214 independent of a session and generally apply to all sessions a user 215 agent is setting up. They typically remain stable for a longer 216 period of time and apply to any session set up while they are valid. 217 However, it is possible for session-independent policies to change 218 over time. For example, a policy that defines a bandwidth limit for 219 a user can change during the day, defining a lower limit during peak 220 hours and allow more bandwidth off-peak. The policy server informs a 221 UA when session-independent policies change. 223 3.1. Architecture and Overview 225 +-------------+ 226 /------| policy | 227 +----+ / | server 1 | 228 | |---/ +-------------+ 229 | UA | ... 230 | |---\ +-------------+ 231 +----+ \ | policy | 232 \------| server n | 233 +-------------+ 235 Figure 1 237 A SIP UA can receive session-independent policies from one or more 238 policy servers. In a typical configuration, a UA receives session- 239 independent policies from a policy server in the local network domain 240 (i.e., the domain from which the UA receives IP service) and possibly 241 the SIP service provider domain (i.e., the domain the UA registers 242 at). The local network can have policies that support the access 243 network infrastructure. For example, in a wireless network where 244 bandwidth is scarce, a provider can restrict the bandwidth available 245 to an individual user. The SIP service provider can have policies 246 that are needed to support services or policies that reflect the 247 service level agreement with the user. Thus, in most cases, a UA 248 will receive session-independent policies from one or two policy 249 servers. 251 Setting up session-independent policies involves the following steps: 253 1. A user agent discovers session-independent policy servers in the 254 local network and SIP service provider domain 255 2. A user agent requests session-independent policies from the 256 discovered policy servers. A user agent typically requests these 257 policies when it starts up or connects to a new network domain. 258 3. The policy server selects the policies that apply to this user 259 agent. The policy server can have general policies that apply to 260 all users or maintain separate policies for each individual user. 261 The selected policies are returned to the user agent. 262 4. The policy server can update the policies, for example, when 263 network conditions change. 265 3.2. Policy Subscription 267 3.2.1. UAC Behavior 269 A UA that supports session-independent policies compliant to this 270 specification MUST attempt to retrieve session-independent policies 271 from the local network and the SIP service provider domain, unless 272 the UA knows (e.g., through configuration) that a domain does not 273 provide session-independent policies (in which case the UA SHOULD NOT 274 retrieve session-independent policies from this specific domain). 276 A UA that supports session-independent policies compliant to this 277 specification MUST support the retrieval of session-independent 278 policies from the local network and the SIP service provider domain 279 using the "ua-profile" event package defined in the Framework for SIP 280 User Agent Profile Delivery [I-D.ietf-sipping-config-framework]. The 281 UA MAY support other methods of retrieving session-independent 282 policies from local network and SIP service provider domain. 284 The "ua-profile" event package [I-D.ietf-sipping-config-framework] 285 provides a mechanism to subscribe to session-independent policies. A 286 UA subscribes to the policy server in the local network domain using 287 the procedures defined for the "local-network" profile-type. The UA 288 uses the procedures defined for the "user" profile type to subscribe 289 to the policy server in the SIP service provider domain. 291 A UA (re-)subscribes to session-independent policies when the 292 following events occur: 294 o The UA registers a new address-of-record (AoR) or removes a AoR 295 from the set of AoRs it has registered. In these cases, the UA 296 MUST establish subscriptions for each new AoR using the "user" and 297 the "local-network" profile-types. The UA MUST terminate all 298 subscriptions for AoRs it has removed. 299 o The UA changes the domain it is connected to. The UA MUST 300 terminate all existing subscriptions for the "local-network" 301 profile-type. The UA MUST then create a new subscription for each 302 AoR it maintains using the "local-network" profile-type. This 303 way, the UA stops receiving policies from the previous local 304 domain and starts to receive the policies of the new local domain. 305 The UA does not need to change the subscriptions for "user" 306 profiles. 308 If a UA is unable to establish a subscription, the UA SHOULD NOT 309 attempt to re-try this subscription, unless one of the above events 310 occurs again. This is to limit the number of SUBSCRIBE requests sent 311 within domains that do not support session-independent policies. 312 However, a UA SHOULD retry the subscription with a longer time 313 interval (e.g., once every 24 hours). This enables UAs to detect new 314 policies that are deployed in a network that previously did not have 315 policies. 317 A UA that supports session-independent policies compliant to this 318 specification MUST support the User Agent Profile Data Set for Media 319 Policy [I-D.ietf-sipping-media-policy-dataset]. To indicate that the 320 UA wants to receive session-independent policies, the UA includes the 321 MIME type "application/media-policy-dataset+xml" in the Accept header 322 field of a SUBSCRIBE request. 324 A UA MUST apply the session-independent policies it has received and 325 use these policies in the session descriptions it creates. If the UA 326 decides not to use the received policies, then the UA MUST NOT set up 327 a session unless it changes the domain that provided these policies. 328 A UA MAY try to connect to another local network and/or SIP service 329 provider domain with a different set of policies. 331 If a UA receives both session-independent and session-specific 332 policies, the UA MUST apply the session-independent policies to the 333 session description before the session description is sent to the 334 session-specific policy server (see Section 4). Thus, session- 335 independent policies are always applied before session-specific 336 policies are retrieved. 338 3.2.2. UAS Behavior 340 A policy server MAY send a notification to the UA every time the 341 session-independent policies covered by the subscription change. The 342 definition of what causes a policy to change is at the discretion of 343 the administrator. A change in the policy can be triggered, for 344 example, by a change in the network status, by the change in the time 345 of day or by an update of the service level agreement with the 346 customer. 348 4. Session-Specific Policies 350 Session-specific policies are policies that are created specifically 351 for one particular session of a UA. Thus, session-specific policies 352 will typically be different for different sessions. The session- 353 specific policies for a session can change during the course of the 354 session. For example, a user can run out of credit during a session, 355 which will cause the network to disallow the transmission all media 356 streams from this point on. 358 4.1. Architecture 360 domain 1 361 +-----------+ 362 /------| proxy |----... 363 +----+ / +-----------+ 364 | |---/ +-----------+ 365 | | | policy | 366 | UA |============| server | 367 | | +-----------+ 368 | |**** +-----------+ 369 +----+ * | policy | 370 *******|enforcement|****... 371 +-----------+ 373 --- SIP Signaling 374 === Policy Channel 375 *** Media 377 Figure 2 379 The following entities are needed for session-specific policies (see 380 Figure 2): a user agent (UA), a proxy, a policy server and possibly a 381 policy enforcement entity. 383 The role of the proxy is to provide a rendezvous mechanism for UAs 384 and policy servers. It ensures that each UA has the URI [RFC3986] of 385 the policy server in its domain and knows where to retrieve policies 386 from. The proxy conveys the policy server URI to UAs in case they 387 have not yet received it (e.g., in a previous call or through 388 configuration). The proxy does not deliver the actual policies to 389 UAs. 391 The policy server is a separate logical entity that can be physically 392 co-located with the proxy. The role of the policy server is to 393 deliver session policies to UAs. The policy server receives session 394 information from the UA, uses this information to determine the 395 policies that apply to the session and returns these policies to the 396 UA. The mechanism for generating policies (i.e., making policy 397 decisions) is outside of the scope of this specification. A policy 398 server can, for example, query an external entity to get policies or 399 it can directly incorporate a policy decision point and generate 400 policies locally. 402 A UA receives the URI of a policy server from a proxy. It uses this 403 URI to contact the policy server. It provides information about the 404 current session to the policy server and receives session policies in 405 response. The UA can also receive policy updates from the policy 406 server during the course of a session. 408 A network can have a policy enforcement infrastructure in place. 409 However, this specification does not make any assumptions about the 410 enforcement of session policies and the mechanisms defined here are 411 orthogonal to a policy enforcement infrastructure. 413 In principle, each domain that is traversed by SIP signaling messages 414 can define session-specific policies for a session. Each domain 415 needs to run a policy server and a proxy that is able to rendezvous a 416 UA with the policy server (as shown in Figure 2). However, it is 417 expected that session-specific policies will often only be provided 418 by the local domain of the user agent. 420 4.2. Overview 422 The protocol defined in this specification clearly separates SIP 423 signaling and the exchange of policies. SIP signaling is only used 424 to rendezvous the UA with the policy server. From this point on, UA 425 and policy server communicate directly with each other over a 426 separate policy channel. This is opposed to a piggyback model, where 427 the exchange of policy information between endpoint and a policy 428 server in the network is piggybacked onto the SIP signaling messages 429 that are exchanged between endpoints. 431 The main advantage of using a separate policy channel is that it 432 decouples signaling between endpoints from the policy exchange 433 between an endpoint and a policy server. This decoupling has a 434 number of desirable properties. It enables the use of separate 435 encryption mechanisms on the signaling path to secure the 436 communication between endpoints, and on the policy channel to secure 437 the communication between endpoint and policy server. Policies can 438 be submitted directly from the policy server to the endpoint and do 439 not travel along the signaling path, possibly crossing many domains. 440 Endpoints set up a separate policy channel to each policy server and 441 can disclose the information requested by the specific policy server 442 (e.g., offer or offer/answer). Finally, policy servers do not need 443 to rely on a SIP signaling message flowing by to send policies or 444 policy updates to an endpoint. A policy server can use the policy 445 channel at any time to update session policies as needed. A 446 disadvantage of the separate channel model is that it requires 447 additional messages for the exchange of policy information. 449 Following this model, signaling for session-specific policies 450 involves the following two fundamental tasks: 452 1. UA/policy server rendezvous: a UA setting up a session needs to 453 be able to discover the policy servers that are relevant to this 454 session. 455 2. Policy channel: once the UA has discovered the relevant policy 456 servers for a session, it needs to connect to these servers, 457 disclose session information and retrieve the policies that apply 458 to this session. 460 The communication between UA and policy server on the policy channel 461 involves the following steps: 463 1. A user agent submits information about the session it is trying 464 to establish to the policy server and asks whether a session 465 using these parameters is permissible. 466 2. The policy server generates a policy decision for this session 467 and returns the decision to the user agent. Possible policy 468 decisions are (1) to deny the session, (2) to propose changes to 469 the session parameters with which the session would be 470 acceptable, or (3) to accept the session as it was proposed. 471 3. The policy server can update the policy decision at a later time. 472 A policy decision update can, for example, propose additional 473 changes to the session (e.g., change the available bandwidth) or 474 deny a previously accepted session (i.e., disallow the 475 continuation of a session). 477 In many cases, the mechanism for session-specific policies will be 478 used to disclose session information and return session policies. 480 However, some scenarios only involve the disclosure of session 481 information to a network intermediary. If an intermediary does not 482 intend to return a policy, it can simply accept the session as it was 483 proposed. Similarly, some session-specific policies only apply to 484 the offer (and therefore only require the disclosure of the offer) 485 whereas others apply to offer and answer. Both types of policies are 486 supported by session-specific policy mechanism. 488 4.3. Examples 490 This section provides two examples to illustrate the overall 491 operation of session-specific policies. The call flows depict the 492 rendezvous mechanism between UA and policy server and indicate the 493 points at which the UA exchanges policy information with the policy 494 server. 496 The example is based on the following scenario: there are two domains 497 (domain A and domain B), which both have session-specific policies 498 for the UAs in their domain. Both domains do not provide policies to 499 the UAs outside of their domain. The two domains have a proxy (P A 500 and P B) and a policy server (PS A and PS B). The policies in both 501 domains involve the session description offer and answer. 503 4.3.1. Offer in Request 505 The first call flow shown in Figure 3 depicts an INVITE transaction 506 with the offer in the request. It is assumed that this is the first 507 INVITE request the UAC creates in this domain and that it therefore 508 does not have previous knowledge about the policy server URIs in this 509 domain. 511 (1) UA A sends an INVITE request to proxy P A. P A knows that 512 policies apply to this session and (2) returns a 488 (Not Acceptable 513 Here) response to UA A. P A includes the URI of PS A in the 488 (Not 514 Acceptable Here) response. This step is needed since the UAC has no 515 prior knowledge about the URI of PS A. (3) UA A uses the URI to 516 contact PS A, discloses the session description offer to PS A and (4) 517 receives policies for the offer. (5) UA A reformulates the INVITE 518 request under consideration of the received policies and includes a 519 Policy-Id header field to indicate that it has already contacted PS 520 A. P A does not reject the INVITE request this time and removes the 521 Policy-Id header field when forwarding the INVITE request. P B adds 522 a Policy-Contact header field containing the URI of PS B. (6) UA B 523 uses this URI to contact PS B and disclose the offer and the answer 524 it is about to send. (7) UA B receives policies from PS B and applies 525 them to the offer and answer respectively. (8) UA B returns the 526 updated answer in the 200 (OK) response. (9) UA A contacts PS A again 527 with the current offer and answer and (10) retrieves the policies for 528 both from PS A. 530 UA A P A P B UA B 531 | | | | 532 | INVITE offer | | | 533 |---------------->| | | (1) 534 | 488 | | | 535 | + Policy-Contact| | | 536 |<----------------| | | (2) 537 | ACK | | | 538 |---------------->| | | 539 | | PS A | | 540 | | | | 541 | PolicyChannel | | | 542 | + InfoOffer | | | 543 |------------------->| | | (3) 544 | PolicyChannel | | | 545 | + PolicyOffer | | | 546 |<-------------------| | | (4) 547 | | | | 548 | | | | 549 | INVITE offer' | INVITE offer' | INVITE offer' | 550 | + Policy-Id | | + Policy-Contact| 551 |---------------->|--------------->|---------------->| (5) 552 | | | | 553 | | PS B | | 554 | | | | 555 | | | PolicyChannel | 556 | | | + InfoOffer' | 557 | | | + InfoAnswer | 558 | | |<-------------------| (6) 559 | | | PolicyChannel | 560 | | | + PolicyOffer | 561 | | | + PolicyAnswer | 562 | | |------------------->| (7) 563 | | | | 564 | | | | 565 | OK answer' | OK answer' | OK answer' | 566 |<----------------|<---------------|<----------------| (8) 567 | ACK | 568 |--------------------------------------------------->| 569 | | | | 570 | | | | 571 | PolicyChannel | | | 572 | + InfoOffer' | | | 573 | + InfoAnswer' | | | 574 |------------------->| | | (9) 575 | PolicyChannel | | | 576 | + PolicyOffer | | | 577 | + PolicyAnswer | | | 578 |<-------------------| | | (10) 579 | | | | 581 Figure 3 583 4.3.2. Offer in Response 585 The call flow shown in Figure 4 depicts an INVITE transaction with 586 the offer in the response. 588 (1) UA A sends an INVITE request without an offer to proxy P A and 589 (2) P A returns a 488 (Not Acceptable Here) response containing the 590 URI of PS A. (3),(4) UA A uses this policy server URI to set up the 591 policy channel. At this time, UA A does not disclose a session 592 description since it does not have the offer yet. (5) UA A re-sends 593 the INVITE request and includes a Policy-Id header field to indicate 594 that it has contacted PS A. P A does not reject the INVITE request 595 this time and removes the Policy-Id header field when forwarding the 596 INVITE request. P B adds a Policy-Contact header field containing 597 the URI of PS B. (6) UA B uses this URI to discloses the offer to PS 598 B. (7) UA B receives policies from PS B and applies them to the 599 offer. (8) UA B returns the updated offer the 200 (OK) response. 600 (9),(10) UA A contacts PS and discloses the offer and the answer it 601 is about to send. An important difference to the flow in the 602 previous example is that UA A performs steps (9) and (10) before 603 returning the answer in step (11). This enables UA A to return the 604 final answer in the ACK request, which includes all applicable 605 policies. However, it requires that PS A immediately returns a 606 policy to avoid a delay in the transmission of the ACK request. 607 (12),(13) UA B again sends the current offer and answer to PS B and 608 applies the policies it receives to both before using them. 610 UA A P A P B UA B 611 | | | | 612 | INVITE | | | 613 |---------------->| | | (1) 614 | 488 | | | 615 | + Policy-Contact| | | 616 |<----------------| | | (2) 617 | ACK | | | 618 |---------------->| | | 619 | | PS A | | 620 | | | | 621 | PolicyChannel | | | 622 |------------------->| | | (3) 623 | PolicyChannel | | | 624 |<-------------------| | | (4) 625 | | | | 626 | | | | 627 | INVITE | INVITE | INVITE | 628 | + Policy-Id | | + Policy-Contact| 629 |---------------->|--------------->|---------------->| (5) 630 | | | | 631 | | PS B | | 632 | | | | 633 | | | PolicyChannel | 634 | | | + InfoOffer | 635 | | |<-------------------| (6) 636 | | | PolicyChannel | 637 | | | + PolicyOffer | 638 | | |------------------->| (7) 639 | | | | 640 | | | | 641 | OK offer' | OK offer' | OK offer' | 642 |<----------------|<---------------|<----------------| (8) 643 | | | | 644 | | | | 645 | PolicyChannel | | | 646 | + InfoOffer' | | | 647 | + InfoAnswer | | | 648 |------------------->| | | (9) 649 | PolicyChannel | | | 650 | + PolicyOffer | | | 651 | + PolicyAnswer | | | 652 |<-------------------| | | (10) 653 | | | | 654 | ACK answer' | 655 |--------------------------------------------------->| (11) 656 | | | | 657 | | | | 658 | | | PolicyChannel | 659 | | | + InfoOffer' | 660 | | | + InfoAnswer' | 661 | | |<-------------------| (12) 662 | | | PolicyChannel | 663 | | | + PolicyOffer | 664 | | | + PolicyAnswer | 665 | | |------------------->| (13) 666 | | | | 668 Figure 4 670 4.4. UA/Policy Server Rendezvous 672 The first step in setting up session-specific policies is to 673 rendezvous the UAs with the relevant policy servers. This is 674 achieved by providing the URIs of all policy servers relevant for a 675 session to the UAs. 677 4.4.1. UAC Behavior 679 A UAC compliant to this specification MUST include a Supported header 680 field with the option tag "policy" into all requests that can 681 initiate an offer/answer exchange [RFC3264] (e.g., INVITE, UPDATE 682 [RFC3311] and PRACK [RFC3262] requests). The UAC MUST include the 683 "policy" option tag into these requests even if the particular 684 request does not contain an offer or answer (e.g., an INVITE request 685 without an offer). A UAC MAY include the "policy" option tag into 686 all requests. 688 A UAC can receive a 488 (Not Acceptable Here) response that contains 689 a Policy-Contact header field. The Policy-Contact header field is a 690 new header field defined in this specification. It contains one (or 691 multiple alternative) URIs for a policy server. A 488 (Not 692 Acceptable Here) response with this header field is generated by a 693 proxy to convey an URI of the local policy server to the UAC. After 694 receiving a 488 (Not Acceptable Here) response with a Policy-Contact 695 header field, a UAC compliant to this specification needs to decide 696 if it wants to continue with the session now knowing that there is a 697 policy server. If the UAC decides to continue, the UAC MUST use one 698 of the policy server URIs to contact the policy server using the 699 mechanism defined in Section 4.5. 701 The Policy-Contact header can contain multiple URIs each with a 702 different URI scheme and containing an "alt-uri" parameter with 703 identical values. These URIs represent alternative policy channel 704 mechanisms for obtaining the same policy. The UAC chooses one of the 705 alternative URIs to use to obtain the policy. The UAC MAY take as a 706 hint the order of the alternative URIs as indicating a preference as 707 to which URI to use. The topmost URI in the list might be more 708 preferred by the domain of the proxy for use to obtain the policy. 710 After receiving policies from the policy server, the UAC decides if 711 it wants to accept these policies or not. If the UAC accepts these 712 policies, the UAC MUST apply them to the current request and resend 713 the updated request. If no changes are required by policies or no 714 policies have been received, the request can be resent without any 715 policy-induced changes. If the UAC decides that the list of policy 716 servers or the received session policies are unacceptable, then the 717 UAC MUST NOT resend the request. 719 To protect the integrity of the policy server URI in a Policy-Contact 720 header field, the UAC SHOULD use a secured transport protocol such as 721 Transport Layer Security (TLS) [RFC5246] between UAC and proxy. 723 The UAC MUST insert a Policy-Id header field into requests for which 724 it has contacted a policy server and accepted the policies received. 725 The Policy-Id header field is a new header field that is defined in 726 this specification. The UA MUST create a Policy-Id header field 727 value for each policy server it has contacted during the preparation 728 of the request. A Policy-Id header field value contains two pieces 729 of information: the policy server URI and an optional token. The 730 policy server URI is the URI the UA has used to contact the policy 731 server. The token is an opaque string the UAC can receive from the 732 policy server. A token can, for example, be contained in the policy 733 document [I-D.ietf-sipping-media-policy-dataset]. If the UAC has 734 received a token from the policy server the UAC MUST include the 735 token in the Policy-Id header field. The format of the Policy-Id 736 header field is defined in Section 4.4.5. 738 The main purpose of the Policy-Id header field is to enable a proxy 739 to determine if the UAC already knows an URI of the local policy 740 server. If the policy server URI is not yet known to the UAC, the 741 proxy can convey this URI to the UAC by rejecting the request with a 742 488 (Not Acceptable Here) response. 744 In some cases, a request can traverse multiple domains with a 745 session-policy server. Each of these domains can return a 488 (Not 746 Acceptable Here) response containing a policy server URI. A UAC 747 contacts a policy server after receiving a 488 (Not Acceptable Here) 748 response from a domain and before re-sending the request. This 749 creates an implicit order between the policy servers in multiple 750 domains. I.e., a UAC contacts the first policy server, re-sends the 751 modified request, contacts the second policy server, re-sends the 752 modified request and so on. This way, session policies are always 753 applied to a request in the order in which the request traverses 754 through the domains. The UAC MUST NOT change this implicit order 755 among policy servers. 757 A UAC frequently needs to contact the policy server in the local 758 domain before setting up a session. To avoid the retransmission of 759 the local policy server URI in a 488 (Not Acceptable Here) response 760 for each new request, a UA SHOULD maintain a cache that contains the 761 URI of the policy server in the local domain (see Section 4.4.4). 762 The UAC SHOULD use the cached policy server URI to contact the local 763 policy server before sending a request that initiates the offer/ 764 answer exchange for a new session (e.g., an INVITE request). The UAC 765 SHOULD NOT cache a policy server URI that is in a different domain 766 than the UAC even if it is the first policy server URI returned. The 767 first policy server URI returned can be from another domain if the 768 local domain does not have a policy server. Note that UACs perform 769 exact domain comparisons. That is, foo.example.com and example.com 770 are not considered equivalent. 772 UAs can re-negotiate the session description during a session by 773 initiating a subsequent offer/answer exchange, e.g., in an INVITE, 774 UPDATE or PRACK request. When creating such a mid-dialog request, a 775 UA SHOULD contact all policy servers to which it has established a 776 policy channel during the initial offer/answer exchange (see 777 Section 4.5) before sending the request. This avoids the 778 retransmission of all policy server URIs in 488 (Not Acceptable Here) 779 responses for mid-dialog requests. 781 4.4.2. Proxy Behavior 783 A proxy provides rendezvous functionalities for UAs and policy 784 server. This is achieved by conveying the URI of a policy server to 785 the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK 786 requests (or any other request that can initiate an offer/answer 787 exchange). 789 If an offer/answer exchange initiating request contains a Supported 790 header field with the option tag "policy", the proxy MAY reject the 791 request with a 488 (Not Acceptable Here) response to provide the 792 local policy server URI to the UAC. Before rejecting a request, the 793 proxy MUST verify that the request does not contain a Policy-Id 794 header field with the local policy server URI as a value. If the 795 request does not contain such a header field or a local policy server 796 URI is not present in this header field, then the proxy MAY reject 797 the request with a 488 (Not Acceptable Here) response. The proxy 798 MUST insert a Policy-Contact header field in the 488 (Not Acceptable 799 Here) response that contains one (or multiple) URIs of its associated 800 policy server. The proxy MAY add the header field parameter "non- 801 cacheable" to prevent the UAC from caching this policy server URI 802 (see Section 4.4.4). 804 More than one URI for the policy server using different URI schemes 805 MAY be provided by the proxy as alternative URIs to contact the 806 policy. If a proxy includes multiple URIs for the same policy, the 807 proxy MUST include an "alt-uri" parameter for all policy server URIs 808 that are alternatives for obtaining the same policy. The "alt-uri" 809 parameter MUST contain either the domain name of the domain for which 810 all the alternative policy server URIs relate to or a FQDN (e.g., the 811 hostname of a policy server). All URIs that are alternatives for the 812 same policy MUST have the same value for the "alt-uri" parameter. 813 The value used for the "alt-uri" parameter MUST be such that the same 814 value will not be included with other policy server URIs that a UA 815 needs to contact by any other proxy within the same domain or another 816 domain. A method to create a new unique "alt-uri" parameter value is 817 to examine the value of existing "alt-uri" parameters and to make 818 sure that the new value differs. A proxy MAY hint to a UA at a 819 preference as to which URI to use by including the more preferred URI 820 higher in the list than the other alternative URIs. URIs with the 821 same "alt-uri" parameter MUST use different URI schemes. A SIP or 822 SIPS URI MUST be included even if other URI schemes are defined and 823 used in the future. 825 If a local policy server URI is present in a Policy-Id header field 826 value of a request, then the proxy MUST NOT reject the request as 827 described above (it can still reject the request for other reasons). 828 The proxy SHOULD remove the Policy-Id header field value of its 829 associated policy server from the Policy-Id header field before 830 forwarding the request. Not removing the Policy-Id header field 831 value will not cause harm, however, the value is not relevant to any 832 other proxy on the path and only increases message size. It also 833 would disclose the policy server URI to subsequent proxies. 835 The Policy-Id header field serves two main purposes: first and most 836 importantly, it enables the proxy to determine if a UAC already knows 837 the URI of the local policy server. The second purpose of the 838 Policy-Id header field is to enable a domain to route all requests 839 that belong to the same session (i.e., the initial request and 840 requests a UA retransmits after contacting the policy server) to the 841 same proxy and policy server. This is important if a domain has 842 multiple proxy/policy server combinations (e.g., in a proxy/policy 843 server farm that receives requests through a load balancer), which 844 create per-session state in the network. An example for such a 845 scenario is a policy server that is associated with a session border 846 device. The policy server configures the session border device after 847 receiving a session description from the UAC via the policy channel. 848 Retransmitted requests for such a session need to be routed to the 849 same proxy/policy server as the initial request since this proxy/ 850 policy server combination has configured the associated border device 851 for the session. 853 Routing all requests that belong to the same session to the same 854 proxy can be achieved by using the Policy-Id header field token. It 855 requires that the policy server returns a token to the UAC that 856 uniquely identifies the specific proxy/policy server combination. 857 The UAC includes this token in the Policy-Id header field and it can 858 be used (together with the policy server URI) by the proxies in this 859 domain to route the request along the desired path. The format of 860 this token does not require standardization. The only requirement is 861 that the token provides sufficient information for proxies to route 862 the message inside a domain to the desired proxy/policy server. The 863 token can, for example, be a numeric identifier or an IP address. 865 Note: it has been proposed to use the Policy-Id header field to 866 provide a hint for a proxy that the UAC has actually contacted the 867 policy server. This usage also requires the policy server to 868 return a token to the UA. In addition, the policy server needs to 869 share valid tokens with the proxy. After receiving a request with 870 a Policy-Id header field, the proxy can determine if the token in 871 the Policy-Id header field is valid. If it is valid, the proxy 872 knows that the UA has contacted the policy server for this 873 session. However, this token does not provide any proof that the 874 UA has actually used the policies it has received from the policy 875 server. A malicious UA can simply contact the policy server, 876 discard all policies it receives but still use the token in the 877 Policy-Id header field. 879 The proxy MAY insert a Policy-Contact header field into INVITE, 880 UPDATE or PRACK requests (or any other request that can initiate an 881 offer/answer exchange) in order to convey the policy server URI to 882 the UAS. If the request already contains a Policy-Contact header 883 field, the proxy MUST insert the URI after all existing values at the 884 end of the list. A proxy MUST NOT change the order of existing 885 Policy-Contact header field values. 887 A proxy MUST use the Record-Route mechanism [RFC3261] if its 888 associated policy server has session policies that apply to mid- 889 dialog requests. The Record-Route header field enables a proxy to 890 stay in the signaling path and re-submit the policy server URIs to 891 UAs during mid-dialog requests that initiate an offer/answer 892 exchange. Re-submitting the policy server URI to UAs ensures that 893 UAs keep contacting the policy server for mid-dialog requests. 895 A proxy can find out if the UAS supports this extension by examining 896 the Supported header field of responses. The proxy knows that the 897 UAS supports this extension if the Supported header field of a 898 response contains the option tag "policy". A proxy can use this 899 information to determine if the UAS has understood the Policy-Contact 900 header field it has inserted into the request. 902 To protect the integrity of the policy server URI in a Policy-Contact 903 header field, the proxy SHOULD use a secured transport protocol such 904 as TLS [RFC5246] between proxy and UAs. 906 4.4.3. UAS Behavior 908 A UAS can receive an INVITE, UPDATE or PRACK request (or another 909 request that can initiate offer/answer exchanges) that contains a 910 Policy-Contact header field with a list of policy server URIs. A UAS 911 that receives such a request needs to decide if it wants to accept 912 the session knowing that there are policy servers involved. If the 913 Policy-Contact header contains multiple URIs each with a different 914 URI scheme and containing an "alt-uri" parameter with identical 915 values these URI schemes represent alternative policy channel 916 mechanisms for obtaining the same policy. If the UAS accepts the 917 session, the UAS MUST contact one URI out of each group of URIs with 918 identical "alt-uri" parameter values to obtain the policy. The UAS 919 MAY take as a hint the order of the alternative URIs as indicating a 920 preference as to which URI to use. The topmost URI in the list might 921 be more preferred by the domain of the proxy for use to obtain the 922 policy. The UAS MUST contact all policy server URIs in a Policy- 923 Contact header field that are not part of a group of alternative URIs 924 and MUST contact one URI in each group of alternative URIs. The UAS 925 MUST contact these policy server URIs in the order in which they were 926 contained in the Policy-Contact header field, starting with the 927 topmost value (i.e., the value that was inserted first). 929 If a UAS decides that it does not want to accept a session because 930 there are policy servers involved or because one of the session 931 policies received from a policy server is not acceptable, the UAS 932 MUST reject the request with a 488 (Not Acceptable Here) response. 934 The UAS MAY accept a request and continue with setting up a session 935 if it cannot setup a policy channel to the policy server, for 936 example, because the policy server is unreachable or returns an error 937 condition that cannot be resolved by the UAS (i.e., error conditions 938 other than, for example, a 401 (Unauthorized) response). This is to 939 avoid that the failure of a policy server prevents a UA from 940 communicating. Since this session might not be policy compliant 941 without the policy subscription, it can be blocked by policy 942 enforcement mechanisms if they are in place. 944 A UAS can receive a token from a policy server via the policy 945 channel. Since the UAS does not create a Policy-ID header field, it 946 can simply ignore this token. 948 A UAS compliant to this specification MUST include a Supported header 949 field with the option tag "policy" into responses to requests that 950 can initiate an offer/answer exchange. The UAS MAY include this 951 option tag in all responses. This way, a proxy that has inserted the 952 Policy-Contact header field can know that the header field was 953 understood by the UAS. 955 4.4.4. Caching the Local Policy Server URI 957 A UAC frequently needs to contact the policy server in the local 958 domain before setting up a session. To avoid the retransmission of 959 the local policy server URI for each session, a UA SHOULD maintain a 960 cache that contains the URI of the local policy server. 962 A UA can receive this URI in a Policy-Contact header field of a 963 request or a 488 (Not Acceptable Here) response. The UA can also 964 receive the local policy server URI through configuration, for 965 example, via the configuration framework 966 [I-D.ietf-sipping-config-framework]. If a UA has received a local 967 policy server URI through configuration and receives another local 968 policy server URI in a Policy-Contact header field, the UA SHOULD 969 overwrite the configured URI with the most recent one received in a 970 Policy-Contact header field. A policy server URI received in a 971 Policy-Contact header field expires if it has not been refreshed 972 before it reaches the maximum cached URI validity. The default 973 maximum cached URI validity is 24 hours. 975 Domains can prevent a UA from caching the local policy server URI. 976 This is useful, for example, if the policy server does not need to be 977 involved in all sessions or the policy server URI changes from 978 session to session. A proxy can mark the URI of such a policy server 979 as "non-cacheable". A UA MUST NOT cache a non-cacheable policy 980 server URI. The UA SHOULD remove the current URI from the cache when 981 receiving a local policy server URI that is marked as "non- 982 cacheable". This is to avoid the use of policy server URIs that are 983 outdated. 985 The UA SHOULD NOT cache policy server URIs it has received from 986 proxies outside of the local domain. These policy servers need not 987 be relevant for subsequent sessions, which can go to a different 988 destination, traversing different domains. 990 The UA MUST NOT cache tokens it has received from a policy server. A 991 token is only valid for one request. 993 4.4.5. Header Field Definition and Syntax 995 4.4.5.1. Policy-Id Header Field 997 The Policy-Id header field is inserted by the UAC into INVITE, UPDATE 998 or PRACK requests (or any other request that can be used to initiate 999 an offer/answer exchange). The Policy-Id header field identifies all 1000 policy servers the UAC has contacted for this request. 1002 The value of a Policy-Id header field consists of a policy server URI 1003 and an optional token parameter. The token parameter contains a 1004 token the UA might have received from the policy server. 1006 The syntax of the Policy-Id header field is described below in ABNF, 1007 according to RFC5234 [RFC5234], as an extension to the ABNF for SIP 1008 in RFC3261 [RFC3261]: 1010 Policy-Id = "Policy-Id" HCOLON policyURI 1011 *(COMMA policyURI) 1012 policyURI = ( SIP-URI / SIPS-URI / absoluteURI ) 1013 [ SEMI token-param ] *( SEMI generic-param ) 1014 token-param = "token=" token 1016 4.4.5.2. Policy-Contact Header Field 1018 The Policy-Contact header field can be inserted by a proxy into a 488 1019 (Not Acceptable Here) response to INVITE, UPDATE or PRACK requests 1020 (or other requests that initiate an offer/answer exchange). The 1021 value of a Policy-Contact header field consists of a policy server 1022 URI and an optional "non-cacheable" header field parameter. The 1023 policy server URI identifies the policy server that needs to be 1024 contacted by a UAC. The "non-cacheable" header field parameter 1025 indicates that the policy server URI is not intended to be cached by 1026 the UAC. 1028 The Policy-Contact header field can also be inserted by a proxy into 1029 INVITE, UPDATE and PRACK requests (or other requests that can be used 1030 to initiate an offer/answer exchange). It contains an ordered list 1031 of policy server URIs that need to be contacted by the UAS. The 1032 topmost value of this list identifies the policy server that is 1033 contacted first. New header field values are inserted at the end. 1034 With this, the Policy-Contact header field effectively forms a fist- 1035 in-first-out queue. 1037 The syntax of the Policy-Contact header field is described below in 1038 ABNF, according to RFC5234 [RFC5234], as an extension to the ABNF for 1039 SIP in RFC3261 [RFC3261]: 1041 Policy-Contact = "Policy-Contact" HCOLON 1042 policyContact-info *(COMMA policyContact-info) 1044 policyContact-info = LAQUOT policyContact-uri RAQUOT 1045 *( SEMI policyContact-param ) 1047 policyContact-uri = ( SIP-URI / SIPS-URI / absoluteURI ) 1049 policyContact-param = ( "non-cacheable" / policyContact-alt-uri 1050 / generic-param ) 1052 policyContact-alt-uri = "alt-uri" EQUAL hostname 1054 Tables 1 and 2 are extensions of Tables 2 and 3 in RFC 3261 1056 [RFC3261]. The column "INF" is for the INFO method [RFC2976], "PRA" 1057 is for the PRACK method [RFC3262], "UPD" is for the UPDATE method 1058 [RFC3311], "SUB" is for the SUBSCRIBE method [RFC3265], "NOT" is for 1059 the NOTIFY method [RFC3265], "MSG" is for the MESSAGE method 1060 [RFC3428], "REF" is for the REFER method [RFC3515], and "PUB" is for 1061 the PUBLISH method [RFC3903]. 1063 Header field where proxy ACK BYE CAN INV OPT REG UPD 1064 _______________________________________________________________ 1065 Policy-Id R rd - - - c - - c 1066 Policy-Contact R a - - - c - - c 1067 Policy-Contact 488 a - - - c - - c 1068 Table 1: Policy-Id and Policy-Contact Header Fields 1070 Header field where proxy PRA PUB SUB NOT INF MSG REF 1071 _______________________________________________________________ 1072 Policy-Id R rd c - - - - - - 1073 Policy-Contact R a c - - - - - - 1074 Policy-Contact 488 a c - - - - - - 1075 Table 1: Policy-Id and Policy-Contact Header Fields 1077 4.5. Policy Channel 1079 The main task of the policy channel is to enable a UA to submit 1080 information about the session it is trying to establish (i.e., the 1081 offer and the answer) to a policy server and to receive the resulting 1082 session-specific policies and possible updates to these policies in 1083 response. 1085 The Event Package for Session-Specific Session Policies 1086 [I-D.ietf-sipping-policy-package] defines a SUBSCRIBE/NOTIFY-based 1087 [RFC3265] policy channel mechanism. A UA compliant to this 1088 specification MUST support the Event Package for Session-Specific 1089 Session Policies [I-D.ietf-sipping-policy-package]. The UA MUST use 1090 this event package to contact a policy server if the policy server 1091 URI is a SIP-URI or SIPS-URI. A UA MAY support other policy channel 1092 mechanisms. 1094 4.5.1. Creation and Management 1096 A UA discovers the list of policy servers relevant for a session 1097 during the initial offer/answer exchange (see Section 4.4). A UA 1098 compliant to this specification MUST set up a policy channel to each 1099 of the discovered policy server. If the UA does not want to set up a 1100 policy channel to one of the policy servers provided, the UA MUST 1101 cancel or reject a pending INVITE transaction for the session or 1102 terminate the session if it is already in progress. 1104 A UA MUST maintain the policy channel to each discovered policy 1105 server during the lifetime of a session, unless the policy channel is 1106 closed by the policy server or the UA discovers that the policy 1107 server is no longer relevant for the session as described below. 1109 A UAC can receive a 488 (Not Acceptable Here) response with a Policy- 1110 Contact header field containing a new policy server URI in response 1111 to a mid-dialog request. This indicates that the set of policy 1112 servers relevant for the current session has changed. If this 1113 occurs, the UAC MUST retry sending the request as if it was the first 1114 request in a dialog (i.e., without applying any policies except the 1115 policies from the local policy server). This way, the UAC will re- 1116 discover the list of policy servers for the current session. This is 1117 necessary since the UAC has no other way of knowing when to contact 1118 the newly discovered policy server relative to the existing policy 1119 servers and if any of the existing policy servers does not need to be 1120 contacted any more. The UAC MUST set up a policy channel to each new 1121 policy server. The UAC SHOULD close policy channels to policy server 1122 that are not listed any more. If the policy channel to these servers 1123 is not closed, the UAC can receive policies that do not apply to the 1124 session any more. The UAC MUST contact policy servers in the order 1125 in which they were discovered in the most recent request. 1127 If a UAS receives a mid-dialog request with a Policy-Contact header 1128 field containing a list of policy server URIs that is different from 1129 the list of policy servers to which the UAS has currently established 1130 a policy channel, then the UAS MUST set up a policy channel to all 1131 new policy servers and contact them. The UAS SHOULD close policy 1132 channels to servers that are not listed any more. If the policy 1133 channel to these servers is not closed, the UAS can receive policies 1134 that do not apply to the session any more. The UAS MUST use policy 1135 servers in the order in which they were contained in the most recent 1136 Policy-Contact header field. 1138 A UA MUST inform the policy server when a session is terminated 1139 (e.g., when the UA has either sent or received a BYE) via the policy 1140 channel, unless a policy server indicates via the policy channel that 1141 it does not need to be contacted at the end of the session. This 1142 enables a policy server to free all resources it has allocated for 1143 this session. 1145 4.5.2. Contacting the Policy Server 1147 A UA MUST contact all policy servers to which it has established a 1148 policy channel before sending or after receiving a mid-dialog 1149 request. The UA MUST contact the policy servers in the order in 1150 which they were discovered most recently. 1152 A UA that receives a SIP message containing an offer or answer SHOULD 1153 completely process the message (e.g., according to RFC3261 [RFC3261]) 1154 before contacting the policy server. The SIP processing of the 1155 message includes, for example, updating dialog state and timers as 1156 well as creating ACK or PRACK requests as necessary. This ensures 1157 that contacting a policy server does not interfere with SIP message 1158 processing and timing (e.g., by inadvertently causing timers to 1159 expire). This implies, for example, that a UAC which has received a 1160 response to an INVITE request would normally finish the processing of 1161 the response including transmitting the ACK request before it 1162 contacts the policy server. An important exception to this rule is 1163 discussed in the next paragraph. 1165 In some cases, a UA needs to use the offer/answer it has received in 1166 a SIP message to create an ACK or PRACK request for this message, 1167 i.e., it needs to use the offer/answer before finishing the SIP 1168 machinery for this message. For example, a UAC that has received an 1169 offer in the response to an INVITE request needs to apply policies to 1170 the offer and the answer before it can send the answer in an ACK 1171 request. In these cases, a UA SHOULD contact the policy server even 1172 if this is during the processing of a SIP message. This implies that 1173 a UA, which has received an offer in the response of an INVITE 1174 request, would normally contact the policy server and apply session 1175 policies before sending the answer in the ACK request. 1177 Note: this assumes that the policy server can always respond 1178 immediately to a policy request and does not require manual 1179 intervention to create a policy. This will be the case for most 1180 policy servers. If, however, a policy server cannot respond with 1181 a policy right away, it can return a policy that temporarily 1182 denies the session and update this policy as the actual policy 1183 decision becomes available. A delay in the response from the 1184 policy server to the UA would delay the transmission of the ACK 1185 request and could trigger retransmissions of the INVITE response 1186 (also see the recommendations for Flow I in RFC3725 [RFC3725]). 1188 The case of multiple policy servers providing policies to the same UA 1189 requires additional considerations. A policy returned by one policy 1190 server can contain information that needs to be shared with the other 1191 policy servers. For example, two policy servers can have the policy 1192 to insert a media intermediary by modifying the IP addresses and 1193 ports of media streams. In order for media streams to pass through 1194 both intermediaries, each intermediary needs to know the IP address 1195 and port on which the other media intermediary is expecting the 1196 stream to arrive. If media streams are flowing in both directions, 1197 this means that each intermediary needs to know IP addresses and 1198 ports of the other intermediary. 1200 UACs usually contact a policy server twice during an offer/answer 1201 exchange (unless a policy server indicates that it only needs to be 1202 contacted once). Therefore the case of multiple policy servers 1203 providing policies to a single UAC does not require additional steps 1204 in most cases. However, a UAS usually contacts each policy server 1205 only once (see Figure 4). If a session policy returned by one of the 1206 policy servers requires that information is shared between multiple 1207 servers and the UAS receives policies from more than one policy 1208 server, then the UAS MUST contact all policy servers a second time 1209 after contacting all servers the first time. Whether or not a second 1210 round is required is determined by the type of information returned 1211 by the policy server. A data format for session policies (e.g., 1212 [I-D.ietf-sipping-media-policy-dataset]) needs to explicitly state if 1213 a second round is needed for a particular data element. If a UA 1214 receives such an element, it knows that is expected to contact policy 1215 servers a second time. If such a data element is modified during a 1216 mid-call offer/answer exchange and multiple policy servers are 1217 providing policies to a UA then all UAs MUST contact policy servers 1218 in a first and second round. An example call flow is shown in 1219 Appendix B.3. 1221 A UA that supports session-specific policies compliant to this 1222 specification MUST support the User Agent Profile Data Set for Media 1223 Policy [I-D.ietf-sipping-media-policy-dataset] as data format for 1224 session policies. 1226 4.5.3. Using Session Policies 1228 A UA MUST disclose the session description(s) for the current session 1229 to policy servers through the policy channel. The UA MUST apply 1230 session policies it receives to the offer and, if one is received, to 1231 the answer before using the offer/answer. If these policies are 1232 unacceptable, the UA MUST NOT continue with the session. This means 1233 that, the UA MUST cancel or reject a pending INVITE transaction for 1234 the session or terminate the session if it is already in progress. 1235 If the UA receives an unacceptable policy in an INVITE response, the 1236 UA MUST complete the INVITE transaction and then terminate the 1237 session. 1239 When a UA receives a notification about a change in the current 1240 policies, the UA MUST apply the updated policies to the current 1241 session or the UA MUST terminate the session. If the policy update 1242 causes a change in the session description of a session, then the UA 1243 needs to re-negotiate the modified session description with its peer 1244 UA, for example, using a re-INVITE or UPDATE request. For example, 1245 if a policy update disallows the use of video and video is part of 1246 the current session description, then the UA will need to create an 1247 new session description offer without video. After receiving this 1248 offer, the peer UA knows that video can't be used any more and 1249 responds with the corresponding answer. 1251 5. Security Considerations 1253 Policy enforcement mechanisms can prevent a UA from communicating 1254 with another UA if the UAs are not aware of the policies that are 1255 enforced. Policy enforcement mechanisms without policy signaling can 1256 therefore create a denial of service condition for UAs. This 1257 specification provides a mechanism for intermediaries to signal the 1258 policies that are enforced to UAs. It enables UAs to establish 1259 sessions that are conform and pass through policy enforcement. 1261 Session policies can significantly change the behavior of a UA and 1262 can be used by an attacker to compromise a UA. For example, session 1263 policies can be used to prevent a UA from successfully establishing a 1264 session (e.g., by setting the available bandwidth to zero). Such a 1265 policy can be submitted to the UA during a session, which causes the 1266 UA to terminate the session. 1268 A UA transmits session information to a policy server for session- 1269 specific policies. This session information can contain sensitive 1270 data the user does not want an eavesdropper or an unauthorized policy 1271 server to see. Vice versa, session policies can contain sensitive 1272 information about the network or service level agreements the service 1273 provider does not want to disclose to an eavesdropper or an 1274 unauthorized UA. 1276 It is important to secure the communication between the proxy and the 1277 UA (for session-specific policies) as well as the UA and the policy 1278 server. The following four discrete attributes need to be protected: 1280 1. integrity of the policy server URI (for session-specific 1281 policies), 1282 2. authentication of the policy server and, if needed, the user 1283 agent, 1284 3. confidentiality of the messages exchanged between the user agent 1285 and the policy server and 1286 4. ensuring that private information is not exchanged between the 1287 two parties, even over an confidentiality-assured and 1288 authenticated session. 1290 To protect the integrity of the policy server URI, a UA SHOULD use a 1291 secured transport protocol such as TLS [RFC5246] between proxies and 1292 the UA. Protecting the integrity of the policy server URI is 1293 important since an attacker could intercept SIP messages between the 1294 UA and the proxy and remove the policy header fields needed for 1295 session-specific policies. This would impede the rendezvous between 1296 UA and policy server and, since the UA would not contact the policy 1297 server, can prevent a UA from setting up a session. 1299 Instead of removing a policy server URI, an attacker can also modify 1300 the policy server URI and point the UA to a compromised policy 1301 server. It is RECOMMENDED that a UA authenticates policy servers to 1302 prevent such an attack from being effective. 1304 It is RECOMMENDED that the UA only accepts session-independent 1305 policies from trustworthy policy servers as these policies affect all 1306 sessions of a UA. A list of trustworthy session-independent policy 1307 servers can be provided to the UA through configuration. As SIP 1308 messages can be affected by any proxy on a path and session-specific 1309 policies only apply to a single session, a UA MAY choose to accept 1310 session-specific policies from other policy servers as well. 1312 Policy servers SHOULD authenticate UAs to protect the information 1313 that is contained in a session policy. However, a policy server can 1314 also frequently encounter UAs it cannot authenticate. In these 1315 cases, the policy server MAY provide a generic policy that does not 1316 reveal sensitive information to these UAs. 1318 It is RECOMMENDED that administrators use SIPS URIs as policy server 1319 URIs so that subscriptions to session policies are transmitted over 1320 TLS. 1322 The above security attributes are important to protect the 1323 communication between the UA and policy server. This document does 1324 not define the protocol used for the communication between UA and 1325 policy server and merely refers to other specifications for this 1326 purpose. The security considerations of these specifications need to 1327 address the above security aspects. 1329 6. IANA Considerations 1331 6.1. Registration of the "Policy-Id" Header Field 1333 Name of Header Field: Policy-Id 1335 Short form: none 1337 Normative description: Section 4.4.5 of this document 1339 6.2. Registration of the "Policy-Contact" Header Field 1341 Name of Header Field: Policy-Contact 1343 Short form: none 1345 Normative description: Section 4.4.5 of this document 1347 6.3. Registration of the "non-cacheable" Policy-Contact Header Field 1348 Parameter 1350 Registry Name: Header Field Parameters and Parameter Values 1351 Reference: RFC3968 [RFC3968] 1353 Registry: 1355 Header Field Parameter Name Predefined Reference 1356 Values 1357 _____________________________________________________________________ 1358 Policy-Contact non-cacheable Yes this document 1360 6.4. Registration of the "policy" SIP Option-Tag 1362 This specification registers a new SIP option tag, as per the 1363 guidelines in Section 27.1 of RFC3261 [RFC3261]. 1365 This document defines the SIP option tag "policy". 1367 The following row has been added to the "Option Tags" section of the 1368 SIP Parameter Registry: 1370 +------------+------------------------------------------+-----------+ 1371 | Name | Description | Reference | 1372 +------------+------------------------------------------+-----------+ 1373 | policy | This option tag is used to indicate that | this | 1374 | | a UA can process policy server URIs for | document | 1375 | | and subscribe to session-specific | | 1376 | | policies. | | 1377 +------------+------------------------------------------+-----------+ 1379 Name of option: policy 1381 Description: Support for the Policy-Contact and Policy-Id header 1382 fields. 1384 SIP header fields defined: Policy-Contact, Policy-Id 1385 Normative description: This document 1387 7. References 1389 7.1. Normative References 1391 [I-D.ietf-sipping-config-framework] 1392 Channabasappa, S., "A Framework for Session Initiation 1393 Protocol User Agent Profile Delivery", 1394 draft-ietf-sipping-config-framework-18 (work in progress), 1395 October 2010. 1397 [I-D.ietf-sipping-media-policy-dataset] 1398 Hilt, V., Worley, D., Camarillo, G., and J. Rosenberg, "A 1399 User Agent Profile Data Set for Media Policy", 1400 draft-ietf-sipping-media-policy-dataset-11 (work in 1401 progress), February 2011. 1403 [I-D.ietf-sipping-policy-package] 1404 Hilt, V. and G. Camarillo, "A Session Initiation Protocol 1405 (SIP) Event Package for Session-Specific Session 1406 Policies.", draft-ietf-sipping-policy-package-08 (work in 1407 progress), March 2010. 1409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1410 Requirement Levels", BCP 14, RFC 2119, March 1997. 1412 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1413 A., Peterson, J., Sparks, R., Handley, M., and E. 1414 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1415 June 2002. 1417 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1418 Provisional Responses in Session Initiation Protocol 1419 (SIP)", RFC 3262, June 2002. 1421 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1422 with Session Description Protocol (SDP)", RFC 3264, 1423 June 2002. 1425 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1426 Event Notification", RFC 3265, June 2002. 1428 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1429 UPDATE Method", RFC 3311, October 2002. 1431 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1432 (IANA) Header Field Parameter Registry for the Session 1433 Initiation Protocol (SIP)", BCP 98, RFC 3968, 1434 December 2004. 1436 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1437 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1439 7.2. Informative References 1441 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1442 October 2000. 1444 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1445 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1446 for Instant Messaging", RFC 3428, December 2002. 1448 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1449 Method", RFC 3515, April 2003. 1451 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1452 Camarillo, "Best Current Practices for Third Party Call 1453 Control (3pcc) in the Session Initiation Protocol (SIP)", 1454 BCP 85, RFC 3725, April 2004. 1456 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1457 for Event State Publication", RFC 3903, October 2004. 1459 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1460 Resource Identifier (URI): Generic Syntax", STD 66, 1461 RFC 3986, January 2005. 1463 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1464 Description Protocol", RFC 4566, July 2006. 1466 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1467 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1469 Appendix A. Acknowledgements 1471 Many thanks to Allison Mankin, Andrew Allen, Cullen Jennings and 1472 Vijay Gurbani for their contributions to this draft. Many thanks to 1473 Roni Even, Bob Penfield, Mary Barnes, Shida Schubert, Keith Drage, 1474 Lisa Dusseault, Tim Polk and Pasi Eronen for their reviews and 1475 suggestions. 1477 Appendix B. Session-Specific Policies - Call Flows 1479 The following call flows illustrate the overall operation of session- 1480 specific policies including the policy channel protocol as defined in 1481 the SIP Event Package for Session-Specific Session Policies 1482 [I-D.ietf-sipping-policy-package]. 1484 The following abbreviations are used: 1486 o: offer 1487 o': offer modified by a policy 1488 po: offer policy 1489 a: answer 1490 a': answer modified by a policy 1491 pa: answer policy 1492 ps uri: policy server URI (in Policy-Contact header field) 1493 ps id: policy server id (in Policy-Id header field) 1495 B.1. Offer in Invite 1496 UA A P A PS A PS B P B UA B 1497 | | | | | | 1498 |(1) INV | | | | 1499 |-------->| | | | | 1500 |(2) 488 | | | | 1501 |<--------| | | | | 1502 |(3) ACK | | | | | 1503 |-------->| | | | | 1504 |(4) SUBSCRIBE | | | | 1505 |------------------>| | | | 1506 |(5) 200 OK | | | | 1507 |<------------------| | | | 1508 |(6) NOTIFY | | | | 1509 |<------------------| | | | 1510 |(7) 200 OK | | | | 1511 |------------------>| | | | 1512 |(8) INV | | | | 1513 |-------->| | | | | 1514 | |(9) INV | | | 1515 | |---------------------------->| | 1516 | | | | |(10) INV 1517 | | | | |-------->| 1518 | | | |(11) SUBSCRIBE 1519 | | | |<------------------| 1520 | | | |(12) 200 OK | 1521 | | | |------------------>| 1522 | | | |(13) NOTIFY 1523 | | | |------------------>| 1524 | | | |(14) 200 OK | 1525 | | | |<------------------| 1526 | | | | |(15) 200 OK 1527 | | | | |<--------| 1528 | |(16) 200 OK | | | 1529 | |<----------------------------| | 1530 |(17) 200 OK | | | | 1531 |<--------| | | | | 1532 |(18) ACK | | | | | 1533 |------------------------------------------------>| 1534 |(19) SUBSCRIBE | | | 1535 |------------------>| | | | 1536 |(20) 200 OK | | | | 1537 |<------------------| | | | 1538 |(21) NOTIFY | | | 1539 |<------------------| | | | 1540 |(22) 200 OK | | | | 1541 |------------------>| | | | 1542 | | | | | | 1543 | | | | | | 1545 B.2. Offer in Response 1547 UA A P A PS A PS B P B UA B 1548 | | | | | | 1549 |(1) INV | | | | | 1550 |-------->| | | | | 1551 |(2) 488 | | | | 1552 |<--------| | | | | 1553 |(3) ACK | | | | | 1554 |-------->| | | | | 1555 |(4) SUBSCRIBE | | | | 1556 |------------------>| | | | 1557 |(5) 200 OK | | | | 1558 |<------------------| | | | 1559 |(6) NOTIFY | | | | 1560 |<------------------| | | | 1561 |(7) 200 OK | | | | 1562 |------------------>| | | | 1563 |(8) INV | | | | 1564 |-------->| | | | | 1565 | |(9) INV | | | | 1566 | |---------------------------->| | 1567 | | | | |(10) INV 1568 | | | | |-------->| 1569 | | | |(11) SUBSCRIBE | 1570 | | | |<------------------| 1571 | | | |(12) 200 OK | 1572 | | | |------------------>| 1573 | | | |(13) NOTIFY | 1574 | | | |------------------>| 1575 | | | |(14) 200 OK | 1576 | | | |<------------------| 1577 | | | | |(15) 200 OK 1578 | | | | |<--------| 1579 | |(16) 200 OK | | | 1580 | |<----------------------------| | 1581 |(17) 200 OK | | | | 1582 |<--------| | | | | 1583 |(18) SUBSCRIBE | | | 1584 |------------------>| | | | 1585 |(19) 200 OK | | | | 1586 |<------------------| | | | 1587 |(20) NOTIFY | | | 1588 |<------------------| | | | 1589 |(21) 200 OK | | | | 1590 |------------------>| | | | 1591 |(22) ACK | | | | 1592 |------------------------------------------------>| 1593 | | | |(23) SUBSCRIBE 1594 | | | |<------------------| 1595 | | | |(24) 200 OK | 1596 | | | |------------------>| 1597 | | | |(25) NOTIFY 1598 | | | |------------------>| 1599 | | | |(26) 200 OK | 1600 | | | |<------------------| 1601 | | | | | | 1602 | | | | | | 1604 B.3. Multiple Policy Servers for UAS 1606 UA A P A PS A PS B P B UA B 1607 | | | | | | 1608 | | | | | | 1609 | | | | | | 1610 |(1) INV | | | | 1611 |-------->| | | | | 1612 | |(2) INV | | 1613 | |---------------------------->| | 1614 | | | | |(3) INV 1615 | | | | |-------->| 1616 | | |(4) SUBSCRIBE | 1617 | | |<----------------------------| 1618 | | |(5) 200 OK | | 1619 | | |---------------------------->| 1620 | | |(6) NOTIFY | | 1621 | | |---------------------------->| 1622 | | |(7) 200 OK | | 1623 | | |<----------------------------| 1624 | | | |(8) SUBSCRIBE 1625 | | | |<------------------| 1626 | | | |(9) 200 OK | 1627 | | | |------------------>| 1628 | | | |(10) NOTIFY 1629 | | | |------------------>| 1630 | | | |(11) 200 OK | 1631 | | | |<------------------| 1632 | | |(12) SUBSCRIBE | 1633 | | |<----------------------------| 1634 | | |(13) 200 OK | | 1635 | | |---------------------------->| 1636 | | |(14) NOTIFY | 1637 | | |---------------------------->| 1638 | | |(15) 200 OK | | 1639 | | |<----------------------------| 1640 | | | |(16) SUBSCRIBE 1641 | | | |<------------------| 1642 | | | |(17) 200 OK | 1643 | | | |------------------>| 1644 | | | |(18) NOTIFY 1645 | | | |------------------>| 1646 | | | |(19) 200 OK | 1647 | | | |<------------------| 1648 | | | | |(20) 200 OK 1649 | | | | |<--------| 1650 | |(21) 200 OK | | | 1651 | |<----------------------------| | 1652 |(22) 200 OK | | | | 1653 |<--------| | | | | 1654 |(23) ACK | | | | | 1655 |------------------------------------------------>| 1656 | | | | | | 1657 | | | | | | 1659 Authors' Addresses 1661 Volker Hilt 1662 Bell Labs/Alcatel-Lucent 1663 791 Holmdel-Keyport Rd 1664 Holmdel, NJ 07733 1665 USA 1667 Email: volkerh@bell-labs.com 1669 Gonzalo Camarillo 1670 Ericsson 1671 Hirsalantie 11 1672 Jorvas 02420 1673 Finland 1675 Email: Gonzalo.Camarillo@ericsson.com 1677 Jonathan Rosenberg 1678 jdrosen.net 1679 Monmouth, NJ 1680 USA 1682 Email: jdrosen@jdrosen.net