idnits 2.17.1 draft-ietf-sip-session-policy-framework-00.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 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1213. ** 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 840 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 (October 13, 2006) is 6402 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-09 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: April 16, 2007 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 October 13, 2006 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sip-session-policy-framework-00 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 April 16, 2007. 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. This document 47 specifies a framework for SIP session policies that provides a 48 standard mechanism by which a proxy can define or influence policies 49 on sessions, such as the codecs or media types to be used. It 50 defines a model, an overall architecture and new protocol mechanisms 51 for session policies. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5 58 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5 59 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6 60 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7 61 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 10 65 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 12 66 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 13 67 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13 68 4.4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 14 69 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 15 70 4.4.4. Caching Policy Server URIs . . . . . . . . . . . . . . 15 71 4.4.5. Storing Policy Server URIs in a Dialog . . . . . . . . 16 72 4.4.6. Contacting the Policy Server . . . . . . . . . . . . . 17 73 4.4.7. Header Definition and Syntax . . . . . . . . . . . . . 18 74 4.5. Policy Subscription . . . . . . . . . . . . . . . . . . . 19 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 21 78 6.2. Registration of the "Policy-Contact" Header . . . . . . . 21 79 6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 21 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 81 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 21 82 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 22 83 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 24 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Intellectual Property and Copyright Statements . . . . . . . . . . 27 90 1. Introduction 92 The Session Initiation Protocol (SIP) [6] is a signaling protocol for 93 creating, modifying and terminating multimedia sessions. A central 94 element in SIP is the proxy server. Proxy servers are intermediaries 95 that are responsible for request routing, rendezvous, authentication 96 and authorization, mobility, and other signaling services. However, 97 proxies are divorced from the actual sessions - audio, video, and 98 messaging - that SIP establishes. Details of the sessions are 99 carried in the payload of SIP messages, and are usually described 100 with the Session Description Protocol (SDP) [7]. Indeed, SIP 101 provides end-to-end encryption features using S/MIME, so that all 102 information about the sessions can be hidden from eavesdroppers and 103 proxies alike. 105 However, experience has shown that there is a need for SIP 106 intermediaries to impact aspects of a session. For example, SIP may 107 be used in a wireless network, which has limited resources for media 108 traffic. During periods of high activity, the wireless network 109 provider wants to restrict the amount of bandwidth available to each 110 individual user. With session policies, an intermediary in the 111 wireless network can inform the user agent about the bandwidth it can 112 currently count on. This information enables the user agent to make 113 an informed decision about the number of streams, the media types, 114 and the codecs it can successfully use in a session. Similarly, a 115 network provider may have a service level agreement with a user that 116 defines the set of media types a user can use. With session 117 policies, the network can convey the current set of policies to user 118 agents, enabling them to set up sessions without inadvertently 119 violating any of the network 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 enforce the session policies they have in place. For 133 example, a domain might have a policy that disallows the use of video 134 and may enforce this policy by dropping all packets that contain a 135 video encoding. Unfortunately, enforcement mechanisms usually do not 136 inform the user about the policies they are enforcing. Instead, they 137 silently keep the user from doing anything against them. This may 138 lead to a malfunctioning of devices that is incomprehensible to the 139 user. With session policies, the user knows about the current 140 network policies and can set up policy-compliant sessions or simply 141 connect to a domain with less stringent policies. Thus, session 142 policies provide an important combination of consent coupled with 143 enforcement. That is, the user becomes aware of the policy and needs 144 to act on it, but the provider still retains the right to enforce the 145 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 a session and return a policy that replaces the internal IP 155 addresses and ports with external ones. Since session-specific 156 policies are tailored to a session, they only apply to the session 157 they are created for. Session-specific policies are created on a 158 session-by-session basis at the time the session is established. 160 Session-independent policies on the other hand are policies that are 161 created independent of a session and generally apply to all SIP 162 sessions set up by a user agent. A session-independent policy can, 163 for example, be used to inform user agents about an existing 164 bandwidth limit or media type restrictions. Since these policies are 165 not based on a specific session description, they can be created 166 independent of an attempt to set up a session and only need to be 167 conveyed to the user agent when it initializes (e.g. at the time the 168 device is powered on) and when the policies are changed. 170 This specification defines a framework for SIP session policies. It 171 specifies a model, the overall architecture and new protocol 172 mechanisms that are needed for session-independent and session- 173 specific policies. 175 2. Terminology 177 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 179 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 180 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 181 compliant implementations. 183 3. Session-Independent Policies 185 Session-independent policies are policies that are created 186 independent of a session and generally apply to all sessions a user 187 agent is setting up. They typically remain stable for a longer 188 period of time and apply to any session set up while they are valid. 189 However, session-independent policies may also change over time. For 190 example, a policy that defines a bandwidth limit for a user may 191 change during the day, defining a lower limit during peak hours and 192 allow more bandwidth off-peak. 194 3.1. Architecture and Overview 196 +-------------+ 197 /------| policy | 198 +----+ / | server 1 | 199 | |---/ +-------------+ 200 | UA | ... 201 | |---\ +-------------+ 202 +----+ \ | policy | 203 \------| server n | 204 +-------------+ 206 Figure 1 208 A SIP UA may receive session-independent policies from one or more 209 policy servers. In a typical configuration, a UA receives session- 210 independent policies from a policy server in the access or local 211 network domain (i.e. the domain from which the UA receives IP 212 service) and possibly the home network domain (i.e. the domain the UA 213 registers at). The local network may have policies that support the 214 access network infrastructure. For example, in a wireless network 215 where bandwidth is scarce, a provider may restrict the bandwidth 216 available to an individual user. The home network may have policies 217 that are needed to support services or policies that reflect the 218 service level agreement with the user. Thus, in most cases, a UA 219 will receive session-independent policies from one or two policy 220 servers. 222 Setting up session-independent policies involves the following steps: 224 1. A user agent requests session-independent policies from the 225 policy servers in the local network and home domain. A user 226 agent typically requests these policies when it starts up or 227 connects to a new network domain. 229 2. The policy server selects the policies that apply to this user 230 agent. The policy server may have general policies that apply to 231 all users or maintain separate policies for each individual user. 232 The selected policies are returned to the user agent. 233 3. The policy server may update the policies, for example, when 234 network conditions change. 236 3.2. Policy Subscription 238 A UA requests session-independent policies by subscribing to session- 239 independent policies on the policy server in a domain. Subscriptions 240 to session-independent policies are established using the "ua- 241 profile" event package defined in the Framework for SIP User Agent 242 Profile Delivery [4]. 244 The "ua-profile" event package [4] provides a mechanism to discover 245 policy servers in the local network and the home domain. The "local- 246 network" profile-type enables a UA to discover a policy server in the 247 local domain. The "user" profile type enables the discovery of a 248 policy server in the home domain. A UA compliant to this 249 specification SHOULD attempt to discover and subscribe to the policy 250 servers in these two domains. 252 A UA SHOULD (re-)subscribe to session-independent policies when the 253 following events occur: 255 o The UA registers a new address-of-record (AoR) or removes a AoR 256 from the set of AoRs it has registered. In these cases, the UA 257 SHOULD establish subscriptions for each new AoR using the "user" 258 and the "local-network" profile-types. The UA SHOULD terminate 259 all subscriptions for AoRs it has removed. 260 o The UA changes the domain it is connected to. The UA SHOULD 261 terminate all existing subscriptions for the "local-network" 262 profile-type. It SHOULD then create a new subscription for each 263 AoR using the "local-network" profile-type. This way, the UA 264 stops receiving policies from the previous local domain and starts 265 to receive the policies of the new local domain. The UA does not 266 need to change the subscriptions for "user" profiles. 268 If a subscriber is unable to establish a subscription, it SHOULD NOT 269 attempt to re-try this subscription, unless one of the above events 270 occurs again. This is to limit the number of SUBSCRIBE requests sent 271 within domains that do not support session-independent policies. 273 A UA compliant to this specification MUST support the User Agent 274 Profile Data Set for Media Policy [3]. To indicate that the UA wants 275 to receive session-independent policies, it includes the MIME type 276 "application/session-policy+xml" in the Accept header of a SUBSCRIBE 277 request. 279 A policy server MAY send a notification to the subscriber every time 280 the session-independent policies covered by the subscription change. 281 The definition of what causes a policy to change is at the discretion 282 of the administrator. A change in the policy may be triggered, for 283 example, by a change in the network status, by the change in the time 284 of day or by an update of the service level agreement with the 285 customer. The session-independent policies contained in a 286 notification MUST represent a complete session-independent policy. 287 Deltas to previous policies or partial policies are not supported. 289 4. Session-Specific Policies 291 Session-specific policies are policies that are created specifically 292 for one particular session of a UA. Thus, session-specific policies 293 will typically be different for different sessions. The session- 294 specific policies for a session may change during the course of the 295 session. For example, a user may run out of credit during a session, 296 which will cause the network to disallow the transmission all media 297 streams from this point on. 299 4.1. Architecture 301 domain 1 302 +-----------+ 303 /------| proxy |----... 304 +----+ / +-----------+ 305 | |---/ +-----------+ 306 | | | policy | 307 | UA |============| server | 308 | | +-----------+ 309 | |**** +-----------+ 310 +----+ * | policy | 311 *******|enforcement|****... 312 +-----------+ 314 --- SIP Signaling 315 === Policy Channel 316 *** Media 318 Figure 2 320 The following entities are needed for session-specific policies (see 321 Figure 2): a user agent (UA), a proxy, a policy server and possibly a 322 policy enforcement entity. 324 The role of the proxy is to provide a rendezvous mechanism for UAs 325 and policy servers. It conveys the URI of the policy server in its 326 domain to UAs and ensures that each UA knows where to retrieve 327 policies from. It does not deliver the actual policies to UAs. 329 The policy server is a separate logical entity that may be physically 330 co-located with the proxy. The role of the policy server is to 331 deliver session policies to UAs. The policy server receives session 332 information, uses this information to determine the policies that 333 apply to the session and returns these policies to the UA. The 334 mechanism for generating policies (i.e. making policy decisions) is 335 outside the scope of this specification. A policy server may, for 336 example, query an external entity to get the policies that apply to a 337 session or it may directly incorporate a policy decision point and 338 generate policies locally. 340 A UA receives the URI of a policy server from a proxy. It uses this 341 URI to connect to the policy server. It provides information about 342 the current session to the policy server and receives session 343 policies in response. The UA may also receive policy updates from 344 the policy server during the course of a session. 346 A network may have a policy enforcement infrastructure in place. 347 However, this specification does not make any assumptions about the 348 enforcement of session policies and the mechanisms defined here are 349 orthogonal a policy enforcement infrastructure. Their goal is to 350 provide a mechanism to convey session information to a policy server 351 and to return the policies that apply to a session to the UA. 353 In principle, each domain that is traversed by SIP signaling messages 354 can define session-specific policies for a session. Each of these 355 domains needs to run a policy server and a proxy that is able to 356 rendezvous a UA with the policy server (as shown in Figure 2). 357 However, it is expected that session-specific policies will often 358 only be provided by the local domain of the user agent. 360 4.2. Overview 362 The protocol defined in this specification clearly separates SIP 363 signaling and the exchange of policies. SIP signaling is only used 364 to rendezvous the UA with the policy server. From this point on, UA 365 and policy server communicate directly with each other over a 366 separate policy channel. This is opposed to a piggyback model, where 367 the exchange of policy information between endpoint and a policy 368 server in the network is piggybacked onto the SIP signaling messages 369 that are exchanged between endpoints. 371 The main advantage of using a separate policy channel is that it 372 decouples the exchange of signaling messages between endpoints from 373 the exchange of policies between endpoint and policy server. This 374 decoupling provides a number of desirable properties. It enables the 375 use of separate encryption mechanisms on the signaling path to secure 376 the communication between endpoints, and on the policy channel to 377 secure the communication between endpoint and policy server. 378 Policies can be submitted directly from the policy server to the 379 endpoint and never travel along the signaling path, possibly crossing 380 many domains. Endpoints set up a separate policy channel to each 381 policy server and can specifically decide which information they want 382 to disclose to which policy server. Finally, policy servers do not 383 need to rely on a SIP signaling message flowing by to send policies 384 or policy updates to an endpoint. A policy server can use the policy 385 channel at any time to update session policies as needed. A 386 disadvantage of the separate channel model is that it requires 387 additional messages for the exchange of policy information. 389 Following this model, signaling for session-specific policies 390 involves the following two fundamental tasks: 392 1. UA/policy server rendezvous: a UA setting up a session needs to 393 be able to discover the policy servers that are relevant to this 394 session. 395 2. Policy channel: once the UA has discovered the relevant policy 396 servers for a session, it needs to connect to these servers, 397 disclose session information and retrieve the policies that apply 398 to this session. 400 The setting up session-specific policies over the policy channel 401 involves the following steps: 403 1. A user agent submits information about the session it is trying 404 to establish to the policy server and asks whether a session 405 using these parameters is permissible. 406 2. The policy server generates a policy decision for this session 407 and returns the decision to the user agent. Possible policy 408 decisions are (1) to deny the session, (2) to propose changes to 409 the session parameters with which the session would be 410 acceptable, or (3) to accept the session as it was proposed. 411 3. The policy server can update the policy decision at a later time. 412 A policy decision update can, for example, propose additional 413 changes to the session (e.g. change the available bandwidth) or 414 deny a previously accepted session (i.e. disallow the 415 continuation of a session). 417 In many cases, the mechanism for session-specific policies will be 418 used to disclose session information and return session policies. 419 However, some scenarios may only involve the disclosure of session 420 information to a network intermediary. If an intermediary does not 421 intend to return a policy, it can simply accept the session as it was 422 proposed. Similarly, some session-specific policies only apply to 423 the offer (and therefore only require the disclosure of the offer) 424 whereas others apply to offer and answer. Both types of policies are 425 supported by session-specific policy mechanism. 427 4.3. Examples 429 This section provides two examples to illustrate the overall 430 operation of session-specific policies. The call flows depict the 431 rendezvous mechanism between UA and policy server and indicate the 432 points at which the UA exchanges policy information with the policy 433 server. 435 The example is based on the following scenario: there are two domains 436 (domain A and domain B), which both have session-specific policies 437 for the UAs in their domain. Both domains do not provide policies to 438 the UAs outside of their domain. The two domains have a proxy (P A 439 and P B) and a policy server (PS A and PS B). The policies in both 440 domains involve the session description offer and answer. 442 4.3.1. Offer in Request 444 The first call flow shown in Figure 3 depicts an INVITE transaction 445 with the offer in the request. It is assumed that this is the first 446 INVITE request the UAC creates in this domain and that it therefore 447 does not have previous knowledge about the policy server URIs in this 448 domain. 450 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply 451 to this session and (2) returns a 488 to UA A. P A includes the URI 452 of PS A in the 488 response. This step is needed since the UAC has 453 no prior knowledge about the URI of PS A. (3) UA A uses the URI to 454 contact PS A, discloses the session description offer to PS A and (4) 455 receives policies for the offer. (5) UA A reformulates the INVITE 456 request under consideration of the received policies and includes a 457 Policy-Id header to indicate that it has already contacted PS A. P A 458 does not reject the INVITE this time and removes the Policy-Id header 459 when forwarding the INVITE. P B adds a Policy-Contact header 460 containing the URI of PS B. (6) UA B uses this URI to contact PS B 461 and discloses the offer and the answer it is about to send. (7) UA B 462 receives policies from PS B and applies them to the offer and answer 463 respectively. (8) UA B returns the updated answer in the 200 OK. (9) 464 UA A contacts PS A with the answer and (10) retrieves answer policies 465 from PS A. 467 UA A P A P B UA B 468 | | | | 469 | INVITE offer | | | 470 |---------------->| | | (1) 471 | 488 | | | 472 | + Policy-Contact| | | 473 |<----------------| | | (2) 474 | ACK | | | 475 |---------------->| | | 476 | | PS A | | 477 | | | | 478 | PolicyChannel | | | 479 | + InfoOffer | | | 480 |------------------->| | | (3) 481 | PolicyChannel | | | 482 | + PolicyOffer | | | 483 |<-------------------| | | (4) 484 | | | | 485 | | | | 486 | INVITE offer' | INVITE offer' | INVITE offer | 487 | + Policy-Id | | + Policy-Contact| 488 |---------------->|--------------->|---------------->| (5) 489 | | | | 490 | | PS B | | 491 | | | | 492 | | | PolicyChannel | 493 | | | + InfoOffer | 494 | | | + InfoAnswer | 495 | | |<-------------------| (6) 496 | | | PolicyChannel | 497 | | | + PolicyOffer | 498 | | | + PolicyAnswer | 499 | | |------------------->| (7) 500 | | | | 501 | | | | 502 | OK answer | OK answer | OK answer | 503 |<----------------|<---------------|<----------------| (8) 504 | ACK | 505 |--------------------------------------------------->| 506 | | | | 507 | | | | 508 | PolicyChannel | | | 509 | + InfoAnswer | | | 510 |------------------->| | | (9) 511 | PolicyChannel | | | 512 | + PolicyAnswer | | | 513 |<-------------------| | | (10) 514 | | | | 515 Figure 3 517 4.3.2. Offer in Response 519 The call flow shown in Figure 4 depicts an INVITE transaction with 520 the offer in the response. 522 Steps (1) - (8) are analogous to steps (1) - (8) in the previous 523 flow. An important difference is that in steps (9) and (10) UA A 524 contacts PS A after receiving the offer in the 200 OK but before 525 returning the answer in step (11). This enables UA A to return the 526 final answer, which includes all applicable policies, in the ACK. 527 However, it requires that PS A immediately returns a policy to avoid 528 a delay in the transmission of the ACK. This is similar to Flow I in 529 [9]. 531 UA A P A P B UA B 532 | | | | 533 | INVITE | | | 534 |---------------->| | | (1) 535 | 488 | | | 536 | + Policy-Contact| | | 537 |<----------------| | | (2) 538 | ACK | | | 539 |---------------->| | | 540 | | PS A | | 541 | | | | 542 | PolicyChannel | | | 543 |------------------->| | | (3) 544 | PolicyChannel | | | 545 |<-------------------| | | (4) 546 | | | | 547 | | | | 548 | INVITE | INVITE | INVITE | 549 | + Policy-Id | | + Policy-Contact| 550 |---------------->|--------------->|---------------->| (5) 551 | | | | 552 | | PS B | | 553 | | | | 554 | | | PolicyChannel | 555 | | | + InfoOffer | 556 | | |<-------------------| (6) 557 | | | PolicyChannel | 558 | | | + PolicyOffer | 559 | | |------------------->| (7) 560 | | | | 561 | | | | 562 | OK offer | OK offer | OK offer | 563 |<----------------|<---------------|<----------------| (8) 564 | | | | 565 | | | | 566 | PolicyChannel | | | 567 | + InfoOffer | | | 568 | + InfoAnswer | | | 569 |------------------->| | | (9) 570 | PolicyChannel | | | 571 | + PolicyOffer | | | 572 | + PolicyAnswer | | | 573 |<-------------------| | | (10) 574 | | | | 575 | ACK answer | 576 |--------------------------------------------------->| (11) 577 | | | | 578 | | | | 579 | | | PolicyChannel | 580 | | | + InfoAnswer | 581 | | |<-------------------| (12) 582 | | | PolicyChannel | 583 | | | + PolicyAnswer | 584 | | |------------------->| (13) 585 | | | | 587 Figure 4 589 4.4. UA/Policy Server Rendezvous 591 The first step in setting up session-specific policies is to 592 rendezvous the UAs with the relevant policy servers. This is 593 achieved by providing the URIs of all policy servers relevant for a 594 session to the UAs. 596 4.4.1. UAC Behavior 598 A UAC compliant to this specification MUST include a Supported header 599 field with the option tag "policy" into all requests that can 600 initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK 601 requests). Guidelines for the sets of messages in which offers and 602 answers can appear are defined in RFC3261 [6]. The UA MUST include 603 the "policy" option tag into these requests even if the particular 604 request does not contain an offer or answer (e.g. an INVITE request 605 without an offer). 607 The UAC may receive a 488 response that contains a Policy-Contact 608 header field. The Policy-Contact header is a new header defined in 609 this specification. It contains the URI of a policy server. A 488 610 response with this header is generated by a proxy to convey the URI 611 of the local policy server to the UAC. A UAC SHOULD use this URI to 612 contact the policy server using mechanism defined in Section 4.5. It 613 SHOULD apply the policies received to the request and resend the 614 updated request. If no changes are required by policies or no 615 policies have been received, the request can be resend without any 616 policy-induced changes (headers etc. are still updated as needed for 617 the retransmission). 619 The UAC MUST insert a Policy-Id header into a request if it has 620 consulted a policy server for this request. The Policy-Id header 621 MUST include the URIs of all policy servers the UAC has contacted for 622 the request. The Policy-Id header enables a proxy to determine 623 whether the URI of its associated policy server is already known to 624 the UAC (and thus the request can be passed through) or whether the 625 URI still needs to be conveyed to the UAC in a 488 response. 627 In some cases, a request may traverse multiple domains with session- 628 policies in place. Each of these domains may return a 488 response 629 containing a policy server URI. Since the UAC contacts a policy 630 server after receiving a 488 response from a domain and before re- 631 sending the request, session policies are always applied to a request 632 in the order in which the request traverses through the domains. The 633 UAC MUST NOT change this implicit order among policy servers. 635 A UAC frequently needs to contact the policy server in the local 636 domain before sending a new request. To avoid the retransmission of 637 the local policy server URI in a 488 for each new request, a UA 638 SHOULD cache the URI of the local policy server (see Section 4.4.4). 639 It SHOULD use the cached policy server URI to contact the local 640 policy server before sending a request that initiates the first 641 offer/answer exchange in a dialog (e.g. an INVITE request). 643 A UAC may need to initiate subsequent offer/answer exchanges in a 644 dialog (e.g. using INVITE, UPDATE or PRACK requests) to re-negotiate 645 the session description. When creating such a mid-dialog request, a 646 UAC SHOULD contact the same policy servers it has contacted during 647 the initial offer/answer exchange in the dialog (see Section 4.4.5) 648 before sending the request. This avoids the retransmission of all 649 policy server URIs in 488 responses for mid-dialog requests. 651 4.4.2. Proxy Behavior 653 A proxy provides rendezvous functionality for UAs and a policy 654 server. This is achieved by conveying the URI of a policy server to 655 the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK 656 requests (or any other request that can initiate an offer/answer 657 exchange). 659 If such a request contains a Supported header field with the option 660 tag "policy", the proxy MAY reject the request with a 488 response to 661 provide the local policy server URI to the UAC. Before rejecting a 662 request, the proxy MUST verify that the request does not have a 663 Policy-Id header field, which already contains the local policy 664 server URI. If the request does not have such a header or the local 665 policy server URI is not present in this header, then the proxy MAY 666 reject the request with a 488. The proxy MUST insert a Policy- 667 Contact header in the 488 response that contains the URI of its 668 associated policy server. The proxy MAY add the header field 669 parameter "non-cacheable" to prevent the UAC from caching this policy 670 server URI (see Section 4.4.4). 672 If the local policy server URI is already present in the Policy-Id 673 header of a request, the proxy MUST NOT reject the request as 674 described above. The proxy SHOULD remove this policy server URI from 675 the Policy-Id header field before forwarding the request. Keeping 676 this URI in the Policy-Id header would just consume space in the 677 message without providing any value and would disclose the URI to 678 subsequent proxies. 680 The proxy MAY insert a Policy-Contact header field into INVITE, 681 UPDATE or PRACK requests (or any other request that can initiate an 682 offer/answer exchange) in order to convey the policy server URI to 683 the UAS. If the request already contains a Policy-Contact header 684 field, the proxy MUST insert the URI ahead of all existing values at 685 the beginning of the list. A proxy MUST NOT change the order of 686 existing Policy-Contact header values. 688 4.4.3. UAS Behavior 690 A UAS may receive an INVITE, UPDATE or PRACK request (or another 691 request that can initiate offer/answer exchanges), which contains a 692 Policy-Contact header filed with a list of policy server URIs. A UAS 693 that receives such a request SHOULD contact all policy server URIs in 694 a Policy-Contact header. The UAS MUST contact the policy server URIs 695 in the order in which they were contained in the Policy-Contact 696 header, starting with the topmost value. 698 4.4.4. Caching Policy Server URIs 700 A UAC may frequently need to contact the policy server in the local 701 domain before sending a request. To avoid the retransmission of the 702 local policy server URI for each new request, each UA SHOULD cache 703 the URI of the local policy server. A UA may receive this URI in a 704 Policy-Contact header inserted by the local proxy into a 488 response 705 or a request. Alternatively, the UA may also have received the local 706 policy server URI through configuration or other means. If a UA has 707 received a local policy server URI through configuration and receives 708 another one in a Policy-Contact header, it SHOULD overwrite the 709 configured URI with the most recent one received in a Policy-Contact 710 header. 712 Domains can prevent a UA from caching the local policy server URI. 713 This is useful, for example, if the policy server does not need to be 714 involved in all sessions or the policy server URI changes from 715 session to session. A proxy can mark the URI of such a local policy 716 server as "non-cacheable". A UA MUST NOT cache a non-cacheable 717 policy server URI. It SHOULD remove the current URI from the cache 718 when receiving a "non-cacheable" URI. This is to avoid the use of 719 policy server URIs that are outdated. 721 The UA SHOULD NOT cache policy server URIs it has received from 722 proxies outside of the local domain. These policy servers may not be 723 relevant for subsequent sessions, which may go to a different 724 destination, traversing different domains. 726 4.4.5. Storing Policy Server URIs in a Dialog 728 A UA discovers the list of policy servers relevant for a dialog 729 during the initial offer/answer exchange. It SHOULD store this list 730 of policy server URIs for a dialog, as part of the dialog state. The 731 UA SHOULD maintain this list until the dialog is terminated. It 732 SHOULD store policy server URIs in this list even if they are marked 733 as "non-cacheable". The non-cacheable parameter only refers to 734 caching policy server URIs for re-use between dialogs. 736 If a UAC has contacted all stored policy servers before sending a 737 mid-dialog request and receives a 488 in response to this request 738 with a Policy-Contact header containing a new policy server URI, it 739 MUST discard the stored policy server URI list for the current 740 dialog. Receiving a 488 response at this point indicates that the 741 set of policy servers relevant for the current dialog has changed. 742 The UAC SHOULD retry sending the request as if it was the first 743 request in a dialog (i.e. without applying any policies except 744 policies from the local policy server). This way, the UAC will re- 745 discover the list of policy server URIs relevant for the current 746 request. 748 If a UAS receives a mid-dialog request with a Policy-Contact header 749 containing a list of policy server URIs that is different from the 750 list stored for the dialog, then the UAS SHOULD replace the stored 751 list with the one received in the Policy-Contact header field. 753 4.4.6. Contacting the Policy Server 755 A UA compliant to this specification SHOULD contact the discovered 756 policy servers and apply session policies to an offer or answer 757 before using the offer or answer. 759 Some session policies only apply to the offer whereas other policies 760 apply to the offer as well as the answer. A UA that contacts a 761 policy server UA SHOULD disclose the offer to the policy server. A 762 UA SHOULD disclose the answer to the policy server, unless the policy 763 server has indicated on the policy channel (when processing the 764 offer) that the disclosure of the answer is not needed for this 765 session. When disclosing the answer to the policy servers, the UA 766 MUST contact the same policy servers it has contacted for the offer. 768 A UA that receives a SIP message containing an offer or answer SHOULD 769 completely process the message (e.g. according to [6]) before 770 contacting the policy server. The SIP processing of the message 771 includes, for example, updating dialog state and timers as well as 772 creating an ACK or PRACK request as necessary. This ensures that 773 contacting a policy server does not interfere with SIP message 774 processing (e.g. by inadvertently causing timers to expire). It 775 implies, for example, that a UAC which has received a response to an 776 INVITE request SHOULD finish the processing of the response including 777 transmitting the ACK before it contacts the policy server. An 778 important exception to this rule is explained in the next paragraph. 780 In some cases, a UA needs to use the offer/answer it has received in 781 a SIP message to complete SIP processing of this message. For 782 example, a UAC that has received an offer in the response to an 783 INVITE request needs to apply policies to the offer and the resulting 784 answer before it can insert the answer into an ACK. In these cases, 785 a UA SHOULD contact the policy server even if this is during the 786 processing of a SIP message. This implies that a UA, which has 787 received an offer in the response of an INVITE request, SHOULD 788 contact the policy server and apply session policies before sending 789 the answer in the ACK. 791 Note: this assumes that the policy server immediately responds to 792 a policy request and does not require manual intervention to 793 create a policy. A delay in the response from the policy server 794 would delay the transmission of the ACK and could trigger 795 retransmissions of the INVITE response (also see the 796 recommendations for Flow I in [9]). 798 4.4.7. Header Definition and Syntax 800 The Policy-Id header field is inserted by the UAC into INVITE, UPDATE 801 or PRACK requests (or any other request that can be used to initiate 802 an offer/answer exchange). The Policy-Id header identifies all 803 policy servers the UAC has contacted for this request. A Policy-Id 804 header value is the URI of a policy server. 806 The syntax of the Policy-Id header field is: 808 Policy-Id = "Policy-Id" HCOLON policyURI 809 *(COMMA policyURI) 810 policyURI = ( SIP-URI / SIPS-URI ) [ SEMI generic-param ] 812 The Policy-Contact header field can be inserted by a proxy into a 488 813 response to INVITE, UPDATE or PRACK requests (or other requests that 814 initiate an offer/answer exchange). It contains a policy server URI 815 that needs to be contacted by the UAC. A proxy MAY add the "non- 816 cacheable" header field parameter to indicate that a UA MUST NOT 817 cache this policy server URI. 819 The Policy-Contact header field can also be inserted by a proxy into 820 INVITE, UPDATE and PRACK requests (or other requests that can be used 821 to initiate an offer/answer exchange). It contains an ordered list 822 of policy server URIs that need to be contacted by the UAS. The UAS 823 starts to process the header field at the topmost value of this list. 824 New header field values are inserted at the top. The Policy-Contact 825 header field effectively forms a stack. The "non-cacheable" header 826 field parameter MUST NOT be used in a request. 828 The syntax of the Policy-Contact header field is: 830 Policy-Contact = "Policy-Contact" HCOLON policyContactURI 831 *(COMMA policyContactURI) 832 policyContactURI = ( SIP-URI / SIPS-URI ) 833 [ SEMI "non-cacheable" / generic-param ] 835 The BNF for SIP-URI, IPS-URI and generic-param is defined in [6]. 837 Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' 838 is for the UPDATE method [5]. 840 Header field where proxy ACK BYE CAN INV OPT REG UPD 841 _______________________________________________________________ 842 Policy-Id R rd - - - o - - o 843 Policy-Contact R a - - - o - - o 844 Policy-Contact 488 a - - - o - - o 845 Table 1: Policy-Id and Policy-Contact Header Fields 847 4.5. Policy Subscription 849 The rendezvous mechanism described in the previous section enables 850 proxies to deliver the URIs of policy servers to the UAC and UAS. 851 This section describes the mechanism for the policy channel, i.e. the 852 protocol UAs use to contact the policy servers. The main task of the 853 policy channel is to enable a UA to submit information about the 854 session it is trying to establish (i.e. the offer and the answer) to 855 a policy server and to receive the resulting session-specific 856 policies and possible updates to these policies in response. 858 A UA compliant to this specification MUST implement the Event Package 859 for Session-Specific Session Policies [2]. It contacts a policy 860 server by subscribing to this event package. 862 When subscribing to session-specific policies, the UA discloses 863 information about the session it is trying to establish to the policy 864 server as described in [2]. This information is used by the policy 865 server to determine the session-specific policy for this session. 866 The policy server returns the policies that apply to this session in 867 NOTIFY messages. It returns an initial set of policies when the 868 subscription is established and may notify the UA when there are 869 updates to these policies. Complete call flow examples for session- 870 specific policies that include policy channel messages can be found 871 in Appendix B. 873 A UA SHOULD use the policies it has received from the policy server 874 in the current session (i.e. the session the subscription is for). 876 When a UA receives a notification about a change in the current 877 policies, it SHOULD apply the updated policies to the current 878 session. If this update causes a change in the session description 879 of a session, the UA may need to re-negotiate the modified session 880 description with its peer UA, for example, using a re-INVITE or 881 UPDATE request. For example, if a policy update disallows the use of 882 video and video is part of the current session description, then the 883 UA will need to create an new session description offer without 884 video. After receiving this offer, the peer UA knows that video 885 can't be used any more and responds with the corresponding answer. 886 The re-INVITE or UPDATE message need to be generated in accordance to 887 Section 4.4.1. 889 5. Security Considerations 891 Session policies can significantly change the behavior of a user 892 agent and can be used by an attacker to compromise a user agent. For 893 example, session policies can be used to prevent a user agent from 894 successfully establishing a session (e.g. by setting the available 895 bandwidth to zero). Such a policy can be submitted to the user agent 896 during a session, which will cause the UA to terminate the session. 898 A user agent transmits session information to a policy server for 899 session-specific policies. This session information may contain 900 sensitive data the user may not want an eavesdropper or an 901 unauthorized policy server to see. In particular, the session 902 information may contain the encryption keys for media streams. Vice 903 versa, session policies may also contain sensitive information about 904 the network or service level agreements the service provider may not 905 want to disclose to an eavesdropper or an unauthorized user agent. 907 It is important to secure the communication between the proxy and the 908 user agent (for session-specific policies) as well as the user agent 909 and the policy server. The following four discrete attributes need 910 to be protected: 912 1. integrity of the policy server URI (for session-specific 913 policies), 914 2. mutual authentication between the user agent and the policy 915 server, 916 3. confidentiality of the messages exchanged between the user agent 917 and the policy server and 918 4. ensuring that private information is not exchanged between the 919 two parties, even over an confidentiality-assured and 920 authenticated session. 922 To protect the integrity of the policy server URI, a UA SHOULD use a 923 secured transport protocol such as TLS between proxies and the UA. 924 Protecting the integrity of the policy server URI is important since 925 an attacker could intercept SIP messages between the UA and proxy and 926 remove the policy headers needed for session-specific policies. This 927 would impede the rendezvous between UA and policy server and, since 928 the UA would not contact the policy server, may prevent a UA from 929 setting up a session. 931 Instead of removing a policy server URI, an attacker can also modify 932 the policy server URI and point the UA to a compromised policy 933 server. To prevent such an attack from being effective, it is 934 RECOMMENDED that a UA authenticates policy servers. 936 It is RECOMMENDED that administrators use SIPS URIs as policy server 937 URIs so that subscriptions to session policies are transmitted over 938 TLS. 940 The above security attributes are important to protect the 941 communication between the user agent and policy server. This 942 document does not define the protocol used for the communication 943 between user agent and policy server and merely refers to other 944 specifications for this purpose. The security considerations of 945 these specifications need to address the above security aspects. 947 6. IANA Considerations 949 6.1. Registration of the "Policy-Id" Header 951 Name of Header: Policy-Id 953 Short form: none 955 Normative description: Section 4.4.7 of this document 957 6.2. Registration of the "Policy-Contact" Header 959 Name of Header: Policy-Contact 961 Short form: none 963 Normative description: Section 4.4.7 of this document 965 6.3. Registration of the "policy" SIP Option-Tag 967 Name of option: policy 969 Description: Support for the Policy-Contact and Policy-Id headers. 971 SIP headers defined: Policy-Contact, Policy-Id 973 Normative description: This document 975 Appendix A. Acknowledgements 977 Many thanks to Allison Mankin for the discussions and the suggestions 978 for this draft and to Roni Even, Bob Penfield, Mary Barnes and Shida 979 Schubert for reviewing the draft and providing feedback. Many thanks 980 to Vijay Gurbani for the comments and feedback. 982 Appendix B. Session-Specific Policies - Call Flows 984 The following call flows illustrate the overall operation of session- 985 specific policies. The call flows contain all messages needed for 986 UA/policy server rendezvous and the policy subscription. 988 The following abbreviations are used: 990 o: offer 991 o': offer modified by a policy 992 po: offer policy 993 a: answer 994 a': answer modified by a policy 995 pa: answer policy 996 ps uri: policy server URI (in Policy-Contact header) 997 ps id: policy server id (in Policy-Id header) 999 B.1. Offer in Invite 1000 UA A P A PS A PS B P B UA B 1001 | | | | | | 1002 |(1) INV | | | | 1003 |-------->| | | | | 1004 |(2) 488 | | | | 1005 |<--------| | | | | 1006 |(3) ACK | | | | | 1007 |-------->| | | | | 1008 |(4) SUBSCRIBE | | | | 1009 |------------------>| | | | 1010 |(5) 200 OK | | | | 1011 |<------------------| | | | 1012 |(6) NOTIFY | | | | 1013 |<------------------| | | | 1014 |(7) 200 OK | | | | 1015 |------------------>| | | | 1016 |(8) INV | | | | 1017 |-------->| | | | | 1018 | |(9) INV | | | 1019 | |---------------------------->| | 1020 | | | | |(10) INV 1021 | | | | |-------->| 1022 | | | |(11) SUBSCRIBE 1023 | | | |<------------------| 1024 | | | |(12) 200 OK | 1025 | | | |------------------>| 1026 | | | |(13) NOTIFY 1027 | | | |------------------>| 1028 | | | |(14) 200 OK | 1029 | | | |<------------------| 1030 | | | | |(15) 200 OK 1031 | | | | |<--------| 1032 | |(16) 200 OK | | | 1033 | |<----------------------------| | 1034 |(17) 200 OK | | | | 1035 |<--------| | | | | 1036 |(18) ACK | | | | | 1037 |------------------------------------------------>| 1038 |(19) SUBSCRIBE | | | 1039 |------------------>| | | | 1040 |(20) 200 OK | | | | 1041 |<------------------| | | | 1042 |(21) NOTIFY | | | | 1043 |<------------------| | | | 1044 |(22) 200 OK | | | | 1045 |------------------>| | | | 1046 | | | | | | 1047 | | | | | | 1049 B.2. Offer in Response 1051 UA A P A PS A PS B P B UA B 1052 | | | | | | 1053 |(1) INV | | | | | 1054 |-------->| | | | | 1055 |(2) 488 | | | | 1056 |<--------| | | | | 1057 |(3) ACK | | | | | 1058 |-------->| | | | | 1059 |(4) SUBSCRIBE | | | | 1060 |------------------>| | | | 1061 |(5) 200 OK | | | | 1062 |<------------------| | | | 1063 |(6) NOTIFY | | | | 1064 |<------------------| | | | 1065 |(7) 200 OK | | | | 1066 |------------------>| | | | 1067 |(8) INV | | | | 1068 |-------->| | | | | 1069 | |(9) INV | | | | 1070 | |---------------------------->| | 1071 | | | | |(10) INV 1072 | | | | |-------->| 1073 | | | |(11) SUBSCRIBE | 1074 | | | |<------------------| 1075 | | | |(12) 200 OK | 1076 | | | |------------------>| 1077 | | | |(13) NOTIFY | 1078 | | | |------------------>| 1079 | | | |(14) 200 OK | 1080 | | | |<------------------| 1081 | | | | |(15) 200 OK 1082 | | | | |<--------| 1083 | |(16) 200 OK | | | 1084 | |<----------------------------| | 1085 |(17) 200 OK | | | | 1086 |<--------| | | | | 1087 |(18) SUBSCRIBE | | | 1088 |------------------>| | | | 1089 |(19) 200 OK | | | | 1090 |<------------------| | | | 1091 |(20) NOTIFY | | | 1092 |<------------------| | | | 1093 |(21) 200 OK | | | | 1094 |------------------>| | | | 1095 |(22) ACK | | | | 1096 |------------------------------------------------>| 1097 | | | |(23) SUBSCRIBE 1098 | | | |<------------------| 1099 | | | |(24) 200 OK | 1100 | | | |------------------>| 1101 | | | |(25) NOTIFY 1102 | | | |------------------>| 1103 | | | |(26) 200 OK | 1104 | | | |<------------------| 1105 | | | | | | 1106 | | | | | | 1108 7. References 1110 7.1. Normative References 1112 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1113 Levels", BCP 14, RFC 2119, March 1997. 1115 [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) 1116 Event Package for Session-Specific Session Policies.", 1117 draft-ietf-sipping-policy-package-01 (work in progress), 1118 April 2006. 1120 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 1121 Data Set for Media Policy", 1122 draft-ietf-sipping-media-policy-dataset-01 (work in progress), 1123 March 2006. 1125 [4] Petrie, D., "A Framework for Session Initiation Protocol User 1126 Agent Profile Delivery", draft-ietf-sipping-config-framework-09 1127 (work in progress), October 2006. 1129 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1130 Method", RFC 3311, October 2002. 1132 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1133 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1134 Session Initiation Protocol", RFC 3261, June 2002. 1136 7.2. Informative References 1138 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1139 Protocol", RFC 2327, April 1998. 1141 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1142 Session Description Protocol (SDP)", RFC 3264, June 2002. 1144 [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1145 "Best Current Practices for Third Party Call Control (3pcc) in 1146 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1147 April 2004. 1149 Authors' Addresses 1151 Volker Hilt 1152 Bell Labs/Lucent Technologies 1153 101 Crawfords Corner Rd 1154 Holmdel, NJ 07733 1155 USA 1157 Email: volkerh@bell-labs.com 1159 Gonzalo Camarillo 1160 Ericsson 1161 Hirsalantie 11 1162 Jorvas 02420 1163 Finland 1165 Email: Gonzalo.Camarillo@ericsson.com 1167 Jonathan Rosenberg 1168 Cisco Systems 1169 600 Lanidex Plaza 1170 Parsippany, NJ 07054 1171 USA 1173 Email: jdrosen@cisco.com 1175 Full Copyright Statement 1177 Copyright (C) The Internet Society (2006). 1179 This document is subject to the rights, licenses and restrictions 1180 contained in BCP 78, and except as set forth therein, the authors 1181 retain all their rights. 1183 This document and the information contained herein are provided on an 1184 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1185 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1186 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1187 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1188 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1189 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1191 Intellectual Property 1193 The IETF takes no position regarding the validity or scope of any 1194 Intellectual Property Rights or other rights that might be claimed to 1195 pertain to the implementation or use of the technology described in 1196 this document or the extent to which any license under such rights 1197 might or might not be available; nor does it represent that it has 1198 made any independent effort to identify any such rights. Information 1199 on the procedures with respect to rights in RFC documents can be 1200 found in BCP 78 and BCP 79. 1202 Copies of IPR disclosures made to the IETF Secretariat and any 1203 assurances of licenses to be made available, or the result of an 1204 attempt made to obtain a general license or permission for the use of 1205 such proprietary rights by implementers or users of this 1206 specification can be obtained from the IETF on-line IPR repository at 1207 http://www.ietf.org/ipr. 1209 The IETF invites any interested party to bring to its attention any 1210 copyrights, patents or patent applications, or other proprietary 1211 rights that may cover technology that may be required to implement 1212 this standard. Please address the information to the IETF at 1213 ietf-ipr@ietf.org. 1215 Acknowledgment 1217 Funding for the RFC Editor function is provided by the IETF 1218 Administrative Support Activity (IASA).