SIPPING Working Group                                            V. Hilt
Internet-Draft                                  Bell Labs/Alcatel-Lucent
Intended status: Standards Track                            G. Camarillo
Expires: February 23, 2008                                      Ericsson
                                                            J. Rosenberg
                                                                   Cisco
                                                         August 22, 2007


   A Framework for Session Initiation Protocol (SIP) Session Policies
               draft-ietf-sip-session-policy-framework-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Proxy servers play a central role as an intermediary in the Session
   Initiation Protocol (SIP) as they define and impact policies on call
   routing, rendezvous, and other call features.  This document
   specifies a framework for SIP session policies that provides a
   standard mechanism by which a proxy can define or influence policies



Hilt, et al.            Expires February 23, 2008               [Page 1]


Internet-Draft          Session Policy Framework             August 2007


   on sessions, such as the codecs or media types to be used.  It
   defines a model, an overall architecture and new protocol mechanisms
   for session policies.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Session-Independent Policies . . . . . . . . . . . . . . . . .  5
     3.1.  Architecture and Overview  . . . . . . . . . . . . . . . .  5
     3.2.  Policy Subscription  . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  UAC Behavior . . . . . . . . . . . . . . . . . . . . .  6
       3.2.2.  UAS Behavior . . . . . . . . . . . . . . . . . . . . .  7
   4.  Session-Specific Policies  . . . . . . . . . . . . . . . . . .  7
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1.  Offer in Request . . . . . . . . . . . . . . . . . . . 11
       4.3.2.  Offer in Response  . . . . . . . . . . . . . . . . . . 13
     4.4.  UA/Policy Server Rendezvous  . . . . . . . . . . . . . . . 14
       4.4.1.  UAC Behavior . . . . . . . . . . . . . . . . . . . . . 15
       4.4.2.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . 16
       4.4.3.  UAS Behavior . . . . . . . . . . . . . . . . . . . . . 19
       4.4.4.  Caching the Local Policy Server URI  . . . . . . . . . 19
       4.4.5.  Header Definition and Syntax . . . . . . . . . . . . . 20
     4.5.  Policy Channel . . . . . . . . . . . . . . . . . . . . . . 22
       4.5.1.  Creation and Management  . . . . . . . . . . . . . . . 22
       4.5.2.  Contacting the Policy Server . . . . . . . . . . . . . 23
       4.5.3.  Using Session Policies . . . . . . . . . . . . . . . . 24
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  Registration of the "Policy-Id" Header . . . . . . . . . . 26
     6.2.  Registration of the "Policy-Contact" Header  . . . . . . . 26
     6.3.  Registration of the "policy" SIP Option-Tag  . . . . . . . 26
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 28
   Appendix B.  Session-Specific Policies - Call Flows  . . . . . . . 28
     B.1.  Offer in Invite  . . . . . . . . . . . . . . . . . . . . . 29
     B.2.  Offer in Response  . . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33







Hilt, et al.            Expires February 23, 2008               [Page 2]


Internet-Draft          Session Policy Framework             August 2007


1.  Introduction

   The Session Initiation Protocol (SIP) [7] is a signaling protocol for
   creating, modifying and terminating multimedia sessions.  A central
   element in SIP is the proxy server.  Proxy servers are intermediaries
   that are responsible for request routing, rendezvous, authentication
   and authorization, mobility, and other signaling services.  However,
   proxies are divorced from the actual sessions - audio, video, and
   session-mode messaging - that SIP establishes.  Details of the
   sessions are carried in the payload of SIP messages, and are usually
   described with the Session Description Protocol (SDP) [11].

   Experience has shown that there is a need for SIP intermediaries to
   impact aspects of a session.  For example, SIP can be used in a
   wireless network, which has limited resources for media traffic.
   During periods of high activity, the wireless network provider may
   want to restrict the amount of bandwidth available to each user.
   With session policies, an intermediary in the wireless network can
   inform the user agent about the bandwidth it has available.  This
   information enables the user agent to make an informed decision about
   the number of streams, the media types, and the codecs it can
   successfully use in a session.  Similarly, a network provider can
   have a service level agreement with a user that defines the set of
   media types the user can use.  With session policies, the network can
   convey the current set of policies to user agents, enabling them to
   set up sessions without inadvertently violating any of the network
   policies.

   In another example, a SIP user agent is using a network which is
   connected to the public Internet through a firewall or a network
   border device.  The network provider would like to tell the user
   agent that it needs to send its media streams to a specific IP
   address and port on the firewall or border device to reach the public
   Internet.  Knowing this policy enables the user agent to set up
   sessions across the firewall or the network border.  In contrast to
   other methods for inserting a media intermediary, the use of session
   policies does not require the inspection or modification of SIP
   message bodies.

   Domains often have the need to enforce the session policies they have
   in place.  For example, a domain might have a policy that disallows
   the use of video and can have an enforcement mechanism that drops all
   packets containing a video encoding.  Unfortunately, these
   enforcement mechanisms usually do not inform the user about the
   policies they are enforcing.  Instead, they silently keep the user
   from doing anything against them.  This can lead to a malfunctioning
   of devices that is incomprehensible to the user.  With session
   policies, the user knows about the current network policies and can



Hilt, et al.            Expires February 23, 2008               [Page 3]


Internet-Draft          Session Policy Framework             August 2007


   set up policy-compliant sessions or simply connect to a domain with
   less stringent policies.  Thus, session policies provide an important
   combination of consent coupled with enforcement.  That is, the user
   becomes aware of the policy and needs to act on it, but the provider
   still retains the right to enforce the policy.

   Two types of session policies exist: session-specific policies 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
   examine the session description a UA is proposing and to return a
   policy specifically for this session description.  For example, an
   intermediary could open pinholes in a firewall/NAT for each media
   stream in the proposed session description.  It can then return a
   policy for the session description that replaces the IP addresses and
   ports of the UA with the ones opened in the firewall/NAT that are
   reachable from external.  Since session-specific policies are
   tailored to a session, they only apply to the session they are
   created for.  Session-specific policies are created on a session-by-
   session basis at the time the session is established.

   Session-independent policies on the other hand are policies that are
   created independent of a session and generally apply to all SIP
   sessions set up by a user agent.  A session-independent policy can,
   for example, be used to inform user agents about an existing
   bandwidth limit or media type restrictions.  Since these policies are
   not based on a specific session description, they can be created
   independent of an attempt to set up a session and only need to be
   conveyed to the user agent when it initializes (e.g., at the time the
   device is powered on) and when policies are changed.

   This specification defines a framework for SIP session policies.  It
   specifies a model, the overall architecture and new protocol
   mechanisms that are needed for session-independent and session-
   specific policies.  Since session-specific and session-independent
   policies have different requirements, this specification defines two
   different mechanisms to deliver them to user agents.  These
   mechanisms are independent of each other and, depending on whether
   one or both types of session policies are needed, it is possible to
   use the session-specific or the session-independent mechanism or both
   to deliver policies to user agents.


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 [1].



Hilt, et al.            Expires February 23, 2008               [Page 4]


Internet-Draft          Session Policy Framework             August 2007


3.  Session-Independent Policies

   Session-independent policies are policies that are created
   independent of a session and generally apply to all sessions a user
   agent is setting up.  They typically remain stable for a longer
   period of time and apply to any session set up while they are valid.
   However, session-independent policies can also change over time.  For
   example, a policy that defines a bandwidth limit for a user can
   change during the day, defining a lower limit during peak hours and
   allow more bandwidth off-peak.

