One document matched: draft-ietf-sip-session-policy-framework-04.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3725 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3725.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3264 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'>
<!ENTITY rfc4566 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY rfc3311 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml'>
<!ENTITY rfc2976 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2976.xml'>
<!ENTITY rfc3262 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3262.xml'>
<!ENTITY rfc3265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY rfc3428 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3428.xml'>
<!ENTITY rfc3515 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml'>
<!ENTITY rfc3903 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml'>
<!ENTITY rfc5234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY i-d.ietf-sipping-config-framework PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-config-framework.xml'>
<!ENTITY i-d.ietf-sipping-media-policy-dataset PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-media-policy-dataset.xml'>
<!ENTITY i-d.ietf-sipping-policy-package PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-policy-package.xml'>
]>
<rfc ipr='full3978' category='std' docName='draft-ietf-sip-session-policy-framework-04'>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<front>
<title abbrev='Session Policy Framework'>A Framework for Session
Initiation Protocol (SIP) Session Policies</title>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
<address>
<postal><street>791 Holmdel-Keyport Rd</street>
<city>Holmdel</city> <region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>
<email>volkerh@bell-labs.com</email>
</address>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author initials='J.R.' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization>Cisco</organization>
<address>
<postal>
<city>Edison</city><region>NJ</region>
<country>USA</country>
</postal>
<email>jdrosen@cisco.com</email>
</address>
</author>
<date month='August' year='2008' />
<area>Transport</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Session Policy</keyword>
<abstract>
<t>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 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Session Initiation Protocol (SIP) <xref target="RFC3261" />
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) <xref target="RFC4566"
/>. </t>
<t>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 could 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.</t>
<t>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. </t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t>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
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Session-Independent Policies">
<t>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, it is possible for session-independent
policies to 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. The policy server informs a UA when session-independent
policies change.</t>
<section title="Architecture and Overview">
<figure anchor='fig:architectureindep'>
<artwork><![CDATA[
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
]]></artwork>
</figure>
<t>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.</t>
<t>Setting up session-independent policies involves the
following steps:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>The policy server can update the policies, for example,
when network conditions change.</t>
</list></t>
</section>
<section title="Policy Subscription">
<section title="UAC Behavior">
<t>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.</t>
<t>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 <xref
target="I-D.ietf-sipping-config-framework">Framework for SIP
User Agent Profile Delivery</xref>. The UA MAY support other
methods of retrieving session-independent policies from local
network and SIP service provider domain.</t>
<t>The "ua-profile" event package <xref
target="I-D.ietf-sipping-config-framework" /> 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.</t>
<t>A UA (re-)subscribes to session-independent policies when the
following events occur:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>If a subscriber is unable to establish a subscription, the subscriber
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.</t>
<t>A UA compliant to this specification MUST support the User
Agent Profile Data Set for Media Policy <xref
target="I-D.ietf-sipping-media-policy-dataset" />. 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 field of a SUBSCRIBE request. </t>
<t>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.</t>
<t>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 <xref target="sec:specficpolicy"/>). Thus,
session-independent policies are always applied before session-specific
policies are retrieved.</t>
</section>
<section title="UAS Behavior">
<t>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.</t>
</section>
</section>
</section>
<section title="Session-Specific Policies" anchor='sec:specficpolicy'>
<t>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.</t>
<section title="Architecture">
<figure anchor='fig:architecture'>
<artwork><![CDATA[
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
--- SIP Signaling
=== Policy Channel
*** Media
]]></artwork>
</figure>
<t>The following entities are needed for session-specific
policies (see <xref target="fig:architecture" />): a user agent
(UA), a proxy, a policy server and possibly a policy enforcement
entity.</t>
<t>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 configuration). The proxy does not deliver the actual
policies to UAs.</t>
<t>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.</t>
<t>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 server during the course of a
session.</t>
<t>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 to a policy enforcement
infrastructure.</t>
<t>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 <xref target="fig:architecture" />). However, it is expected
that session-specific policies will often only be provided by
the local domain of the user agent.</t>
</section>
<section title="Overview">
<t>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.</t>
<t>The main advantage of using a separate policy channel is that
it decouples signaling between endpoints from the policy
exchange between an endpoint and a 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 do not 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.</t>
<t>Following this model, signaling for session-specific policies
involves the following two fundamental tasks:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
</list></t>
<t>The communication between UA and policy server on the policy
channel involves the following steps:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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).</t>
</list></t>
<t>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.</t>
</section>
<section title="Examples">
<t>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.</t>
<t>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 domains involve the session description offer and
answer.</t>
<section title="Offer in Request">
<t>The first call flow shown in <xref target="fig:flow1" /> 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. </t>
<t>(1) UA A sends an INVITE request to proxy P A. P A knows that
policies apply to this session and (2) returns a 488 (Not
Acceptable Here) response 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 field to indicate that it has
already contacted PS A. P A does not reject the INVITE request this time
and removes the Policy-Id header field when forwarding the
INVITE request. P B adds a Policy-Contact header field 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) response. (9) UA A contacts PS A with the answer and (10)
retrieves answer policies from PS A.</t>
<figure anchor='fig:flow1'>
<artwork><![CDATA[
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)
| | | |
]]></artwork>
</figure>
</section>
<section title="Offer in Response" anchor="sec:offerrespflow">
<t>The call flow shown in <xref target="fig:flow2" /> depicts an INVITE
transaction with the offer in the response.</t>
<t>(1) UA A sends an INVITE request 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
field to indicate that it has contacted PS A. P A does not
reject the INVITE request this time and removes the Policy-Id header
field when forwarding the INVITE request. P B adds a Policy-Contact
header field 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) response. (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 request,
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 request. (12),(13) UA B also sends the
answer to PS B and applies the policies it receives to the
answer before using it.</t>
<figure anchor='fig:flow2'>
<artwork><![CDATA[
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)
| | | |
| | 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)
| | | |
]]></artwork>
</figure>
</section>
</section>
<section title="UA/Policy Server Rendezvous" anchor='sec:distmech'>
<t>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.</t>
<section title="UAC Behavior" anchor='sec:uacbehavior'>
<t>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 <xref
target="RFC3264" /> (e.g., INVITE, UPDATE <xref target="RFC3311"
/> and PRACK <xref target="RFC3262"/> 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.</t>
<t>A UAC can receive a 488 (Not Acceptable Here) response that
contains a Policy-Contact header field. The Policy-Contact
header field is a new header field defined in this specification. It
contains the URI of a policy server. A 488 (Not Acceptable Here)
response with this header field 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 field, 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 <xref target="sec:polchannel"/>. 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. </t>
<t>The UAC MAY resend 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.</t>
<t>To protect the integrity of the policy server URI in a
Policy-Contact header field, the UAC SHOULD use a secured transport
protocol such as TLS between UAC and proxy.</t>
<t>The UAC MUST insert a Policy-Id header field into requests for
which it has contacted a policy server and accepted the policies
received. The Policy-Id header field is a new header field that is defined
in this specification. The UA MUST create a Policy-Id header field
value for each policy server it has contacted during the
preparation of the request. A Policy-Id header field 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 string the UAC
can receive from the policy server. A token can, for example, be
contained in the policy document <xref
target="I-D.ietf-sipping-media-policy-dataset" />. If the UAC
has received a token from the policy server the UAC MUST include
the token in the Policy-Id header field. The format of the Policy-Id
header field is defined in <xref target='sec:syntax'/>.</t>
<t>The main purpose of the Policy-Id header field is to enable a proxy
to determine if the UAC already knows the URI of the local
policy server. 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.</t>
<t>In some cases, a request can traverse multiple domains with a
session-policy server. 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.</t>
<t>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) response for each new request, a UA SHOULD maintain a
cache that contains the URI of the local policy server (see <xref
target='sec:uricache'/>). 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).</t>
<t>UAs can re-negotiate the session description during a
session by initiating a subsequent offer/answer exchange, e.g.,
in an INVITE, UPDATE or PRACK request. 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 <xref target='sec:polchannel' />)
before sending the request. This avoids the retransmission of
all policy server URIs in 488 (Not Acceptable Here) responses
for mid-dialog requests.</t>
</section>
<section title="Proxy Behavior">
<t>A proxy provides rendezvous functionalities for UAs and
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).</t>
<t>If an offer/answer exchange initiating 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 with the local policy
server URI as a value. If the request does not contain such a
header field or the local policy server URI is not present in this
header field, then the proxy MAY reject the request with a 488 (Not
Acceptable Here) response. The proxy MUST insert a Policy-Contact header field
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 <xref target='sec:uricache'/>).</t>
<t>If the local policy server URI is present in a Policy-Id
header field 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 field
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.</t>
<t>The Policy-Id header field 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 field 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.</t>
<t>Routing all requests that belong to the same session to the
same proxy can be achieved by using the Policy-Id header field 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 field
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 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.</t>
<t><list style="empty">
<t>Note: it has been proposed to use the Policy-Id header field 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 field, the proxy can determine if
the token in the Policy-Id header field 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 field.</t>
</list></t>
<t>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 after
all existing values at the end of the list. A proxy MUST NOT
change the order of existing Policy-Contact header field values.</t>
<t>A proxy MUST use the Record-Route mechanism <xref
target="RFC3261" /> if its associated policy server has session
policies that apply to mid-dialog requests. The Record-Route
header field 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.</t>
<t>A proxy can find out if the UAS supports this extension by
examining the Supported header field of responses. The proxy knows
that the UAS supports this extension if the Supported header field
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 field it has inserted into the request.</t>
<t>To protect the integrity of the policy server URI in a
Policy-Contact header field, the proxy SHOULD use a secured transport
protocol such as TLS between proxy and UAs.</t>
</section>
<section title="UAS Behavior">
<t>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 field. The UAS MUST contact the
policy server URIs in the order in which they were contained in
the Policy-Contact header field, starting with the topmost value (i.e.,
the value that was inserted first). </t>
<t>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. </t>
<t>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) response). This is to avoid that the failure of
a policy server prevents a UA from communicating. Since this
session might not be policy compliant without the policy
subscription, it can be blocked by policy enforcement mechanisms
if they are in place.</t>
<t>A UAS can receive a token from a policy server via the policy
channel. Since the UAS does not create a Policy-ID header field, it
can simply ignore this token.</t>
<t>A UAS compliant to this specification MUST include a
Supported header field with the option tag "policy" into
responses to requests that can initiate an offer/answer
exchange. The UAS MAY include this option tag in all responses. This
way, a proxy that has inserted the Policy-Contact header field can
know that the header field was understood by the UAS.</t>
</section>
<section title="Caching the Local Policy Server URI"
anchor='sec:uricache'>
<t>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.</t>
<t>A UA can receive this URI in a Policy-Contact header field 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 <xref
target="I-D.ietf-sipping-config-framework" />. If a UA has
received a local policy server URI through configuration and
receives another local policy server URI in a Policy-Contact
header field, the UA SHOULD overwrite the configured URI with the most
recent one received in a Policy-Contact header field.</t>
<t>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.</t>
<t>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.</t>
<t>The UA MUST NOT cache tokens it has received from a policy
server. A token is only valid for one request.</t>
</section>
<section title="Header Field Definition and Syntax" anchor='sec:syntax'>
<section title="Policy-Id Header Field" anchor='sec:policy-id-syntax'>
<t>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 field identifies all policy servers the UAC has contacted for
this request. </t>
<t>The value of a Policy-Id header field consists of a policy server
URI and an optional token parameter. The token parameter
contains a token the UA might have received from the policy
server.</t>
<t>The syntax of the Policy-Id header field is described below
in ABNF, according to <xref target="RFC5234">RFC5234</xref>, as
an extension to the ABNF for SIP in <xref
target="RFC3261">RFC3261</xref>:</t>
<figure>
<artwork><![CDATA[
Policy-Id = "Policy-Id" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token
]]></artwork>
</figure>
</section>
<section title="Policy-Contact Header Field" anchor='sec:policy-contact-syntax'>
<t>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 field 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 is not intended to be cached by the UAC.</t>
<t>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 end. With this, the Policy-Contact
header field effectively forms a fist-in-first-out queue. </t>
<t>The syntax of the Policy-Contact header field is described below
in ABNF, according to <xref target="RFC5234">RFC5234</xref>, as
an extension to the ABNF for SIP in <xref
target="RFC3261">RFC3261</xref>:</t>
<figure>
<artwork><![CDATA[
Policy-Contact = "Policy-Contact" HCOLON policyContactURI
*(COMMA policyContactURI)
policyContactURI = ( SIP-URI / SIPS-URI / absoluteURI )
[ SEMI "non-cacheable" ] *( SEMI generic-param )
]]></artwork>
</figure>
<t>Tables 1 and 2 are extensions of Tables 2 and 3 in <xref
target="RFC3261">RFC 3261</xref>. The column "INF" is for the
INFO method <xref target="RFC2976"/>, "PRA" is for the PRACK
method <xref target="RFC3262"/>, "UPD" is for the UPDATE method
<xref target="RFC3311" />, "SUB" is for the SUBSCRIBE method
<xref target="RFC3265" />, "NOT" is for the NOTIFY method <xref
target="RFC3265" />, "MSG" is for the MESSAGE method <xref
target="RFC3428" />, "REF" is for the REFER method <xref
target="RFC3515" />, and "PUB" is for the PUBLISH method <xref
target="RFC3903" />.</t>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Policy Channel" anchor='sec:polchannel'>
<t>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.</t>
<t>The Event Package for Session-Specific Session Policies <xref
target="I-D.ietf-sipping-policy-package" /> defines a
SUBSCRIBE/NOTIFY-based <xref target="RFC3265" /> policy channel mechanism. A UA compliant to
this specification MUST support the Event Package for
Session-Specific Session Policies <xref
target="I-D.ietf-sipping-policy-package" />. This event package
MUST be used to contact a policy server if the policy server URI
is a SIP-URI or SIPS-URI. A UA MAY support other policy channel
mechanisms.</t>
<section title="Creation and Management">
<t>A UA discovers the list of policy servers relevant for a
session during the initial offer/answer exchange (see <xref
target="sec:distmech" />). 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
one of 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. </t>
<t>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.</t>
<t>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 as described below.</t>
<t>A UAC can receive a 488 (Not Acceptable Here) response with a
Policy-Contact header field 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 the policies from the local policy server). This
way, the UAC will re-discover the list of policy servers
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 server. The UAC SHOULD close policy
channels to policy server that are not listed any more. The UAC
MUST contact policy servers in the order in which they were
discovered in the most recent request.</t>
<t>If a UAS receives a mid-dialog request with a Policy-Contact
header field 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 field.</t>
<t>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. </t>
</section>
<section title="Contacting the Policy Server">
<t>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 servers in the
order in which they were discovered most recently.</t>
<t>A UA that receives a SIP message containing an offer or
answer SHOULD completely process the message (e.g., according to
<xref target="RFC3261">RFC3261</xref>) 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 request before it contacts the
policy server. An important exception to this rule is discussed
in the next paragraph.</t>
<t>In some cases, a UA needs to use the offer/answer it has
received in a SIP message to create an ACK or PRACK request 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 request. 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 request.</t>
<t><list style="empty">
<t>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 request and could trigger retransmissions of
the INVITE response (also see the recommendations for Flow I
in <xref target="RFC3725">RFC3725</xref>).</t>
</list></t>
<t>The case of multiple policy servers providing policies to the
same UA requires additional considerations. A policy returned by
one policy server can contain information that needs to be
shared with the other policy servers. For example, two policy
servers can have the policy to insert a media intermediary by
modifying the IP addresses and ports of media streams. In order
for media streams to pass through both intermediaries, each
intermediary needs to know the IP address and port on which the
other media intermediary is expecting the stream to arrive. If
media streams are flowing in both directions, this means that
each intermediary needs to know IP addresses and ports of the
other intermediary.</t>
<t>UAs usually contact a policy server twice during an
offer/answer exchange (unless a policy server indicates that it
only needs to be contacted once). Therefore the case of
multiple policy servers providing policies to a single
UA does not require additional steps in most cases. However, a
UAS usually contacts each policy server only once (see <xref
target="fig:flow2" />). If a session policy returned by one of
the policy servers requires that information is shared between
multiple servers and the UAS receives policies from more than one policy
server, the UAS MUST contact all policy servers a second time
after contacting all servers the first time. Whether or not this
second round is required is determined by the type of
information returned by the policy server. The data format for
session policies explicitly states if a second round is
needed for a particular data element. If a UAS supports this
data format and receives such an element, it knows that is
expected to contact policy servers a second time. If such a data element is
modified during a mid-call offer/answer exchange and multiple
policy servers are providing policies to a UA then all UAs MUST
contact policy servers in a first and second round. An example
call flow for the UAS is shown in <xref target="sec:multiuas"
/>. </t>
</section>
<section title="Using Session Policies">
<t>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.</t>
<t>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 responds
with the corresponding answer. </t>
</section>
</section>
</section>
<section anchor="sec:security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><list style="numbers">
<t>integrity of the policy server URI (for session-specific
policies),</t>
<t>authentication of the policy server and, if needed, the user
agent,</t>
<t>confidentiality of the messages exchanged between the user
agent and the policy server and</t>
<t>ensuring that private information is not exchanged between
the two parties, even over an confidentiality-assured and
authenticated session.</t>
</list></t>
<t>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 header fields 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.</t>
<t>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. </t>
<t>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.</t>
<t>It is RECOMMENDED that administrators use SIPS URIs as policy
server URIs so that subscriptions to session policies are
transmitted over TLS.</t>
<t>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.</t>
</section>
<section anchor="sec:iana" title="IANA Considerations">
<section title='Registration of the "Policy-Id" Header Field'>
<t><list>
<t>Name of Header Field: Policy-Id</t>
</list></t>
<t><list>
<t>Short form: none</t>
</list></t>
<t><list>
<t>Normative description: <xref target="sec:syntax" /> of this document</t>
</list></t>
</section>
<section title='Registration of the "Policy-Contact" Header Field'>
<t><list>
<t>Name of Header Field: Policy-Contact</t>
</list></t>
<t><list>
<t>Short form: none</t>
</list></t>
<t><list>
<t>Normative description: <xref target="sec:syntax" /> of this
document</t>
</list></t>
</section>
<section title='Registration of the "policy" SIP Option-Tag'>
<t>This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of <xref
target="RFC3261">RFC3261</xref>.</t>
<t>This document defines the SIP option tag "policy".</t>
<t>The following row has been added to the "Option Tags" section
of the SIP Parameter Registry:</t>
<figure>
<artwork><![CDATA[
+------------+------------------------------------------+-----------+
| 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. | |
+------------+------------------------------------------+-----------+
]]></artwork>
</figure>
<t><list>
<t>Name of option: policy</t>
</list></t>
<t><list>
<t>Description: Support for the Policy-Contact and Policy-Id
header fields.</t>
</list></t>
<t><list>
<t>SIP header fields defined: Policy-Contact, Policy-Id</t>
</list></t>
<t><list>
<t>Normative description: This document</t>
</list></t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
<!--
<reference anchor='I-D.ietf-sipping-policy-package'>
<front>
<title abbrev='Session-Specific Policy Package'>A Session Initiation
Protocol (SIP) Event Package for Session-Specific Session Policies.</title>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
</author>
<date month='January' year='2007' />
<area>Transport</area>
<workgroup>SIPPING Working Group</workgroup>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipping-policy-package-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-03.txt' />
</reference>
-->
&i-d.ietf-sipping-policy-package;
<!--
<reference anchor='I-D.ietf-sipping-media-policy-dataset'>
<front>
<title abbrev='Media Policy Dataset'>A User Agent Profile Data Set
for Media Policy</title>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
</author>
<author initials='J.R.' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization>Cisco Systems</organization>
</author>
<date month='August' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipping-media-policy-dataset-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-05.txt' />
</reference>
-->
&i-d.ietf-sipping-media-policy-dataset;
&i-d.ietf-sipping-config-framework;
&rfc3311;
&rfc3261;
&rfc3265;
&rfc3262;
&rfc3264;
&rfc5234;
</references>
<references title='Informative References'>
&rfc2976;
&rfc4566;
&rfc3428;
&rfc3515;
&rfc3903;
<!--
<reference anchor='I-D.hilt-sipping-policy-usecases'>
<front>
<title abbrev='Session-specific Policy Use Cases'>Use Cases for
Session-Specific Session Initiation Protocol (SIP) Session
Policies</title>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
</author>
<date month='June' year='2005' />
<abstract>
<t>This draft describes use cases for session-specific Session
Initiation Protocol (SIP) sessions policies.</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hilt-sipping-policy-usecases-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hilt-sipping-policy-usecases-00.txt' />
</reference>
<reference anchor='I-D.petrie-sipping-profile-datasets'>
<front>
<title abbrev='SIP UA Data Sets'>A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets</title>
<author initials="D." surname="Petrie" fullname="Daniel Petrie">
<organization>SIPez LLC.</organization>
</author>
<author initials="S." surname="Lawrence" fullname="Scott Lawrence">
<organization>Pingtel Corp.</organization>
</author>
<author initials="M." surname="Dolly" fullname="Martin Dolly">
<organization>AT&T Labs</organization>
</author>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
</author>
<date month='October' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-petrie-sipping-profile-datasets-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-petrie-sipping-profile-datasets-03.txt' />
</reference>
-->
&rfc3725;
<!--
<reference anchor='I-D.ietf-sipping-session-policy-req'>
<front>
<title>Requirements for Session Policy for the Session Initiation Protocol (SIP)</title>
<author initials='J' surname='Rosenberg' fullname='Jonathan Rosenberg'>
<organization />
</author>
<date month='July' day='20' year='2004' />
<abstract><t>The proxy server plays a central role as an intermediary
in the establishment of sessions in the Session Initiation Protocol
(SIP). In that role, they can define and impact policies on call
routing, rendezvous, and other call features. However, there is no
standard means by which proxies can have any influence on session
policies, such as the codecs that are to be used. As such, ad-hoc and
non-conformant techniques have been deployed to allow for such policy
mechanisms. There is a need for a standards-based and complete
mechanism for session policies. This document defines a set of
requirements for such a mechanism.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sipping-session-policy-req-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-policy-req-02.txt' />
</reference>
-->
</references>
<section title="Acknowledgements">
<t>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.</t>
</section>
<section title="Session-Specific Policies - Call Flows">
<t>The following call flows illustrate the overall operation of
session-specific policies including the policy channel protocol as
defined in the <xref target="I-D.ietf-sipping-policy-package">SIP
Event Package for Session-Specific Session Policies</xref>.</t>
<t>The following abbreviations are used: </t>
<t><list style="empty">
<t>o: offer</t>
<t>o': offer modified by a policy</t>
<t>po: offer policy</t>
<t>a: answer</t>
<t>a': answer modified by a policy</t>
<t>pa: answer policy</t>
<t>ps uri: policy server URI (in Policy-Contact header field)</t>
<t>ps id: policy server id (in Policy-Id header field)</t>
</list></t>
<section title="Offer in Invite">
<figure>
<artwork><![CDATA[
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 | | | |
|------------------>| | | |
| | | | | |
| | | | | |
]]></artwork>
</figure>
</section>
<section title="Offer in Response">
<figure>
<artwork><![CDATA[
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'> | | | |
|------------------------------------------------>|
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
]]></artwork>
</figure>
</section>
<section title="Multiple Policy Servers for UAS" anchor='sec:multiuas'>
<figure>
<artwork><![CDATA[
UA A P A PS A PS B P B UA B
| | | | | |
| | | | | |
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
| |(2) INV <o, uri PSA> | |
| |---------------------------->| |
| | | | |(3) INV <o, uri PSA, uri PSB>
| | | | |-------->|
| | |(4) SUBSCRIBE <o, a> |
| | |<----------------------------|
| | |(5) 200 OK | |
| | |---------------------------->|
| | |(6) NOTIFY <po, pa>| |
| | |---------------------------->|
| | |(7) 200 OK | |
| | |<----------------------------|
| | | |(8) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(9) 200 OK |
| | | |------------------>|
| | | |(10) NOTIFY <po, pa>
| | | |------------------>|
| | | |(11) 200 OK |
| | | |<------------------|
| | |(12) SUBSCRIBE <o", a"> |
| | |<----------------------------|
| | |(13) 200 OK | |
| | |---------------------------->|
| | |(14) NOTIFY <po, pa> |
| | |---------------------------->|
| | |(15) 200 OK | |
| | |<----------------------------|
| | | |(16) SUBSCRIBE <o", a">
| | | |<------------------|
| | | |(17) 200 OK |
| | | |------------------>|
| | | |(18) NOTIFY <po, pa>
| | | |------------------>|
| | | |(19) 200 OK |
| | | |<------------------|
| | | | |(20) 200 OK <a">
| | | | |<--------|
| |(21) 200 OK <a"> | | |
| |<----------------------------| |
|(22) 200 OK <a"> | | | |
|<--------| | | | |
|(23) ACK | | | | |
|------------------------------------------------>|
| | | | | |
| | | | | |
]]></artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:31 |