draft-ietf-sipping-session-policy-framework-00.txt   draft-ietf-sipping-session-policy-framework-01.txt 
SIPPING Working Group V. Hilt SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Lucent Technologies Internet-Draft Bell Labs/Lucent Technologies
Expires: October 6, 2006 G. Camarillo Expires: December 25, 2006 G. Camarillo
Ericsson Ericsson
J. Rosenberg J. Rosenberg
Cisco Systems Cisco Systems
April 4, 2006 June 23, 2006
A Framework for Session Initiation Protocol (SIP) Session Policies A Framework for Session Initiation Protocol (SIP) Session Policies
draft-ietf-sipping-session-policy-framework-00 draft-ietf-sipping-session-policy-framework-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 6, 2006. This Internet-Draft will expire on December 25, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Proxy servers play a central role as an intermediary in the Session Proxy servers play a central role as an intermediary in the Session
Initiation Protocol (SIP) as they define and impact policies on call Initiation Protocol (SIP) as they define and impact policies on call
routing, rendezvous, and other call features. However, there is routing, rendezvous, and other call features. However, there is
currently no standard mechanism by which a proxy can influence currently no standard mechanism by which a proxy can define or
session policies such as the codecs or media types to be used. This influence policies on sessions such as the codecs or media types to
document specifies a framework for SIP session policies. It defines be used. This document specifies a framework for SIP session
two types of session policies, session-specific and session- policies that provides this capability to proxies. It defines a
independent policies and introduces a model, an overall architecture model, an overall architecture and the protocol components for
and the protocol components needed for session policies. session policies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Session-Independent Policies . . . . . . . . . . . . . . . . . 4 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5
3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6
3.2.1. Subscription . . . . . . . . . . . . . . . . . . . . . 5 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7
3.2.2. Content . . . . . . . . . . . . . . . . . . . . . . . 6
4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 6
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 8 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 9 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 10
4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 12 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 12
4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 13 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 13
4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Caching of Policy Server URIs . . . . . . . . . . . . 14 4.4.2. Caching of Policy Server URIs . . . . . . . . . . . . 14
4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 15 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 15
4.4.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 4.4.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15
4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 16 4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 16
4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Policy Subscription . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 19
6.2. Registration of the "Policy-Contact" Header . . . . . . . 19
6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Appendix B. Call Flows . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Session-Specific Policies - Call Flows . . . . . . . 19
B.1. PUBLISH/SUBSCRIBE - Offer in Invite . . . . . . . . . . . 19 B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 20
B.2. PUBLISH/SUBSCRIBE - Offer in Response . . . . . . . . . . 21 B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 22
B.3. SUBSCRIBE - Offer in Invite . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.4. SUBSCRIBE - Offer in Response . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [6] is a signaling protocol for The Session Initiation Protocol (SIP) [6] is a signaling protocol for
creating, modifying and terminating multimedia sessions. A central creating, modifying and terminating multimedia sessions. A central
element in SIP is the proxy server. Proxy servers are intermediaries element in SIP is the proxy server. Proxy servers are intermediaries
that are responsible for request routing, rendezvous, authentication that are responsible for request routing, rendezvous, authentication
and authorization, mobility, and other signaling services. However, and authorization, mobility, and other signaling services. However,
proxies are divorced from the actual sessions - audio, video, and proxies are divorced from the actual sessions - audio, video, and
messaging - that SIP establishes. Details of the sessions are messaging - that SIP establishes. Details of the sessions are
skipping to change at page 3, line 26 skipping to change at page 3, line 26
provides end-to-end encryption features using S/MIME, so that all provides end-to-end encryption features using S/MIME, so that all
information about the sessions can be hidden from eavesdroppers and information about the sessions can be hidden from eavesdroppers and
proxies alike. proxies alike.
However, experience has shown that there is a need for SIP However, experience has shown that there is a need for SIP
intermediaries to impact aspects of a session. For example, SIP may intermediaries to impact aspects of a session. For example, SIP may
be used in a wireless network, which has limited resources for media be used in a wireless network, which has limited resources for media
traffic. During periods of high activity, the wireless network traffic. During periods of high activity, the wireless network
provider wants to restrict the amount of bandwidth available to each provider wants to restrict the amount of bandwidth available to each
individual user. With session policies, an intermediary in the individual user. With session policies, an intermediary in the
wireless network can inform the user agent about the bandwidth it wireless network can inform the user agent about the bandwidth it can
currently has available. This information enables the user agent to currently count on. This information enables the user agent to make
make an informed decision about the number of streams, the media an informed decision about the number of streams, the media types,
types, and the codecs it can successfully use in a session. and the codecs it can successfully use in a session. Similarly, a
network provider may have a service level agreement with a user that
defines the set of media types a 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 In another example, a SIP user agent is using a network which is
connected to the public Internet through a firewall or a network connected to the public Internet through a firewall or a network
border device. The network provider would like to tell the user border device. The network provider would like to tell the user
agent that it needs to send its media streams to a specific IP 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 address and port on the firewall or border device to reach the public
Internet. Knowing this policy enables the user agent to set up Internet. Knowing this policy enables the user agent to set up
sessions across the firewall or the network border. In contrast to sessions across the firewall or the network border. In contrast to
other methods for inserting a media intermediary, the use of session other methods for inserting a media intermediary, the use of session
policies does not require the inspection or modification of SIP policies does not require the inspection or modification of SIP
message bodies. Other user cases for session policies are described message bodies.
in [8].
Domains sometimes enforce policies they have in place. For example,
a domain might have a configuration in which all packets containing a
certain audio codec are dropped. Unfortunately, enforcement
mechanisms usually do not inform the user about the policies they are
enforcing and silently keep the user from doing anything against
them. This may lead to the malfunctioning of devices that is
incomprehensible to the user. With session policies, the user knows
about the restricted codecs and can use a different codec or simply
connect to a domain with less stringent policies. 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, Domains often enforce the session policies they have in place. For
but the provider still retains the right to enforce the policy. example, a domain might have a policy that disallows the use of video
and may enforce this policy by dropping all packets that contain a
video encoding. Unfortunately, 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 may
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 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 Two types of session policies exist: session-specific policies and
session-independent policies. Session-specific policies are policies session-independent policies. Session-specific policies are policies
that are created for one particular session, in response to the that are created for one particular session, based on the session
session description for this session. For example, a session- description of this session. They enable a network intermediary to
specific policy may modify the IP addresses and ports of media examine the session description a UA is proposing and to return a
streams in a specific session. Since session-specific policies are policy specifically for this session description. For example, an
tailored to a session, they only apply to the session they are intermediary could open pinholes in a firewall/NAT for each media
created for. Session-specific policies are created on a session-by- stream in a session and return a policy that replaces the internal IP
session basis during the establishment of the session. addresses and ports with external ones. 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 Session-independent policies on the other hand are policies that are
created independent of a session and generally apply to the SIP created independent of a session and generally apply to the SIP
sessions set up by a user agent. Since these policies are not based sessions set up by a user agent. A session-independent policy can,
on a specific session description, they can be created and conveyed for example, be used to inform user agents about an existing
to the user agent at any time, independent of an attempt to set up a bandwidth limit or media type restrictions. Since these policies are
session. 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 once (e.g. at the time the device is
powered on).
This specification defines a framework for SIP session policies. It This specification defines a framework for SIP session policies. It
specifies a model, the overall architecture, and the protocol specifies a model, the overall architecture, and the protocol
components that are needed for session-independent and session- components that are needed for session-independent and session-
specific policies. specific policies.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
3. Session-Independent Policies 3. Session-Independent Policies
This section defines a model and the protocol components for session- Session-independent policies are policies that are created
independent policies. independent of a session and generally apply to the sessions a user
agent is setting up. They typically remain stable for a longer
period of time and apply to the sessions set up while they are valid.
However, session-independent policies may also change over time. For
example, a policy that defines a bandwidth limit for a user may
change during the day, defining a lower limit during peak hours and
allow more bandwidth off-peak.
3.1. Overview 3.1. Architecture and Overview
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
Figure 1
A SIP UA may 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 access or local
network domain (i.e. the domain from which the UA receives IP
service) and possibly the home network domain (i.e. the domain the UA
registers at). The local network may, for example, have policies
that support the access network infrastructure (e.g. in a wireless
network where bandwidth is scarce, a provider may restrict the
bandwidth available to an individual user). The home network may
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 at
most two policy servers.
Setting up session-independent policies involves the following steps: Setting up session-independent policies involves the following steps:
1. A user agent requests session-independent policies from the 1. A user agent requests session-independent policies from the
policy servers in the local network and home domain. These two policy servers in the local network and home domain. A user
domains most likely have session-independent policies for a user agent typically requests these policies when it starts up or
agent. A user agent typically request these policies when it connects to a new network domain.
starts up or connects to a new network domain.
2. The policy server selects the policies that apply to this user 2. The policy server selects the policies that apply to this user
agent. The policy server may have general policies that apply to agent. The policy server may have general policies that apply to
all users or maintain separate policies for each individual user. all users or maintain separate policies for each individual user.
The selected policies are returned to the user agent. The selected policies are returned to the user agent.
3. The policy server may update the policies, for example, when 3. The policy server may update the policies, for example, when
network conditions change. network conditions change.
3.2. Protocol 3.2. Policy Subscription
A UA subscribes to session-independent policies using the "ua
profile" event package defined in the Framework for SIP User Agent
Profile Delivery [4]. This event package has been designed to
support subscriptions to user agent configuration information as well
as to session-specific policies. A server can provide session-
independent policies and configuration information through the same
subscription. However, it is expected that session-independent
policies and configuration information will often be provided by
different servers, which may even be in different domains. In
addition, session-independent policies may change more frequently
than configuration information since they may consider external
information, such as the network status.
3.2.1. Subscription
Session-independent policies are usually provided by the network A UA requests session-independent policies by subscribing to the
domain the UA is physically connected to (i.e. the local network policy server in a domain. Subscriptions to session-independent
domain). This domain may, for example, have policies that limit the policies are established using the "ua-profile" event package defined
bandwidth currently available to each user. Frequently, the domain a in the Framework for SIP User Agent Profile Delivery [4].
user registers at (i.e., the domain in the address-of-record (AoR))
will also provides session-independent policies. This domain may,
for example, provide policies needed for a service the user has
subscribed to.
The "ua profile" event package [4] provides a mechanism to discover The "ua-profile" event package [4] provides a mechanism to discover
policy servers in these two domains. The "localnetwork" profile-type policy servers in the local network and the home domain. The "local-
enables a UA to discover a servers in the local network domain; the network" profile-type enables a UA to discover a policy server in the
"user" profile type enables the discovery of a server in the AoR local domain; the "user" profile type in the home domain. A UA
domain. A UA SHOULD attempt to discover and subscribe to the policy compliant to this specification SHOULD attempt to discover and
servers in these two domains. subscribe to the policy servers in these two domains.
A UA SHOULD create a SUBSCRIBE request when the following events A UA SHOULD (re-)subscribe to session-independent policies when the
occur: following events occur:
o The UA registers a new AoR or it removes a AoR from the set of o The UA registers a new AoR or removes a AoR from the set of AoRs
AoRs it has registered. In these cases, the UA SHOULD establish it has registered. In these cases, the UA SHOULD establish
subscriptions for each new AoR using the "user" and the subscriptions for each new AoR using the "user" and the "local-
"localnetwork" profile-types. The UA SHOULD terminate all network" profile-types. The UA SHOULD terminate all subscriptions
subscriptions for AoRs it has removed. for AoRs it has removed.
o The UA changes the domain it is connected to. The UA SHOULD o The UA changes the domain it is connected to. The UA SHOULD
terminate all existing subscriptions for the "localnetwork" terminate all existing subscriptions for the "local-network"
profile-type. It SHOULD then create a new subscription for each profile-type. It SHOULD then create a new subscription for each
AoR using the "localnetwork" profile-type. This way, the UA stops AoR using the "local-network" profile-type. This way, the UA
receiving policies from the previous local domain and starts stops receiving policies from the previous local domain and starts
receives policies from the new local domain instead. The UA does to receive the policies of the new local domain. The UA does not
not need to change the subscriptions for "user" profiles. need to change the subscriptions for "user" profiles.
If a subscriber is unable to establish a subscription, it SHOULD NOT If a subscriber is unable to establish a subscription, it SHOULD NOT
attempt to re-try this subscription, unless one of the above events attempt to re-try this subscription, unless one of the above events
occurs again. This is to limit the number of SUBSCRIBE requests sent occurs again. This is to limit the number of SUBSCRIBE requests sent
within domains that do not support session-independent policies. within domains that do not support session-independent policies.
3.2.2. Content A UA compliant to this specification MUST support the User Agent
Profile Data Set for Media Policy [3] and the Schema for SIP User
The "ua profile" event package is an abstract event package that does Agent Profile Data Sets [8]. To indicate that the UA wants to
not define a default content type for subscriptions. A user agent receive session-independent policies, it includes the MIME type
subscribing to session-independent policies SHOULD include the MIME "application/session-policy+xml" in addition to the MIME type of the
type for the Schema for SIP User Agent Profile Data Sets [9] and the Schema for SIP User Agent Profile Data Sets in the Accept header of a
"application/session-policy+xml" format [3] in the Accept header of a SUBSCRIBE request.
SUBSCRIBE request. The Schema for SIP User Agent Profile Data Sets
is an abstract format for configuration data that is extended by the
"application/session-policy+xml" format for media-related policies.
These are the default formats for subscriptions to session-
independent policies and MUST be supported by a user agent compliant
to this specification.
A policy server MAY send a notification to the subscriber every time A policy server MAY send a notification to the subscriber every time
the session-independent policy covered by the subscription changes. the session-independent policies covered by the subscription changes.
The definition of what causes a policy to change is at the discretion The definition of what causes a policy to change is at the discretion
of the administrator. A change in the policy may be triggered, for of the administrator. A change in the policy may be triggered, for
example, by a change in the network status or simply by an update of example, by a change in the network status, by the change in the time
the service level agreement with the customer. The session- of day or by an update of the service level agreement with the
independent policy contained in notification MUST represent a customer. The session-independent policies contained in a
complete session-independent policy. Deltas to previous policies or notification MUST represent a complete session-independent policy.
partial policies are not supported. Deltas to previous policies or partial policies are not supported.
4. Session-Specific Policies 4. Session-Specific Policies
This section defines a model, an architecture and the protocol Session-specific policies are policies that are created specifically
components for session-specific policies. 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 may change during the course of the
session. For example, a user may run out of credit during a session,
which will cause the network to disallow the transmission all media
streams from this point on.
4.1. Architecture 4.1. Architecture
+-------------+ domain 1
/------| Proxy |----... +-----------+
+----+ / +-------------+ /------| proxy |----...
| |---/ +-------------+ +----+ / +-----------+
| | | Policy | | |---/ +-----------+
| UA |============| Server | | | | policy |
| | +-------------+ | UA |============| server |
| |**** +-------------+ | | +-----------+
+----+ * | Router w/ | | |**** +-----------+
*******| Policy |****... +----+ * | policy |
| Enforcement | *******|enforcement|****...
+-------------+ +-----------+
--- SIP Signaling --- SIP Signaling
=== Policy Channel === Policy Channel
*** Media *** Media
Figure 1 Figure 2
The following entities are involved in setting up session-specific The following entities are needed for session-specific policies (see
policies (see Figure 1): a user agent (UA), a proxy, a policy server Figure 2): a user agent (UA), a proxy, a policy server and possibly a
and possibly a router with policy enforcement functionality. policy enforcement entity.
The role of the proxy is to provide a rendezvous mechanism for UA and The role of the proxy is to provide a rendezvous mechanism for UAs
policy server. It conveys the URI of the policy server in its domain and policy servers. It conveys the URI of the policy server in its
to UAs and ensures that each UA knows where to retrieve policies domain to UAs and ensures that each UA knows where to retrieve
from. It does not deliver the actual policies to UAs. policies from. It does not deliver the actual policies to UAs.
The policy server is a separate logical entity that may be physically The policy server is a separate logical entity that may be physically
co-located with the proxy. The role of the policy server is to co-located with the proxy. The role of the policy server is to
deliver session policies to UAs. The policy server receives session deliver session policies to UAs. The policy server receives session
information, uses this information to determine the policies that information, uses this information to determine the policies that
apply to the session and returns the corresponding session policy to apply to the session and returns these policies to the UA. The
the UA. The mechanism for generating policies (i.e. making policy mechanism for generating policies (i.e. making policy decisions) is
decisions) is outside the scope of this specification. A policy outside the scope of this specification. A policy server may, for
server may, for example, query an external entity to get the policies example, query an external entity to get the policies that apply to a
that apply to a session or it may directly incorporate a policy session or it may directly incorporate a policy decision point and
decision point and generate policies locally. generate policies locally.
A UA receives the URI of a policy server from the proxy. It uses A UA receives the URI of a policy server from a proxy. It uses this
this URI to establish a policy channel to the policy server. It URI to connect to the policy server. It provides information about
provides information about the current session to the policy server the current session to the policy server and receives session
and receives session policies in response. The UA may also receive policies in response. The UA may also receive policy updates from
policy updates from the policy server during the course of a session. the policy server during the course of a session.
A network may have a policy enforcement infrastructure in place. A network may have a policy enforcement infrastructure in place.
However, this specification does not make any assumptions about the However, this specification does not make any assumptions about the
enforcement of session policies and the mechanisms defined here are enforcement of session policies and the mechanisms defined here are
orthogonal a policy enforcement infrastructure. Their goal is to orthogonal a policy enforcement infrastructure. Their goal is to
provide a mechanism to convey session information to a policy server provide a mechanism to convey session information to a policy server
and to return the policies that apply to a session to the UA. and to return the policies that apply to a session to the UA.
4.2. Overall Operation In principle, each domain that is traversed by SIP signaling messages
can define session-specific policies for a session. Each of these
domains 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 The protocol defined in this specification clearly separates SIP
signaling and the exchange of policy information. SIP signaling is signaling and the exchange of policies. SIP signaling is only used
only used to rendezvous the UA with the policy server. From this to rendezvous the UA with the policy server. From this point on, UA
point on, UA and policy server communicate directly with each other and policy server communicate directly with each other over a
over a separate policy channel. This is opposed to a piggyback separate policy channel. This is opposed to a piggyback model, where
model, where the exchange of policy information between endpoint and the exchange of policy information between endpoint and a policy
a policy server in the network is piggybacked onto the SIP signaling server in the network is piggybacked onto the SIP signaling messages
messages that are exchanged between endpoints. that are exchanged between endpoints.
The main advantage of using a separate policy channel is that it The main advantage of using a separate policy channel is that it
decouples the exchange of signaling messages between endpoints from decouples the exchange of signaling messages between endpoints from
the exchange of policy information between endpoint and a policy the exchange of policies between endpoint and policy server. This
server. This decoupling provides a number of desirable properties. decoupling provides a number of desirable properties. It enables the
It enables the use of separate encryption mechanisms on the signaling use of separate encryption mechanisms on the signaling path (to
path (to secure the communication between endpoints) and on the secure the communication between endpoints) and on the policy channel
policy channel (to secure the communication between endpoint and (to secure the communication between endpoint and policy server).
policy server). Policies can be submitted directly from the policy Policies can be submitted directly from the policy server to the
server to the endpoint and never travel along the signaling path, endpoint and never travel along the signaling path, possibly crossing
possibly crossing many domains. Endpoints set up a separate policy many domains. Endpoints set up a separate policy channel to each
channel to each policy server and can specifically decide which policy server and can specifically decide which information they want
information they want to disclose to which policy server. Finally, to disclose to which policy server. Finally, policy servers do not
policy servers do not need to rely on a SIP signaling message flowing need to rely on a SIP signaling message flowing by to send policies
by to send policies or policy updates to the endpoint. A policy or policy updates to an endpoint. A policy server can use the policy
server can use the policy channel at any time to update session channel at any time to update session policies as needed. A
policies as needed. A disadvantage of the separate channel model is disadvantage of the separate channel model is that it requires
that it requires additional messages for the exchange of policy additional messages for the exchange of policy information.
information.
Following this model, the signaling for session-specific policies Following this model, signaling for session-specific policies
involves the following two fundamental tasks: involves the following two fundamental tasks:
1. UA/policy server rendezvous: a UA setting up a session needs to 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 be able to discover the policy servers that are relevant to this
session. In principle, each domain that is traversed by the session.
signaling messages of a session can have session policies in
place and therefore run a policy server. However, session-
specific policies are usually only provided by the local domain
of the user agent.
2. Policy channel: once the UA has discovered the relevant policy 2. Policy channel: once the UA has discovered the relevant policy
servers for a session, it needs to retrieve the policies that servers for a session, it needs to connect to these servers,
apply to the current session from these servers. disclose session information and retrieve the policies that apply
to this session.
The exchange of policy information on the policy channel follows the The setting up session-specific policies over the policy channel
model described below: involves the following steps:
1. A user agent submits a session description to the policy server 1. A user agent submits information about the session it is trying
and asks whether a session using this session description is to establish to the policy server and asks whether a session
permissible. using these parameters is permissible.
2. The policy server generates a policy decision for this session 2. The policy server generates a policy decision for this session
and returns the decision to the user agent. Possible policy and returns the decision to the user agent. Possible policy
decisions are to (1) deny the session, (2) propose changes to the decisions are (1) to deny the session, (2) to propose changes to
session description with which the session is acceptable, or (3) the session parameters with which the session would be
accept the session as it was proposed. acceptable, or (3) to accept the session as it was proposed.
3. The policy server possibly updates the policy decision at a later 3. The policy server can update the policy decision at a later time.
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).
The protocol mechanisms for UA/policy server rendezvous and the In many cases, the mechanism for session-specific policies will be
mechanism used on the policy channel are discussed in the following used to disclose session information and return session policies.
sections. However, some scenarios may 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 4.3. Examples
This section provides two examples to illustrate the overall This section provides two examples to illustrate the overall
operation of session-specific policies. The call flows depict the operation of session-specific policies. The call flows depict the
rendezvous mechanism between UA and policy server in detail and rendezvous mechanism between UA and policy server and indicate the
indicate the points at which the UA exchanges policy information with points at which the UA exchanges policy information with the policy
the policy server. server.
The example is based on the following scenario: there are two domains The example is based on the following scenario: there are two domains
(domain A and domain B), which both have session-specific policies (domain A and domain B), which both have session-specific policies
for the UAs in their domain. Both domains do not provide policies to 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 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 and P B) and a policy server (PS A and PS B). The policies in both
domains involve the session description offer and answer. domains involve the session description offer and answer.
4.3.1. Offer in Request 4.3.1. Offer in Request
The first call flow depicts an INVITE transaction with the offer in The first call flow depicts an INVITE transaction with the offer in
the request. It is assumed that the UAC does not have previous the request. It is assumed that this is the first INVITE request the
knowledge about the policy server in its domain. 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 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply
to this session and (2) returns a 488 to UA A. P A includes the URI to this session and (2) returns a 488 to UA A. P A includes the URI
of PS A in the 488 response. (3) UA A contacts PS A, discloses the of PS A in the 488 response. This step is needed since the UAC has
session description offer to PS A and (4) receives policies for the no prior knowledge about the URI of PS A. (3) UA A uses the URI to
offer. (5) UA A reformulates the INVITE request under consideration contact PS A, discloses the session description offer to PS A and (4)
of the received policies and includes a Policy-Id header to indicate receives policies for the offer. (5) UA A reformulates the INVITE
that it has already contacted PS A. P A does not reject the INVITE request under consideration of the received policies and includes a
this time and removes the Policy-Id header when forwarding the Policy-Id header to indicate that it has already contacted PS A. P A
INVITE. P B adds a Policy-Contact header containing the URI of PS B. does not reject the INVITE this time and removes the Policy-Id header
(6) UA B uses this URI to contact PS B and discloses the offer and when forwarding the INVITE. P B adds a Policy-Contact header
the answer it is about to send. (7) UA B receives policies from PS B containing the URI of PS B. (6) UA B uses this URI to contact PS B
and applies them to the offer and answer respectively. (8) UA B and discloses the offer and the answer it is about to send. (7) UA B
returns the updated answer in the 200 OK. (9) UA A contacts PS A with receives policies from PS B and applies them to the offer and answer
the answer and (10) retrieves answer policies from PS A. 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.
UA A P A P B UA B UA A P A P B UA B
| | | | | | | |
| INVITE offer | | | | INVITE offer | | |
|---------------->| | | (1) |---------------->| | | (1)
| 488 | | | | 488 | | |
| + Policy-Contact| | | | + Policy-Contact| | |
|<----------------| | | (2) |<----------------| | | (2)
| ACK | | | | ACK | | |
|---------------->| | | |---------------->| | |
skipping to change at page 12, line 10 skipping to change at page 12, line 10
| PolicyChannel | | | | PolicyChannel | | |
| + PolicyAnswer | | | | + PolicyAnswer | | |
|<-------------------| | | (10) |<-------------------| | | (10)
| | | | | | | |
4.3.2. Offer in Response 4.3.2. Offer in Response
This call flow depicts an INVITE transaction with the offer in the This call flow depicts an INVITE transaction with the offer in the
response. response.
Steps (1) - (8) are analogous to steps (1) - (8) in the above flow. Steps (1) - (8) are analogous to steps (1) - (8) in the previous
An important difference is that in steps (9) and (10) UA A contacts flow. An important difference is that in steps (9) and (10) UA A
PS A after receiving the offer in the 200 OK but before returning the contacts PS A after receiving the offer in the 200 OK but before
answer in step (11). This enables UA A to return the final answer, returning the answer in step (11). This enables UA A to return the
which includes all applicable policies, in the ACK. However, it final answer, which includes all applicable policies, in the ACK.
requires that PS A immediately returns a policy to avoid a delay in However, it requires that PS A immediately returns a policy to avoid
the transmission of the ACK. This is similar to Flow I in [10]. a delay in the transmission of the ACK. This is similar to Flow I in
[9].
UA A P A P B UA B UA A P A P B UA B
| | | | | | | |
| INVITE | | | | INVITE | | |
|---------------->| | | (1) |---------------->| | | (1)
| 488 | | | | 488 | | |
| + Policy-Contact| | | | + Policy-Contact| | |
|<----------------| | | (2) |<----------------| | | (2)
| ACK | | | | ACK | | |
|---------------->| | | |---------------->| | |
skipping to change at page 13, line 38 skipping to change at page 13, line 39
rendezvous the UAs with the relevant policy servers. This is rendezvous the UAs with the relevant policy servers. This is
achieved by providing the URIs of all policy servers relevant for a achieved by providing the URIs of all policy servers relevant for a
session to the UAs. session to the UAs.
4.4.1. UAC Behavior 4.4.1. UAC Behavior
When a UA compliant to this specification generates an INVITE or When a UA compliant to this specification generates an INVITE or
UPDATE request, it MUST include a Supported header field with the UPDATE request, it MUST include a Supported header field with the
option tag "policy" in the request. option tag "policy" in the request.
A UAC may receive a 488 in response to an INVITE or UPDATE request, The UAC may receive a 488 in response to an INVITE or UPDATE request,
which contains a Policy-Contact header field. This is a new header which contains a Policy-Contact header field. This is a new header
defined in this specification that contains the URI of a policy defined in this specification that contains the URI of a policy
server. A 488 response with this header is generated by a proxy to server. A 488 response with this header is generated by a proxy to
convey the URI of the local policy server to the UAC. The UAC SHOULD convey the URI of the local policy server to the UAC. The UAC SHOULD
use this URI to contact the policy server and ask for policies for use this URI to contact the policy server using mechanism defined in
current session. The UAC SHOULD apply the policies received and Section 4.5. The UAC SHOULD apply the policies received and resend
resend the updated request. the updated request.
The UAC MUST insert a Policy-Id header into the updated request. The The UAC MUST insert a Policy-Id header into a request if it has
Policy-Id header MUST include the URIs of all policy servers the UAC contacted a policy server for this request. The Policy-Id header
has contacted during the processing of the request. The Policy-Id MUST include the URIs of all policy servers the UAC has contacted for
header enables a proxy to determine whether the URI of its policy the request. The Policy-Id header enables a proxy to determine
server is already known to the UAC (and thus the request can be whether the URI of its policy server is already known to the UAC (and
passed through) or whether the URI still needs to be conveyed to the thus the request can be passed through) or whether the URI still
UAC in a 488 response. needs to be conveyed to the UAC in a 488 response.
In some cases, a request may traverse multiple domains with session- In some cases, a request may traverse multiple domains with session-
policies in place. Each of these domains may return a 488 response policies in place. Each of these domains may return a 488 response
containing a policy server URI. Since the UAC contacts the policy containing a policy server URI. Since the UAC contacts a policy
server URI received in a 488 response before it resends the request, server after receiving a 488 response from a domain and before re-
session policies are always applied to a session in the order in sending the request, session policies are always applied to a request
which the request traverses through these domains. The UAC SHOULD in the order in which the request traverses through the domains. The
NOT change this implicit order among policy servers. UAC SHOULD NOT change this implicit order among policy servers.
Session policies may apply to the offer, the answer or both session Some types of session policies only apply to the offer whereas other
descriptions. Depending on the type of session policies, a UAC may policies apply to the offer as well as the answer. A UA SHOULD
need to submit the offer and/or the answer to the policy server. generally disclose the offer and the answer to the policy server.
However, the policy server may indicate on the policy channel (after
receiving the offer) that the disclosure of the answer is not needed
for this session. In this case, the UAC MAY skip the disclosure of
the answer for this particular session.
If the UAC receives an answer in the response to an INVITE request Depending on whether or not the UAC has included an offer in the
(i.e. the request contained the offer), it MUST send the ACK before INVITE request it has sent to the UAS, it will receive an answer or
retrieving the policies for the answer from the policy server. If an offer in the response from the UAS. If the response contains an
the UAC receives a response with an offer (i.e. the INVITE request answer (i.e. the request contained an offer), it MUST send the ACK
did not contain an offer), the UAC MUST first contact the policy before contacting the policy server with the answer. The UAC MUST
server to retrieve session policies and apply these policies before contact the same policy servers it has contacted for the offer. If
sending the answer in the ACK. The answer in the ACK will therefore the response contains an offer (i.e. the INVITE request was empty),
already consider the relevant policies. the UAC MUST first contact the policy server to retrieve session
policies and apply these policies before sending the answer in the
ACK. The answer in the ACK will therefore already consider the
relevant policies.
This approach assumes that the policy server immediately responds This approach assumes that the policy server immediately responds
to a policy request and does not require manual intervention to to a policy request and does not require manual intervention to
create a policy. A delay in the response from the policy server create a policy. A delay in the response from the policy server
would delay the transmission of the ACK and could trigger would delay the transmission of the ACK and could trigger
retransmissions of the INVITE response (also see the retransmissions of the INVITE response (also see the
recommendations for Flow I in [10]). recommendations for Flow I in [9]).
4.4.2. Caching of Policy Server URIs 4.4.2. Caching of Policy Server URIs
A UAC SHOULD cache the URI of the policy server in the local domain. A UAC may frequently need to contact the policy server in the local
It may receive this URI in a 488 from the local proxy after sending domain. To avoid the retransmission of the local policy server URI
an INVITE message. The UA may also receive an initial local policy for each INVITE or UPDATE request, the UAC SHOULD cache the URI of
server URI through configuration or other means. This way, it can be the local policy server. The UAC may receive this URI in a 488 from
avoided that the local proxy needs to reject the first INVITE in the local proxy after sending an INVITE or UPDATE message.
order to initialize the UAs policy server URI cache. A policy server Alternatively, the UA may also have received the local policy server
URI received through configuration can, of course, be overwritten by URI through configuration or other means. If the UAC has received a
a policy server URI in a 488 response. local policy server URI through configuration and receives another
one in a 488 response, it SHOULD overwrite the configured URI with
the one received in the 488 response. The UAC SHOULD contact the
cached local policy server URI when creating a new INVITE or UPDATE
request, before they are sent.
The UAC SHOULD use the cached policy server URI to retrieve session Domains can prevent the UAC from caching the local policy server URI.
policies for a new INVITE or UPDATE request before it is sent. This is useful, for example, if the policy server does not need to be
Caching the local policy server URI avoids the retransmission of this involved in all sessions or the policy server URI changes from
URI for each new INVITE or UPDATE request. Domains can prevent the session to session. A proxy can mark the URI of such a local policy
UAC from caching the local policy server URI. This is useful, for server as "non-cacheable". The UA SHOULD NOT cache a non-cacheable
example, if the policy server does not need to be involved in all policy server URI. It SHOULD remove the current URI from the cache
sessions or the policy server URI changes from session to session. A when receiving a "non-cacheable" URI.
proxy can mark the URI of such a policy server as "non-cacheable".
The UA SHOULD NOT cache a non-cacheable policy server URI. It SHOULD
remove the current URI from the cache when receiving a "non-
cacheable" URI.
The UAC SHOULD NOT cache policy server URIs it has received from The UAC SHOULD NOT cache policy server URIs it has received from
proxies outside of the local domain. These policy servers may not be proxies outside of the local domain. These policy servers may not be
relevant for subsequent sessions, which may go to a different relevant for subsequent sessions, which may go to a different
destination, traversing different domains. destination, traversing different domains.
The UAC SHOULD store the list of policy server URIs is has contacted The UAC SHOULD store the list of policy server URIs is has contacted
for a session. The UAC should keep this list until the session is for a session as part of the session state. The UAC should keep this
terminated. The UAC SHOULD contact the policy server URIs in this list until the session is terminated. The UAC SHOULD contact the
list for each mid-dialog INVITE or UPDATE request. This avoids the policy server URIs in this list for mid-dialog INVITE or UPDATE
retransmission of policy server URIs for each mid-dialog requests. request. Caching these URIs avoids the retransmission of policy
server URIs for each mid-dialog requests.
4.4.3. UAS Behavior 4.4.3. UAS Behavior
An incoming INVITE or UPDATE request may contain a Policy-Contact An incoming INVITE or UPDATE request may contain a Policy-Contact
header with a list of policy server URIs. The UAS SHOULD use these header with a list of policy server URIs. The UAS SHOULD contact all
URIs to ask for session policies. The UAS MUST use the policy server policy server URIs in a Policy-Contact header. The UAS MUST contact
URIs in the order in which they were contained in the Policy-Contact the policy server URIs in the order in which they were contained in
header, starting with the topmost value. the Policy-Contact header, starting with the topmost value.
If the UAS receives an ACK with an answer, it may need to contact the If the UAS receives an ACK containing an answer, it SHOULD contact
policy servers again depending on the policy type. In this case, it the policy servers again with the answer. In this case, it MUST
MUST contact the same policy servers it has contacted for the offer. contact the same policy servers it has contacted for the offer.
However, the policy server may have indicated in response to the
offer that the disclosure of the answer is not needed for this
session. In this case, the UAS MAY skip the disclosure of the answer
for this particular session.
4.4.4. Proxy Behavior 4.4.4. Proxy Behavior
A proxy may provide the URI of the local policy server to the UAC or A proxy provides rendezvous functionality for UAs and the local
the UAS when processing an INVITE or UPDATE request. policy server. This is achieved by conveying the URI of the local
policy server to the UAC or the UAS (or both) when processing an
INVITE or UPDATE request.
If an INVITE or UPDATE request contains a Supported header field with If an INVITE or UPDATE request contains a Supported header field with
the option tag "policy", the proxy MAY reject the request with a 488 the option tag "policy", the proxy MAY reject the request with a 488
response to provide the local policy server URI to the UAC. Before response to provide the local policy server URI to the UAC. Before
rejecting a request, the proxy MUST check whether the request has a rejecting a request, the proxy MUST verify that the request does not
Policy-Id header field that already contains this policy server URI. have a Policy-Id header field, which already contains the local
If the request does not have such a header or the local policy server policy server URI. If the request does not have such a header or the
URI is not present in that header, then the proxy MAY reject the local policy server URI is not present in this header, then the proxy
request with a 488. The proxy MUST insert a Policy-Contact header in MAY reject the request with a 488. The proxy MUST insert a Policy-
the 488 response that contains the URI of the local policy server. Contact header in the 488 response that contains the URI of the local
The proxy MAY add the header field parameter "non-cacheable" to policy server. The proxy MAY add the header field parameter "non-
prevent the UAC from caching this policy server URI. cacheable" to prevent the UAC from caching this policy server URI.
If the local policy server URI is already present in the Policy-Id If the local policy server URI is already present in the Policy-Id
header of an INVITE or UPDATE request, the proxy MUST NOT reject the header of an INVITE or UPDATE request, the proxy MUST NOT reject the
request as described above. The proxy SHOULD remove this policy request as described above. The proxy SHOULD remove this policy
server URI from the Policy-Id header field before forwarding the server URI from the Policy-Id header field before forwarding the
request. request.
The proxy MAY insert a Policy-Contact header field into an INVITE or The proxy MAY insert a Policy-Contact header field into an INVITE or
UPDATE request in order to convey the policy server URI to the UAS. UPDATE request in order to convey the policy server URI to the UAS.
If the request already contains a Policy-Contact header field, the If the request already contains a Policy-Contact header field, the
proxy MUST insert the URI before all existing values at the beginning proxy MUST insert the URI ahead of all existing values at the
of the list. A proxy MUST NOT change the order of existing Policy- beginning of the list. A proxy MUST NOT change the order of existing
Contact header values. Policy-Contact header values.
4.4.5. Header Definition and Syntax 4.4.5. Header Definition and Syntax
The Policy-Id header field is inserted into an INVITE or UPDATE The Policy-Id header field is inserted into an INVITE or UPDATE
request by the UAC. It identifies all policy servers the UAC has request by the UAC. It identifies all policy servers the UAC has
contacted for the request. A Policy-Id header value is the URI of a contacted for this request. A Policy-Id header value is the URI of a
policy server. policy server.
The syntax of the Policy-Id header field is: The syntax of the Policy-Id header field is:
Policy-Id = "Policy-Id" HCOLON absoluteURI Policy-Id = "Policy-Id" HCOLON absoluteURI
*(COMMA absoluteURI) *(COMMA absoluteURI)
The Policy-Contact header field can be inserted into INVITE and The Policy-Contact header field can be inserted into a 488 response
to an INVITE or UPDATE request by a proxy. It contains a policy
server URI that needs to be contacted by the UAC. A proxy MAY add
the "non-cacheable" header field parameter to indicate that the UAC
should not cache the policy server URI.
The Policy-Contact header field can also be inserted into INVITE and
UPDATE requests by a proxy. It contains an ordered list of policy UPDATE requests by a proxy. It contains an ordered list of policy
server URIs that need to be contacted by the UAS. The UAS starts to server URIs that need to be contacted by the UAS. The UAS starts to
process the header field at the topmost value of this list. New process the header field at the topmost value of this list. New
header field values are inserted at the top. The Policy-Contact header field values are inserted at the top. The Policy-Contact
header field effectively forms a stack. The "non-cacheable" header header field effectively forms a stack. The "non-cacheable" header
field parameter MUST NOT be used in a request. field parameter MUST NOT be used in a request.
The Policy-Contact header field can also be inserted into a 488
response to an INVITE or UPDATE request by a proxy. It contains a
policy server URI that needs to be contacted by the UAC. A proxy MAY
add the "non-cacheable" header field parameter to indicate that the
UAC should not cache the policy server URI.
The syntax of the Policy-Contact header field is: The syntax of the Policy-Contact header field is:
Policy-Contact = "Policy-Contact" HCOLON policyURI Policy-Contact = "Policy-Contact" HCOLON policyURI
*(COMMA policyURI) *(COMMA policyURI)
policyURI = absoluteURI [ SEMI "non-cacheable" ] policyURI = absoluteURI [ SEMI "non-cacheable" ]
The BNF for absoluteURI is defined in [6]. The BNF for absoluteURI is defined in [6].
Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD'
is for the UPDATE method [5]. is for the UPDATE method [5].
Header field where proxy ACK BYE CAN INV OPT REG UPD Header field where proxy ACK BYE CAN INV OPT REG UPD
_______________________________________________________________ _______________________________________________________________
Policy-Id R rd - - - o - - o Policy-Id R rd - - - o - - o
Policy-Contact R a - - - o - - o Policy-Contact R a - - - o - - o
Policy-Contact 488 a - - - o - - o Policy-Contact 488 a - - - o - - o
Table 1: Policy-Id and Policy-Contact Header Fields Table 1: Policy-Id and Policy-Contact Header Fields
4.5. Policy Channel 4.5. Policy Subscription
The main task of the policy channel is to enable the transmission of The rendezvous mechanism described in the previous section enables
session descriptions (i.e. the offer and the answer) of a session to proxies to deliver the URIs of policy servers to the UAC and UAS.
the policy server and to transmit the resulting session policies back This section describes the mechanism for the policy channel, i.e. the
to the UA. protocol UAs use to contact the policy servers. 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 uses the "session-spec-policy" event package [2] to subscribe to A UA compliant to this specification MUST implement the Event Package
session-specific policies on a policy server. The UA receives the for Session-Specific Session Policies [2]. It contacts a policy
policies that apply to a session through this subscription. The server by subscribing to this event package.
policy server returns the initial policies for a session when the
When subscribing to session-specific policies, the UA discloses
information about the session it is trying to establish to the policy
server as described in [2]. This information is used by the policy
server to determine the session-specific policy for this session.
The policy server returns the policies that apply to this session in
NOTIFY messages. It returns an initial set of policies when the
subscription is established and may notify the UA when there are subscription is established and may notify the UA when there are
updates to these policies. updates to these policies. Complete call flow examples for session-
specific policies that include policy channel messages can be found
in Appendix B.
A UA SHOULD use the policies it has received from the policy server
in the current session (i.e. the session the subscription is for).
When a UA receives a policy update, it SHOULD apply the update to the When a UA receives a policy update, it SHOULD apply the update to the
current session. Typically, this will require the UA to generate a current session. If this update causes a change in the session
re-INVITE or UPDATE message and re-negotiate the session description. description of a session, the UA may need to generate a re-INVITE or
For example, if a policy update disallows the use of video and video UPDATE message to re-negotiate the modified session description with
is part of the current session description, then the UA will need to its peer UA. For example, if a policy update disallows the use of
create an new session description offer without video. After video and video is part of the current session description, then the
receiving this offer, the peer UA knows that video can't be used any UA will need to create an new session description offer without
more and responds with the corresponding answer. video. After receiving this offer, the peer UA knows that video
can't be used any more and responds with the corresponding answer.
Before a policy server can generate a session-specific policy, it 5. Security Considerations
needs to receive the session descriptions of a session.
The session-spec-policy event package enables a UA to include the Session policies can significantly change the behavior of a user
session descriptions in the body of the SUBSCRIBE request (see [2]). agent and can therefore be used by an attacker to compromise a user
These session descriptions are used by the policy server to generate agent. For example, session policies can be used to set up a user
the session policies the UA is subscribing to. The policy server agent so that it is unable to successfully establish a session (e.g.
returns these policies in NOTIFY messages. Detailed call flows can by setting the available bandwidth to zero). Such a policy can be
be found in Appendix B. submitted to the user agent during a session, which will cause the UA
to terminate the session.
An alternative approach is using the SUBSCRIBE and PUBLISH methods. A user agent transmits session information to a policy server for
session-specific policies. This session information may contain
sensitive data the user may not want an eavesdropper or an
unauthorized policy server to see. In particular, 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.
A UA inserts the session descriptions into the body of a PUBLISH User agents should therefore authenticate a policy server before
request and sends it to the policy server. After publishing the accepting a session policy. Policy servers should authenticate user
session descriptions, the UA uses the session-spec-policy event agents before sending a session policy. This document does not
package to subscribe to the resulting session policies. define the protocols between user agents and policy servers and
merely refers to other specifications. The security considerations
of these specifications apply and provide the mechanisms needed to
secure these protocols.
The PUBLISH requests use a new event package for session descriptions Administrators should use SIPS URIs as policy server URIs, if
[needs to be defined]. The published session descriptions establish possible, so that subscriptions to session policies are transmitted
a state on the policy server. The policy server uses this state as over TLS.
input to generate session policies for the described session. These
policies form a separate state on the policy server, to which the UA
can subscribe to using the session-spec-policy event package. This
effectively decouples the transmission of session descriptions (via
PUBLISH requests) from the transmission of session policies (through
the subscription). PUBLISH and SUBSCRIBE requests for the same
session use identical Request-URIs and event parameters so that a
policy server can correlate both. Detailed call flows can be found
in Appendix B.
OPEN ISSUE: Need to select one approach for conveying session This document defines a new mechanism that enables proxies to
descriptions to the policy server!! The following provides an rendezvous UAs and policy servers. An attacker can use this
short analysis of both approaches. Call flows can be found in mechanism to refer a UA to compromised policy server. The UA can
Appendix B. prevent such an attack from being effective by authenticating policy
PUBLISH and SUBSCRIBE: servers.
* Session descriptions can in some cases be submitted to the
policy server by an entity that is different from the entity
that subscribes to session policies (e.g. by a proxy).
However, the separation of session description sender and
policy receiver may lead to deadlocks in some scenarios. This
may occur if the subscriber to session policies (e.g. the UA)
is waiting for a policy but the entity responsible for
submitting session descriptions (e.g. the proxy) can't submit
the necessary session descriptions because it has not yet
received them.
* PUBLISH and SUBSCRIBE both establish their own soft states in
the policy server. Thus, there are two states that need to be
maintained by the policy server and both need to be refreshed
individually.
* This approach requires the implementation of two event packages
by UA and policy server.
SUBSCRIBE:
* Using SUBSCRIBE simplifies the message flow between UA and
policy server. In a simple session (offer in INVITE, no state
refreshes) there are four messages less to be transmitted.
* No need to establish, maintain and refresh two different states
on the policy server. This simplifies UA and policy server
implementation.
* Session descriptions are directly coupled to a subscription to
policies. There is no need to correlate two states on the
policy server. Also, no need to cover cases in which session
descriptions are published without a policy subscription and
vice versa.
* Only one event package needs to be implemented by UA and the
policy server.
* SUBSCRIBE bodies usually have the semantic of a filter An attacker could intercept SIP messages between the UA and proxy and
criteria. I.e. they are used to select the resource the remove the policy headers needed for session-specific policies. This
subscription is for out of a set of existing objects. Here, would impede the rendezvous between UA and policy server and, since
SUBSCRIBE bodies are used to as input to generate the resource the UA would not contact the policy server, may prevent a UA from
the subscription is for. This is a change in the use of setting up a session. This attack can be prevented by using a
SUBSCRIBE bodies. secured transport protocol such as TLS between proxies and UA.
5. Security Considerations 6. IANA Considerations
In particular authentication and authorization are critical issues 6.1. Registration of the "Policy-Id" Header
that need to be addressed here.
[TBD.] Name of Header: Policy-Id
6. IANA Considerations Short form: none
[TBD.] 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
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
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Allison Mankin for the discussions and the suggestions Many thanks to Allison Mankin for the discussions and the suggestions
for this draft. Many thanks also to everyone who contributed by for this draft. Many thanks to everyone who contributed by providing
providing feedback on the mailing list and in IETF meetings. feedback on the mailing list and in IETF meetings.
Appendix B. Call Flows
Appendix B. Session-Specific Policies - Call Flows
The following call flows illustrate the overall operation of session- The following call flows illustrate the overall operation of session-
specific policies using PUBLISH/SUBSCRIBE and SUBSCRIBE only. The specific policies. The call flows contain all messages needed for
call flows contain all messages needed for UA/policy server UA/policy server rendezvous and the policy subscription.
rendezvous and for the policy channel. The following abbreviations
are used: The following abbreviations are used:
o: offer o: offer
o': offer modified by a policy o': offer modified by a policy
po: offer policy po: offer policy
a: answer a: answer
a': answer modified by a policy a': answer modified by a policy
pa: answer policy pa: answer policy
ps uri: policy server URI (in Policy-Contact header) ps uri: policy server URI (in Policy-Contact header)
ps id: policy server id (in Policy-Id header) ps id: policy server id (in Policy-Id header)
B.1. PUBLISH/SUBSCRIBE - Offer in Invite B.1. Offer in Invite
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) PUBLISH <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) SUBSCRIBE | | | |
|------------------>| | | |
|(7) 200 OK | | | |
|<------------------| | | |
|(8) NOTIFY <po> | | | |
|<------------------| | | |
|(9) 200 OK | | | |
|------------------>| | | |
|(10) INV <ps id, o'> | | |
|-------->| | | | |
| |(11) INV <o'> | | |
| |---------------------------->| |
| | | | |(12) INV <o', ps uri>
| | | | |-------->|
| | | |(13) PUBLISH <o', a>
| | | |<------------------|
| | | |(14) 200 OK |
| | | |------------------>|
| | | |(15) SUBSCRIBE |
| | | |<------------------|
| | | |(16) 200 OK |
| | | |------------------>|
| | | |(17) NOTIFY <po, pa>
| | | |------------------>|
| | | |(18) 200 OK |
| | | |<------------------|
| | | | |(19) 200 OK <a'>
| | | | |<--------|
| |(20) 200 OK <a'> | | |
| |<----------------------------| |
|(21) 200 OK <a'> | | | |
|<--------| | | | |
|(22) ACK | | | | |
|------------------------------------------------>|
|(23) PUBLISH <a'> | | | |
|------------------>| | | |
|(24) 200 OK | | | |
|<------------------| | | |
|(25) NOTIFY <pa> | | | |
|<------------------| | | |
|(26) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |
B.2. PUBLISH/SUBSCRIBE - 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) PUBLISH <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) SUBSCRIBE |
| | | |<------------------|
| | | |(14) 200 OK |
| | | |------------------>|
| | | |(15) NOTIFY <po> |
| | | |------------------>|
| | | |(16) 200 OK |
| | | |<------------------|
| | | | |(17) 200 OK <o'>
| | | | |<--------|
| |(18) 200 OK <o'> | | |
| |<----------------------------| |
|(19) 200 OK <o'> | | | |
|<--------| | | | |
|(20) PUBLISH <o', a> | | |
|------------------>| | | |
|(21) 200 OK | | | |
|<------------------| | | |
|(22) NOTIFY <po, pa> | | |
|<------------------| | | |
|(23) 200 OK | | | |
|------------------>| | | |
|(24) ACK <a'> | | | |
|------------------------------------------------>|
| | | |(25) PUBLISH <a'> |
| | | |<------------------|
| | | |(26) 200 OK |
| | | |------------------>|
| | | |(27) NOTIFY <po, pa>
| | | |------------------>|
| | | |(28) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
B.3. SUBSCRIBE - Offer in Invite
UA A P A PS A PS B P B UA B UA A P A PS A PS B P B UA B
| | | | | | | | | | | |
|(1) INV <o> | | | | |(1) INV <o> | | | |
|-------->| | | | | |-------->| | | | |
|(2) 488 <ps uri> | | | | |(2) 488 <ps uri> | | | |
|<--------| | | | | |<--------| | | | |
|(3) ACK | | | | | |(3) ACK | | | | |
|-------->| | | | | |-------->| | | | |
|(4) SUBSCRIBE <o> | | | | |(4) SUBSCRIBE <o> | | | |
|------------------>| | | | |------------------>| | | |
skipping to change at page 24, line 5 skipping to change at page 22, line 5
|------------------>| | | | |------------------>| | | |
|(20) 200 OK | | | | |(20) 200 OK | | | |
|<------------------| | | | |<------------------| | | |
|(21) NOTIFY <pa> | | | | |(21) NOTIFY <pa> | | | |
|<------------------| | | | |<------------------| | | |
|(22) 200 OK | | | | |(22) 200 OK | | | |
|------------------>| | | | |------------------>| | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
B.4. SUBSCRIBE - Offer in Response B.2. Offer in Response
UA A P A PS A PS B P B UA B UA A P A PS A PS B P B UA B
| | | | | | | | | | | |
|(1) INV | | | | | |(1) INV | | | | |
|-------->| | | | | |-------->| | | | |
|(2) 488 <ps uri> | | | | |(2) 488 <ps uri> | | | |
|<--------| | | | | |<--------| | | | |
|(3) ACK | | | | | |(3) ACK | | | | |
|-------->| | | | | |-------->| | | | |
|(4) SUBSCRIBE | | | | |(4) SUBSCRIBE | | | |
skipping to change at page 25, line 24 skipping to change at page 23, line 24
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP)
Event Package for Session-Specific Session Policies.", Event Package for Session-Specific Session Policies.",
draft-ietf-sipping-session-policy-package-00 (work in progress), draft-ietf-sipping-policy-package-01 (work in progress),
April 2006. April 2006.
[3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile
Data Set for Media Policy", Data Set for Media Policy",
draft-ietf-sipping-media-policy-dataset-01 (work in progress), draft-ietf-sipping-media-policy-dataset-01 (work in progress),
March 2006. March 2006.
[4] Petrie, D., "A Framework for Session Initiation Protocol User [4] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-08 Agent Profile Delivery", draft-ietf-sipping-config-framework-08
(work in progress), March 2006. (work in progress), March 2006.
skipping to change at page 25, line 48 skipping to change at page 23, line 48
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
7.2. Informative References 7.2. Informative References
[7] Handley, M. and V. Jacobson, "SDP: Session Description [7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[8] Hilt, V. and G. Camarillo, "Use Cases for Session-Specific [8] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and
Session Initiation Protocol (SIP) Session Policies",
draft-hilt-sipping-policy-usecases-00 (work in progress),
June 2005.
[9] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and
Guidelines for Defining Session Initiation Protocol User Agent Guidelines for Defining Session Initiation Protocol User Agent
Profile Data Sets", draft-petrie-sipping-profile-datasets-03 Profile Data Sets", draft-petrie-sipping-profile-datasets-03
(work in progress), October 2005. (work in progress), October 2005.
[10] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004. April 2004.
Authors' Addresses Authors' Addresses
Volker Hilt Volker Hilt
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
101 Crawfords Corner Rd 101 Crawfords Corner Rd
Holmdel, NJ 07733 Holmdel, NJ 07733
 End of changes. 93 change blocks. 
540 lines changed or deleted 467 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/