3.1.  Architecture and Overview

                        +-------------+
                 /------|   policy    |
      +----+    /       |  server 1   |
      |    |---/        +-------------+
      | UA |                 ...
      |    |---\        +-------------+
      +----+    \       |   policy    |
                 \------|  server n   |
                        +-------------+


                                 Figure 1

   A SIP UA can receive session-independent policies from one or more
   policy servers.  In a typical configuration, a UA receives session-
   independent policies from a policy server in the local network domain
   (i.e., the domain from which the UA receives IP service) and possibly
   the SIP service provider domain (i.e., the domain the UA registers
   at).  The local network can have policies that support the access
   network infrastructure.  For example, in a wireless network where
   bandwidth is scarce, a provider can restrict the bandwidth available
   to an individual user.  The SIP service provider can have policies
   that are needed to support services or policies that reflect the
   service level agreement with the user.  Thus, in most cases, a UA
   will receive session-independent policies from one or two policy
   servers.

   Setting up session-independent policies involves the following steps:

   1.  A user agent requests session-independent policies from the
       policy servers in the local network and SIP service provider
       domain.  A user agent typically requests these policies when it
       starts up or connects to a new network domain.





Hilt, et al.            Expires February 23, 2008               [Page 5]


Internet-Draft          Session Policy Framework             August 2007


   2.  The policy server selects the policies that apply to this user
       agent.  The policy server can have general policies that apply to
       all users or maintain separate policies for each individual user.
       The selected policies are returned to the user agent.
   3.  The policy server can update the policies, for example, when
       network conditions change.

3.2.  Policy Subscription

3.2.1.  UAC Behavior

   A UA that supports session-independent policies MUST attempt to
   retrieve session-independent policies from the local network and the
   SIP service provider domain, unless the UA knows (e.g., through
   configuration) that a domain does not provide session-independent
   policies.  In this case, the UA SHOULD NOT retrieve session-
   independent policies from this specific domain.

   A UA MUST support the retrieval of session-independent policies from
   the local network and the SIP service provider domain using the "ua-
   profile" event package defined in the Framework for SIP User Agent
   Profile Delivery [4].  The UA MAY support other methods of retrieving
   session-independent policies from local network and SIP service
   provider domain.

   The "ua-profile" event package [4] provides a mechanism to subscribe
   to session-independent policies.  A UA subscribes to the policy
   server in the local network domain using the procedures defined for
   the "local-network" profile-type.  The UA uses the procedures defined
   for the "user" profile type to subscribe to the policy server in the
   SIP service provider domain.

   A UA (re-)subscribes to session-independent policies when the
   following events occur:

   o  The UA registers a new address-of-record (AoR) or removes a AoR
      from the set of AoRs it has registered.  In these cases, the UA
      MUST establish subscriptions for each new AoR using the "user" and
      the "local-network" profile-types.  The UA MUST terminate all
      subscriptions for AoRs it has removed.
   o  The UA changes the domain it is connected to.  The UA MUST
      terminate all existing subscriptions for the "local-network"
      profile-type.  The UA MUST then create a new subscription for each
      AoR it maintains using the "local-network" profile-type.  This
      way, the UA stops receiving policies from the previous local
      domain and starts to receive the policies of the new local domain.
      The UA does not need to change the subscriptions for "user"
      profiles.



Hilt, et al.            Expires February 23, 2008               [Page 6]


Internet-Draft          Session Policy Framework             August 2007


   If a subscriber is unable to establish a subscription, it SHOULD NOT
   attempt to re-try this subscription, unless one of the above events
   occurs again.  This is to limit the number of SUBSCRIBE requests sent
   within domains that do not support session-independent policies.

   A UA compliant to this specification MUST support the User Agent
   Profile Data Set for Media Policy [3].  To indicate that the UA wants
   to receive session-independent policies, it includes the MIME type
   "application/media-policy-dataset+xml" in the Accept header of a
   SUBSCRIBE request.

   A UA MUST apply the session-independent policies it has received and
   use these policies in the session descriptions it creates.  If the UA
   decides not to use the received policies, then the UA MUST NOT set up
   a session unless it changes the domain that provided these policies.
   A UA MAY try to connect to another local network and/or SIP service
   provider domain with a different set of policies.

   If a UA receives both session-independent and session-specific
   policies, the UA MUST apply the session-independent policies to the
   session description before the session description is sent to the
   session-specific policy server (see Section 4).  Thus, session-
   independent policies are always applied before session-specific
   policies are retrieved.

3.2.2.  UAS Behavior

   A policy server MAY send a notification to the subscriber every time
   the session-independent policies covered by the subscription change.
   The definition of what causes a policy to change is at the discretion
   of the administrator.  A change in the policy can be triggered, for
   example, by a change in the network status, by the change in the time
   of day or by an update of the service level agreement with the
   customer.  The policy server MUST insert a complete session-
   independent policy into a notification sent to the subscriber.
   Deltas to previous policies or partial policies are not supported.


4.  Session-Specific Policies

   Session-specific policies are policies that are created specifically
   for one particular session of a UA.  Thus, session-specific policies
   will typically be different for different sessions.  The session-
   specific policies for a session can change during the course of the
   session.  For example, a user can run out of credit during a session,
   which will cause the network to disallow the transmission all media
   streams from this point on.




Hilt, et al.            Expires February 23, 2008               [Page 7]


Internet-Draft          Session Policy Framework             August 2007


4.1.  Architecture

                           domain 1
                        +-----------+
                 /------|   proxy   |----...
      +----+    /       +-----------+
      |    |---/        +-----------+
      |    |            |  policy   |
      | UA |============|  server   |
      |    |            +-----------+
      |    |****        +-----------+
      +----+    *       |  policy   |
                 *******|enforcement|****...
                        +-----------+

      --- SIP Signaling
      === Policy Channel
      *** Media

                                 Figure 2

   The following entities are needed for session-specific policies (see
   Figure 2): a user agent (UA), a proxy, a policy server and possibly a
   policy enforcement entity.

   The role of the proxy is to provide a rendezvous mechanism for UAs
   and policy servers.  It ensures that each UA has the URI of the
   policy server in its domain and knows where to retrieve policies
   from.  The proxy conveys the policy server URI to UAs in case they
   have not yet received it (e.g., in a previous call or through other
   means such as configuration).  The proxy does not deliver the actual
   policies to UAs.

   The policy server is a separate logical entity that can be physically
   co-located with the proxy.  The role of the policy server is to
   deliver session policies to UAs.  The policy server receives session
   information from the UA, uses this information to determine the
   policies that apply to the session and returns these policies to the
   UA.  The mechanism for generating policies (i.e., making policy
   decisions) is outside of the scope of this specification.  A policy
   server can, for example, query an external entity to get policies or
   it can directly incorporate a policy decision point and generate
   policies locally.

   A UA receives the URI of a policy server from a proxy.  It uses this
   URI to contact the policy server.  It provides information about the
   current session to the policy server and receives session policies in
   response.  The UA can also receive policy updates from the policy



Hilt, et al.            Expires February 23, 2008               [Page 8]


