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