A Framework for Session Initiation Protocol (SIP) Session Policies
Extracted elements (33)
The framework uses a separate policy channel rather than piggybacking policy information on SIP signaling messages. This decouples endpoint-to-endpoint signaling from endpoint-to-policy-server policy exchange, enables separate encryption on each path, prevents policies from traversing multiple unintended domains, and allows policy servers to push updates at any time without waiting for a SIP message to flow by.
The Policy-ID header field token parameter allows domains with multiple proxy/policy server combinations (e.g., a load-balanced farm) to route all requests belonging to the same session to the same proxy/policy server that configured per-session state such as a session border device for pinhole opening.
Two distinct policy types are defined: session-specific policies (created per-session from the session description at setup time, e.g., to open firewall pinholes) and session-independent policies (created independently of any session, applied to all sessions, delivered via subscription). Their different requirements necessitate two separate delivery mechanisms.
Intermediaries MAY fall back to existing mechanisms such as rejecting non-policy-compliant sessions with a 488 response for backward compatibility with UAs that do not support this specification. UAs lacking support receive the same behavior as today, though this approach has drawbacks and explicit policy signaling is RECOMMENDED.
When a UAS receives policies from multiple policy servers and one returns a data element (as defined by RFC 6796) indicating information-sharing is required, the UAS MUST contact all policy servers a second time after the first round to allow cross-server coordination (e.g., when two servers each insert a media intermediary requiring each other's IP/port).
A proxy MUST use the Record-Route mechanism if its associated policy server has policies that apply to mid-dialog requests, to remain on the signaling path and resubmit policy server URIs to UAs for subsequent offer/answer exchanges.
A proxy MUST verify that a request does not already contain the local policy server URI in a Policy-ID header field before rejecting with 488. If rejecting, the proxy MUST insert a Policy-Contact header field with its policy server URI(s) in the 488 response.
A UA compliant to this specification MUST support the Event Package for Session-Specific Policies [RFC6795] and MUST use it when the policy server URI is a SIP-URI or SIPS-URI.
A UA MUST disclose the session description(s) to policy servers through the policy channel and MUST apply received session policies to the offer and answer before use. If policies are unacceptable, the UA MUST NOT continue with the session.
A UA MUST inform the policy server via the policy channel when a session terminates (BYE sent or received), unless the policy server indicates otherwise, so the server can release session resources.
A UA MUST NOT cache a policy server URI marked 'non-cacheable' and SHOULD remove any currently cached local policy server URI when a non-cacheable URI is received, to prevent use of outdated URIs.
A UA MUST set up a policy channel to each discovered policy server and MUST maintain that channel for the lifetime of the session. If the UA does not want to establish a channel to a required policy server, it MUST cancel or reject the pending INVITE or terminate the in-progress session.
A UA supporting session-independent policies MUST retrieve them using the 'ua-profile' event package [RFC6080] from both the local network (using 'local-network' profile-type) and SIP service provider domain (using 'user' profile-type). If session-independent and session-specific policies are both present, the UA MUST apply session-independent policies first.
A UAC compliant to this specification MUST include a Supported header field with the option tag 'policy' in all requests that can initiate an offer/answer exchange (e.g., INVITE, UPDATE, PRACK), even if that particular request does not contain an offer or answer.
A UAS receiving a Policy-Contact header field MUST contact one URI from each group of alternative URIs (same 'alt-uri' value) and MUST contact all non-alternative URIs, in the top-to-bottom order listed. If an unacceptable policy is received, the UAS MUST reject with 488.
After receiving a 488 (Not Acceptable Here) with a Policy-Contact header field and deciding to continue, the UAC MUST use one of the provided policy server URIs to contact the policy server per Section 4.5, then MUST apply the received policies and re-send the updated request with a Policy-ID header field.
If a UAS receives a mid-dialog request with a changed Policy-Contact list, the UAS MUST set up a policy channel to all new policy servers and contact them, and SHOULD close channels to servers no longer listed to avoid receiving inapplicable policies.
The UAC MUST insert a Policy-ID header field into requests for which it has contacted a policy server and accepted the policies. If a token was received from the policy server, the UAC MUST include that token in the Policy-ID header field value.
The UAC MUST NOT change the implicit ordering among policy servers established by successive 488 responses; policy servers must be contacted in the order requests traverse their domains.
When a proxy includes multiple alternative URIs for the same policy, it MUST include an 'alt-uri' parameter on all of them with the same domain/FQDN value, and MUST include a SIP or SIPS URI even if other URI schemes are also provided.
When a UA receives notification of a policy change, it MUST apply the updated policies to the current session or MUST terminate the session. If the policy update modifies the session description, the UA must renegotiate with its peer (e.g., via re-INVITE or UPDATE).
The Policy-Contact header field is inserted by a proxy into 488 responses or INVITE/UPDATE/PRACK requests to convey one or more policy server URIs to the UAC or UAS. It supports alternative URIs via the 'alt-uri' parameter (indicating different transport schemes for the same policy) and a 'non-cacheable' parameter to prevent URI caching.
The Policy-ID header field is inserted by the UAC into INVITE, UPDATE, or PRACK requests to identify all policy servers the UAC has contacted for the current request. Its value consists of a policy server URI and an optional opaque token received from the policy server.
The 'policy' SIP option tag is registered to indicate that a UA supports the Policy-Contact and Policy-ID header fields and can subscribe to session-specific policies. It is included in the Supported header of requests initiating offer/answer exchanges.
IANA registration of the 'non-cacheable' parameter for the Policy-Contact header field in the SIP Header Field Parameters and Parameter Values registry (RFC 3968), with predefined values (Yes).
IANA registration of the 'Policy-Contact' SIP header field (no short form), valid in INVITE/UPDATE/PRACK requests and in 488 responses; proxy behavior is 'a' (add).
IANA registration of the 'Policy-ID' SIP header field (no short form), valid in requests (R column) for INVITE, UPDATE, and PRACK; proxy behavior is 'rd' (remove and delete on forward).
IANA registration of the 'policy' option tag in the SIP Option Tags registry, indicating a UA supports Policy-Contact and Policy-ID header fields and can subscribe to session-specific policies.
An attacker can intercept SIP messages and remove Policy-Contact header fields, preventing UA/policy server rendezvous and blocking session setup; or modify the policy server URI to redirect the UA to a compromised server. UAs SHOULD use TLS between UA and proxy to protect Policy-Contact header integrity, and it is RECOMMENDED that UAs authenticate policy servers.
Malicious session policies can be used to deny service — for example, setting available bandwidth to zero mid-session forces termination. Policy enforcement without policy signaling also creates a denial-of-service condition since UAs cannot know what is enforced. It is RECOMMENDED that UAs only accept session-independent policies from trustworthy, configured servers; session-specific policies from other servers MAY be accepted since they apply to only a single session.
Session information submitted to a policy server (offer, answer) may contain sensitive user data; session policies may reveal sensitive network or SLA information. Communication between UA and policy server must protect confidentiality, and both parties should authenticate each other. Policy servers that cannot authenticate a UA MAY return a generic policy that omits sensitive information.
Policy-Contact ABNF: 'Policy-Contact = "Policy-Contact" HCOLON policyContact-info *(COMMA policyContact-info)' where policyContact-info is a URI in angle brackets with optional parameters 'non-cacheable', 'alt-uri=hostname', or generic-param. Extends RFC 3261 ABNF.
Policy-ID ABNF: 'Policy-ID = "Policy-ID" HCOLON policyURI *(COMMA policyURI)' where 'policyURI = (SIP-URI / SIPS-URI / absoluteURI) [SEMI token-param] *(SEMI generic-param)' and 'token-param = "token=" token'. Extends RFC 3261 ABNF.