Internet-Draft          Session Policy Framework             August 2007


   server during the course of a session.

   A network can have a policy enforcement infrastructure in place.
   However, this specification does not make any assumptions about the
   enforcement of session policies and the mechanisms defined here are
   orthogonal a policy enforcement infrastructure.  Their goal is to
   provide a mechanism to convey session information to a policy server
   and to return the policies that apply to a session to the UA.

   In principle, each domain that is traversed by SIP signaling messages
   can define session-specific policies for a session.  Each domain
   needs to run a policy server and a proxy that is able to rendezvous a
   UA with the policy server (as shown in Figure 2).  However, it is
   expected that session-specific policies will often only be provided
   by the local domain of the user agent.

4.2.  Overview

   The protocol defined in this specification clearly separates SIP
   signaling and the exchange of policies.  SIP signaling is only used
   to rendezvous the UA with the policy server.  From this point on, UA
   and policy server communicate directly with each other over a
   separate policy channel.  This is opposed to a piggyback model, where
   the exchange of policy information between endpoint and a policy
   server in the network is piggybacked onto the SIP signaling messages
   that are exchanged between endpoints.

   The main advantage of using a separate policy channel is that it
   decouples the exchange of signaling messages between endpoints from
   the exchange of policies between endpoint and policy server.  This
   decoupling has a number of desirable properties.  It enables the use
   of separate encryption mechanisms on the signaling path to secure the
   communication between endpoints, and on the policy channel to secure
   the communication between endpoint and policy server.  Policies can
   be submitted directly from the policy server to the endpoint and
   never travel along the signaling path, possibly crossing many
   domains.  Endpoints set up a separate policy channel to each policy
   server and can disclose the information requested by the specific
   policy server (e.g., offer or offer/answer).  Finally, policy servers
   do not need to rely on a SIP signaling message flowing by to send
   policies or policy updates to an endpoint.  A policy server can use
   the policy channel at any time to update session policies as needed.
   A disadvantage of the separate channel model is that it requires
   additional messages for the exchange of policy information.

   Following this model, signaling for session-specific policies
   involves the following two fundamental tasks:




Hilt, et al.            Expires February 23, 2008               [Page 9]


Internet-Draft          Session Policy Framework             August 2007


   1.  UA/policy server rendezvous: a UA setting up a session needs to
       be able to discover the policy servers that are relevant to this
       session.
   2.  Policy channel: once the UA has discovered the relevant policy
       servers for a session, it needs to connect to these servers,
       disclose session information and retrieve the policies that apply
       to this session.

   The communication between UA and policy server on the policy channel
   involves the following steps:

   1.  A user agent submits information about the session it is trying
       to establish to the policy server and asks whether a session
       using these parameters is permissible.
   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.
   3.  The policy server can update the policy decision at a later time.
       A policy decision update can, for example, propose additional
       changes to the session (e.g., change the available bandwidth) or
       deny a previously accepted session (i.e., disallow the
       continuation of a session).

   In many cases, the mechanism for session-specific policies will be
   used to disclose session information and return session policies.
   However, some scenarios only involve the disclosure of session
   information to a network intermediary.  If an intermediary does not
   intend to return a policy, it can simply accept the session as it was
   proposed.  Similarly, some session-specific policies only apply to
   the offer (and therefore only require the disclosure of the offer)
   whereas others apply to offer and answer.  Both types of policies are
   supported by session-specific policy mechanism.

4.3.  Examples

   This section provides two examples to illustrate the overall
   operation of session-specific policies.  The call flows depict the
   rendezvous mechanism between UA and policy server and indicate the
   points at which the UA exchanges policy information with the policy
   server.

   The example is based on the following scenario: there are two domains
   (domain A and domain B), which both have session-specific policies
   for the UAs in their domain.  Both domains do not provide policies to
   the UAs outside of their domain.  The two domains have a proxy (P A
   and P B) and a policy server (PS A and PS B).  The policies in both



Hilt, et al.            Expires February 23, 2008              [Page 10]


Internet-Draft          Session Policy Framework             August 2007


   domains involve the session description offer and answer.

4.3.1.  Offer in Request

   The first call flow shown in Figure 3 depicts an INVITE transaction
   with the offer in the request.  It is assumed that this is the first
   INVITE request the UAC creates in this domain and that it therefore
   does not have previous knowledge about the policy server URIs in this
   domain.

   (1) UA A sends an INVITE to proxy P A. P A knows that policies apply
   to this session and (2) returns a 488 (Not Acceptable Here) to UA A.
   P A includes the URI of PS A in the 488 (Not Acceptable Here)
   response.  This step is needed since the UAC has no prior knowledge
   about the URI of PS A. (3) UA A uses the URI to contact PS A,
   discloses the session description offer to PS A and (4) receives
   policies for the offer. (5) UA A reformulates the INVITE request
   under consideration of the received policies and includes a Policy-Id
   header to indicate that it has already contacted PS A. P A does not
   reject the INVITE this time and removes the Policy-Id header when
   forwarding the INVITE.  P B adds a Policy-Contact header containing
   the URI of PS B. (6) UA B uses this URI to contact PS B and discloses
   the offer and the answer it is about to send. (7) UA B receives
   policies from PS B and applies them to the offer and answer
   respectively. (8) UA B returns the updated answer in the 200 OK. (9)
   UA A contacts PS A with the answer and (10) retrieves answer policies
   from PS A.
























Hilt, et al.            Expires February 23, 2008              [Page 11]


Internet-Draft          Session Policy Framework             August 2007


    UA A              P A              P B             UA B
     |                 |                |                 |
     | INVITE offer    |                |                 |
     |---------------->|                |                 | (1)
     | 488             |                |                 |
     | + Policy-Contact|                |                 |
     |<----------------|                |                 | (2)
     | ACK             |                |                 |
     |---------------->|                |                 |
     |                 | PS A           |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoOffer        |             |                 |
     |------------------->|             |                 | (3)
     | PolicyChannel      |             |                 |
     | + PolicyOffer      |             |                 |
     |<-------------------|             |                 | (4)
     |                    |             |                 |
     |                 |                |                 |
     | INVITE offer'   | INVITE offer'  | INVITE offer    |
     | + Policy-Id     |                | + Policy-Contact|
     |---------------->|--------------->|---------------->| (5)
     |                 |                |                 |
     |                 |           PS B |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoOffer        |
     |                 |             | + InfoAnswer       |
     |                 |             |<-------------------| (6)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyOffer      |
     |                 |             | + PolicyAnswer     |
     |                 |             |------------------->| (7)
     |                 |             |                    |
     |                 |                |                 |
     | OK answer       | OK answer      | OK answer       |
     |<----------------|<---------------|<----------------| (8)
     | ACK                                                |
     |--------------------------------------------------->|
     |                 |                |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoAnswer       |             |                 |
     |------------------->|             |                 | (9)
     | PolicyChannel      |             |                 |
     | + PolicyAnswer     |             |                 |
     |<-------------------|             |                 | (10)
     |                    |             |                 |



Hilt, et al.            Expires February 23, 2008              [Page 12]


Internet-Draft          Session Policy Framework             August 2007


                                 Figure 3

