idnits 2.17.1 draft-ietf-sipping-session-policy-framework-01.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 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1096. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1103. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1109. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 769 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2006) is 6510 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 (-08) exists of draft-ietf-sipping-policy-package-01 == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-01 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-08 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-03 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: December 25, 2006 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 June 23, 2006 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sipping-session-policy-framework-01 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 December 25, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Proxy servers play a central role as an intermediary in the Session 45 Initiation Protocol (SIP) as they define and impact policies on call 46 routing, rendezvous, and other call features. However, there is 47 currently no standard mechanism by which a proxy can define or 48 influence policies on sessions such as the codecs or media types to 49 be used. This document specifies a framework for SIP session 50 policies that provides this capability to proxies. It defines a 51 model, an overall architecture and the protocol components for 52 session policies. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5 59 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5 60 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6 61 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7 62 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 10 66 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 12 67 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 13 68 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13 69 4.4.2. Caching of Policy Server URIs . . . . . . . . . . . . 14 70 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 15 71 4.4.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 72 4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 16 73 4.5. Policy Subscription . . . . . . . . . . . . . . . . . . . 17 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 19 77 6.2. Registration of the "Policy-Contact" Header . . . . . . . 19 78 6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 19 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 80 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 19 81 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 20 82 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 22 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 Intellectual Property and Copyright Statements . . . . . . . . . . 26 89 1. Introduction 91 The Session Initiation Protocol (SIP) [6] is a signaling protocol for 92 creating, modifying and terminating multimedia sessions. A central 93 element in SIP is the proxy server. Proxy servers are intermediaries 94 that are responsible for request routing, rendezvous, authentication 95 and authorization, mobility, and other signaling services. However, 96 proxies are divorced from the actual sessions - audio, video, and 97 messaging - that SIP establishes. Details of the sessions are 98 carried in the payload of SIP messages, and are usually described 99 with the Session Description Protocol (SDP) [7]. Indeed, SIP 100 provides end-to-end encryption features using S/MIME, so that all 101 information about the sessions can be hidden from eavesdroppers and 102 proxies alike. 104 However, experience has shown that there is a need for SIP 105 intermediaries to impact aspects of a session. For example, SIP may 106 be used in a wireless network, which has limited resources for media 107 traffic. During periods of high activity, the wireless network 108 provider wants to restrict the amount of bandwidth available to each 109 individual user. With session policies, an intermediary in the 110 wireless network can inform the user agent about the bandwidth it can 111 currently count on. This information enables the user agent to make 112 an informed decision about the number of streams, the media types, 113 and the codecs it can successfully use in a session. Similarly, a 114 network provider may have a service level agreement with a user that 115 defines the set of media types a user can use. With session 116 policies, the network can convey the current set of policies to user 117 agents, enabling them to set up sessions without inadvertently 118 violating any of the network policies. 120 In another example, a SIP user agent is using a network which is 121 connected to the public Internet through a firewall or a network 122 border device. The network provider would like to tell the user 123 agent that it needs to send its media streams to a specific IP 124 address and port on the firewall or border device to reach the public 125 Internet. Knowing this policy enables the user agent to set up 126 sessions across the firewall or the network border. In contrast to 127 other methods for inserting a media intermediary, the use of session 128 policies does not require the inspection or modification of SIP 129 message bodies. 131 Domains often enforce the session policies they have in place. For 132 example, a domain might have a policy that disallows the use of video 133 and may enforce this policy by dropping all packets that contain a 134 video encoding. Unfortunately, enforcement mechanisms usually do not 135 inform the user about the policies they are enforcing. Instead, they 136 silently keep the user from doing anything against them. This may 137 lead to a malfunctioning of devices that is incomprehensible to the 138 user. With session policies, the user knows about the current 139 network policies and can set up policy-compliant sessions or simply 140 connect to a domain with less stringent policies. Thus, session 141 policies provide an important combination of consent coupled with 142 enforcement. That is, the user becomes aware of the policy and needs 143 to act on it, but the provider still retains the right to enforce the 144 policy. 146 Two types of session policies exist: session-specific policies and 147 session-independent policies. Session-specific policies are policies 148 that are created for one particular session, based on the session 149 description of this session. They enable a network intermediary to 150 examine the session description a UA is proposing and to return a 151 policy specifically for this session description. For example, an 152 intermediary could open pinholes in a firewall/NAT for each media 153 stream in a session and return a policy that replaces the internal IP 154 addresses and ports with external ones. Since session-specific 155 policies are tailored to a session, they only apply to the session 156 they are created for. Session-specific policies are created on a 157 session-by-session basis at the time the session is established. 159 Session-independent policies on the other hand are policies that are 160 created independent of a session and generally apply to the SIP 161 sessions set up by a user agent. A session-independent policy can, 162 for example, be used to inform user agents about an existing 163 bandwidth limit or media type restrictions. Since these policies are 164 not based on a specific session description, they can be created 165 independent of an attempt to set up a session and only need to be 166 conveyed to the user agent once (e.g. at the time the device is 167 powered on). 169 This specification defines a framework for SIP session policies. It 170 specifies a model, the overall architecture, and the protocol 171 components that are needed for session-independent and session- 172 specific policies. 174 2. Terminology 176 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 177 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 178 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 179 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 180 compliant implementations. 182 3. Session-Independent Policies 184 Session-independent policies are policies that are created 185 independent of a session and generally apply to the sessions a user 186 agent is setting up. They typically remain stable for a longer 187 period of time and apply to the sessions set up while they are valid. 188 However, session-independent policies may also change over time. For 189 example, a policy that defines a bandwidth limit for a user may 190 change during the day, defining a lower limit during peak hours and 191 allow more bandwidth off-peak. 193 3.1. Architecture and Overview 195 +-------------+ 196 /------| policy | 197 +----+ / | server 1 | 198 | |---/ +-------------+ 199 | UA | ... 200 | |---\ +-------------+ 201 +----+ \ | policy | 202 \------| server n | 203 +-------------+ 205 Figure 1 207 A SIP UA may receive session-independent policies from one or more 208 policy servers. In a typical configuration, a UA receives session- 209 independent policies from a policy server in the access or local 210 network domain (i.e. the domain from which the UA receives IP 211 service) and possibly the home network domain (i.e. the domain the UA 212 registers at). The local network may, for example, have policies 213 that support the access network infrastructure (e.g. in a wireless 214 network where bandwidth is scarce, a provider may restrict the 215 bandwidth available to an individual user). The home network may 216 have policies that are needed to support services or policies that 217 reflect the service level agreement with the user. Thus, in most 218 cases, a UA will receive session-independent policies from one or at 219 most two policy servers. 221 Setting up session-independent policies involves the following steps: 223 1. A user agent requests session-independent policies from the 224 policy servers in the local network and home domain. A user 225 agent typically requests these policies when it starts up or 226 connects to a new network domain. 228 2. The policy server selects the policies that apply to this user 229 agent. The policy server may have general policies that apply to 230 all users or maintain separate policies for each individual user. 231 The selected policies are returned to the user agent. 232 3. The policy server may update the policies, for example, when 233 network conditions change. 235 3.2. Policy Subscription 237 A UA requests session-independent policies by subscribing to the 238 policy server in a domain. Subscriptions to session-independent 239 policies are established using the "ua-profile" event package defined 240 in the Framework for SIP User Agent Profile Delivery [4]. 242 The "ua-profile" event package [4] provides a mechanism to discover 243 policy servers in the local network and the home domain. The "local- 244 network" profile-type enables a UA to discover a policy server in the 245 local domain; the "user" profile type in the home domain. A UA 246 compliant to this specification SHOULD attempt to discover and 247 subscribe to the policy servers in these two domains. 249 A UA SHOULD (re-)subscribe to session-independent policies when the 250 following events occur: 252 o The UA registers a new AoR or removes a AoR from the set of AoRs 253 it has registered. In these cases, the UA SHOULD establish 254 subscriptions for each new AoR using the "user" and the "local- 255 network" profile-types. The UA SHOULD terminate all subscriptions 256 for AoRs it has removed. 257 o The UA changes the domain it is connected to. The UA SHOULD 258 terminate all existing subscriptions for the "local-network" 259 profile-type. It SHOULD then create a new subscription for each 260 AoR using the "local-network" profile-type. This way, the UA 261 stops receiving policies from the previous local domain and starts 262 to receive the policies of the new local domain. The UA does not 263 need to change the subscriptions for "user" profiles. 265 If a subscriber is unable to establish a subscription, it SHOULD NOT 266 attempt to re-try this subscription, unless one of the above events 267 occurs again. This is to limit the number of SUBSCRIBE requests sent 268 within domains that do not support session-independent policies. 270 A UA compliant to this specification MUST support the User Agent 271 Profile Data Set for Media Policy [3] and the Schema for SIP User 272 Agent Profile Data Sets [8]. To indicate that the UA wants to 273 receive session-independent policies, it includes the MIME type 274 "application/session-policy+xml" in addition to the MIME type of the 275 Schema for SIP User Agent Profile Data Sets in the Accept header of a 276 SUBSCRIBE request. 278 A policy server MAY send a notification to the subscriber every time 279 the session-independent policies covered by the subscription changes. 280 The definition of what causes a policy to change is at the discretion 281 of the administrator. A change in the policy may be triggered, for 282 example, by a change in the network status, by the change in the time 283 of day or by an update of the service level agreement with the 284 customer. The session-independent policies contained in a 285 notification MUST represent a complete session-independent policy. 286 Deltas to previous policies or partial policies are not supported. 288 4. Session-Specific Policies 290 Session-specific policies are policies that are created specifically 291 for one particular session of a UA. Thus, session-specific policies 292 will typically be different for different sessions. The session- 293 specific policies for a session may change during the course of the 294 session. For example, a user may run out of credit during a session, 295 which will cause the network to disallow the transmission all media 296 streams from this point on. 298 4.1. Architecture 300 domain 1 301 +-----------+ 302 /------| proxy |----... 303 +----+ / +-----------+ 304 | |---/ +-----------+ 305 | | | policy | 306 | UA |============| server | 307 | | +-----------+ 308 | |**** +-----------+ 309 +----+ * | policy | 310 *******|enforcement|****... 311 +-----------+ 313 --- SIP Signaling 314 === Policy Channel 315 *** Media 317 Figure 2 319 The following entities are needed for session-specific policies (see 320 Figure 2): a user agent (UA), a proxy, a policy server and possibly a 321 policy enforcement entity. 323 The role of the proxy is to provide a rendezvous mechanism for UAs 324 and policy servers. It conveys the URI of the policy server in its 325 domain to UAs and ensures that each UA knows where to retrieve 326 policies from. It does not deliver the actual policies to UAs. 328 The policy server is a separate logical entity that may be physically 329 co-located with the proxy. The role of the policy server is to 330 deliver session policies to UAs. The policy server receives session 331 information, uses this information to determine the policies that 332 apply to the session and returns these policies to the UA. The 333 mechanism for generating policies (i.e. making policy decisions) is 334 outside the scope of this specification. A policy server may, for 335 example, query an external entity to get the policies that apply to a 336 session or it may directly incorporate a policy decision point and 337 generate policies locally. 339 A UA receives the URI of a policy server from a proxy. It uses this 340 URI to connect to the policy server. It provides information about 341 the current session to the policy server and receives session 342 policies in response. The UA may also receive policy updates from 343 the policy server during the course of a session. 345 A network may have a policy enforcement infrastructure in place. 346 However, this specification does not make any assumptions about the 347 enforcement of session policies and the mechanisms defined here are 348 orthogonal a policy enforcement infrastructure. Their goal is to 349 provide a mechanism to convey session information to a policy server 350 and to return the policies that apply to a session to the UA. 352 In principle, each domain that is traversed by SIP signaling messages 353 can define session-specific policies for a session. Each of these 354 domains needs to run a policy server and a proxy that is able to 355 rendezvous a UA with the policy server (as shown in Figure 2). 356 However, it is expected that session-specific policies will often 357 only be provided by the local domain of the user agent. 359 4.2. Overview 361 The protocol defined in this specification clearly separates SIP 362 signaling and the exchange of policies. SIP signaling is only used 363 to rendezvous the UA with the policy server. From this point on, UA 364 and policy server communicate directly with each other over a 365 separate policy channel. This is opposed to a piggyback model, where 366 the exchange of policy information between endpoint and a policy 367 server in the network is piggybacked onto the SIP signaling messages 368 that are exchanged between endpoints. 370 The main advantage of using a separate policy channel is that it 371 decouples the exchange of signaling messages between endpoints from 372 the exchange of policies between endpoint and policy server. This 373 decoupling provides a number of desirable properties. It enables the 374 use of separate encryption mechanisms on the signaling path (to 375 secure the communication between endpoints) and on the policy channel 376 (to secure the communication between endpoint and policy server). 377 Policies can be submitted directly from the policy server to the 378 endpoint and never travel along the signaling path, possibly crossing 379 many domains. Endpoints set up a separate policy channel to each 380 policy server and can specifically decide which information they want 381 to disclose to which policy server. Finally, policy servers do not 382 need to rely on a SIP signaling message flowing by to send policies 383 or policy updates to an endpoint. A policy server can use the policy 384 channel at any time to update session policies as needed. A 385 disadvantage of the separate channel model is that it requires 386 additional messages for the exchange of policy information. 388 Following this model, signaling for session-specific policies 389 involves the following two fundamental tasks: 391 1. UA/policy server rendezvous: a UA setting up a session needs to 392 be able to discover the policy servers that are relevant to this 393 session. 394 2. Policy channel: once the UA has discovered the relevant policy 395 servers for a session, it needs to connect to these servers, 396 disclose session information and retrieve the policies that apply 397 to this session. 399 The setting up session-specific policies over the policy channel 400 involves the following steps: 402 1. A user agent submits information about the session it is trying 403 to establish to the policy server and asks whether a session 404 using these parameters is permissible. 405 2. The policy server generates a policy decision for this session 406 and returns the decision to the user agent. Possible policy 407 decisions are (1) to deny the session, (2) to propose changes to 408 the session parameters with which the session would be 409 acceptable, or (3) to accept the session as it was proposed. 410 3. The policy server can update the policy decision at a later time. 411 A policy decision update can, for example, propose additional 412 changes to the session (e.g. change the available bandwidth) or 413 deny a previously accepted session (i.e. disallow the 414 continuation of a session). 416 In many cases, the mechanism for session-specific policies will be 417 used to disclose session information and return session policies. 418 However, some scenarios may only involve the disclosure of session 419 information to a network intermediary. If an intermediary does not 420 intend to return a policy, it can simply accept the session as it was 421 proposed. Similarly, some session-specific policies only apply to 422 the offer (and therefore only require the disclosure of the offer) 423 whereas others apply to offer and answer. Both types of policies are 424 supported by session-specific policy mechanism. 426 4.3. Examples 428 This section provides two examples to illustrate the overall 429 operation of session-specific policies. The call flows depict the 430 rendezvous mechanism between UA and policy server and indicate the 431 points at which the UA exchanges policy information with the policy 432 server. 434 The example is based on the following scenario: there are two domains 435 (domain A and domain B), which both have session-specific policies 436 for the UAs in their domain. Both domains do not provide policies to 437 the UAs outside of their domain. The two domains have a proxy (P A 438 and P B) and a policy server (PS A and PS B). The policies in both 439 domains involve the session description offer and answer. 441 4.3.1. Offer in Request 443 The first call flow depicts an INVITE transaction with the offer in 444 the request. It is assumed that this is the first INVITE request the 445 UAC creates in this domain and that it therefore does not have 446 previous knowledge about the policy server URIs in this domain. 448 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply 449 to this session and (2) returns a 488 to UA A. P A includes the URI 450 of PS A in the 488 response. This step is needed since the UAC has 451 no prior knowledge about the URI of PS A. (3) UA A uses the URI to 452 contact PS A, discloses the session description offer to PS A and (4) 453 receives policies for the offer. (5) UA A reformulates the INVITE 454 request under consideration of the received policies and includes a 455 Policy-Id header to indicate that it has already contacted PS A. P A 456 does not reject the INVITE this time and removes the Policy-Id header 457 when forwarding the INVITE. P B adds a Policy-Contact header 458 containing the URI of PS B. (6) UA B uses this URI to contact PS B 459 and discloses the offer and the answer it is about to send. (7) UA B 460 receives policies from PS B and applies them to the offer and answer 461 respectively. (8) UA B returns the updated answer in the 200 OK. (9) 462 UA A contacts PS A with the answer and (10) retrieves answer policies 463 from PS A. 465 UA A P A P B UA B 466 | | | | 467 | INVITE offer | | | 468 |---------------->| | | (1) 469 | 488 | | | 470 | + Policy-Contact| | | 471 |<----------------| | | (2) 472 | ACK | | | 473 |---------------->| | | 474 | | PS A | | 475 | | | | 476 | PolicyChannel | | | 477 | + InfoOffer | | | 478 |------------------->| | | (3) 479 | PolicyChannel | | | 480 | + PolicyOffer | | | 481 |<-------------------| | | (4) 482 | | | | 483 | | | | 484 | INVITE offer' | INVITE offer' | INVITE offer | 485 | + Policy-Id | | + Policy-Contact| 486 |---------------->|--------------->|---------------->| (5) 487 | | | | 488 | | PS B | | 489 | | | | 490 | | | PolicyChannel | 491 | | | + InfoOffer | 492 | | | + InfoAnswer | 493 | | |<-------------------| (6) 494 | | | PolicyChannel | 495 | | | + PolicyOffer | 496 | | | + PolicyAnswer | 497 | | |------------------->| (7) 498 | | | | 499 | | | | 500 | OK answer | OK answer | OK answer | 501 |<----------------|<---------------|<----------------| (8) 502 | ACK | 503 |--------------------------------------------------->| 504 | | | | 505 | | | | 506 | PolicyChannel | | | 507 | + InfoAnswer | | | 508 |------------------->| | | (9) 509 | PolicyChannel | | | 510 | + PolicyAnswer | | | 511 |<-------------------| | | (10) 512 | | | | 514 4.3.2. Offer in Response 516 This call flow depicts an INVITE transaction with the offer in the 517 response. 519 Steps (1) - (8) are analogous to steps (1) - (8) in the previous 520 flow. An important difference is that in steps (9) and (10) UA A 521 contacts PS A after receiving the offer in the 200 OK but before 522 returning the answer in step (11). This enables UA A to return the 523 final answer, which includes all applicable policies, in the ACK. 524 However, it requires that PS A immediately returns a policy to avoid 525 a delay in the transmission of the ACK. This is similar to Flow I in 526 [9]. 528 UA A P A P B UA B 529 | | | | 530 | INVITE | | | 531 |---------------->| | | (1) 532 | 488 | | | 533 | + Policy-Contact| | | 534 |<----------------| | | (2) 535 | ACK | | | 536 |---------------->| | | 537 | | PS A | | 538 | | | | 539 | PolicyChannel | | | 540 |------------------->| | | (3) 541 | PolicyChannel | | | 542 |<-------------------| | | (4) 543 | | | | 544 | | | | 545 | INVITE | INVITE | INVITE | 546 | + Policy-Id | | + Policy-Contact| 547 |---------------->|--------------->|---------------->| (5) 548 | | | | 549 | | PS B | | 550 | | | | 551 | | | PolicyChannel | 552 | | | + InfoOffer | 553 | | |<-------------------| (6) 554 | | | PolicyChannel | 555 | | | + PolicyOffer | 556 | | |------------------->| (7) 557 | | | | 558 | | | | 559 | OK offer | OK offer | OK offer | 560 |<----------------|<---------------|<----------------| (8) 561 | | | | 562 | | | | 563 | PolicyChannel | | | 564 | + InfoOffer | | | 565 | + InfoAnswer | | | 566 |------------------->| | | (9) 567 | PolicyChannel | | | 568 | + PolicyOffer | | | 569 | + PolicyAnswer | | | 570 |<-------------------| | | (10) 571 | | | | 572 | ACK answer | 573 |--------------------------------------------------->| (11) 574 | | | | 575 | | | | 576 | | | PolicyChannel | 577 | | | + InfoAnswer | 578 | | |<-------------------| (12) 579 | | | PolicyChannel | 580 | | | + PolicyAnswer | 581 | | |------------------->| (13) 582 | | | | 584 4.4. UA/Policy Server Rendezvous 586 The first step in setting up session-specific policies is to 587 rendezvous the UAs with the relevant policy servers. This is 588 achieved by providing the URIs of all policy servers relevant for a 589 session to the UAs. 591 4.4.1. UAC Behavior 593 When a UA compliant to this specification generates an INVITE or 594 UPDATE request, it MUST include a Supported header field with the 595 option tag "policy" in the request. 597 The UAC may receive a 488 in response to an INVITE or UPDATE request, 598 which contains a Policy-Contact header field. This is a new header 599 defined in this specification that contains the URI of a policy 600 server. A 488 response with this header is generated by a proxy to 601 convey the URI of the local policy server to the UAC. The UAC SHOULD 602 use this URI to contact the policy server using mechanism defined in 603 Section 4.5. The UAC SHOULD apply the policies received and resend 604 the updated request. 606 The UAC MUST insert a Policy-Id header into a request if it has 607 contacted a policy server for this request. The Policy-Id header 608 MUST include the URIs of all policy servers the UAC has contacted for 609 the request. The Policy-Id header enables a proxy to determine 610 whether the URI of its policy server is already known to the UAC (and 611 thus the request can be passed through) or whether the URI still 612 needs to be conveyed to the UAC in a 488 response. 614 In some cases, a request may traverse multiple domains with session- 615 policies in place. Each of these domains may return a 488 response 616 containing a policy server URI. Since the UAC contacts a policy 617 server after receiving a 488 response from a domain and before re- 618 sending the request, session policies are always applied to a request 619 in the order in which the request traverses through the domains. The 620 UAC SHOULD NOT change this implicit order among policy servers. 622 Some types of session policies only apply to the offer whereas other 623 policies apply to the offer as well as the answer. A UA SHOULD 624 generally disclose the offer and the answer to the policy server. 625 However, the policy server may indicate on the policy channel (after 626 receiving the offer) that the disclosure of the answer is not needed 627 for this session. In this case, the UAC MAY skip the disclosure of 628 the answer for this particular session. 630 Depending on whether or not the UAC has included an offer in the 631 INVITE request it has sent to the UAS, it will receive an answer or 632 an offer in the response from the UAS. If the response contains an 633 answer (i.e. the request contained an offer), it MUST send the ACK 634 before contacting the policy server with the answer. The UAC MUST 635 contact the same policy servers it has contacted for the offer. If 636 the response contains an offer (i.e. the INVITE request was empty), 637 the UAC MUST first contact the policy server to retrieve session 638 policies and apply these policies before sending the answer in the 639 ACK. The answer in the ACK will therefore already consider the 640 relevant policies. 642 This approach assumes that the policy server immediately responds 643 to a policy request and does not require manual intervention to 644 create a policy. A delay in the response from the policy server 645 would delay the transmission of the ACK and could trigger 646 retransmissions of the INVITE response (also see the 647 recommendations for Flow I in [9]). 649 4.4.2. Caching of Policy Server URIs 651 A UAC may frequently need to contact the policy server in the local 652 domain. To avoid the retransmission of the local policy server URI 653 for each INVITE or UPDATE request, the UAC SHOULD cache the URI of 654 the local policy server. The UAC may receive this URI in a 488 from 655 the local proxy after sending an INVITE or UPDATE message. 656 Alternatively, the UA may also have received the local policy server 657 URI through configuration or other means. If the UAC has received a 658 local policy server URI through configuration and receives another 659 one in a 488 response, it SHOULD overwrite the configured URI with 660 the one received in the 488 response. The UAC SHOULD contact the 661 cached local policy server URI when creating a new INVITE or UPDATE 662 request, before they are sent. 664 Domains can prevent the UAC from caching the local policy server URI. 665 This is useful, for example, if the policy server does not need to be 666 involved in all sessions or the policy server URI changes from 667 session to session. A proxy can mark the URI of such a local policy 668 server as "non-cacheable". The UA SHOULD NOT cache a non-cacheable 669 policy server URI. It SHOULD remove the current URI from the cache 670 when receiving a "non-cacheable" URI. 672 The UAC SHOULD NOT cache policy server URIs it has received from 673 proxies outside of the local domain. These policy servers may not be 674 relevant for subsequent sessions, which may go to a different 675 destination, traversing different domains. 677 The UAC SHOULD store the list of policy server URIs is has contacted 678 for a session as part of the session state. The UAC should keep this 679 list until the session is terminated. The UAC SHOULD contact the 680 policy server URIs in this list for mid-dialog INVITE or UPDATE 681 request. Caching these URIs avoids the retransmission of policy 682 server URIs for each mid-dialog requests. 684 4.4.3. UAS Behavior 686 An incoming INVITE or UPDATE request may contain a Policy-Contact 687 header with a list of policy server URIs. The UAS SHOULD contact all 688 policy server URIs in a Policy-Contact header. The UAS MUST contact 689 the policy server URIs in the order in which they were contained in 690 the Policy-Contact header, starting with the topmost value. 692 If the UAS receives an ACK containing an answer, it SHOULD contact 693 the policy servers again with the answer. In this case, it MUST 694 contact the same policy servers it has contacted for the offer. 695 However, the policy server may have indicated in response to the 696 offer that the disclosure of the answer is not needed for this 697 session. In this case, the UAS MAY skip the disclosure of the answer 698 for this particular session. 700 4.4.4. Proxy Behavior 702 A proxy provides rendezvous functionality for UAs and the local 703 policy server. This is achieved by conveying the URI of the local 704 policy server to the UAC or the UAS (or both) when processing an 705 INVITE or UPDATE request. 707 If an INVITE or UPDATE request contains a Supported header field with 708 the option tag "policy", the proxy MAY reject the request with a 488 709 response to provide the local policy server URI to the UAC. Before 710 rejecting a request, the proxy MUST verify that the request does not 711 have a Policy-Id header field, which already contains the local 712 policy server URI. If the request does not have such a header or the 713 local policy server URI is not present in this header, then the proxy 714 MAY reject the request with a 488. The proxy MUST insert a Policy- 715 Contact header in the 488 response that contains the URI of the local 716 policy server. The proxy MAY add the header field parameter "non- 717 cacheable" to prevent the UAC from caching this policy server URI. 719 If the local policy server URI is already present in the Policy-Id 720 header of an INVITE or UPDATE request, the proxy MUST NOT reject the 721 request as described above. The proxy SHOULD remove this policy 722 server URI from the Policy-Id header field before forwarding the 723 request. 725 The proxy MAY insert a Policy-Contact header field into an INVITE or 726 UPDATE request in order to convey the policy server URI to the UAS. 727 If the request already contains a Policy-Contact header field, the 728 proxy MUST insert the URI ahead of all existing values at the 729 beginning of the list. A proxy MUST NOT change the order of existing 730 Policy-Contact header values. 732 4.4.5. Header Definition and Syntax 734 The Policy-Id header field is inserted into an INVITE or UPDATE 735 request by the UAC. It identifies all policy servers the UAC has 736 contacted for this request. A Policy-Id header value is the URI of a 737 policy server. 739 The syntax of the Policy-Id header field is: 741 Policy-Id = "Policy-Id" HCOLON absoluteURI 742 *(COMMA absoluteURI) 744 The Policy-Contact header field can be inserted into a 488 response 745 to an INVITE or UPDATE request by a proxy. It contains a policy 746 server URI that needs to be contacted by the UAC. A proxy MAY add 747 the "non-cacheable" header field parameter to indicate that the UAC 748 should not cache the policy server URI. 750 The Policy-Contact header field can also be inserted into INVITE and 751 UPDATE requests by a proxy. It contains an ordered list of policy 752 server URIs that need to be contacted by the UAS. The UAS starts to 753 process the header field at the topmost value of this list. New 754 header field values are inserted at the top. The Policy-Contact 755 header field effectively forms a stack. The "non-cacheable" header 756 field parameter MUST NOT be used in a request. 758 The syntax of the Policy-Contact header field is: 760 Policy-Contact = "Policy-Contact" HCOLON policyURI 761 *(COMMA policyURI) 762 policyURI = absoluteURI [ SEMI "non-cacheable" ] 764 The BNF for absoluteURI is defined in [6]. 766 Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' 767 is for the UPDATE method [5]. 769 Header field where proxy ACK BYE CAN INV OPT REG UPD 770 _______________________________________________________________ 771 Policy-Id R rd - - - o - - o 772 Policy-Contact R a - - - o - - o 773 Policy-Contact 488 a - - - o - - o 774 Table 1: Policy-Id and Policy-Contact Header Fields 776 4.5. Policy Subscription 778 The rendezvous mechanism described in the previous section enables 779 proxies to deliver the URIs of policy servers to the UAC and UAS. 780 This section describes the mechanism for the policy channel, i.e. the 781 protocol UAs use to contact the policy servers. The main task of the 782 policy channel is to enable a UA to submit information about the 783 session it is trying to establish (i.e. the offer and the answer) to 784 a policy server and to receive the resulting session-specific 785 policies and possible updates to these policies in response. 787 A UA compliant to this specification MUST implement the Event Package 788 for Session-Specific Session Policies [2]. It contacts a policy 789 server by subscribing to this event package. 791 When subscribing to session-specific policies, the UA discloses 792 information about the session it is trying to establish to the policy 793 server as described in [2]. This information is used by the policy 794 server to determine the session-specific policy for this session. 795 The policy server returns the policies that apply to this session in 796 NOTIFY messages. It returns an initial set of policies when the 797 subscription is established and may notify the UA when there are 798 updates to these policies. Complete call flow examples for session- 799 specific policies that include policy channel messages can be found 800 in Appendix B. 802 A UA SHOULD use the policies it has received from the policy server 803 in the current session (i.e. the session the subscription is for). 805 When a UA receives a policy update, it SHOULD apply the update to the 806 current session. If this update causes a change in the session 807 description of a session, the UA may need to generate a re-INVITE or 808 UPDATE message to re-negotiate the modified session description with 809 its peer UA. For example, if a policy update disallows the use of 810 video and video is part of the current session description, then the 811 UA will need to create an new session description offer without 812 video. After receiving this offer, the peer UA knows that video 813 can't be used any more and responds with the corresponding answer. 815 5. Security Considerations 817 Session policies can significantly change the behavior of a user 818 agent and can therefore be used by an attacker to compromise a user 819 agent. For example, session policies can be used to set up a user 820 agent so that it is unable to successfully establish a session (e.g. 821 by setting the available bandwidth to zero). Such a policy can be 822 submitted to the user agent during a session, which will cause the UA 823 to terminate the session. 825 A user agent transmits session information to a policy server for 826 session-specific policies. This session information may contain 827 sensitive data the user may not want an eavesdropper or an 828 unauthorized policy server to see. In particular, the session 829 information may contain the encryption keys for media streams. Vice 830 versa, session policies may also contain sensitive information about 831 the network or service level agreements the service provider may not 832 want to disclose to an eavesdropper or an unauthorized user agent. 834 User agents should therefore authenticate a policy server before 835 accepting a session policy. Policy servers should authenticate user 836 agents before sending a session policy. This document does not 837 define the protocols between user agents and policy servers and 838 merely refers to other specifications. The security considerations 839 of these specifications apply and provide the mechanisms needed to 840 secure these protocols. 842 Administrators should use SIPS URIs as policy server URIs, if 843 possible, so that subscriptions to session policies are transmitted 844 over TLS. 846 This document defines a new mechanism that enables proxies to 847 rendezvous UAs and policy servers. An attacker can use this 848 mechanism to refer a UA to compromised policy server. The UA can 849 prevent such an attack from being effective by authenticating policy 850 servers. 852 An attacker could intercept SIP messages between the UA and proxy and 853 remove the policy headers needed for session-specific policies. This 854 would impede the rendezvous between UA and policy server and, since 855 the UA would not contact the policy server, may prevent a UA from 856 setting up a session. This attack can be prevented by using a 857 secured transport protocol such as TLS between proxies and UA. 859 6. IANA Considerations 861 6.1. Registration of the "Policy-Id" Header 863 Name of Header: Policy-Id 865 Short form: none 867 Normative description: Section 4.4.5 of this document 869 6.2. Registration of the "Policy-Contact" Header 871 Name of Header: Policy-Contact 873 Short form: none 875 Normative description: Section 4.4.5 of this document 877 6.3. Registration of the "policy" SIP Option-Tag 879 Name of option: policy 881 Description: Support for the Policy-Contact and Policy-Id headers. 883 SIP headers defined: Policy-Contact, Policy-Id 885 Normative description: This document 887 Appendix A. Acknowledgements 889 Many thanks to Allison Mankin for the discussions and the suggestions 890 for this draft. Many thanks to everyone who contributed by providing 891 feedback on the mailing list and in IETF meetings. 893 Appendix B. Session-Specific Policies - Call Flows 894 The following call flows illustrate the overall operation of session- 895 specific policies. The call flows contain all messages needed for 896 UA/policy server rendezvous and the policy subscription. 898 The following abbreviations are used: 900 o: offer 901 o': offer modified by a policy 902 po: offer policy 903 a: answer 904 a': answer modified by a policy 905 pa: answer policy 906 ps uri: policy server URI (in Policy-Contact header) 907 ps id: policy server id (in Policy-Id header) 909 B.1. Offer in Invite 910 UA A P A PS A PS B P B UA B 911 | | | | | | 912 |(1) INV | | | | 913 |-------->| | | | | 914 |(2) 488 | | | | 915 |<--------| | | | | 916 |(3) ACK | | | | | 917 |-------->| | | | | 918 |(4) SUBSCRIBE | | | | 919 |------------------>| | | | 920 |(5) 200 OK | | | | 921 |<------------------| | | | 922 |(6) NOTIFY | | | | 923 |<------------------| | | | 924 |(7) 200 OK | | | | 925 |------------------>| | | | 926 |(8) INV | | | | 927 |-------->| | | | | 928 | |(9) INV | | | 929 | |---------------------------->| | 930 | | | | |(10) INV 931 | | | | |-------->| 932 | | | |(11) SUBSCRIBE 933 | | | |<------------------| 934 | | | |(12) 200 OK | 935 | | | |------------------>| 936 | | | |(13) NOTIFY 937 | | | |------------------>| 938 | | | |(14) 200 OK | 939 | | | |<------------------| 940 | | | | |(15) 200 OK 941 | | | | |<--------| 942 | |(16) 200 OK | | | 943 | |<----------------------------| | 944 |(17) 200 OK | | | | 945 |<--------| | | | | 946 |(18) ACK | | | | | 947 |------------------------------------------------>| 948 |(19) SUBSCRIBE | | | 949 |------------------>| | | | 950 |(20) 200 OK | | | | 951 |<------------------| | | | 952 |(21) NOTIFY | | | | 953 |<------------------| | | | 954 |(22) 200 OK | | | | 955 |------------------>| | | | 956 | | | | | | 957 | | | | | | 959 B.2. Offer in Response 961 UA A P A PS A PS B P B UA B 962 | | | | | | 963 |(1) INV | | | | | 964 |-------->| | | | | 965 |(2) 488 | | | | 966 |<--------| | | | | 967 |(3) ACK | | | | | 968 |-------->| | | | | 969 |(4) SUBSCRIBE | | | | 970 |------------------>| | | | 971 |(5) 200 OK | | | | 972 |<------------------| | | | 973 |(6) NOTIFY | | | | 974 |<------------------| | | | 975 |(7) 200 OK | | | | 976 |------------------>| | | | 977 |(8) INV | | | | 978 |-------->| | | | | 979 | |(9) INV | | | | 980 | |---------------------------->| | 981 | | | | |(10) INV 982 | | | | |-------->| 983 | | | |(11) SUBSCRIBE | 984 | | | |<------------------| 985 | | | |(12) 200 OK | 986 | | | |------------------>| 987 | | | |(13) NOTIFY | 988 | | | |------------------>| 989 | | | |(14) 200 OK | 990 | | | |<------------------| 991 | | | | |(15) 200 OK 992 | | | | |<--------| 993 | |(16) 200 OK | | | 994 | |<----------------------------| | 995 |(17) 200 OK | | | | 996 |<--------| | | | | 997 |(18) SUBSCRIBE | | | 998 |------------------>| | | | 999 |(19) 200 OK | | | | 1000 |<------------------| | | | 1001 |(20) NOTIFY | | | 1002 |<------------------| | | | 1003 |(21) 200 OK | | | | 1004 |------------------>| | | | 1005 |(22) ACK | | | | 1006 |------------------------------------------------>| 1007 | | | |(23) SUBSCRIBE 1008 | | | |<------------------| 1009 | | | |(24) 200 OK | 1010 | | | |------------------>| 1011 | | | |(25) NOTIFY 1012 | | | |------------------>| 1013 | | | |(26) 200 OK | 1014 | | | |<------------------| 1015 | | | | | | 1016 | | | | | | 1018 7. References 1020 7.1. Normative References 1022 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1023 Levels", BCP 14, RFC 2119, March 1997. 1025 [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) 1026 Event Package for Session-Specific Session Policies.", 1027 draft-ietf-sipping-policy-package-01 (work in progress), 1028 April 2006. 1030 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 1031 Data Set for Media Policy", 1032 draft-ietf-sipping-media-policy-dataset-01 (work in progress), 1033 March 2006. 1035 [4] Petrie, D., "A Framework for Session Initiation Protocol User 1036 Agent Profile Delivery", draft-ietf-sipping-config-framework-08 1037 (work in progress), March 2006. 1039 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1040 Method", RFC 3311, October 2002. 1042 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1043 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1044 Session Initiation Protocol", RFC 3261, June 2002. 1046 7.2. Informative References 1048 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1049 Protocol", RFC 2327, April 1998. 1051 [8] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and 1052 Guidelines for Defining Session Initiation Protocol User Agent 1053 Profile Data Sets", draft-petrie-sipping-profile-datasets-03 1054 (work in progress), October 2005. 1056 [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1057 "Best Current Practices for Third Party Call Control (3pcc) in 1058 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1059 April 2004. 1061 Authors' Addresses 1063 Volker Hilt 1064 Bell Labs/Lucent Technologies 1065 101 Crawfords Corner Rd 1066 Holmdel, NJ 07733 1067 USA 1069 Email: volkerh@bell-labs.com 1071 Gonzalo Camarillo 1072 Ericsson 1073 Hirsalantie 11 1074 Jorvas 02420 1075 Finland 1077 Email: Gonzalo.Camarillo@ericsson.com 1079 Jonathan Rosenberg 1080 Cisco Systems 1081 600 Lanidex Plaza 1082 Parsippany, NJ 07054 1083 USA 1085 Email: jdrosen@cisco.com 1087 Intellectual Property Statement 1089 The IETF takes no position regarding the validity or scope of any 1090 Intellectual Property Rights or other rights that might be claimed to 1091 pertain to the implementation or use of the technology described in 1092 this document or the extent to which any license under such rights 1093 might or might not be available; nor does it represent that it has 1094 made any independent effort to identify any such rights. Information 1095 on the procedures with respect to rights in RFC documents can be 1096 found in BCP 78 and BCP 79. 1098 Copies of IPR disclosures made to the IETF Secretariat and any 1099 assurances of licenses to be made available, or the result of an 1100 attempt made to obtain a general license or permission for the use of 1101 such proprietary rights by implementers or users of this 1102 specification can be obtained from the IETF on-line IPR repository at 1103 http://www.ietf.org/ipr. 1105 The IETF invites any interested party to bring to its attention any 1106 copyrights, patents or patent applications, or other proprietary 1107 rights that may cover technology that may be required to implement 1108 this standard. Please address the information to the IETF at 1109 ietf-ipr@ietf.org. 1111 Disclaimer of Validity 1113 This document and the information contained herein are provided on an 1114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1116 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1117 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1118 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1121 Copyright Statement 1123 Copyright (C) The Internet Society (2006). This document is subject 1124 to the rights, licenses and restrictions contained in BCP 78, and 1125 except as set forth therein, the authors retain all their rights. 1127 Acknowledgment 1129 Funding for the RFC Editor function is currently provided by the 1130 Internet Society.