idnits 2.17.1 draft-ietf-sipping-policy-package-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The notifier may keep up the subscription after rejecting a session to indicate that it may send an updated policy decision for this session to the subscriber at a later time. This is useful, for example, if the session was rejected due to a temporary shortage of resources and the notifier expects that this problem to be resolved shortly. In this case, the subscriber SHOULD not terminate the subscription to session-specific policies. -- 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 (August 22, 2007) is 6091 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) ** Obsolete normative reference: RFC 4346 (ref. '2') (Obsoleted by RFC 5246) == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-02 ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-sip-session-policy-framework-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '9') (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 5 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/Alcatel-Lucent 4 Intended status: Standards Track G. Camarillo 5 Expires: February 23, 2008 Ericsson 6 August 22, 2007 8 A Session Initiation Protocol (SIP) Event Package for Session-Specific 9 Session Policies. 10 draft-ietf-sipping-policy-package-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 23, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines a Session Initiation Protocol (SIP) event 44 package for session-specific policies. This event package enables 45 user agents to subscribe to session policies for a SIP session and to 46 receive notifications if these policies change. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Event Package Formal Definition . . . . . . . . . . . . . . . 4 53 3.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 55 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 4 56 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 5 57 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5 58 3.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 6 59 3.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 8 60 3.8. Notifier generation of NOTIFY requests . . . . . . . . . . 9 61 3.9. Subscriber processing of NOTIFY requests . . . . . . . . . 10 62 3.10. Handling of forked requests . . . . . . . . . . . . . . . 11 63 3.11. Rate of notifications . . . . . . . . . . . . . . . . . . 11 64 3.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 16 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 Intellectual Property and Copyright Statements . . . . . . . . . . 18 76 1. Introduction 78 The Framework for Session Initiation Protocol (SIP) [5] Session 79 Policies [7] defines a protocol framework that enables a proxy to 80 define and impact policies on sessions such as the codecs or media 81 types to be used. This framework identifies two types of session 82 policies: session-specific and session-independent policies. 83 Session-specific policies are policies that are created for one 84 particular session, based on the session description of this session. 85 They enable a network intermediary to inspect the session description 86 a UA is proposing and to return a policy specifically generated for 87 this session description. For example, an intermediary could open 88 pinholes in a firewall/NAT for each media stream in a session and 89 return a policy that replaces the internal IP addresses and ports in 90 the session description with external ones. Since session-specific 91 policies are tailored to a session, they only apply to the session 92 they are created for. A user agent requests session-specific 93 policies on a session-by-session basis at the time a session is 94 created and the session description is known. Session-independent 95 policies on the other hand are policies that are created independent 96 of a session and generally apply to all the SIP sessions set up by a 97 user agent. 99 The Framework for SIP Session Policies [7] defines a mechanism that 100 enables UAs to discover the URIs of session-specific policy servers. 101 This specification defines a SIP event package [4] that enables UAs 102 to subscribe to session-specific policies on a policy server. 103 Subscribing to session-specific policies involves the following steps 104 (see the Session Policy Framework [7]): 106 1. A user agent submits the details of the session it is trying to 107 establish to the policy server and asks whether a session using 108 these parameters is permissible. For example, a user agent might 109 propose a session that contains the media types audio and video. 110 2. The policy server generates a policy decision for this session 111 and returns the decision to the user agent. Possible policy 112 decisions are (1) to deny the session, (2) to propose changes to 113 the session parameters with which the session would be 114 acceptable, or (3) to accept the session as it was proposed. An 115 example for a policy decision is to disallow the use of video but 116 agree to all other aspects of the proposed session. 117 3. The policy server can update the policy decision at a later time. 118 A policy decision update can require additional changes to the 119 session (e.g., because the available bandwidth has changed) or 120 deny a previously accepted session (i.e., disallow the 121 continuation of a session). 123 The event package for session-specific policies enables a user agent 124 to subscribe to the policies for a SIP session following the above 125 model. The subscriber initiates a subscription by submitting the 126 details of the session it is trying to establish to the notifier 127 (i.e., the policy server) in the body of a SUBSCRIBE request. The 128 notifier uses this information to determine the policy decision for 129 this session. It conveys the initial policy decision to the 130 subscriber in a NOTIFY and all changes to this decision in subsequent 131 NOTIFYs. 133 2. Terminology 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 137 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 138 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 139 compliant implementations. 141 3. Event Package Formal Definition 143 This document provides the details for defining a SIP event package 144 as required by RFC 3265 [4]. 146 3.1. Event Package Name 148 The name of the event package defined in this specification is 149 "session-spec-policy". 151 3.2. Event Package Parameters 153 This package defines the optional event package parameter "local- 154 only". This parameter is only defined for NOTIFY requests and MUST 155 be ignored if received in a SUBSCRIBE request. The usage of the 156 "local-only" parameter is described in Section 3.3, Section 3.8 and 157 Section 3.9. 159 3.3. SUBSCRIBE Bodies 161 A SUBSCRIBE for this event package MUST contain a body that describes 162 a SIP session. The purpose of this body is to enable the notifier to 163 generate the policies the subscriber is interested in. In this event 164 package, the Request-URI, the event package name and event parameters 165 are not sufficient to determine the resource a subscription is for. 166 However, with the session description in the SUBSCRIBE body, the 167 notifier can generate the requested policy decision and create policy 168 events for this resource. 170 All subscribers and notifiers MUST support the MIME type 171 "application/media-policy-dataset+xml" as defined in the User Agent 172 Profile Data Set for Media Policy [3]. The "application/ 173 media-policy-dataset+xml" format is the default format for SUBSCRIBE 174 bodies in this event package. Subscribers and notifiers MAY 175 negotiate the use of other formats capable of representing a session. 177 Note: It has been proposed to directly use SDP [9] instead of 178 encoding the session descriptions in the Media Policy [3] format. 179 However, using a separate format such as the Media Policy format 180 has a number of advantages over the direct use of SDP: i) the 181 Media Policy format is more flexible and allows the inclusion of 182 information that can't be expressed in SDP (e.g., the target URI), 183 ii) the Media Policy format enables the encoding of local and 184 remote session descriptions in a single document (not requiring 185 the use of MIME multipart and new content disposition types), and 186 iii) it aligns the formats used for session-specific and session- 187 independent policies. A drawback is that it requires the UA to 188 encode SDP and session information in Media Policy documents. 190 3.4. Subscription Duration 192 A subscription to the session-specific policy package is usually 193 established at the beginning of a session and terminated when the 194 corresponding session ends. A typical duration of a phone call is a 195 few minutes. 197 Since the duration of a subscription to the session-specific policy 198 package is related to the lifetime of the corresponding session, the 199 value for the duration of a subscription is largely irrelevant. 200 However, the duration SHOULD be longer than the typical duration of a 201 session. The default subscription duration for this event package is 202 set to two hours. 204 A subscription MAY be terminated before a session ends by the 205 notifier. For example, a notifier may terminate the subscription 206 after the initial policy notification has been sent to the subscriber 207 if it knows that these policies will not change during the session. 208 A subscriber MUST NOT terminate a subscription unless it is 209 terminating the session this subscription is for or discovers that 210 the notifier has been removed from the list of policy servers 211 relevant for this session (see the Session Policy Framework [7]). 213 3.5. NOTIFY Bodies 215 In this event package, the body of a notification contains the 216 session policy requested by the subscriber. All subscribers and 217 notifiers MUST support the format "application/ 218 media-policy-dataset+xml" [3] as a format for NOTIFY bodies. 220 The SUBSCRIBE request MAY contain an Accept header field. If no such 221 header field is present, it has a default value of "application/ 222 media-policy-dataset+xml". If the header field is present, it MUST 223 include "application/media-policy-dataset+xml", and MAY include any 224 other MIME type capable of representing session-specific policies. 225 As defined in RFC 3265 [4], the body of notifications MUST be in one 226 of the formats defined in the Accept header of the SUBSCRIBE request 227 or in the default format. 229 If the notifier uses the same format in NOTIFY bodies that was used 230 by the subscriber in the SUBSCRIBE body (e.g., "application/ 231 media-policy-dataset+xml"), the notifier can expect that the 232 subscriber supports all format extensions that were used in the 233 SUBSCRIBE body. The notifier cannot assume that the subscriber 234 supports other extensions beyond that and SHOULD NOT use such 235 extensions. 237 If the SUBSCRIBE request contained a representation of the local 238 session description and the subscription was accepted, then the 239 NOTIFY body MUST contain a policy for the local session description. 240 If the SUBSCRIBE request of an accepted subscription contained the 241 local and the remote session description, then the NOTIFY body MUST 242 contain two policies, one for the local and one for the remote 243 session description. 245 3.6. Subscriber generation of SUBSCRIBE requests 247 The subscriber follows the general rules for generating SUBSCRIBE 248 requests defined in RFC 3265 [4]. The subscriber MUST provide 249 sufficient information in the SUBSCRIBE body to fully describe the 250 session for which it seeks to receive session-specific policies. The 251 subscriber MUST use the most recent session description as a basis 252 for this information. 254 If the "application/media-policy-dataset+xml" format is used in 255 SUBSCRIBE bodies, the subscriber MUST provide a value for each field 256 that is defined for session information documents [3] and for which 257 the subscriber has information available. In other words, the 258 subscriber MUST fill in the elements of a session information 259 document as complete as possible. If the subscriber supports 260 extensions of the "application/media-policy-dataset+xml" format, the 261 subscriber MUST also provide a value for each field defined by this 262 extension for session information documents, if possible. Providing 263 as much information as possible avoids that a session is rejected due 264 to a lack of session information and the negotiation of the 265 information to be disclosed between notifier and subscriber. 267 Subscriptions to this event package are typically created in 268 conjunction with an SDP offer/answer exchange [8] during the 269 establishment of a session (see the Session Policy Framework [7]). 270 If used with an offer/answer exchange, the subscriber MUST insert the 271 representation of the local session description in the SUBSCRIBE 272 body. The local session description is the one that was created by 273 the subscriber (e.g., the offer if the subscriber has initiated the 274 offer/answer exchange). Under certain circumstances, a UA may not 275 have a session description when subscribing to session-specific 276 policies, for example, when it is composing an empty INVITE request 277 (i.e., an INVITE request that does not contain an offer). In these 278 cases, a UA SHOULD establish a subscription without including a 279 representation of the local session description. The UA MUST send 280 another SUBSCRIBE request that contains this session description as 281 soon as the session description becomes available, for example, when 282 the UA receives a 200 OK to an empty INVITE request. A policy server 283 can choose to admit a session only after the UA has disclosed the 284 session descriptions. 286 The subscriber SHOULD also include a representation of the remote 287 session description in the SUBSCRIBE body. The remote session 288 description is the one the subscriber has received (i.e., the answer 289 if the subscriber has initiated the offer/answer exchange). In some 290 scenarios, the remote session description is not available to the 291 subscriber at the time the subscription to session-specific policies 292 is established. In this case, the initial SUBSCRIBE message SHOULD 293 only contain a representation of the local session description. When 294 the remote description becomes available, the subscriber SHOULD 295 refresh the subscription by sending another SUBSCRIBE request, which 296 then contains the local and the remote session description, unless 297 the subscriber has received a NOTIFY with the "local-only" parameter. 298 This parameter indicates that the notifier does not need to see the 299 remote session description. 301 A user agent can change the session description of an ongoing 302 session. A change in the session description will typically affect 303 the policy decisions for this session. A subscriber MUST refresh the 304 subscription to session-specific policies every time the session 305 description of a session changes. It does this by sending a 306 SUBSCRIBE request, which contains the details of the updated session 307 descriptions. 309 A subscriber may receive a error that indicates a server failure in 310 response to a SUBSCRIBE request. In this case, the subscriber SHOULD 311 try to locate an alternative server, for example, using the 312 procedures described in [6]. If no alternative server can be 313 located, the subscriber MAY continue with the session for which it 314 wanted to receive session-specific policies without subscribing to 315 session-specific policies. This is to avoid that a failed policy 316 server prevents a UA from setting up or continuing with a session. 317 Since the sessions created by the UA may not be policy compliant 318 without this subscription, they may be blocked by policy enforcement 319 mechanisms if they are in place. 321 Session policies can contain sensitive information. Moreover, policy 322 decisions can significantly impact the behavior of a user agent. A 323 user agent should therefore verify the identity of a policy server 324 and make sure that policies have not been altered in transit. All 325 implementations of this package MUST support TLS [2] and the SIPS URI 326 scheme. A subscriber SHOULD use SIPS URIs when subscribing to 327 session-specific policies so that policies are transmitted over TLS. 328 See Section 4. 330 3.7. Notifier processing of SUBSCRIBE requests 332 All subscriptions to session-specific policies SHOULD be 333 authenticated and authorized before approval. However, a policy 334 server may frequently encounter UAs it cannot authenticate. In these 335 cases, the policy server MAY provide a generic policy that does not 336 reveal sensitive information to these UAs. For details see 337 Section 4. 339 The authorization policy is at the discretion of the administrator. 340 In general, all users SHOULD be allowed to subscribe to the session- 341 specific policies of their sessions. A subscription to this event 342 package will typically be established by a device that needs to know 343 about the policies for its sessions. However, subscriptions may also 344 be established by applications (e.g., a conference server). In those 345 cases, an authorization policy will typically be provided for these 346 applications. 348 Responding in a timely manner to a SUBSCRIBE request is crucial for 349 this event package. A notifier must minimize the time needed for 350 processing SUBSCRIBE requests and generating the initial NOTIFY. 351 This includes minimizing the time needed to generate an initial 352 policy decision. A short response time is in particular important 353 for this event package since it minimizes the delay for fetching 354 policies during an INVITE transaction and therefore reduces call 355 setup time. In addition, subscriptions to session-specific policies 356 can be established while the subscriber is in an INVITE transaction 357 at a point where it has received the 200 OK but before sending the 358 ACK. Delaying the creation of the initial NOTIFY would delay the 359 transmission of the ACK. A more detailed discussion of this scenario 360 can be found in the Session Policy Framework [7]. 362 A subscriber may not have disclosed enough information in the 363 SUBSCRIBE request to enable the notifier to generate a policy 364 decision. For example, a UA may have subscribed to session-specific 365 policies without including the representation of a session 366 description. The policy server SHOULD accept such a subscription. 367 However, the policy server SHOULD generate a NOTIFY request that 368 indicates that a policy decision could not be made due to 369 insufficient information. This can be expressed by either generating 370 a NOTIFY request with an empty body or by inserting a corresponding 371 policy decision document into the NOTIFY body. 373 3.8. Notifier generation of NOTIFY requests 375 A notifier sends a notification in response to SUBSCRIBE requests as 376 defined in RFC 3265 [4]. In addition, a notifier MAY send a 377 notification at any time during the subscription. Typically, it will 378 send one every time the policy decision this subscription is for has 379 changed. When and why a policy decision changes is entirely at the 380 discretion of the administrator. A policy decision can change for 381 many reasons. For example, a network may become congested due to an 382 increase in traffic and reduces the bandwidth available to an 383 individual user. Another example is a session that has been started 384 during "business hours" and continues into "evening hours" where more 385 bandwidth or video sessions are available to the user according to 386 the service level agreement. 388 Policy decisions are expressed in the format negotiated for the 389 NOTIFY body (e.g., "application/media-policy-dataset+xml"). The 390 policy document in a NOTIFY body MUST represent a complete policy 391 decision. Notifications that contain the deltas to previous policy 392 decisions or partial policy decisions are not supported in this event 393 package. 395 The notifier SHOULD terminate the subscription if the policy decision 396 is to reject a session and if it can be expected that this decision 397 will not change in the foreseeable future. The notifier SHOULD keep 398 the subscription alive, if it rejects a session but expects that the 399 session can be admitted soon. For example, if the session was 400 rejected due to a temporary shortage of resources and the notifier 401 expects that these resources will become available again shortly it 402 should keep the subscription alive. The decision to reject a session 403 is expressed in the policy decision document. A session is admitted 404 by returning a policy decision document that requires some or no 405 changes to the session. 407 If the notifier has not received enough information to make a policy 408 decision from the subscriber (e.g., because it did not receive a 409 session description), the notifier SHOULD NOT terminate the 410 subscription since it can be expected that the UA refreshes the 411 subscription with a SUBSCRIBE request that contains more information. 412 The notifier SHOULD generate a NOTIFY request with an empty body or 413 with a body that contains a policy decision document indicating that 414 the decision could not be made. 416 Some session-specific policies do not require the disclosure of the 417 remote session description to the notifier. If a notifier determines 418 that this is the case after receiving a SUBSCRIBE request, the 419 notifier SHOULD include the "local-only" event parameter in NOTIFY 420 requests. 422 3.9. Subscriber processing of NOTIFY requests 424 A subscriber MUST apply the policy decision received in a NOTIFY to 425 the session associated with this subscription. If the UA decides not 426 to apply the received policy decision, the UA MUST NOT set up the 427 session and MUST terminate the session if the session is already in 428 progress. If the UA has a pending INVITE transaction for this 429 session, the UA MUST cancel or reject the INVITE request. 431 If the subscriber receives a NOTIFY indicating that the session has 432 been rejected, the subscriber MUST NOT attempt to establish this 433 session. If the notifier has terminated the subscription after 434 rejecting the session, the subscriber SHOULD NOT try to re-send the 435 same SUBSCRIBE request again. The termination of the subscription by 436 the notifier indicates that the policy decision for this session is 437 final and will not change in the foreseeable future. The subscriber 438 MAY only try to re-subscribe for this session if at least one aspect 439 of the session (e.g., a parameter in the session description or the 440 target URI) has changed. 442 The notifier may keep up the subscription after rejecting a session 443 to indicate that it may send an updated policy decision for this 444 session to the subscriber at a later time. This is useful, for 445 example, if the session was rejected due to a temporary shortage of 446 resources and the notifier expects that this problem to be resolved 447 shortly. In this case, the subscriber SHOULD not terminate the 448 subscription to session-specific policies. 450 The subscriber may receive a NOTIFY which indicates that the 451 SUBSCRIBE request did not contain enough information. The subscriber 452 SHOULD re-subscribe with more complete information as soon as the 453 missing information (e.g., the session description) is available. 455 A subscriber may receive an update to a policy decision for a session 456 that is already established. The subscriber MUST apply the new 457 policy decision to this session. If a UA decides that it does not 458 want to apply the new policy decision, the UA MUST terminate the 459 session. An updated policy decision may require the UA to generate a 460 re-INVITE or UPDATE request in this session if the session 461 description has changed or it may need to terminate this session. A 462 policy update that requires a UA to terminate a session can, for 463 example, be triggered by the users account running out of credit or 464 the detection of an emergency that requires the termination of non- 465 emergency calls. 467 If the subscriber receives a NOTIFY that contains the "local-only" 468 event parameter, the subscriber SHOULD NOT include the remote session 469 description in subsequent SUBSCRIBE requests within this 470 subscription. 472 3.10. Handling of forked requests 474 This event package allows the creation of only one dialog as a result 475 of an initial SUBSCRIBE request. The techniques to achieve this 476 behavior are described in [4]. 478 3.11. Rate of notifications 480 It is anticipated that the rate of policy changes will be very low. 481 In any case, notifications SHOULD NOT be generated at a rate of more 482 than once every five seconds. 484 3.12. State Agents 486 State agents play no role in this package. 488 3.13. Examples 490 The following message flow illustrates how a user agent (Alice's 491 phone) can subscribe to session-specific policies when establishing a 492 call (here to Bob's phone). The flow assumes that the user agent has 493 already received the policy server URI (e.g., through configuration 494 or as described in the Session Policy Framework [7]) and it does not 495 show messages for authentication on a transport or SIP level. 497 These call flow examples are informative and not normative. 498 Implementers should consult the main text of this document for exact 499 protocol details. 501 Policy Server Alice Bob 502 | | | 503 |(1) SUBSCRIBE | | 504 |<------------------| | 505 |(2) 200 OK | | 506 |------------------>| | 507 |(3) NOTIFY | | 508 |------------------>| | 509 |(4) 200 OK | | 510 |<------------------| | 511 | |(5) INVITE | 512 | |------------------>| 513 | | | 514 | |(6) 200 OK | 515 | |<------------------| 516 | |(7) ACK | 517 | |------------------>| 518 |(8) SUBSCRIBE | | 519 |<------------------| | 520 |(9) 200 OK | | 521 |------------------>| | 522 |(10) NOTIFY | | 523 |------------------>| | 524 |(11) 200 OK | | 525 |<------------------| | 526 | | | 528 Message Details 530 (1) SUBSCRIBE Alice -> Policy Server 532 SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0 533 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 534 ;branch=z9hG4bK74bf 535 Max-Forwards: 70 536 From: Alice ;tag=8675309 537 To: PS 538 Call-ID: rt4353gs2egg@pc.biloxi.example.com 539 CSeq: 1 SUBSCRIBE 540 Contact: 541 Expires: 7200 542 Event: session-spec-policy 543 Accept: application/media-policy-dataset+xml 544 Content-Type: application/media-policy-dataset+xml 545 Content-Length: ... 547 [Local session description (offer)] 549 (2) 200 OK Policy Server -> Alice 550 (3) NOTIFY Policy Server -> Alice 552 NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0 553 Via: SIP/2.0/TLS srvr.biloxi.example.com:5061 554 ;branch=z9hG4bK74br 555 Max-Forwards: 70 556 From: PS ;tag=31451098 557 To: Alice ;tag=8675309 558 Call-ID: rt4353gs2egg@pc.biloxi.example.com 559 CSeq: 1 NOTIFY 560 Event: session-spec-policy 561 Subscription-State: active;expires=7200 562 Content-Type: application/media-policy-dataset+xml 563 Content-Length: ... 565 [Policy for local session description (offer)] 567 (4) 200 OK Alice -> Policy Server 569 (5) INVITE Alice -> Bob 571 (6) 200 OK Bob -> Alice 573 (7) ACK Alice -> Bob 575 (8) SUBSCRIBE Alice -> Policy Server 577 SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0 578 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 579 ;branch=z9hG4bKna998sl 580 Max-Forwards: 70 581 From: Alice ;tag=8675309 582 To: PS ;tag=31451098 583 Call-ID: rt4353gs2egg@pc.biloxi.example.com 584 CSeq: 2 SUBSCRIBE 585 Expires: 7200 586 Event: session-spec-policy 587 Accept: application/media-policy-dataset+xml 588 Content-Type: application/media-policy-dataset+xml 589 Content-Length: ... 591 [Local session description (offer)] 592 [Remote session description (answer)] 594 (9) 200 OK Policy Server -> Alice 595 (10) NOTIFY Policy Server -> Alice 597 NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0 598 Via: SIP/2.0/TLS srvr.biloxi.example.com:5061 599 ;branch=z9hG4bKna998sk 600 Max-Forwards: 70 601 From: PS ;tag=31451098 602 To: Alice ;tag=8675309 603 Call-ID: rt4353gs2egg@pc.biloxi.example.com 604 CSeq: 2 NOTIFY 605 Event: session-spec-policy 606 Subscription-State: active;expires=7200 607 Content-Type: application/media-policy-dataset+xml 608 Content-Length: ... 610 [Policy for local session description (offer)] 611 [Policy for remote session description (answer)] 613 F6 200 OK Alice -> Policy Server 615 4. Security Considerations 617 Session policies can significantly change the behavior of a user 618 agent and can therefore be used by an attacker to compromise a user 619 agent. For example, session policies can be used to prevent a user 620 agent from successfully establishing a session (e.g., by setting the 621 available bandwidth to zero). Such a policy can be submitted to the 622 user agent during a session, which may cause the UA to terminate the 623 session. 625 A user agent transmits session information to a policy server. This 626 information may contain sensitive data the user may not want an 627 eavesdropper or an unauthorized policy server to see. For example, 628 the session information may contain the encryption keys for media 629 streams. Vice versa, session policies may also contain sensitive 630 information about the network or service level agreements the service 631 provider may not want to disclose to an eavesdropper or an 632 unauthorized user agent. 634 It is therefore important to secure the communication between the 635 user agent and the policy server. The following three discrete 636 attributes need to be protected: 638 1. authentication of the policy server and, if needed, the user 639 agent, 640 2. confidentiality of the messages exchanged between the user agent 641 and the policy server and 642 3. ensuring that private information is not exchanged between the 643 two parties, even over a confidentiality-assured and 644 authenticated session. 646 The confidentiality of the messages exchanged between the two parties 647 can be protected by encrypting the data stream through a TLS session 648 using the cipher suites specified in [5]. 650 Accordingly, policy servers SHOULD be addressable only through a SIPS 651 URI and MUST support TLS. In order to send a subscription to the 652 policy server, the user agent MUST support TLS, although it does not 653 need to possess a certificate. In such a case, the policy server 654 SHOULD authenticate the UA using HTTP Digest. The confidentiality of 655 the communication between the policy server and the user agent will 656 be assured as long as the policy server supports TLS and is reached 657 through a SIPS URI. 659 Authenticating the two parties can be performed using X.509 660 certificates exchanged through TLS and other techniques such as HTTP 661 Digest. When the user agent establishes a TLS session with the 662 policy server, the policy server will present it a X.509 certificate. 663 The user agent SHOULD ensure that the identity of the policy server 664 encoded in the certificate matches the URI that the user received 665 when it used the Session Policy Framework [7] to retrieve a URI of a 666 session-specific policy server. 668 When a policy server receives a new subscription (as opposed to a 669 refresh subscription), the policy server SHOULD try to authenticate 670 the user agent using any means at its disposal. If the user agent 671 has a TLS certificate, the identity of the user agent SHOULD be 672 contained in the certificate, or if the user agent does not possess a 673 certificate, the policy server SHOULD challenge the user agent using 674 HTTP Digest. A policy server may frequently encounter UAs it cannot 675 authenticate. In these cases, the policy server MAY provide a 676 generic policy that does not reveal sensitive information to these 677 UAs. 679 And finally, the fact that the user agent and the policy server have 680 successfully authenticated each other and have established a secure 681 TLS session does not absolve either one from ensuring that they do 682 not communicate sensitive information. For example, a session 683 description may contain sensitive information -- session keys, for 684 example -- that the user agent may not want to share with the policy 685 server; and indeed, the policy server does not need such information 686 to effectively formulate a policy. Thus, the user agent should not 687 insert such sensitive information in a session information document 688 that it sends to the policy server. Likewise, the policy server may 689 have information that is sensitive and of no use to the user agent -- 690 network service level agreements, or network statistics, for example. 691 Thus, the policy server should refrain from transmitting such 692 information to the user agent. 694 5. IANA Considerations 696 5.1. Event Package Name 698 This specification registers an event package, based on the 699 registration procedures defined in RFC 3265 [2]. The following is 700 the information required for such a registration: 702 Package Name: session-spec-policy 704 Package or Template-Package: This is a package. 706 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 707 with the RFC number of this specification). 709 Person to Contact: Volker Hilt, volkerh@bell-labs.com. 711 6. References 713 6.1. Normative References 715 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 716 Levels", BCP 14, RFC 2119, March 1997. 718 [2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 719 Protocol Version 1.1", RFC 4346, April 2006. 721 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 722 Data Set for Media Policy", 723 draft-ietf-sipping-media-policy-dataset-02 (work in progress), 724 October 2006. 726 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 727 Notification", RFC 3265, June 2002. 729 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 730 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 731 Session Initiation Protocol", RFC 3261, June 2002. 733 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 734 (SIP): Locating SIP Servers", RFC 3263, June 2002. 736 [7] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 737 Session Initiation Protocol (SIP) Session Policies", 738 draft-ietf-sip-session-policy-framework-00 (work in progress), 739 October 2006. 741 6.2. Informative References 743 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 744 Session Description Protocol (SDP)", RFC 3264, June 2002. 746 [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 747 Description Protocol", RFC 4566, July 2006. 749 Appendix A. Acknowledgements 751 Many thanks to Jonathan Rosenberg for the discussions and suggestions 752 for this draft. Many thanks to Roni Even, Bob Penfield, Mary Barnes 753 and Shida Schubert for reviewing the draft and to Vijay Gurbani for 754 the contributions to the security considerations section. 756 Authors' Addresses 758 Volker Hilt 759 Bell Labs/Alcatel-Lucent 760 791 Holmdel-Keyport Rd 761 Holmdel, NJ 07733 762 USA 764 Email: volkerh@bell-labs.com 766 Gonzalo Camarillo 767 Ericsson 768 Hirsalantie 11 769 Jorvas 02420 770 Finland 772 Email: Gonzalo.Camarillo@ericsson.com 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2007). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org. 814 Acknowledgment 816 Funding for the RFC Editor function is provided by the IETF 817 Administrative Support Activity (IASA).