4.3.2.  Offer in Response

   The call flow shown in Figure 4 depicts an INVITE transaction with
   the offer in the response.

   (1) UA A sends an INVITE without an offer to proxy P A and (2) P A
   returns a 488 (Not Acceptable Here) response containing the URI of PS
   A. (3),(4) UA A uses this policy server URI to set up the policy
   channel.  At this time, UA A does not disclose a session description
   since it does not have the offer yet. (5) UA A re-sends the INVITE
   request and includes a Policy-Id header to indicate that it has
   contacted PS A. P A does not reject the INVITE this time and removes
   the Policy-Id header when forwarding the INVITE.  P B adds a Policy-
   Contact header containing the URI of PS B. (6) UA B uses this URI to
   discloses the offer to PS B. (7) UA B receives policies from PS B and
   applies them to the offer. (8) UA B returns the updated offer the 200
   OK. (9),(10) UA A contacts PS and discloses the offer and the answer
   it is about to send.  An important difference to the flow in the
   previous example is that UA A performs steps (9) and (10) before
   returning the answer in step (11).  This enables UA A to return the
   final answer in the ACK, which includes all applicable policies.
   However, it requires that PS A immediately returns a policy to avoid
   a delay in the transmission of the ACK. (12),(13) UA B also sends the
   answer to PS B and applies the policies it receives to the answer
   before using it.

    UA A              P A              P B             UA B
     |                 |                |                 |
     | INVITE          |                |                 |
     |---------------->|                |                 | (1)
     | 488             |                |                 |
     | + Policy-Contact|                |                 |
     |<----------------|                |                 | (2)
     | ACK             |                |                 |
     |---------------->|                |                 |
     |                 | PS A           |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     |------------------->|             |                 | (3)
     | PolicyChannel      |             |                 |
     |<-------------------|             |                 | (4)
     |                    |             |                 |
     |                 |                |                 |
     | INVITE          | INVITE         | INVITE          |
     | + Policy-Id     |                | + Policy-Contact|
     |---------------->|--------------->|---------------->| (5)



Hilt, et al.            Expires February 23, 2008              [Page 13]


Internet-Draft          Session Policy Framework             August 2007


     |                 |                |                 |
     |                 |           PS B |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoOffer        |
     |                 |             |<-------------------| (6)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyOffer      |
     |                 |             |------------------->| (7)
     |                 |             |                    |
     |                 |                |                 |
     | OK offer        | OK offer       | OK offer        |
     |<----------------|<---------------|<----------------| (8)
     |                 |                |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoOffer        |             |                 |
     | + InfoAnswer       |             |                 |
     |------------------->|             |                 | (9)
     | PolicyChannel      |             |                 |
     | + PolicyOffer      |             |                 |
     | + PolicyAnswer     |             |                 |
     |<-------------------|             |                 | (10)
     |                    |             |                 |
     | ACK answer                                         |
     |--------------------------------------------------->| (11)
     |                 |                |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoAnswer       |
     |                 |             |<-------------------| (12)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyAnswer     |
     |                 |             |------------------->| (13)
     |                 |             |                    |

                                 Figure 4

4.4.  UA/Policy Server Rendezvous

   The first step in setting up session-specific policies is to
   rendezvous the UAs with the relevant policy servers.  This is
   achieved by providing the URIs of all policy servers relevant for a
   session to the UAs.







Hilt, et al.            Expires February 23, 2008              [Page 14]


Internet-Draft          Session Policy Framework             August 2007


4.4.1.  UAC Behavior

   A UAC compliant to this specification MUST include a Supported header
   field with the option tag "policy" into all requests that can
   initiate an offer/answer exchange [10] (e.g., INVITE, UPDATE and
   PRACK requests).  The UA MUST include the "policy" option tag into
   these requests even if the particular request does not contain an
   offer or answer (e.g., an INVITE request without an offer).  A UA MAY
   include the "policy" option tag into all requests.

   A UAC can receive a 488 (Not Acceptable Here) response that contains
   a Policy-Contact header field.  The Policy-Contact header is a new
   header defined in this specification.  It contains the URI of a
   policy server.  A 488 (Not Acceptable Here) response with this header
   is generated by a proxy to convey the URI of the local policy server
   to the UAC.  After receiving a 488 (Not Acceptable Here) response
   with a Policy-Contact header, a UAC compliant to this specification
   needs to decide if it wants to continue with the session now knowing
   that there is a policy server.  If the UAC decides to continue, it
   MUST use the policy server URI to contact the policy server using the
   mechanism defined in Section 4.5.  After receiving policies from the
   policy server, the UAC decides if it wants to accept these policies
   or not.  If the UAC accepts these policies, the UAC MUST apply them
   to the current request and resend the updated request.  If no changes
   are required by policies or no policies have been received, the
   request can be resent without any policy-induced changes.  If the UAC
   decides that the list of policy servers or the received session
   policies are unacceptable, then the UAC MUST NOT resend the request.

   The UAC MAY resent the unchanged request if it cannot setup a policy
   channel to the policy server, for example, because the policy server
   is unreachable or returns an error condition that cannot be resolved
   by the UAC (i.e., error conditions other than, for example, a 401
   (Unauthorized) responses).  This is to avoid that the failure of a
   policy server prevents a UA from communicating.

   To protect the integrity of the policy server URI in a Policy-Contact
   header, the UAC SHOULD use a secured transport protocol such as TLS
   between UAC and proxy.

   The UAC MUST insert a Policy-Id header into a request if it has
   contacted a policy server and accepted the policies received for this
   request.  The Policy-Id header is a new header that is defined in
   this specification.  The UA MUST create a Policy-Id header value for
   each policy server involved in the preparation of a request.  A
   Policy-Id header value contains two pieces of information: the policy
   server URI and an optional token.  The policy server URI is the URI
   the UA has used to contact the policy server.  The token is an opaque



Hilt, et al.            Expires February 23, 2008              [Page 15]


Internet-Draft          Session Policy Framework             August 2007


   string the UAC can receive from the policy server after contacting
   it.  A token can, for example, be contained in the policy document
   [3].  If the UAC has received a token from the policy server the UAC
   MUST include the token in the Policy-Id header.  The format of the
   Policy-Id header is defined in Section 4.4.5.

   The Policy-Id header enables a proxy to determine if the UAC already
   knows the URI of the local policy server.  A proxy can pass through a
   request if the URI of its policy server is included in the Policy-Id
   header.  If the policy server URI is not yet known to the UAC, the
   proxy can convey this URI to the UAC by rejecting the request with a
   488 (Not Acceptable Here) response.

   In some cases, a request can traverse multiple domains with session-
   policies in place.  Each of these domains can return a 488 (Not
   Acceptable Here) response containing a policy server URI.  Since the
   UAC contacts a policy server after receiving a 488 (Not Acceptable
   Here) response from a domain and before re-sending the request,
   session policies are always applied to a request in the order in
   which the request traverses through the domains.  The UAC MUST NOT
   change this implicit order among policy servers.

   A UAC frequently needs to contact the policy server in the local
   domain before setting up a session.  To avoid the retransmission of
   the local policy server URI in a 488 (Not Acceptable Here) for each
   new request, a UA SHOULD maintain a cache that contains the URI of
   the local policy server (see Section 4.4.4).  The UAC SHOULD use the
   cached policy server URI to contact the local policy server before
   sending a request that initiates the offer/answer exchange for a new
   session (e.g., an INVITE request).

   A UA can decide to change the session description of a session and to
   initiate subsequent offer/answer exchanges (e.g., using INVITE,
   UPDATE or PRACK requests) to re-negotiate the session description.
   When creating such a mid-dialog request, a UA SHOULD contact all
   policy servers to which it has established a policy channel during
   the initial offer/answer exchange (see Section 4.5) before sending
   the request.  This avoids the retransmission of all policy server
   URIs in 488 (Not Acceptable Here) responses for mid-dialog requests.

4.4.2.  Proxy Behavior

   A proxy provides rendezvous functionality for UAs and a policy
   server.  This is achieved by conveying the URI of a policy server to
   the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK
   requests (or any other request that can initiate an offer/answer
   exchange).




Hilt, et al.            Expires February 23, 2008              [Page 16]


Internet-Draft          Session Policy Framework             August 2007


   If such a request contains a Supported header field with the option
   tag "policy", the proxy MAY reject the request with a 488 (Not
   Acceptable Here) response to provide the local policy server URI to
   the UAC.  Before rejecting a request, the proxy MUST verify that the
   request does not contain a Policy-Id header field, which has the
   local policy server URI as a value.  If the request does not contain
   such a header or the local policy server URI is not present in this
   header, then the proxy MAY reject the request with a 488 (Not
   Acceptable Here).  The proxy MUST insert a Policy-Contact header in
   the 488 (Not Acceptable Here) response that contains the URI of its
   associated policy server.  The proxy MAY add the header field
   parameter "non-cacheable" to prevent the UAC from caching this policy
   server URI (see Section 4.4.4).

   If the local policy server URI is present in a Policy-Id header value
   of a request, then the proxy MUST NOT reject the request as described
   above (it can still reject the request for other reasons).  The proxy
   SHOULD remove the Policy-Id header value of its associated policy
   server from the Policy-Id header field before forwarding the request.
   This value only increases message size and is not relevant to other
   proxies on the path.  It also would disclose the policy server URI to
   subsequent proxies.

   The Policy-Id header serves two main purposes: first and most
   importantly, it enables the proxy to determine if a UAC already knows
   the URI of the local policy server.  The second purpose of the
   Policy-Id header is to enable a domain to route all requests that
   belong to the same session (i.e., the initial request and requests a
   UA retransmits after contacting the policy server) to the same proxy
   and policy server.  This is important if a domain has multiple proxy/
   policy server combinations (e.g., in a proxy/policy server farm that
   receives requests through a load balancer), which create per-session
   state in the network.  An example for such a scenario is a policy
   server that is associated with a session border device.  The policy
   server configures the session border device after receiving a session
   description from the UAC via the policy channel.  Retransmitted
   requests for such a session need to be routed to the same proxy/
   policy server as the initial request since this proxy/policy server
   combination has configured the associated border device for the
   session.

   Routing requests that belong to the same session to the same proxy
   can be achieved by using the Policy-Id header token.  It requires
   that the policy server returns a token to the UAC that uniquely
   identifies the specific proxy/policy server combination.  The UAC
   includes this token in the Policy-Id header and it can be used
   (together with the policy server URI) by the proxies in this domain
   to route the request along the desired path.  The format of this



Hilt, et al.            Expires February 23, 2008              [Page 17]


Internet-Draft          Session Policy Framework             August 2007


   token does not require standardization.  The only requirement is that
   the token provides sufficient information for proxies to route the
   message inside a domain to the desired proxy/policy server.  The
   token can, for example, be a numeric identifier or an IP address.

      Note: it has been proposed to use the Policy-Id header to provide
      a hint for a proxy that the UAC has actually contacted the policy
      server.  This usage also requires the policy server to return a
      token to the UA.  In addition, the policy server needs to share
      valid tokens with the proxy.  After receiving a request with a
      Policy-Id header, the proxy can determine if the token in the
      Policy-Id header is valid.  If it is valid, the proxy knows that
      the UA has contacted the policy server for this session.  However,
      this token does not provide any proof that the UA has actually
      used the policies it has received from the policy server.  A
      malicious UA can simply contact the policy server, discard all
      policies it receives but still use the token in the Policy-Id
      header.

   The proxy MAY insert a Policy-Contact header field into INVITE,
   UPDATE or PRACK requests (or any other request that can initiate an
   offer/answer exchange) in order to convey the policy server URI to
   the UAS.  If the request already contains a Policy-Contact header
   field, the proxy MUST insert the URI ahead of all existing values at
   the beginning of the list.  A proxy MUST NOT change the order of
   existing Policy-Contact header values.

   A proxy MUST use the Record-Route header mechanism [7] if its
   associated policy server has session policies that apply to mid-
   dialog requests.  The proxy MAY use the Record-Route header mechanism
   in other cases.  The Record-Route header enables a proxy to stay in
   the signaling path and re-submit the policy server URIs to UAs during
   mid-dialog requests that initiate an offer/answer exchange.  Re-
   submitting the policy server URI to UAs ensures that UAs keep
   contacting the policy server for mid-dialog requests.

   A proxy can find out if the UAS supports this extension by examining
   the Supported header of responses.  The proxy knows that the UAS
   supports this extension if the Supported header of a response
   contains the option tag "policy".  A proxy can use this information
   to determine if the UAS has understood the Policy-Contact header it
   has inserted into the request.

   To protect the integrity of the policy server URI in a Policy-Contact
   header, the proxy SHOULD use a secured transport protocol such as TLS
   between proxy and UAs.





Hilt, et al.            Expires February 23, 2008              [Page 18]


Internet-Draft          Session Policy Framework             August 2007


4.4.3.  UAS Behavior

   A UAS can receive an INVITE, UPDATE or PRACK request (or another
   request that can initiate offer/answer exchanges) that contains a
   Policy-Contact header field with a list of policy server URIs.  A UAS
   that receives such a request needs to decide if it wants to accept
   the session knowing that there are policy servers involved.  If it
   accepts, the UAS MUST contact all policy server URIs in a Policy-
   Contact header.  The UAS MUST contact the policy server URIs in the
   order in which they were contained in the Policy-Contact header,
   starting with the topmost value.

   If a UAS decides that it does not want to accept a session because
   there are policy servers involved or because one of the session
   policies received from a policy server is not acceptable, the UAS
   MUST reject the request with a 488 (Not Acceptable Here) response.

   The UAS MAY accept a request and continue with setting up a session
   if it cannot setup a policy channel to the policy server, for
   example, because the policy server is unreachable or returns an error
   condition that cannot be resolved by the UAS (i.e., error conditions
   other than, for example, a 401 (Unauthorized) responses).  This is to
   avoid that the failure of a policy server prevents a UA from
   communicating.  Since this session may not be policy compliant
   without the policy subscription, it may be blocked by policy
   enforcement mechanisms if they are in place.

   A UAS can receive a token from a policy server via the policy
   channel.  Since the UAS does not create a Policy-ID header, it can
   simply ignore this token.

   A UAS compliant to this specification MUST include a Supported header
   field with the option tag "policy" into responses.  This way, a proxy
   that has inserted the Policy-Contact header can know that the header
   was understood by the UAS.

4.4.4.  Caching the Local Policy Server URI

   A UAC frequently needs to contact the policy server in the local
   domain before setting up a session.  To avoid the retransmission of
   the local policy server URI for each session, a UA SHOULD maintain a
   cache that contains the URI of the local policy server.

   A UA can receive this URI in a Policy-Contact header of a request or
   a 488 (Not Acceptable Here) response.  The UA can also receive the
   local policy server URI through configuration, for example, via the
   configuration framework [4].  If a UA has received a local policy
   server URI through configuration and receives another local policy



Hilt, et al.            Expires February 23, 2008              [Page 19]


Internet-Draft          Session Policy Framework             August 2007


   server URI in a Policy-Contact header, the UA SHOULD overwrite the
   configured URI with the most recent one received in a Policy-Contact
   header.

   Domains can prevent a UA from caching the local policy server URI.
   This is useful, for example, if the policy server does not need to be
   involved in all sessions or the policy server URI changes from
   session to session.  A proxy can mark the URI of such a policy server
   as "non-cacheable".  A UA MUST NOT cache a non-cacheable policy
   server URI.  The UA SHOULD remove the current URI from the cache when
   receiving a local policy server URI that is marked as "non-
   cacheable".  This is to avoid the use of policy server URIs that are
   outdated.

   The UA SHOULD NOT cache policy server URIs it has received from
   proxies outside of the local domain.  These policy servers need not
   be relevant for subsequent sessions, which can go to a different
   destination, traversing different domains.

   The UA MUST NOT cache tokens it has received from a policy server.  A
   token is only valid for one request.

4.4.5.  Header Definition and Syntax

4.4.5.1.  Policy-Id Header

   The Policy-Id header field is inserted by the UAC into INVITE, UPDATE
   or PRACK requests (or any other request that can be used to initiate
   an offer/answer exchange).  The Policy-Id header identifies all
   policy servers the UAC has contacted for this request.

   The value of a Policy-Id header consists of a policy server URI and
   an optional token parameter.  The token parameter contains a token
   the UA may have received from the policy server.

   The syntax of the Policy-Id header field is:

     Policy-Id        = "Policy-Id" HCOLON policyURI
                        *(COMMA  policyURI)
     policyURI        = ( SIP-URI / SIPS-URI )
                        [ SEMI token-param ] *( SEMI generic-param )
     token-param      = "token=" token

   The BNF for SIP-URI, SIPS-URI, token and generic-param is defined in
   RFC3261 [7].






Hilt, et al.            Expires February 23, 2008              [Page 20]


Internet-Draft          Session Policy Framework             August 2007


4.4.5.2.  Policy-Contact Header

   The Policy-Contact header field can be inserted by a proxy into a 488
   (Not Acceptable Here) response to INVITE, UPDATE or PRACK requests
   (or other requests that initiate an offer/answer exchange).  The
   value of a Policy-Contact header consists of a policy server URI and
   an optional "non-cacheable" parameter.  The policy server URI
   identifies the policy server that needs to be contacted by a UAC.
   The "non-cacheable" parameter indicates that the policy server URI
   should not be cached by the UAC.

   The Policy-Contact header field can also be inserted by a proxy into
   INVITE, UPDATE and PRACK requests (or other requests that can be used
   to initiate an offer/answer exchange).  It contains an ordered list
   of policy server URIs that need to be contacted by the UAS.  The
   topmost value of this list identifies the policy server that is
   contacted first.  New header field values are inserted at the top.
   With this, the Policy-Contact header field effectively forms a stack.

   The syntax of the Policy-Contact header field is:

     Policy-Contact   = "Policy-Contact" HCOLON policyContactURI
                        *(COMMA policyContactURI)
     policyContactURI = ( SIP-URI / SIPS-URI )
                        [ SEMI "non-cacheable" ] *( SEMI generic-param )

   The BNF for SIP-URI, SIPS-URI and generic-param is defined in RFC3261
   [7].

   Tables 1 and 2 are extensions of Tables 2 and 3 in RFC 3261 [7].  The
   column "INF" is for the INFO method [6], "PRA" is for the PRACK
   method [9], "UPD" is for the UPDATE method [5], "SUB" is for the
   SUBSCRIBE method [8], "NOT" is for the NOTIFY method [8], "MSG" is
   for the MESSAGE method [12], "REF" is for the REFER method [13], and
   "PUB" is for the PUBLISH method [14].

     Header field          where   proxy ACK BYE CAN INV OPT REG UPD
     _______________________________________________________________
     Policy-Id               R       rd   -   -   -   c   -   -   c
     Policy-Contact          R       a    -   -   -   c   -   -   c
     Policy-Contact         488      a    -   -   -   c   -   -   c
           Table 1: Policy-Id and Policy-Contact Header Fields









Hilt, et al.            Expires February 23, 2008              [Page 21]


Internet-Draft          Session Policy Framework             August 2007


     Header field          where   proxy PRA PUB SUB NOT INF MSG REF
     _______________________________________________________________
     Policy-Id               R       rd   c   -   -   -   -   -   -
     Policy-Contact          R       a    c   -   -   -   -   -   -
     Policy-Contact         488      a    c   -   -   -   -   -   -
           Table 1: Policy-Id and Policy-Contact Header Fields

4.5.  Policy Channel

   The main task of the policy channel is to enable a UA to submit
   information about the session it is trying to establish (i.e., the
   offer and the answer) to a policy server and to receive the resulting
   session-specific policies and possible updates to these policies in
   response.

   A UA compliant to this specification MUST implement the Event Package
   for Session-Specific Session Policies [2] as policy channel.  The UA
   sets up a policy channel by subscribing to the policy server using
   this event package.

4.5.1.  Creation and Management

   A UA discovers the list of policy servers relevant for a session
   during the initial offer/answer exchange (see Section 4.4).  A UA
   compliant to this specification MUST set up a policy channel to each
   of the discovered policy server.  If the UA does not want to set up a
   policy channel to the policy servers provided, the UA MUST NOT
   continue with the session.  This means that, the UA MUST cancel or
   reject a pending INVITE transaction for the session or terminate the
   session if it is already in progress.

   If setting up a policy channel to one of the discovered policy
   servers fails, the UA MAY continue with the initiation of a session
   without contacting this policy server.  Setting up a policy channel
   can fail, for example, because the server is unreachable or returns
   an error condition that cannot be resolved by the UAC (i.e., error
   conditions other than, for example, a 401 (Unauthorized) responses).
   The UA SHOULD continue an ongoing session if a policy server fails
   after the session has been set up.  The UA SHOULD consider the
   policies it has previously received from the failed policy server.
   This is to avoid that the failure of a policy server prevents a UA
   from communicating.

   A UA MUST maintain the policy channel to each discovered policy
   server during the lifetime of a session, unless the policy channel is
   closed by the policy server or the UA discovers that the policy
   server is no longer relevant for the session (see below).




Hilt, et al.            Expires February 23, 2008              [Page 22]


Internet-Draft          Session Policy Framework             August 2007


   A UAC can receive a 488 (Not Acceptable Here) with a Policy-Contact
   header containing a new policy server URI in response to a mid-dialog
   request.  This indicates that the set of policy servers relevant for
   the current session has changed.  If this occurs, the UAC MUST retry
   sending the request as if it was the first request in a dialog (i.e.,
   without applying any policies except policies from the local policy
   server).  This way, the UAC will re-discover the list of policy
   servers relevant for the current session.  The UAC should compare the
   new list with the list of policy servers to which it currently has
   established a policy channel.  The UAC MUST set up a policy channel
   to each new policy servers.  The UAC SHOULD close a policy channel if
   the policy server is not listed any more.  The UAC MUST contact
   policy servers in the order in which they were discovered in the most
   recent request.

   If a UAS receives a mid-dialog request with a Policy-Contact header
   containing a list of policy server URIs that is different from the
   list of policy servers to which the UAS has currently established a
   policy channel, then the UAS MUST set up a policy channel to all new
   policy servers and contact them.  The UAS SHOULD close policy
   channels to servers that are not listed any more.  The UAS MUST use
   policy servers in the order in which they were contained in the most
   recent Policy-Contact header.

   A UA MUST inform the policy server when a session is terminated via
   the policy channel, unless a policy server indicates via the policy
   channel that it does not need to be contacted at the end of the
   session.  This enables a policy server to free all resources it has
   allocated for this session.

