RFC 6795
A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies
RFC 6795: A SIP Event Package for Session-Specific Policies 💖
Bestie, this RFC is a whole vibe. It's from December 2012 and it's on the Standards Track 📜, which means it's an official Internet standard, not just a suggestion. The authors are V. Hilt from Bell Labs/Alcatel-Lucent and G. Camarillo from Ericsson 🦋. It has ISSN 2070-1721. The header has no Obsoletes or Updates lines, so it doesn't list anything it replaces or changes. Iconic, honestly 👑.
Abstract ✨
okay so this spec defines a SIP event package for session-specific policies 🎀. It lets user agents (UAs) subscribe to the policies for a SIP session and get notified if those policies change. Main character energy 💅.
Status of This Memo 📋
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🌸.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6795 🧚.
Copyright Notice 🌈
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💀.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Event Package Formal Definition .................................3
3.1. Event Package Name .........................................4
3.2. Event Package Parameters ...................................4
3.3. SUBSCRIBE Bodies ...........................................4
3.4. Subscription Duration ......................................5
3.5. NOTIFY Bodies ..............................................5
3.6. Subscriber Generation of SUBSCRIBE Requests ................6
3.7. Notifier Processing of SUBSCRIBE Requests ..................8
3.8. Notifier Generation of NOTIFY Requests .....................9
3.9. Subscriber Processing of NOTIFY Requests ..................10
3.10. Handling of Forked Requests ..............................11
3.11. Rate of Notifications ....................................11
3.12. State Agents .............................................11
3.13. Examples .................................................11
4. Security Considerations ........................................14
5. IANA Considerations ............................................16
5.1. Event Package Name ........................................16
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................17
Appendix A. Acknowledgements ......................................181. Introduction 🦋
okay so the Framework for SIP Session Policies [RFC6794] is the protocol framework that lets a proxy define and affect policies on sessions, like which codecs or media types get used. It describes two kinds of session policies: session-specific and session-independent 💅.
Session-specific policies are made for one particular session, based on that session's description ✨. They let a network intermediary look at the session description a UA is proposing, then send back a policy made specifically for that description. For example, an intermediary could open pinholes in a firewall/NAT for each media stream in a session, then return a policy that swaps the internal IP addresses and ports in the session description for external ones 🔥. Since these policies are tailored to one session, they only apply to that session. A UA asks for them session by session, at the moment the session is created and its description is known 🎀. Session-independent policies are different. They're created independently of any session and generally apply to all the SIP sessions a user agent sets up 🌸.
"A Framework for Session Initiation Protocol (SIP) Session Policies" [RFC6794] also defines a mechanism that lets UAs discover the URIs of session-specific policy servers 🧚. This spec defines a SIP event package [RFC6665] that lets UAs subscribe to session-specific policies on a policy server 💖. Subscribing to them goes through these steps (see the Session Policy Framework [RFC6794]):
- A user agent submits the details of the session it wants to set up to the policy server, and asks whether a session with those parameters is allowed. For example, a user agent might propose a session with audio and video media types 🎀.
- The policy server makes a policy decision for that session and sends it back to the user agent. The possible decisions are (1) deny the session, (2) propose changes to the session parameters that would make it acceptable, or (3) accept the session as proposed. One example is disallowing video while agreeing to everything else in the proposed session 🫶.
- The policy server can update its decision later. An update might require more changes to the session (for example, because the available bandwidth changed), or it might deny a session that was already accepted, meaning the session can't continue 😭.
The event package for session-specific policies lets a user agent subscribe to the policies for a SIP session using that same model 👑. The subscriber starts a subscription by putting the details of the session it wants into the body of a SUBSCRIBE request and sending it to the notifier (i.e., the policy server) 💅. The notifier uses that info to make the policy decision for the session. It sends the initial decision to the subscriber in a NOTIFY request, then sends every later change in subsequent NOTIFY requests 🌈.
2. Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥.
3. Event Package Formal Definition 🎀
This document gives the details you need to define a SIP event package, as RFC 6665 [RFC6665] requires 💖.
3.1. Event Package Name 🏷️
The name of the event package defined here is "session-spec-policy" ✨.
3.2. Event Package Parameters 🧁
This package defines the following two event package parameters 🌸:
local-only: The "local-only" parameter is optional and only defined for NOTIFY requests. It indicates that the notifier doesn't need the remote session description. It MUST be ignored if received in a SUBSCRIBE request. How this parameter gets used is described in Sections 3.6, 3.8 and 3.9 🫶.insufficient-info: The "insufficient-info" parameter is optional and only defined for NOTIFY requests. The notifier uses it to say that it couldn't make a policy decision because it didn't have enough information 😭. The "insufficient-info" parameter MUST be ignored if received in a SUBSCRIBE request. How it gets used is described in Sections 3.7, 3.8 and 3.9 🙈.
3.3. SUBSCRIBE Bodies 📦
A SUBSCRIBE for this event package MUST contain a body that describes a SIP session 🦋. That body's whole job is to let the notifier generate the policies the subscriber cares about 💅. In this package, the Request-URI, the event package name, and the event parameters are NOT enough by themselves to figure out which resource a subscription is for. With the session description in the SUBSCRIBE body, though, the notifier can produce the requested policy decision and create policy events for that resource ✨.
All subscribers and notifiers MUST support the MIME type application/media-policy-dataset+xml, as defined in "A User Agent Profile Data Set for Media Policy" [RFC6796] 💜. application/media-policy-dataset+xml is the default format for SUBSCRIBE bodies in this package 🌈. Subscribers and notifiers MAY negotiate other formats that can represent a session 🎀.
Note: It has been proposed to use Session Description Protocol (SDP) [RFC4566] directly, rather than encoding session descriptions in the Media Policy [RFC6796] format. Using a separate format like Media Policy has a few advantages over plain SDP: i) the Media Policy format is more flexible and can include info that SDP can't express (e.g., the target URI), ii) the Media Policy format can encode local and remote session descriptions in one document (no MIME multipart or new content disposition types needed), and iii) the Media Policy format lines up the formats used for session-specific and session-independent policies. The drawback is that the UA has to encode SDP and session info into Media Policy documents 🙈.
3.4. Subscription Duration ⏳
A subscription to the session-specific policy package usually starts at the beginning of a session and ends when that session ends 💖. A typical phone call lasts a few minutes 📞.
Since a subscription's duration is tied to the lifetime of its session, the exact value is mostly irrelevant 🧚. Even so, the duration SHOULD be longer than the typical length of a session ✨. The default subscription duration for this event package is set to two hours ⭐.
A notifier MAY terminate a subscription before the session ends 🦋. For example, a notifier might end the subscription after sending the initial policy notification if it knows the policies won't change during the session 🌸. A subscriber MUST NOT terminate a subscription unless it's terminating the session the subscription is for, or it finds out that the notifier was removed from the list of policy servers relevant to this session (see the Session Policy Framework [RFC6794]) 🔥. A subscriber MUST refresh a subscription with a SUBSCRIBE request before the last SUBSCRIBE request expires, so the subscription doesn't time out 💅✨.
3.5. NOTIFY Bodies 💌
okay so in this event package, the NOTIFY body is where the session policy the subscriber asked for actually lives 🎀 All subscribers and notifiers MUST support application/media-policy-dataset+xml [RFC6796] as a format for NOTIFY bodies. no exceptions, bestie 💅
The SUBSCRIBE request MAY contain an Accept header field 🦋 If there isn't one, it defaults to application/media-policy-dataset+xml. If it IS there, it MUST include application/media-policy-dataset+xml, and it MAY also include any other MIME type that can represent session-specific policies. As RFC 6665 [RFC6665] spells out, the NOTIFY body MUST be in one of the formats listed in the SUBSCRIBE's Accept header or the default format. basically the body has to match what was on the list 🫶
If the notifier sends NOTIFY bodies in the same format the subscriber used in its SUBSCRIBE body (like application/media-policy-dataset+xml), the notifier can expect that the subscriber supports all the format extensions that were used in the SUBSCRIBE body 🧚 It can't assume the subscriber knows about any other extensions past that, so it SHOULD NOT use them. no surprise extensions, periodt 🙈
If the SUBSCRIBE request had a representation of the local session description and the subscription got accepted, then the NOTIFY body MUST contain a policy for the local session description ✨ And if an accepted subscription's SUBSCRIBE request had both the local AND the remote session description, the NOTIFY body MUST contain two policies: one for the local and one for the remote. two policies, one for each side, iykyk 👑
3.6. Subscriber Generation of SUBSCRIBE Requests 🌸
the subscriber follows the general rules for making SUBSCRIBE requests from RFC 6665 [RFC6665] 💖 The subscriber MUST provide enough info in the SUBSCRIBE body to fully describe the session it wants session-specific policies for. and it MUST base that info on the most recent session description. the freshest tea only ☕
if the application/media-policy-dataset+xml format is used in SUBSCRIBE bodies, the subscriber MUST provide a value for every field defined for session information documents [RFC6796] that it has info for. basically, the subscriber MUST fill in the elements of a session information document as completely as it can 📝 If the subscriber supports extensions of the application/media-policy-dataset+xml format, it MUST also provide a value for each field that this extension defines for session information documents, if possible. giving the notifier as much info as possible helps avoid having the session rejected for lack of session information, and it also cuts down on back-and-forth about what info gets shared between notifier and subscriber 🔥
subscriptions to this event package are usually created alongside an SDP offer/answer exchange [RFC3264] when a session is being set up (see the Session Policy Framework [RFC6794]) 🦋 When it's used with an offer/answer exchange, the subscriber MUST insert the representation of the local session description into the SUBSCRIBE body. the local session description is the one the subscriber made (like the offer, if the subscriber started the offer/answer exchange). sometimes a UA doesn't have a session description yet when it subscribes to session-specific policies, like when it's composing an empty INVITE request (an INVITE that doesn't have an offer in it) 🙈 In those cases, a UA SHOULD establish a subscription without including a representation of the local session description. then the UA MUST refresh the subscription with a SUBSCRIBE request that carries this session description as soon as it's available, for example when the UA gets a 200 OK to that empty INVITE request. a policy server can choose to admit a session only after the UA has disclosed the session descriptions, so that's the vibe 🌈
the subscriber SHOULD also include a representation of the remote session description in the SUBSCRIBE body 🎀 The remote session description is the one the subscriber received (like the answer, if the subscriber started the offer/answer exchange). in some scenarios the remote session description isn't available yet when the subscription to session-specific policies gets set up. in that case, the initial SUBSCRIBE message SHOULD only contain a representation of the local session description. once the remote description shows up, the subscriber SHOULD refresh the subscription by sending another SUBSCRIBE request that has BOTH the local and the remote session description, unless the subscriber got a NOTIFY request with the local-only parameter. that parameter means the notifier doesn't need to see the remote session description 🧚
a user agent can change the session description of an ongoing session 💅 A change in the session description will usually affect the policy decisions for that session. so a subscriber MUST refresh the subscription to session-specific policies every single time the session description of a session changes. it does this by sending a SUBSCRIBE request with the details of the updated session descriptions. the policy stays in sync, bestie 💖
sometimes a subscriber gets an error response to a SUBSCRIBE request that indicates a server failure ⭐ In that case, the subscriber SHOULD try to find an alternative server, for example using the procedures in [RFC3263]. if no alternative server can be found, the subscriber MAY keep going with the session it wanted session-specific policies for, without subscribing to session-specific policies. the reason is so a broken policy server doesn't stop a UA from setting up or continuing a session. but heads up: since the sessions the UA creates may not be policy compliant without this subscription, policy enforcement mechanisms, if they're in place, may block them 💀
session policies can contain sensitive information, and policy decisions can seriously change how a user agent behaves. so a user agent SHOULD (lowercase, but still important!) verify the identity of a policy server and make sure the policies weren't altered in transit. ALL implementations of this package MUST support Transport Layer Security (TLS) [RFC5246] and the Session Initiation Protocol Secure (SIPS) URI scheme. a subscriber SHOULD use SIPS URIs when subscribing to session-specific policies so the policies get sent over TLS 🔐 see Section 4 for the full security story, it's serious business 😭
3.7. Notifier Processing of SUBSCRIBE Requests 🔥
all subscriptions to session-specific policies SHOULD be authenticated and authorized before they get approved 🛡️ BUT a policy server may run into UAs it can't authenticate, and in those cases the policy server MAY provide a generic policy that doesn't reveal sensitive info to those UAs. for the details, check Section 4 👀
the authorization policy is up to the administrator 💜 In general, all users SHOULD be allowed to subscribe to the session-specific policies of their own sessions. a device that needs to know the policies for its sessions will usually be the one that sets up a subscription to this event package. but applications can also subscribe (like a conference server), and in those cases an authorization policy will usually be provided for those applications 🎀
responding quickly to a SUBSCRIBE request is super important for this event package 🏃♀️ A notifier has to minimize the time it takes to process SUBSCRIBE requests and to generate the initial NOTIFY request. that includes minimizing the time it takes to make an initial policy decision. a short response time matters a lot here because it cuts the delay for fetching policies during an INVITE transaction, which means shorter call setup time ⚡ Also, subscriptions to session-specific policies can be set up while the subscriber is in an INVITE transaction, at the point where it has gotten the 200 OK but hasn't sent the ACK yet. if creating the initial NOTIFY request gets delayed, the ACK gets delayed too 😭 You can find a more detailed discussion of this scenario in the Session Policy Framework [RFC6794] 🌸
a subscriber might not have shared enough info in the SUBSCRIBE request for the notifier to make a policy decision 🙈 For example, a UA might subscribe to session-specific policies without including a representation of a session description. the policy server SHOULD accept that kind of subscription ✨
the policy server SHOULD generate a NOTIFY request that includes the insufficient-info event package parameter 🧚 A NOTIFY request with this parameter means a policy decision couldn't be made because info was missing. the body of that NOTIFY request can either be empty or contain a policy decision document that gives hints about which info was missing 🦋
3.8. Notifier Generation of NOTIFY Requests 💖
okay so the notifier sends a notification when it's answering SUBSCRIBE requests, as defined in [RFC6665]. 🫶 But it also MAY send one at literally any point during the subscription, whenever it wants. Usually it'll send one every time the policy decision this subscription is for has changed ✨. And when and why that decision changes is totally up to the administrator 👑. The reasons can be all over the place. Like, a network gets congested because traffic spiked, so it cuts the bandwidth for one user 💀. Or a session started during "business hours" rolls into "evening hours," where the service level agreement gives the user more bandwidth or more video sessions 🎀.
Policy decisions are written in whatever format got negotiated for the NOTIFY body, like application/media-policy-dataset+xml 🦋. The policy document in a NOTIFY body MUST represent a complete policy decision 🔥. Deltas against earlier decisions, or partial decisions, are NOT supported in this event package 🙅♀️. No exceptions, bestie.
Now, the notifier SHOULD terminate the subscription if the policy decision is to reject a session AND it can be expected that this decision won't change in the foreseeable future 💅. But if it rejects a session and still expects the session can get admitted soon, the notifier SHOULD keep the subscription alive 🌸. Like, if the session got rejected because resources were temporarily short and those resources are about to free up again, keeping the subscription open is the move ✨. A session gets admitted by returning a policy decision document that requires some changes to the session, or no changes at all 🧚.
If the notifier hasn't gotten enough info from the subscriber to make a decision (like, it never received a session description) 🙈, the notifier SHOULD NOT terminate the subscription. The UA is expected to refresh the subscription with a SUBSCRIBE request that has more info in it 🫶. Instead, the notifier SHOULD generate a NOTIFY request with the insufficient-info event package parameter, which says a decision couldn't be made because info was missing 💜. That NOTIFY can have an empty body, or a body with a policy decision document that says what was missing 🍓.
Some session-specific policies don't need the remote session description disclosed to the notifier at all 🦋. If the notifier figures that out after getting a SUBSCRIBE request, it SHOULD include the local-only event parameter in its NOTIFY requests 🔐.
3.9. Subscriber Processing of NOTIFY Requests 🎀
A subscriber MUST apply the policy decision it gets in a NOTIFY request to the session tied to this subscription 💅. If the UA decides NOT to apply that decision, the UA MUST NOT set up the session, and if the session is already in progress, the UA MUST terminate it 😭. And if the UA has a pending INVITE transaction for this session, the UA MUST cancel or reject that INVITE request 💀.
If the subscriber gets a NOTIFY request saying the session was rejected, the subscriber MUST NOT try to establish that session 🙅♀️. If the notifier terminated the subscription after rejecting the session, the subscriber SHOULD NOT try to re-send that same SUBSCRIBE request again 🌈. Termination like that means the decision for this session is final and won't change in the foreseeable future 🔒. The subscriber MAY try to re-subscribe for this session, though, if at least one aspect of the session changed (like a parameter in the session description or the target URI), or if there's some other reason to think retrying will work (for example, a lot of time has passed since the last attempt) ✨.
The notifier MAY keep the subscription up after rejecting a session, so it can send an updated policy decision for this session later on 🧚. This is handy when the session got rejected because resources were temporarily short and the notifier expects that problem to be fixed soon 🌸. Another example: the session got rejected because it was attempted during a restricted period, and that period is about to end 🕰️. In that case, the subscriber SHOULD not terminate the subscription to session-specific policies 💖.
The subscriber MAY get a NOTIFY request with an insufficient-info event package parameter, which means the SUBSCRIBE request didn't have enough info 🙈. The subscriber SHOULD refresh the subscription with more complete info as soon as the missing info (like the session description) is available 🫶.
A subscriber MAY get an update to a policy decision for a session that's already established 👑. The subscriber MUST apply the new policy decision to that session 💅. If a UA decides it does NOT want to apply the new decision, the UA MUST terminate the session 😤. An updated decision might require the UA to generate a re-INVITE or UPDATE request in this session if the session description changed, or it might mean terminating the session altogether 🦋. A policy update that forces a UA to terminate a session can be triggered by, for example, the user's account running out of credit, or by an emergency that means non-emergency calls have to be ended 🚨.
If the subscriber gets a NOTIFY request with the local-only event parameter, the subscriber SHOULD NOT include the remote session description in later SUBSCRIBE requests within this subscription 🌸.
3.10. Handling of Forked Requests 🍴
This event package only lets one dialog get created from a single initial SUBSCRIBE request 💅. The techniques for making that happen are described in [RFC6665] ✨.
3.11. Rate of Notifications ⏱️
Policy changes are expected to be super rare, so the rate of policy changes will be very low 🐢. Even so, notifications SHOULD NOT be generated more than once every five seconds 🙅♀️.
3.12. State Agents 🫥
State agents play no role in this package 💜.
3.13. Examples 🧚
The following message flow shows how a user agent (Alice's phone) can subscribe to session-specific policies while setting up a call to Bob's phone 📞✨. The flow assumes the user agent already got the policy server URI (maybe through configuration, or as described in the Session Policy Framework [RFC6794]) 🦋. It also doesn't show the authentication messages on a transport or SIP level 🙈.
These call flow examples are informative and not normative 💖. Implementers should check the main text of this document for the exact protocol details 🫶.
Policy Server Alice Bob
| | |
|(1) SUBSCRIBE | |
|<------------------| |
|(2) 200 OK | |
|------------------>| |
|(3) NOTIFY | |
|------------------>| |
|(4) 200 OK | |
|<------------------| |
| |(5) INVITE |
| |------------------>|
| | |
| |(6) 200 OK |
| |<------------------|
| |(7) ACK |
| |------------------>|
|(8) SUBSCRIBE | |
|<------------------| |
|(9) 200 OK | |
|------------------>| |
|(10) NOTIFY | |
|------------------>| |
|(11) 200 OK | |
|<------------------| |
| | |Message Details 📝
(1) SUBSCRIBE Alice -> Policy Server
SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74bf
Max-Forwards: 70
From: Alice <sips:alice@biloxi.example.com>;tag=8675309
To: PS <sips:policy@biloxi.example.com>
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 SUBSCRIBE
Contact: <sips:alice@pc.biloxi.example.com>
Expires: 7200
Event: session-spec-policy
Accept: application/media-policy-dataset+xml
Content-Type: application/media-policy-dataset+xml
Content-Length: ...
[Local session description (offer)](2) 200 OK Policy Server -> Alice(3) NOTIFY Policy Server -> Alice
NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS srvr.biloxi.example.com:5061
;branch=z9hG4bK74br
Max-Forwards: 70
From: PS <sips:policy@biloxi.example.com>;tag=31451098
To: Alice <sips:alice@biloxi.example.com>;tag=8675309
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 NOTIFY
Event: session-spec-policy
Subscription-State: active;expires=7200
Content-Type: application/media-policy-dataset+xml
Content-Length: ...
[Policy for local session description (offer)](4) 200 OK Alice -> Policy Server(5) INVITE Alice -> Bob(6) 200 OK Bob -> Alice(7) ACK Alice -> Bob(8) SUBSCRIBE Alice -> Policy Server
SUBSCRIBE sips:policy@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bKna998sl
Max-Forwards: 70
From: Alice <sips:alice@biloxi.example.com>;tag=8675309
To: PS <sips:policy@biloxi.example.com>;tag=31451098
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 2 SUBSCRIBE
Expires: 7200
Event: session-spec-policy
Accept: application/media-policy-dataset+xml
Content-Type: application/media-policy-dataset+xml
Content-Length: ...
[Local session description (offer)]
[Remote session description (answer)](9) 200 OK Policy Server -> Alice(10) NOTIFY Policy Server -> Alice
NOTIFY sips:alice@pc.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS srvr.biloxi.example.com:5061
;branch=z9hG4bKna998sk
Max-Forwards: 70
From: PS <sips:policy@biloxi.example.com>;tag=31451098
To: Alice <sips:alice@biloxi.example.com>;tag=8675309
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 2 NOTIFY
Event: session-spec-policy
Subscription-State: active;expires=7200
Content-Type: application/media-policy-dataset+xml
Content-Length: ...
[Policy for local session description (offer)]
[Policy for remote session description (answer)]F6 200 OK Alice -> Policy Server4. Security Considerations 🔐
okay bestie, this is the serious part, so put on your big girl boots 👢💅 Session policies can seriously change how a user agent behaves, which means an attacker could use them to compromise a UA 😭 For example, a policy could stop a UA from setting up a session at all (like by setting the available bandwidth to zero 💀). And a policy can be sent to the UA during a session, which may make it terminate that session. ngl, scary stuff.
A user agent sends session information to a policy server 📨 That info can be sensitive, the kind of thing you don't want an eavesdropper or an unauthorized policy server peeking at. Like, the session info may contain the encryption keys for media streams 🔑 It works the other way too: session policies can hold sensitive details about the network or service level agreements that the service provider doesn't want an eavesdropper or an unauthorized user agent to see 🙈
So it is super important to secure the chat between the user agent and the policy server 🫶 There are three discrete attributes that need to be protected:
- authentication of the policy server and, if needed, the user agent,
- confidentiality of the messages exchanged between the user agent and the policy server, and
- ensuring that private information is not exchanged between the two parties, even over a confidentiality-assured and authenticated session.
Authenticating the peers and keeping the policies private while they're in transit is handled by existing SIP security mechanisms (the use of TLS and SIPS URI scheme [RFC3261], [RFC5630]) 🔒
Okay, so, policy servers SHOULD be addressable only through a SIPS URI. Policy server and user agent MUST support TLS 🎀 The confidentiality of the communication between the policy server and the user agent will be assured as long as the policy server supports TLS and is reached through a SIPS URI ✨
Authenticating the two parties can be done with X.509 certificates exchanged through TLS, plus other techniques like HTTP Digest 🪪 When the user agent sets up a TLS session with the policy server, the policy server will show it an X.509 certificate. The user agent SHOULD make sure that the identity of the policy server encoded in the certificate matches the URI of the policy server the user agent got either from the Session Policy Framework [RFC6794] or from other means, like configuration 🧐
When a policy server gets a new subscription (as opposed to a refresh subscription), it SHOULD try to authenticate the user agent using any means it has 🕵️♀️ If the user agent has an X.509 certificate suitable for use with TLS, the identity of the user agent SHOULD be in the certificate. If the user agent doesn't have a certificate, the policy server SHOULD challenge the user agent using HTTP Digest. A policy server may frequently run into UAs it can't authenticate. In those cases, the policy server MAY provide a generic policy that doesn't reveal sensitive information to those UAs 🫣
If the subscriber and notifier want to protect the integrity of the policy exchange end to end, they MAY use S/MIME to protect the session policies 🛡️ However, RFC3261 warns that "[i]mplementers should note, however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of intermediaries from functioning" [RFC3261]. Plot twist, right? 🙃
And finally, the fact that the UA and the policy server have successfully authenticated each other and set up a secure TLS session does NOT let either one off the hook for making sure they don't share sensitive info 🙅♀️ For example, a session description may contain sensitive information (like session keys) that the user agent may not want to share with the policy server. And honestly, the policy server doesn't need that info to put together a policy anyway. So the user agent should not put that sort of sensitive information in a session information document that it sends to the policy server. Likewise, the policy server may have information that is sensitive and of no use to the user agent, like network service level agreements or network statistics. So the policy server should refrain from sending that info to the user agent 🌸
5. IANA Considerations 📋
5.1. Event Package Name 🎀
This spec registers an event package, following the registration procedures defined in RFC 6665 [RFC6665] 💖
Package Name: session-spec-policy
Package or Template-Package: This is a package.
Published Document: RFC 6795.
Person to Contact: Volker Hilt, volker.hilt@bell-labs.com.
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
[RFC6794] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework
for Session Initiation Protocol (SIP) Session Policies",
RFC 6794, December 2012.
[RFC6796] Hilt, V., Camarillo, G., Rosenberg, J., and D. Worley, "A
User Agent Profile Data Set for Media Policy", RFC 6796,
December 2012.6.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.Appendix A. Acknowledgements 🙌
Huge thanks to Jonathan Rosenberg for the discussions and suggestions for this document 💜 Many thanks to Roni Even, Bob Penfield, Mary Barnes, Shida Schubert and Jon Peterson for reviewing the document, and to Vijay Gurbani for the contributions to the Security Considerations section 🫶✨
Authors' Addresses 🌍
Volker Hilt
Bell Labs/Alcatel-Lucent
Lorenzstrasse 10
70435 Stuttgart
Germany
EMail: volker.hilt@bell-labs.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com📦 where this page comes from
- ietf: rfc6795 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms