doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6795.txt b/doc/rfc/rfc6795.txt
new file mode 100644
index 0000000..67f3c5a
--- /dev/null
+++ b/doc/rfc/rfc6795.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           V. Hilt
+Request for Comments: 6795                      Bell Labs/Alcatel-Lucent
+Category: Standards Track                                   G. Camarillo
+ISSN: 2070-1721                                                 Ericsson
+                                                           December 2012
+
+
+         A Session Initiation Protocol (SIP) Event Package for
+                       Session-Specific Policies
+
+Abstract
+
+   This specification defines a Session Initiation Protocol (SIP) event
+   package for session-specific policies.  This event package enables
+   user agents (UAs) to subscribe to session policies for a SIP session
+   and to receive notifications if these policies change.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6795.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 1]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................3
+   3. Event Package Formal Definition .................................3
+      3.1. Event Package Name .........................................4
+      3.2. Event Package Parameters ...................................4
+      3.3. SUBSCRIBE Bodies ...........................................4
+      3.4. Subscription Duration ......................................5
+      3.5. NOTIFY Bodies ..............................................5
+      3.6. Subscriber Generation of SUBSCRIBE Requests ................6
+      3.7. Notifier Processing of SUBSCRIBE Requests ..................8
+      3.8. Notifier Generation of NOTIFY Requests .....................9
+      3.9. Subscriber Processing of NOTIFY Requests ..................10
+      3.10. Handling of Forked Requests ..............................11
+      3.11. Rate of Notifications ....................................11
+      3.12. State Agents .............................................11
+      3.13. Examples .................................................11
+   4. Security Considerations ........................................14
+   5. IANA Considerations ............................................16
+      5.1. Event Package Name ........................................16
+   6. References .....................................................16
+      6.1. Normative References ......................................16
+      6.2. Informative References ....................................17
+   Appendix A. Acknowledgements ......................................18
+
+1.  Introduction
+
+   The Framework for Session Initiation Protocol (SIP) [RFC3261] Session
+   Policies [RFC6794] defines a protocol framework that enables a proxy
+   to define and impact policies on sessions such as the codecs or media
+   types to be used.  This framework identifies two types of session
+   policies: session-specific and session-independent policies.
+   Session-specific policies are policies that are created for one
+   particular session, based on the session description of this session.
+   They enable a network intermediary to inspect the session description
+   that a UA is proposing and to return a policy specifically generated
+   for this session description.  For example, an intermediary could
+   open pinholes in a firewall/NAT for each media stream in a session
+   and return a policy that replaces the internal IP addresses and ports
+   in the session description with external ones.  Since session-
+   specific policies are tailored to a session, they only apply to the
+   session for which they are created.  A UA requests session-specific
+   policies on a session-by-session basis at the time a session is
+   created and the session description is known.  Session-independent
+   policies, on the other hand, are policies that are created
+   independently of a session and generally apply to all the SIP
+   sessions set up by a user agent.
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 2]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   "A Framework for Session Initiation Protocol (SIP) Session Policies"
+   [RFC6794] defines a mechanism that enables UAs to discover the URIs
+   of session-specific policy servers.  This specification defines a SIP
+   event package [RFC6665] that enables UAs to subscribe to session-
+   specific policies on a policy server.  Subscribing to session-
+   specific policies involves the following steps (see the Session
+   Policy Framework [RFC6794]):
+
+   1.  A user agent submits the details of the session it is trying to
+       establish to the policy server and asks whether a session using
+       these parameters is permissible.  For example, a user agent might
+       propose a session that contains the media types audio and video.
+
+   2.  The policy server generates a policy decision for this session
+       and returns the decision to the user agent.  Possible policy
+       decisions are (1) to deny the session, (2) to propose changes to
+       the session parameters with which the session would be
+       acceptable, or (3) to accept the session as it was proposed.  An
+       example for a policy decision is to disallow the use of video but
+       agree to all other aspects of the proposed session.
+
+   3.  The policy server can update the policy decision at a later time.
+       A policy decision update can require additional changes to the
+       session (e.g., because the available bandwidth has changed) or
+       deny a previously accepted session (i.e., disallow the
+       continuation of a session).
+
+   The event package for session-specific policies enables a user agent
+   to subscribe to the policies for a SIP session following the above
+   model.  The subscriber initiates a subscription by submitting the
+   details of the session it is trying to establish to the notifier
+   (i.e., the policy server) in the body of a SUBSCRIBE request.  The
+   notifier uses this information to determine the policy decision for
+   this session.  It conveys the initial policy decision to the
+   subscriber in a NOTIFY request and all changes to this decision in
+   subsequent NOTIFY requests.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Event Package Formal Definition
+
+   This document provides the details for defining a SIP event package
+   as required by RFC 6665 [RFC6665].
+
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 3]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+3.1.  Event Package Name
+
+   The name of the event package defined in this specification is
+   "session-spec-policy".
+
+3.2.  Event Package Parameters
+
+   This package defines the following two event package parameters:
+
+   local-only:  The "local-only" parameter is optional and only defined
+      for NOTIFY requests.  The "local-only" parameter indicates that
+      the remote session description is not required by the notifier.
+      It MUST be ignored if received in a SUBSCRIBE request.  The usage
+      of the "local-only" parameter is described in Sections 3.6, 3.8
+      and 3.9.
+
+   insufficient-info:  The "insufficient-info" parameter is optional and
+      only defined for NOTIFY requests.  It is used by the notifier to
+      indicate that a policy decision could not be made due to
+      insufficient information.  The "insufficient-info" parameter MUST
+      be ignored if received in a SUBSCRIBE request.  The usage of the
+      "insufficient-info" parameter is described in Sections 3.7, 3.8
+      and 3.9.
+
+3.3.  SUBSCRIBE Bodies
+
+   A SUBSCRIBE for this event package MUST contain a body that describes
+   a SIP session.  The purpose of this body is to enable the notifier to
+   generate the policies in which the subscriber is interested.  In this
+   event package, the Request-URI, the event package name, and event
+   parameters are not sufficient to determine the resource a
+   subscription is for.  However, with the session description in the
+   SUBSCRIBE body, the notifier can generate the requested policy
+   decision and create policy events for this resource.
+
+   All subscribers and notifiers MUST support the MIME type
+   "application/media-policy-dataset+xml" as defined in "A User Agent
+   Profile Data Set for Media Policy" [RFC6796].  The "application/
+   media-policy-dataset+xml" format is the default format for SUBSCRIBE
+   bodies in this event package.  Subscribers and notifiers MAY
+   negotiate the use of other formats capable of representing a session.
+
+      Note: It has been proposed to directly use Session Description
+      Protocol (SDP) [RFC4566] instead of encoding the session
+      descriptions in the Media Policy [RFC6796] format.  However, using
+      a separate format such as the Media Policy format has a number of
+      advantages over the direct use of SDP: i) the Media Policy format
+      is more flexible and allows the inclusion of information that
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 4]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+      can't be expressed in SDP (e.g., the target URI), ii) the Media
+      Policy format enables the encoding of local and remote session
+      descriptions in a single document (not requiring the use of MIME
+      multipart and new content disposition types), and iii) the Media
+      Policy format aligns the formats used for session-specific and
+      session-independent policies.  A drawback is that it requires the
+      UA to encode SDP and session information in Media Policy
+      documents.
+
+3.4.  Subscription Duration
+
+   A subscription to the session-specific policy package is usually
+   established at the beginning of a session and terminated when the
+   corresponding session ends.  A typical duration of a phone call is a
+   few minutes.
+
+   Since the duration of a subscription to the session-specific policy
+   package is related to the lifetime of the corresponding session, the
+   value for the duration of a subscription is largely irrelevant.
+   However, the duration SHOULD be longer than the typical duration of a
+   session.  The default subscription duration for this event package is
+   set to two hours.
+
+   A subscription MAY be terminated before a session ends by the
+   notifier.  For example, a notifier may terminate the subscription
+   after the initial policy notification has been sent to the subscriber
+   if it knows that these policies will not change during the session.
+   A subscriber MUST NOT terminate a subscription unless it is
+   terminating the session this subscription is for or discovers that
+   the notifier has been removed from the list of policy servers
+   relevant for this session (see the Session Policy Framework
+   [RFC6794]).  A subscriber MUST refresh a subscription with a
+   SUBSCRIBE request before the last SUBSCRIBE request expires to avoid
+   that the subscription times out.
+
+3.5.  NOTIFY Bodies
+
+   In this event package, the body of a notification contains the
+   session policy requested by the subscriber.  All subscribers and
+   notifiers MUST support the format "application/
+   media-policy-dataset+xml" [RFC6796] as a format for NOTIFY bodies.
+
+   The SUBSCRIBE request MAY contain an Accept header field.  If no such
+   header field is present, it has a default value of "application/
+   media-policy-dataset+xml".  If the header field is present, it MUST
+   include "application/media-policy-dataset+xml", and it MAY include
+   any other MIME type capable of representing session-specific
+
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 5]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   policies.  As defined in RFC 6665 [RFC6665], the body of
+   notifications MUST be in one of the formats defined in the Accept
+   header of the SUBSCRIBE request or in the default format.
+
+   If the notifier uses the same format in NOTIFY bodies that was used
+   by the subscriber in the SUBSCRIBE body (e.g., "application/
+   media-policy-dataset+xml"), the notifier can expect that the
+   subscriber supports all format extensions that were used in the
+   SUBSCRIBE body.  The notifier cannot assume that the subscriber
+   supports other extensions beyond that and SHOULD NOT use such
+   extensions.
+
+   If the SUBSCRIBE request contained a representation of the local
+   session description and the subscription was accepted, then the
+   NOTIFY body MUST contain a policy for the local session description.
+   If the SUBSCRIBE request of an accepted subscription contained the
+   local and the remote session description, then the NOTIFY body MUST
+   contain two policies: one for the local and one for the remote
+   session description.
+
+3.6.  Subscriber Generation of SUBSCRIBE Requests
+
+   The subscriber follows the general rules for generating SUBSCRIBE
+   requests defined in RFC 6665 [RFC6665].  The subscriber MUST provide
+   sufficient information in the SUBSCRIBE body to fully describe the
+   session for which it seeks to receive session-specific policies.  The
+   subscriber MUST use the most recent session description as a basis
+   for this information.
+
+   If the "application/media-policy-dataset+xml" format is used in
+   SUBSCRIBE bodies, the subscriber MUST provide a value for each field
+   that is defined for session information documents [RFC6796] and for
+   which the subscriber has information available.  In other words, the
+   subscriber MUST fill in the elements of a session information
+   document as complete as possible.  If the subscriber supports
+   extensions of the "application/media-policy-dataset+xml" format, the
+   subscriber MUST also provide a value for each field defined by this
+   extension for session information documents, if possible.  Providing
+   as much information as possible avoids that a session is rejected due
+   to a lack of session information and the negotiation of the
+   information to be disclosed between notifier and subscriber.
+
+   Subscriptions to this event package are typically created in
+   conjunction with an SDP offer/answer exchange [RFC3264] during the
+   establishment of a session (see the Session Policy Framework
+   [RFC6794]).  If used with an offer/answer exchange, the subscriber
+   MUST insert the representation of the local session description in
+   the SUBSCRIBE body.  The local session description is the one that
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 6]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   was created by the subscriber (e.g., the offer if the subscriber has
+   initiated the offer/answer exchange).  Under certain circumstances, a
+   UA may not have a session description when subscribing to session-
+   specific policies, for example, when it is composing an empty INVITE
+   request (i.e., an INVITE request that does not contain an offer).  In
+   these cases, a UA SHOULD establish a subscription without including a
+   representation of the local session description.  The UA MUST refresh
+   the subscription with a SUBSCRIBE request that contains this session
+   description as soon as the session description becomes available, for
+   example, when the UA receives a 200 OK to an empty INVITE request.  A
+   policy server can choose to admit a session only after the UA has
+   disclosed the session descriptions.
+
+   The subscriber SHOULD also include a representation of the remote
+   session description in the SUBSCRIBE body.  The remote session
+   description is the one the subscriber has received (i.e., the answer
+   if the subscriber has initiated the offer/answer exchange).  In some
+   scenarios, the remote session description is not available to the
+   subscriber at the time the subscription to session-specific policies
+   is established.  In this case, the initial SUBSCRIBE message SHOULD
+   only contain a representation of the local session description.  When
+   the remote description becomes available, the subscriber SHOULD
+   refresh the subscription by sending another SUBSCRIBE request, which
+   then contains the local and the remote session description, unless
+   the subscriber has received a NOTIFY request with the "local-only"
+   parameter.  This parameter indicates that the notifier does not need
+   to see the remote session description.
+
+   A user agent can change the session description of an ongoing
+   session.  A change in the session description will typically affect
+   the policy decisions for this session.  A subscriber MUST refresh the
+   subscription to session-specific policies every time the session
+   description of a session changes.  It does this by sending a
+   SUBSCRIBE request, which contains the details of the updated session
+   descriptions.
+
+   A subscriber may receive an error that indicates a server failure in
+   response to a SUBSCRIBE request.  In this case, the subscriber SHOULD
+   try to locate an alternative server, for example, using the
+   procedures described in [RFC3263].  If no alternative server can be
+   located, the subscriber MAY continue with the session for which it
+   wanted to receive session-specific policies without subscribing to
+   session-specific policies.  This is to avoid that a failed policy
+   server prevents a UA from setting up or continuing with a session.
+   Since the sessions created by the UA may not be policy compliant
+   without this subscription, they may be blocked by policy enforcement
+   mechanisms if they are in place.
+
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 7]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   Session policies can contain sensitive information.  Moreover, policy
+   decisions can significantly impact the behavior of a user agent.  A
+   user agent should therefore verify the identity of a policy server
+   and make sure that policies have not been altered in transit.  All
+   implementations of this package MUST support Transport Layer Security
+   (TLS) [RFC5246] and the Session Initiation Protocol Secure (SIPS) URI
+   scheme.  A subscriber SHOULD use SIPS URIs when subscribing to
+   session-specific policies so that policies are transmitted over TLS.
+   See Section 4.
+
+3.7.  Notifier Processing of SUBSCRIBE Requests
+
+   All subscriptions to session-specific policies SHOULD be
+   authenticated and authorized before approval.  However, a policy
+   server may frequently encounter UAs it cannot authenticate.  In these
+   cases, the policy server MAY provide a generic policy that does not
+   reveal sensitive information to these UAs.  For details, see
+   Section 4.
+
+   The authorization policy is at the discretion of the administrator.
+   In general, all users SHOULD be allowed to subscribe to the session-
+   specific policies of their sessions.  A subscription to this event
+   package will typically be established by a device that needs to know
+   about the policies for its sessions.  However, subscriptions may also
+   be established by applications (e.g., a conference server).  In those
+   cases, an authorization policy will typically be provided for these
+   applications.
+
+   Responding in a timely manner to a SUBSCRIBE request is crucial for
+   this event package.  A notifier must minimize the time needed for
+   processing SUBSCRIBE requests and generating the initial NOTIFY
+   request.  This includes minimizing the time needed to generate an
+   initial policy decision.  In particular, a short response time is
+   important for this event package since it minimizes the delay for
+   fetching policies during an INVITE transaction and therefore reduces
+   call setup time.  In addition, subscriptions to session-specific
+   policies can be established while the subscriber is in an INVITE
+   transaction at a point where it has received the 200 OK but before
+   sending the ACK.  Delaying the creation of the initial NOTIFY request
+   would delay the transmission of the ACK.  A more detailed discussion
+   of this scenario can be found in the Session Policy Framework
+   [RFC6794].
+
+   A subscriber may not have disclosed enough information in the
+   SUBSCRIBE request to enable the notifier to generate a policy
+   decision.  For example, a UA may have subscribed to session-specific
+   policies without including the representation of a session
+   description.  The policy server SHOULD accept such a subscription.
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 8]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   The policy server SHOULD generate a NOTIFY request that includes the
+   "insufficient-info" event package parameter.  A NOTIFY request with
+   this parameter indicates that a policy decision could not be made due
+   to insufficient information.  The body of such a NOTIFY request can
+   either be empty or contain a policy decision document that provides
+   hints about which information was missing.
+
+3.8.  Notifier Generation of NOTIFY Requests
+
+   A notifier sends a notification in response to SUBSCRIBE requests as
+   defined in RFC 6665 [RFC6665].  In addition, a notifier MAY send a
+   notification at any time during the subscription.  Typically, it will
+   send one every time the policy decision this subscription is for has
+   changed.  When and why a policy decision changes is entirely at the
+   discretion of the administrator.  A policy decision can change for
+   many reasons.  For example, a network may become congested due to an
+   increase in traffic and reduce the bandwidth available to an
+   individual user.  Another example is a session that has been started
+   during "business hours" and continues into "evening hours" where more
+   bandwidth or video sessions are available to the user according to
+   the service level agreement.
+
+   Policy decisions are expressed in the format negotiated for the
+   NOTIFY body (e.g., "application/media-policy-dataset+xml").  The
+   policy document in a NOTIFY body MUST represent a complete policy
+   decision.  Notifications that contain the deltas to previous policy
+   decisions or partial policy decisions are not supported in this event
+   package.
+
+   The notifier SHOULD terminate the subscription if the policy decision
+   is to reject a session and if it can be expected that this decision
+   will not change in the foreseeable future.  The notifier SHOULD keep
+   the subscription alive, if it rejects a session but expects that the
+   session can be admitted soon.  For example, if the session was
+   rejected due to a temporary shortage of resources and the notifier
+   expects that these resources will become available again shortly it
+   should keep the subscription alive.  The decision to reject a session
+   is expressed in the policy decision document.  A session is admitted
+   by returning a policy decision document that requires some or no
+   changes to the session.
+
+   If the notifier has not received enough information to make a policy
+   decision from the subscriber (e.g., because it did not receive a
+   session description), the notifier SHOULD NOT terminate the
+   subscription since it can be expected that the UA refreshes the
+   subscription with a SUBSCRIBE request that contains more information.
+   The notifier SHOULD generate a NOTIFY request with the "insufficient-
+   info" event package parameter to indicate that a policy decision
+
+
+
+Hilt & Camarillo             Standards Track                    [Page 9]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   could not be made due to insufficient information.  This NOTIFY
+   request can contain an empty body or a body that contains a policy
+   decision document indicating which information was missing.
+
+   Some session-specific policies do not require the disclosure of the
+   remote session description to the notifier.  If a notifier determines
+   that this is the case after receiving a SUBSCRIBE request, the
+   notifier SHOULD include the "local-only" event parameter in NOTIFY
+   requests.
+
+3.9.  Subscriber Processing of NOTIFY Requests
+
+   A subscriber MUST apply the policy decision received in a NOTIFY
+   request to the session associated with this subscription.  If the UA
+   decides not to apply the received policy decision, the UA MUST NOT
+   set up the session and MUST terminate the session if the session is
+   already in progress.  If the UA has a pending INVITE transaction for
+   this session, the UA MUST cancel or reject the INVITE request.
+
+   If the subscriber receives a NOTIFY request indicating that the
+   session has been rejected, the subscriber MUST NOT attempt to
+   establish this session.  If the notifier has terminated the
+   subscription after rejecting the session, the subscriber SHOULD NOT
+   try to re-send the same SUBSCRIBE request again.  The termination of
+   the subscription by the notifier indicates that the policy decision
+   for this session is final and will not change in the foreseeable
+   future.  The subscriber MAY try to re-subscribe for this session if
+   at least one aspect of the session (e.g., a parameter in the session
+   description or the target URI) has changed or if there is other
+   reason to believe that re-trying the subscription will be successful
+   (e.g., because time has progressed significantly since the last
+   attempt).
+
+   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 another example, the session was rejected because it was
+   attempted in a restricted period during the day but this period is
+   going to end soon.  In this case, the subscriber SHOULD not terminate
+   the subscription to session-specific policies.
+
+   The subscriber may receive a NOTIFY request that contains an
+   "insufficient-info" event package parameter to indicate that the
+   SUBSCRIBE request did not contain enough information.  The subscriber
+
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 10]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   SHOULD refresh the subscription with more complete information as
+   soon as the missing information (e.g., the session description) is
+   available.
+
+   A subscriber may receive an update to a policy decision for a session
+   that is already established.  The subscriber MUST apply the new
+   policy decision to this session.  If a UA decides that it does not
+   want to apply the new policy decision, the UA MUST terminate the
+   session.  An updated policy decision may require the UA to generate a
+   re-INVITE or UPDATE request in this session if the session
+   description has changed or it may need to terminate this session.  A
+   policy update that requires a UA to terminate a session can, for
+   example, be triggered by the user's account running out of credit or
+   the detection of an emergency that requires the termination of non-
+   emergency calls.
+
+   If the subscriber receives a NOTIFY request that contains the "local-
+   only" event parameter, the subscriber SHOULD NOT include the remote
+   session description in subsequent SUBSCRIBE requests within this
+   subscription.
+
+3.10.  Handling of Forked Requests
+
+   This event package allows the creation of only one dialog as a result
+   of an initial SUBSCRIBE request.  The techniques to achieve this
+   behavior are described in [RFC6665].
+
+3.11.  Rate of Notifications
+
+   It is anticipated that the rate of policy changes will be very low.
+   In any case, notifications SHOULD NOT be generated at a rate of more
+   than once every five seconds.
+
+3.12.  State Agents
+
+   State agents play no role in this package.
+
+3.13.  Examples
+
+   The following message flow illustrates how a user agent (Alice's
+   phone) can subscribe to session-specific policies when establishing a
+   call (here to Bob's phone).  The flow assumes that the user agent has
+   already received the policy server URI (e.g., through configuration
+   or as described in the Session Policy Framework [RFC6794]), and it
+   does not show messages for authentication on a transport or SIP
+   level.
+
+   These call flow examples are informative and not normative.
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 11]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   Implementers should consult the main text of this document for exact
+   protocol details.
+
+
+   Policy Server          Alice                Bob
+       |                   |                   |
+       |(1) SUBSCRIBE      |                   |
+       |<------------------|                   |
+       |(2) 200 OK         |                   |
+       |------------------>|                   |
+       |(3) NOTIFY         |                   |
+       |------------------>|                   |
+       |(4) 200 OK         |                   |
+       |<------------------|                   |
+       |                   |(5) INVITE         |
+       |                   |------------------>|
+       |                   |                   |
+       |                   |(6) 200 OK         |
+       |                   |<------------------|
+       |                   |(7) ACK            |
+       |                   |------------------>|
+       |(8) SUBSCRIBE      |                   |
+       |<------------------|                   |
+       |(9) 200 OK         |                   |
+       |------------------>|                   |
+       |(10) NOTIFY        |                   |
+       |------------------>|                   |
+       |(11) 200 OK        |                   |
+       |<------------------|                   |
+       |                   |                   |
+
+     Message Details
+
+        (1) SUBSCRIBE  Alice -> Policy Server
+
+        SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0
+        Via: SIP/2.0/TLS pc.biloxi.example.com:5061
+         ;branch=z9hG4bK74bf
+        Max-Forwards: 70
+        From: Alice <sips:alice@biloxi.example.com>;tag=8675309
+        To: PS <sips:policy@biloxi.example.com>
+        Call-ID: rt4353gs2egg@pc.biloxi.example.com
+        CSeq: 1 SUBSCRIBE
+        Contact: <sips:alice@pc.biloxi.example.com>
+        Expires: 7200
+        Event: session-spec-policy
+        Accept: application/media-policy-dataset+xml
+        Content-Type: application/media-policy-dataset+xml
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 12]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+        Content-Length: ...
+
+        [Local session description (offer)]
+
+
+        (2) 200 OK  Policy Server -> Alice
+
+        (3) NOTIFY  Policy Server -> Alice
+
+        NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0
+        Via: SIP/2.0/TLS srvr.biloxi.example.com:5061
+         ;branch=z9hG4bK74br
+        Max-Forwards: 70
+        From: PS <sips:policy@biloxi.example.com>;tag=31451098
+        To: Alice <sips:alice@biloxi.example.com>;tag=8675309
+        Call-ID: rt4353gs2egg@pc.biloxi.example.com
+        CSeq: 1 NOTIFY
+        Event: session-spec-policy
+        Subscription-State: active;expires=7200
+        Content-Type: application/media-policy-dataset+xml
+        Content-Length: ...
+
+        [Policy for local session description (offer)]
+
+        (4) 200 OK  Alice -> Policy Server
+
+        (5) INVITE  Alice -> Bob
+
+        (6) 200 OK  Bob -> Alice
+
+        (7) ACK  Alice -> Bob
+
+        (8) SUBSCRIBE  Alice -> Policy Server
+
+        SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0
+        Via: SIP/2.0/TLS pc.biloxi.example.com:5061
+         ;branch=z9hG4bKna998sl
+        Max-Forwards: 70
+        From: Alice <sips:alice@biloxi.example.com>;tag=8675309
+        To: PS <sips:policy@biloxi.example.com>;tag=31451098
+        Call-ID: rt4353gs2egg@pc.biloxi.example.com
+        CSeq: 2 SUBSCRIBE
+        Expires: 7200
+        Event: session-spec-policy
+        Accept: application/media-policy-dataset+xml
+        Content-Type: application/media-policy-dataset+xml
+        Content-Length: ...
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 13]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+        [Local session description (offer)]
+        [Remote session description (answer)]
+
+
+        (9) 200 OK  Policy Server -> Alice
+
+        (10) NOTIFY  Policy Server -> Alice
+
+        NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0
+        Via: SIP/2.0/TLS srvr.biloxi.example.com:5061
+         ;branch=z9hG4bKna998sk
+        Max-Forwards: 70
+        From: PS <sips:policy@biloxi.example.com>;tag=31451098
+        To: Alice <sips:alice@biloxi.example.com>;tag=8675309
+        Call-ID: rt4353gs2egg@pc.biloxi.example.com
+        CSeq: 2 NOTIFY
+        Event: session-spec-policy
+        Subscription-State: active;expires=7200
+        Content-Type: application/media-policy-dataset+xml
+        Content-Length: ...
+
+        [Policy for local session description (offer)]
+        [Policy for remote session description (answer)]
+
+        F6 200 OK  Alice -> Policy Server
+
+
+4.  Security Considerations
+
+   Session policies can significantly change the behavior of a user
+   agent and can therefore be used by an attacker to compromise a user
+   agent.  For example, session policies can be used to prevent a user
+   agent from successfully establishing a session (e.g., by setting the
+   available bandwidth to zero).  Such a policy can be submitted to the
+   user agent during a session, which may cause the UA to terminate the
+   session.
+
+   A user agent transmits session information to a policy server.  This
+   information may contain sensitive data the user may not want an
+   eavesdropper or an unauthorized policy server to see.  For example,
+   the session information may contain the encryption keys for media
+   streams.  Vice versa, session policies may also contain sensitive
+   information about the network or service level agreements the service
+   provider may not want to disclose to an eavesdropper or an
+   unauthorized user agent.
+
+
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 14]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   It is therefore important to secure the communication between the
+   user agent and the policy server.  The following three discrete
+   attributes need to be protected:
+
+   1.  authentication of the policy server and, if needed, the user
+       agent,
+
+   2.  confidentiality of the messages exchanged between the user agent
+       and the policy server, and
+
+   3.  ensuring that private information is not exchanged between the
+       two parties, even over a confidentiality-assured and
+       authenticated session.
+
+   Authentication of the peers and protecting the confidentiality of the
+   policies in transit is achieved by existing SIP security mechanisms
+   (the use of TLS and SIPS URI scheme [RFC3261], [RFC5630]).
+
+   Accordingly, policy servers SHOULD be addressable only through a SIPS
+   URI.  Policy server and user agent MUST support TLS.  The
+   confidentiality of the communication between the policy server and
+   the user agent will be assured as long as the policy server supports
+   TLS and is reached through a SIPS URI.
+
+   Authenticating the two parties can be performed using X.509
+   certificates exchanged through TLS and other techniques such as HTTP
+   Digest.  When the user agent establishes a TLS session with the
+   policy server, the policy server will present it with an X.509
+   certificate.  The user agent SHOULD ensure that the identity of the
+   policy server encoded in the certificate matches the URI of the
+   policy server the user agent has received either using the Session
+   Policy Framework [RFC6794] or other means such as configuration.
+
+   When a policy server receives a new subscription (as opposed to a
+   refresh subscription), the policy server SHOULD try to authenticate
+   the user agent using any means at its disposal.  If the user agent
+   has an X.509 certificate suitable for use with TLS, the identity of
+   the user agent SHOULD be contained in the certificate, or, if the
+   user agent does not possess a certificate, the policy server SHOULD
+   challenge the user agent using HTTP Digest.  A policy server may
+   frequently encounter UAs it cannot authenticate.  In these cases, the
+   policy server MAY provide a generic policy that does not reveal
+   sensitive information to these UAs.
+
+   If the subscriber and notifier desire to protect the integrity of the
+   policy exchange in an end-to-end manner, they MAY use S/MIME to
+   protect the session policies.  However, RFC3261 cautions that
+   "[i]mplementers should note, however, that there may be rare network
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 15]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   intermediaries (not typical proxy servers) that rely on viewing or
+   modifying the bodies of SIP messages (especially SDP), and that
+   secure MIME may prevent these sorts of intermediaries from
+   functioning" [RFC3261].
+
+   And finally, the fact that the user agent and the policy server have
+   successfully authenticated each other and have established a secure
+   TLS session does not absolve either one from ensuring that they do
+   not communicate sensitive information.  For example, a session
+   description may contain sensitive information -- session keys, for
+   example -- that the user agent may not want to share with the policy
+   server; and indeed, the policy server does not need such information
+   to effectively formulate a policy.  Thus, the user agent should not
+   insert such sensitive information in a session information document
+   that it sends to the policy server.  Likewise, the policy server may
+   have information that is sensitive and of no use to the user agent --
+   network service level agreements, or network statistics, for example.
+   Thus, the policy server should refrain from transmitting such
+   information to the user agent.
+
+5.  IANA Considerations
+
+5.1.  Event Package Name
+
+   This specification registers an event package as follows, based on
+   the registration procedures defined in RFC 6665 [RFC6665].
+
+   Package Name: session-spec-policy
+
+   Package or Template-Package: This is a package.
+
+   Published Document: RFC 6795.
+
+   Person to Contact: Volker Hilt, volker.hilt@bell-labs.com.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 16]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
+              Protocol (SIP): Locating SIP Servers", RFC 3263,
+              June 2002.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC6665]  Roach, A., "SIP-Specific Event Notification", RFC 6665,
+              July 2012.
+
+   [RFC6794]  Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework
+              for Session Initiation Protocol (SIP) Session Policies",
+              RFC 6794, December 2012.
+
+   [RFC6796]  Hilt, V., Camarillo, G., Rosenberg, J., and D. Worley, "A
+              User Agent Profile Data Set for Media Policy", RFC 6796,
+              December 2012.
+
+6.2.  Informative References
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              June 2002.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
+              Initiation Protocol (SIP)", RFC 5630, October 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 17]
+
+RFC 6795              Session Policy Event Package         December 2012
+
+
+Appendix A.  Acknowledgements
+
+   Many thanks to Jonathan Rosenberg for the discussions and suggestions
+   for this document.  Many thanks to Roni Even, Bob Penfield, Mary
+   Barnes, Shida Schubert and Jon Peterson for reviewing the document
+   and to Vijay Gurbani for the contributions to the Security
+   Considerations section.
+
+Authors' Addresses
+
+   Volker Hilt
+   Bell Labs/Alcatel-Lucent
+   Lorenzstrasse 10
+   70435 Stuttgart
+   Germany
+
+   EMail: volker.hilt@bell-labs.com
+
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hilt & Camarillo             Standards Track                   [Page 18]
+