4.5.2.  Contacting the Policy Server

   A UA MUST contact all policy servers to which it has established a
   policy channel before sending or after receiving a mid-dialog
   request.  The UA MUST contact the policy server in the order in which
   they were discovered most recently.

   A UA that receives a SIP message containing an offer or answer SHOULD
   completely process the message (e.g., according to RFC3261 [7])
   before contacting the policy server.  The SIP processing of the
   message includes, for example, updating dialog state and timers as
   well as creating ACK or PRACK requests as necessary.  This ensures
   that contacting a policy server does not interfere with SIP message
   processing and timing (e.g., by inadvertently causing timers to
   expire).  This implies, for example, that a UAC which has received a
   response to an INVITE request SHOULD finish the processing of the
   response including transmitting the ACK before it contacts the policy
   server.  An important exception to this rule is discussed in the next



Hilt, et al.            Expires February 23, 2008              [Page 23]


Internet-Draft          Session Policy Framework             August 2007


   paragraph.

   In some cases, a UA needs to use the offer/answer it has received in
   a SIP message to create an ACK or PRACK response for this message,
   i.e., it needs to use the offer/answer before finishing the SIP
   machinery for this message.  For example, a UAC that has received an
   offer in the response to an INVITE request needs to apply policies to
   the offer and the answer before it can send the answer in an ACK.  In
   these cases, a UA SHOULD contact the policy server even if this is
   during the processing of a SIP message.  This implies that a UA,
   which has received an offer in the response of an INVITE request,
   SHOULD contact the policy server and apply session policies before
   sending the answer in the ACK.

      Note: this assumes that the policy server can always respond
      immediately to a policy request and does not require manual
      intervention to create a policy.  This will be the case for most
      policy servers.  If, however, a policy server cannot respond with
      a policy right away, it can return a policy that temporarily
      denies the session and update this policy as the actual policy
      decision becomes available.  A delay in the response from the
      policy server to the UA would delay the transmission of the ACK
      and could trigger retransmissions of the INVITE response (also see
      the recommendations for Flow I in RFC3725 [15]).

4.5.3.  Using Session Policies

   A UA MUST disclose the session description(s) for the current session
   to policy servers through the policy channel.  The UA MUST apply
   session policies it receives to the offer and, if one is received, to
   the answer before using the offer/answer.  If these policies are
   unacceptable, the UA MUST NOT continue with the session.  This means
   that, the UA MUST cancel or reject a pending INVITE transaction for
   the session or terminate the session if it is already in progress.
   If the UA receives an unacceptable policy in an INVITE response, the
   UA MUST complete the INVITE transaction and then terminate the
   session.

   When a UA receives a notification about a change in the current
   policies, the UA MUST apply the updated policies to the current
   session or the UA MUST terminate the session.  If the policy update
   causes a change in the session description of a session, then the UA
   needs to re-negotiate the modified session description with its peer
   UA, for example, using a re-INVITE or UPDATE request.  For example,
   if a policy update disallows the use of video and video is part of
   the current session description, then the UA will need to create an
   new session description offer without video.  After receiving this
   offer, the peer UA knows that video can't be used any more and



Hilt, et al.            Expires February 23, 2008              [Page 24]


Internet-Draft          Session Policy Framework             August 2007


   responds with the corresponding answer.


5.  Security Considerations

   Session policies can significantly change the behavior of a user
   agent and can 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 causes the UA to terminate the session.

   A user agent transmits session information to a policy server for
   session-specific policies.  This session information can contain
   sensitive data the user does not want an eavesdropper or an
   unauthorized policy server to see.  Vice versa, session policies can
   contain sensitive information about the network or service level
   agreements the service provider does not want to disclose to an
   eavesdropper or an unauthorized user agent.

   It is important to secure the communication between the proxy and the
   user agent (for session-specific policies) as well as the user agent
   and the policy server.  The following four discrete attributes need
   to be protected:

   1.  integrity of the policy server URI (for session-specific
       policies),
   2.  authentication of the policy server and, if needed, the user
       agent,
   3.  confidentiality of the messages exchanged between the user agent
       and the policy server and
   4.  ensuring that private information is not exchanged between the
       two parties, even over an confidentiality-assured and
       authenticated session.

   To protect the integrity of the policy server URI, a UA SHOULD use a
   secured transport protocol such as TLS between proxies and the UA.
   Protecting the integrity of the policy server URI is important since
   an attacker could intercept SIP messages between the UA and the proxy
   and remove the policy headers needed for session-specific policies.
   This would impede the rendezvous between UA and policy server and,
   since the UA would not contact the policy server, can prevent a UA
   from setting up a session.

   Instead of removing a policy server URI, an attacker can also modify
   the policy server URI and point the UA to a compromised policy
   server.  To prevent such an attack from being effective, it is
   RECOMMENDED that a UA authenticates policy servers.



Hilt, et al.            Expires February 23, 2008              [Page 25]


Internet-Draft          Session Policy Framework             August 2007


   Policy servers SHOULD authenticate UAs to protect the information
   that is contained in a session policy.  However, a policy server can
   also 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.

   It is RECOMMENDED that administrators use SIPS URIs as policy server
   URIs so that subscriptions to session policies are transmitted over
   TLS.

   The above security attributes are important to protect the
   communication between the user agent and policy server.  This
   document does not define the protocol used for the communication
   between user agent and policy server and merely refers to other
   specifications for this purpose.  The security considerations of
   these specifications need to address the above security aspects.


6.  IANA Considerations

6.1.  Registration of the "Policy-Id" Header

      Name of Header: Policy-Id

      Short form: none

      Normative description: Section 4.4.5 of this document

6.2.  Registration of the "Policy-Contact" Header

      Name of Header: Policy-Contact

      Short form: none

      Normative description: Section 4.4.5 of this document

6.3.  Registration of the "policy" SIP Option-Tag

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of RFC3261 [7].

   This document defines the SIP option tag "policy".

   The following row has been added to the "Option Tags" section of the
   SIP Parameter Registry:






Hilt, et al.            Expires February 23, 2008              [Page 26]


Internet-Draft          Session Policy Framework             August 2007


   +------------+------------------------------------------+-----------+
   | Name       | Description                              | Reference |
   +------------+------------------------------------------+-----------+
   | policy     | This option tag is used to indicate that | this      |
   |            | a UA can process policy server URIs for  | document  |
   |            | and subscribe to session-specific        |           |
   |            | policies.                                |           |
   +------------+------------------------------------------+-----------+

      Name of option: policy

      Description: Support for the Policy-Contact and Policy-Id headers.

      SIP headers defined: Policy-Contact, Policy-Id

      Normative description: This document


