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