7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP)
         Event Package for Session-Specific  Session Policies.",
         draft-ietf-sipping-policy-package-03 (work in progress),
         February 2007.

   [3]   Hilt, V., "A User Agent Profile Data Set for Media Policy",
         draft-ietf-sipping-media-policy-dataset-04 (work in progress),
         May 2007.

   [4]   Petrie, D. and S. Channabasappa, "A Framework for Session
         Initiation Protocol User Agent Profile Delivery",
         draft-ietf-sipping-config-framework-12 (work in progress),
         June 2007.

   [5]   Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
         Method", RFC 3311, October 2002.

   [6]   Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [7]   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, et al.            Expires February 23, 2008              [Page 27]


Internet-Draft          Session Policy Framework             August 2007


   [8]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [9]   Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [10]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

7.2.  Informative References

   [11]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

   [12]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [13]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [14]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [15]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
         April 2004.


Appendix A.  Acknowledgements

   Many thanks to Allison Mankin for the discussions and the suggestions
   for this draft.  Many thanks to Roni Even, Bob Penfield, Mary Barnes,
   Shida Schubert and Keith Drage for reviewing the draft and to Vijay
   Gurbani for the contributions to the security considerations.


Appendix B.  Session-Specific Policies - Call Flows

   The following call flows illustrate the overall operation of session-
   specific policies including the policy channel protocol as defined in
   the SIP Event Package for Session-Specific Session Policies [2].

   The following abbreviations are used:





Hilt, et al.            Expires February 23, 2008              [Page 28]


Internet-Draft          Session Policy Framework             August 2007


      o: offer
      o': offer modified by a policy
      po: offer policy
      a: answer
      a': answer modified by a policy
      pa: answer policy
      ps uri: policy server URI (in Policy-Contact header)
      ps id: policy server id (in Policy-Id header)

B.1.  Offer in Invite









































Hilt, et al.            Expires February 23, 2008              [Page 29]


Internet-Draft          Session Policy Framework             August 2007


   UA A       P A      PS A      PS B       P B      UA B
     |         |         |         |         |         |
     |(1) INV <o>        |         |         |         |
     |-------->|         |         |         |         |
     |(2) 488 <ps uri>   |         |         |         |
     |<--------|         |         |         |         |
     |(3) ACK  |         |         |         |         |
     |-------->|         |         |         |         |
     |(4) SUBSCRIBE <o>  |         |         |         |
     |------------------>|         |         |         |
     |(5) 200 OK         |         |         |         |
     |<------------------|         |         |         |
     |(6) NOTIFY <po>    |         |         |         |
     |<------------------|         |         |         |
     |(7) 200 OK         |         |         |         |
     |------------------>|         |         |         |
     |(8) INV <ps id, o'>|         |         |         |
     |-------->|         |         |         |         |
     |         |(9) INV <o'>       |         |         |
     |         |---------------------------->|         |
     |         |         |         |         |(10) INV <o', ps uri>
     |         |         |         |         |-------->|
     |         |         |         |(11) SUBSCRIBE <o', a>
     |         |         |         |<------------------|
     |         |         |         |(12) 200 OK        |
     |         |         |         |------------------>|
     |         |         |         |(13) NOTIFY <po, pa>
     |         |         |         |------------------>|
     |         |         |         |(14) 200 OK        |
     |         |         |         |<------------------|
     |         |         |         |         |(15) 200 OK <a'>
     |         |         |         |         |<--------|
     |         |(16) 200 OK <a'>   |         |         |
     |         |<----------------------------|         |
     |(17) 200 OK <a'>   |         |         |         |
     |<--------|         |         |         |         |
     |(18) ACK |         |         |         |         |
     |------------------------------------------------>|
     |(19) SUBSCRIBE <o', a'>      |         |         |
     |------------------>|         |         |         |
     |(20) 200 OK        |         |         |         |
     |<------------------|         |         |         |
     |(21) NOTIFY <po, pa>         |         |         |
     |<------------------|         |         |         |
     |(22) 200 OK        |         |         |         |
     |------------------>|         |         |         |
     |         |         |         |         |         |
     |         |         |         |         |         |



Hilt, et al.            Expires February 23, 2008              [Page 30]


Internet-Draft          Session Policy Framework             August 2007


B.2.  Offer in Response

   UA A       P A      PS A      PS B       P B      UA B
     |         |         |         |         |         |
     |(1) INV  |         |         |         |         |
     |-------->|         |         |         |         |
     |(2) 488 <ps uri>   |         |         |         |
     |<--------|         |         |         |         |
     |(3) ACK  |         |         |         |         |
     |-------->|         |         |         |         |
     |(4) SUBSCRIBE      |         |         |         |
     |------------------>|         |         |         |
     |(5) 200 OK         |         |         |         |
     |<------------------|         |         |         |
     |(6) NOTIFY         |         |         |         |
     |<------------------|         |         |         |
     |(7) 200 OK         |         |         |         |
     |------------------>|         |         |         |
     |(8) INV <ps id>    |         |         |         |
     |-------->|         |         |         |         |
     |         |(9) INV  |         |         |         |
     |         |---------------------------->|         |
     |         |         |         |         |(10) INV <ps uri>
     |         |         |         |         |-------->|
     |         |         |         |(11) SUBSCRIBE <o> |
     |         |         |         |<------------------|
     |         |         |         |(12) 200 OK        |
     |         |         |         |------------------>|
     |         |         |         |(13) NOTIFY <po>   |
     |         |         |         |------------------>|
     |         |         |         |(14) 200 OK        |
     |         |         |         |<------------------|
     |         |         |         |         |(15) 200 OK <o'>
     |         |         |         |         |<--------|
     |         |(16) 200 OK <o'>   |         |         |
     |         |<----------------------------|         |
     |(17) 200 OK <o'>   |         |         |         |
     |<--------|         |         |         |         |
     |(18) SUBSCRIBE <o', a>       |         |         |
     |------------------>|         |         |         |
     |(19) 200 OK        |         |         |         |
     |<------------------|         |         |         |
     |(20) NOTIFY <po, pa>         |         |         |
     |<------------------|         |         |         |
     |(21) 200 OK        |         |         |         |
     |------------------>|         |         |         |
     |(22) ACK <a'>      |         |         |         |
     |------------------------------------------------>|



Hilt, et al.            Expires February 23, 2008              [Page 31]


Internet-Draft          Session Policy Framework             August 2007


     |         |         |         |(23) SUBSCRIBE <o', a'>
     |         |         |         |<------------------|
     |         |         |         |(24) 200 OK        |
     |         |         |         |------------------>|
     |         |         |         |(25) NOTIFY <po, pa>
     |         |         |         |------------------>|
     |         |         |         |(26) 200 OK        |
     |         |         |         |<------------------|
     |         |         |         |         |         |
     |         |         |         |         |         |


Authors' Addresses

   Volker Hilt
   Bell Labs/Alcatel-Lucent
   791 Holmdel-Keyport Rd
   Holmdel, NJ  07733
   USA

   Email: volkerh@bell-labs.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Jonathan Rosenberg
   Cisco
   Edison, NJ
   USA

   Email: jdrosen@cisco.com













Hilt, et al.            Expires February 23, 2008              [Page 32]


Internet-Draft          Session Policy Framework             August 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hilt, et al.            Expires February 23, 2008              [Page 33]