RFC 3521

RFC 3521: Framework for Session Set-up with Media Authorization 🎀

• Authors: L-N. Hamer (Nortel Networks), B. Gage (Nortel Networks), and H. Shieh (AT&T Wireless) 💜
• Category: Informational 🌸
• Date: April 2003 📅
• Obsoletes / Updates: It doesn't list anything it obsoletes or updates 🦋

Status of this Memo ✨

Okay so, this memo is just here to give the Internet community some info 📚. It does not specify an Internet standard of any kind, so nobody is being told to build anything, bestie 🙈. You can share it as much as you want, distribution is unlimited 💅.

Copyright Notice 🌈

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒

Abstract 💖

Okay so, when you set up a multimedia stream, you gotta think about three things: end-to-end QoS, authorizing who's allowed to use network resources, and keeping accurate accounting of what got used 🧾. During session set-up, policies may be enforced so the media streams being requested stay inside the service profile for the requesting host 🎯. Same vibe for resources: when a host asks for resources to give a packet flow a certain QoS, policies may be enforced so those resources stay inside the resource profile for that host ✨.

To prevent fraud and make sure billing is accurate, this document walks through different scenarios and mechanisms that link everything together 🔗. The goal is to verify that the resources being used to provide a requested QoS actually match the media streams that were requested (and authorized) for the session. It's giving "check your receipts" energy 🧾💅.

Table of Contents 🍓

   1.  Introduction....................................................2
   2.  Conventions used in this document...............................3
   3.  Definition of terms.............................................4
   4.  The Coupled Model...............................................5
       4.1   Coupled Model Message Flows...............................6
       4.2   Coupled Model Authorization Token.........................8
       4.3   Coupled Model Protocol Impacts............................8
   5.  The Associated Model <<using One Policy Server>>................8
       5.1   Associated Model Message Flows
             <<using One Policy Server>>...............................9
       5.2   Associated Model Authorization Token
             <<using One Policy Server>>..............................11
       5.3   Associated Model Protocol Impacts
             <<using One Policy Server>>..............................11
       5.4   Associated Model Network Impacts
             <<using One Policy Server>>..............................12
   6.  The Associated Model <<using Two Policy Servers>>..............12
       6.1   Associated Model Message Flows
             <<using Two Policy Servers>>.............................13
       6.2   Associated Model Authorization Token
             <<using Two Policy Servers>>.............................15
       6.3   Associated Model Protocol Impacts
             <<using Two Policy Servers>>.............................16
   7. The Non-Associated Model........................................16
       7.1   Non-Associated Model Message Flow........................17
       7.2   Non-Associated Model Authorization Token.................19
       7.3   Non-Associated Model Protocol Impacts....................19
   8.  Conclusions....................................................20
   9.  Security Considerations........................................21
   10. Normative References...........................................22
   11. Informative References.........................................23
   12. Acknowledgments................................................23
   13. Authors' Addresses.............................................24
   14. Full Copyright Statement.......................................25

1. Introduction 🦋

Okay so, there are a bunch of mechanisms that let end hosts use a session management protocol (for example SIP [6]) to say "hey, I need QoS requirements met before this session can be set up" 📞. But here's the tea: a separate protocol (for example RSVP [7]) is what actually requests the resources needed to meet the end-to-end QoS of the media stream 🫶. To prevent fraud and keep billing accurate, some linkage is needed to verify that the resources being used to provide the requested QoS match the media streams that were requested (and authorized) for the session 💅.

This document describes that linkage using a "token" 🎟️. It does similar stuff to a gate in [12] and to a ticket in the push model of [10] ✨. The token is generated by a policy server (or a session management server), then it gets transparently relayed through the end host to the edge router, where it's used as part of the policy-controlled flow admission process 🔐.

In some environments, authorizing media streams can take advantage of the fact that pre-established relationships already exist between network elements (for example session management servers, edge routers, policy servers and end hosts) 🤝. Pre-established relationships assume the different network elements are configured with the identities of the other network elements and, if necessary, with security keys and so on, which they need to set up a trust relationship 🔑. But in other environments those pre-established relationships might not exist, and that can happen for a few reasons: it's too complicated to set up all those associations ahead of time (like in a network with lots of elements), different business entities are involved (like a service provider and an access provider), or the associations are super dynamic (like in a mobile environment) 📱🌀.

In this document, we go through these scenarios and the mechanisms network elements use to swap information. The point is to authorize the use of resources for a service and to coordinate actions between the session and resource management entities 🧚. Specific extensions to session management protocols (for example SIP [6] and H.323), to resource reservation protocols (for example RSVP [4] and YESSIR), and to policy management protocols (for example COPS-PR [9] and COPS-RSVP [3]) that are needed to actually make these scenarios work are out of scope for this document 🙈.

For clarity, this document illustrates the media authorization concepts using SIP for session signalling, RSVP for resource reservation, and COPS for talking to the policy servers 📚. Just know that the framework could also be applied to a multimedia services scenario that uses different signalling protocols 🌈.

2. Conventions used in this document 🎀

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 BCP 14, RFC 2119 [1] 📖. These are the official key words, so read them carefully, bestie 👑.

3. Definition of terms 🧩

Figure 1 introduces a generic model for session establishment, QoS, and policy enforcement 🗺️.

                  +-------------------------------------+   +---+
                  | SCD - Service Control Domain        |   |   |
                  | +-----------------------+ +--------+|   | I |
                  | |Session management     | |Policy  ||   | n |
                  | |server                 | |Server  ||   | t |
                  | | +---------+ +------+  | |  +----+||<->| e |
                  | | |SIP Proxy| |PEP   |<-|-|->|PDP |||   | r |
                  | | +---------+ +------+  | |  +----+||   | - |
                  | +-----------------------+ +--------+|   | c |
                  |                                     |   | o |
                  +-------------------------------------+   | n |
                                                            | n |
                  +-------------------------------------+   | e |
                  | RCD - Resource Control Domain       |   | c |
                  |                                     |   | t |
                  |                                     |   | i |
                  |  +------------+    +-------------+  |   | n |
   +----------+   |  |Edge Router |    |Policy Server|  |   | g |
   | End      |   |  |            |    |             |  |   |   |
   | Host     |   |  |+----------+|    |+----------+ |  |   | N |
   |+--------+|   |  ||RSVP Agent||    ||PDP       | |  |   | e |
   ||RSVP    ||<->|  |+----------+|<-->|+----------+ |  |<->| t |
   ||Client  ||   |  |+----------+|    |             |  |   | w |
   |+--------+|   |  || PEP      ||    |             |  |   | o |
   ||SIP User||   |  |+----------+|    |             |  |   | r |
   ||Agent   ||   |  +------------+    +-------------+  |   | k |
   |+--------+|   |                                     |   |   |
   +----------+   +-------------------------------------+   +---+

           Figure 1: Generic media authorization network model

EH - End Host: The End Host is the device a subscriber uses to access network services 📱. It has a client for requesting network services (for example through SIP) and a client for requesting network resources (for example through RSVP) 💖.

ER - Edge Router: The Edge Router is the network element that connects the end host to the rest of the Resource Control Domain 🚪. It contains a PEP to enforce policies about how the End Host uses resources in the Resource Control Domain 🔥. It also has a signalling agent (for example for RSVP) to handle resource reservation requests coming from the End Host 🦋.

PDP - Policy Decision Point: The PDP is a logical entity sitting in the Policy Server, and it's responsible for authorizing or denying access to services and/or resources 👑.

PEP - Policy Enforcement Point: The PEP is a logical entity that enforces the policy decisions the PDP makes 💅. Other PEPs may live in other network elements that aren't shown in Figure 1, but those won't be discussed in this document 🙈.

PS - Policy Server: The Policy Server is a network element that includes a PDP 🧚. There may be a PS in the Service Control Domain to control use of services, and there may be a separate PS in the Resource Control Domain to control use of resources along the packet forwarding path 🛣️. Also, network topology may require multiple Policy Servers within either Domain, but they give consistent policy decisions so it looks like there's just one PDP in each Domain 🫶✨.

RCD - Resource Control Domain: The Resource Control Domain is a logical grouping of elements that provide connectivity along the packet forwarding paths to and from an End Host 🌐. The RCD contains ER and PS entities, whose responsibilities include managing resources along those forwarding paths 💜. There may be one or more RCDs within an autonomous domain 🌸.

SCD - Service Control Domain: The Service Control Domain is a logical grouping of elements that offer applications and content to subscribers of their services 🎬. The Session Management Server lives in the SCD along with a PS 🌈. There may be one or more SCDs within an autonomous domain 💅.

SMS - Session Management Server: The Session Management Server is a network element that provides session management services (for example telephony call control) 📞. It contains a PEP to enforce policies about how the End Host uses services 🔐. It also has a signalling agent or proxy (for example for SIP) to handle service requests from the End Host 🦋.

4. The Coupled Model ✨

okay so, in some environments there's already a trust relationship set up between the network pieces (session management servers, edge routers, policy servers, and end hosts) 🫶 we call this the "coupled model" because everyone's presumed to be super tightly connected 💜 the key vibes are:

• Policy decisions, including media authorization, are made by a single Policy Server 👑
• The Edge Router, Session Management Servers and Policy Server involved in establishing the session are known a priori 🧚 like, the End Host might be set up to use a Session Management Server that belongs to the Edge Router it's plugged into 🎀
• There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS 🤝

Here's the lineup, bestie 🦋

                                                   +--------+
      +------+                                     |        |
      |      |   1     +--------------------+    2 |        |
      |      |-------->| Session Management |----->|        |
      |      |<--------|      Server        |<-----|        |
      |      |   4     +--------------------+    3 |        |
      | End  |                                     | Policy |
      | Host |                                     | Server |
      |      |                                     |        |
      |      |   5     +--------------------+   6  |        |
      |      |-------->|        Edge        |----->|        |
      |      |<--------|       Router       |<-----|        |
      |      |   8     +--------------------+    7 |        |
      +------+                                     |        |
                                                   +--------+

                        Figure 2: The Coupled Model

4.1. Coupled Model Message Flows 💅

so in this model, we assume there's one Policy Server handling both the Service Control and Resource Control Domains, and that there are pre-defined trust relationships between the PS and SMS and between the PS and ER 🔥 with that set, the entities can talk to each other like this. we only go through the originating side flows, just to keep it simple 🌸 the same ideas work for the terminating side too, periodt ✨

1. The End Host sends a session set-up request (e.g., SIP INVITE) to the Session Management Server. This tells it, among other things, which media streams the session will use 🎀 As part of this step, the End Host may authenticate itself to the Session Management Server 🙈
2. The Session Management Server, possibly after waiting for the media stream negotiation to finish, sends a policy decision request (e.g., COPS REQ) to the Policy Server to figure out whether the session set-up request should be allowed to go ahead 💖
3. The Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after tweaking the parameters of the media to be used 🍓 Included in this response is a "token" that the Policy Server can use later to recognize the session and the media it authorized 🦋
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) saying that session set-up is complete or still in progress ✨ Included in this response is a description of the negotiated media, along with the token from the Policy Server 🫶
5. The End Host sends a request (e.g., RSVP PATH) to reserve the resources it needs to give the media stream the required QoS 🔥 Included in this request is the token from the Policy Server, which came through the Session Management Server 💜
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the Policy Server to check whether the resource reservation request should be allowed to go ahead 👑 Included in this request is the token from the Policy Server that the End Host provided. The Policy Server uses this token to match the resource request with the media authorization it already gave to the Session Management Server 🧚
7. The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after tweaking the parameters of the resources to be reserved 🌈
8. The Edge Router, possibly after waiting for the end-to-end resource negotiation to finish, sends a response to the End Host (e.g., RSVP RESV) saying that resource reservation is complete or still in progress 💅✨

4.2. Coupled Model Authorization Token 🎀

in the Coupled Model, the Policy Server is the only network entity that needs to read what's inside the token 🔐 so the contents of the token are implementation dependent 🙌 and since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to make sure the token's integrity is preserved in transit 🛡️ the exact mechanisms are also implementation dependent, so it's up to the builders 💖

4.3. Coupled Model Protocol Impacts 🌸

using a media authorization token in the Coupled Model means adding new fields to several protocols 🦋 here's the tea:

• Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router 🔥 The content and internal structure (if any) of this object SHOULD be opaque to the resource reservation protocol 🫣 For example, this is achieved in RSVP with the Policy Data object defined in [8] 💜
• Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transparently transport the token from the Policy Server to the Session Management Server and from the Edge Router to the Policy Server 👑 The content and internal structure (if any) of this object SHOULD be opaque to the policy management protocol 🧚 For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8] ✨
• Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host 🎀 The content and internal structure (if any) of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]) 🍓

5. The Associated Model <<using One Policy Server>> 🦋

okay bestie, this is the scenario with a whole network of Session Management Servers, Edge Routers, and Policy Servers 🌐✨ it's so big that nobody can know the full topology, so we need a different vibe. the key tea:

• Policy decisions, including media authorization, are made by the same Policy Server for both the Session Management Server and the Edge Router. however, the Policy Server may change on a per-transaction basis, aka per policy request 💅
• The Edge Router, Session Management Server and Policy Server involved in establishing the session are not known a priori. for example, the End Host may be dynamically configured to use one of a pool of Session Management Servers, and each Session Management Server may be statically configured to use one of a pool of Policy Servers 🎀

another example: the End Host may be mobile and keep changing which Edge Router its point of attachment uses to talk to the rest of the network 🚶‍♀️💨

• There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS. 🫶

here's the picture (iconic, i know 😭):

                  +---------------------+    +---------+
                  |       SMS 'n'       |<-->|  PS 'm' |
                  +---------------------+   +--------+ |
   +------+                  : : :              |        | |
   |      |   1     +--------------------+    2 |        | |
   |      |-------->| Session Management |----->|        | |
   |      |<--------|    Server 1        |<-----|        | |
   |      |   4     +--------------------+    3 |        | |
   | End  |                                     | Policy | |
   | Host |           +--------------------+    | Server | |
   |      |           |      ER 'n'        |    |   1    | |
   |      |   5     +-+------------------+ |    |        | |
   |      |-------->|        Edge        |-+  6 |        | |
   |      |<--------|       Router       |----->|        | |
   |      |   8     +--------------------+    7 |        | |
   +------+                               <-----|        |-+
                                            +--------+

      Figure 3: The Associated Model using One Policy Server

5.1. Associated Model Message Flows <<using One Policy Server>>

okay so in this model we assume a Policy Server can make decisions for BOTH the Service Control and Resource Control Domains 🔥 and yep, the same pre-defined trust relationships: PS↔SMS and PS↔ER. these entities can totally talk to each other like this. we only walk through the originating side, because simplicity is everything 💖 the same ideas work for the terminating side too.

1. the End Host sends a session set-up request (e.g., SIP INVITE) to the Session Management Server, saying (among other things) which media streams it wants to use in the session 📞. as part of this step, the End Host may authenticate itself to the Session Management Server 🔐
2. the Session Management Server, possibly after waiting for the media stream negotiation to finish, sends a policy decision request (e.g., COPS REQ) to the Policy Server so it can figure out if the session set-up request is allowed to go ahead 🤔
3. the Policy Server sends back a decision (e.g., COPS DEC) to the Session Management Server, possibly after tweaking the parameters of the media to be used ✨. included in this response is a "token" that the Policy Server can use later to identify the session and the media it authorized 🎟️
4. the Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) saying session set-up is complete or still in progress 🌸. included is a description of the negotiated media, plus the token from the Policy Server 💌
5. the End Host sends a request (e.g., RSVP PATH) to reserve the resources needed to give the media stream its required QoS 🏋️‍♀️. included in this request is the token from the Policy Server, passed along via the Session Management Server 🔑
6. the Edge Router intercepts the reservation request and inspects the token to learn which Policy Server authorized the media 👀. then it sends a policy decision request to that Policy Server to see if the resource reservation request is allowed to proceed. included in this request is the token from the Policy Server, as provided by the End Host 🧚. the Policy Server uses that token to match the request for resources with the media authorization it gave the Session Management Server earlier, which is honestly so clever 😭
7. the Policy Server sends a decision to the Edge Router, possibly after tweaking the parameters of the resources to be reserved 🛠️
8. the Edge Router, possibly after waiting for end-to-end negotiation of resources to finish, sends a response to the End Host (e.g., RSVP RESV) saying resource reservation is complete or still going 🎉

5.2. Associated Model Authorization Token <<using One Policy Server>>

okay this part is giving SECURITY ENERGY 🛡️. since the ER doesn't know which SMS and PS are involved in session establishment, the token MUST include:

• a correlation identifier 🔗. this is info the Policy Server can use to match the resource reservation request with the media that was authorized during session set-up. the Policy Server is the only network entity that needs to read what's inside the correlation identifier, so in this model its contents are implementation dependent 🤫. because the End Host is assumed to be untrusted 🙈, the Policy Server SHOULD take measures to make sure the integrity of the correlation identifier survives transit. the exact mechanisms are also implementation dependent.
• the identity of the authorizing entity 🪪. the Edge Router uses this to figure out which Policy Server it should ask for resource policy decisions.

in some environments, an Edge Router might have no way to check whether the identity refers to a legit Policy Server inside its domain 😬. so to protect against authorization requests getting redirected to a bogus authorizing entity, the token SHOULD also include:

• authentication data 🔏. this is calculated over all the other fields of the token using an agreed mechanism. the mechanism the Edge Router uses is beyond the scope of this document 🙃

the detailed semantics of an authorization token are defined in [4]. 📚

5.3. Associated Model Protocol Impacts <<using One Policy Server>>

this version of the Associated Model needs new fields in several protocols, so buckle up 🎢:

• Resource reservation protocol. a new protocol field or object MUST be added to the resource reservation protocol to transparently carry the token from the End Host to the Edge Router 🚚. its content and internal structure MUST be specified so the Edge Router can tell apart the elements of the token described in Section 5.2 🧩. for example, RSVP does this with the Policy Data object defined in [8].
• Policy management protocol. a new protocol field or object MUST be added to the policy management protocol to transparently carry the token (or at least the correlation identifier) from the Edge Router to the Policy Server 📨. its content and internal structure SHOULD be opaque to the policy management protocol. for example, COPS-RSVP does this with the Policy Data object defined in [8].
• Session management protocol. a new protocol field or object MUST be added to the session management protocol to transparently carry the media authorization token from the Session Management Server to the End Host 💬. its content and internal structure SHOULD be opaque to the session management protocol (e.g., SIP [6]).

5.4. Associated Model Network Impacts <<using One Policy Server>>

this version needs the Edge Router to inspect the token to learn which Policy Server authorized the media 🔍. in some environments that might just not be possible for the Edge Router 😩. in those cases, an Associated Model using Two Policy Servers (section 6) is required 🌟.

this version also means the Edge Router has to talk to multiple Policy Servers 📞📞. policy decisions are made by the same Policy Server for both the Session Management Server and the Edge Router, but the Policy Server may change on a per-transaction basis. note that the COPS framework doesn't currently let PEPs change PDP on a per-transaction basis 🙅‍♀️. to use this model, a new framework has to be defined for policy decision outsourcing. this model also implies that the Policy Servers can interact and/or make decisions for the Edge Router in a consistent manner (e.g., as though there is only a single RCD Policy Server) 🧠. how that gets done is beyond the scope of this document, bestie 💜

6. The Associated Model <<using Two Policy Servers>> 🦋

okay so this scenario is giving big network energy 🌐✨ There are multiple instances of the Session Management Servers, Edge Routers and Policy Servers floating around, and it gets so complicated that nobody can possibly know the whole network topology 😭 Like, no single entity gets to hold all that knowledge, bestie.

The key vibes of this scenario:

• Policy decisions, including media authorization, are made by Policy Servers. 👑
• There is a PS in the Resource Control Domain that is separate from the PS in the Service Control Domain. 🎀
• The Edge Router, Session Management Server and Policy Servers involved in setting up a session are not known ahead of time. For example, the End Host might be dynamically configured to use one of a pool of Session Management Servers, or the End Host might be mobile and keep switching which Edge Router it uses to talk to the rest of the network 🧚
• There is a pre-defined trust relationship between the SMS and the SCD PS. 🫶
• There is a pre-defined trust relationship between the ER and the RCD PS. 🫶
• There is a pre-defined trust relationship between the RCD and SCD Policy Servers. 🫶

                  +--------------------+    +--------+
   +------+       |       SMS `n'      |    |        |
   |      |   1   +-+------------------+ |    |  SCD   |
   |      |-------->| Session Management |-+  2 | Policy |
   |      |<--------|      Server        |----->| Server |
   |      |   4     +--------------------+<-----|        |
   | End  |                                   3 +--------+
   |      |                                      7 ^  |
   | Host |           +--------------------+       |  v 8
   |      |           |       ER 'n'       |    +--------+
   |      |   5     +-+------------------+ |    |        |
   |      |-------->|        Edge        |-+  6 |  RCD   |
   |      |<--------|       Router       |----->| Policy |
   |      |   10    +--------------------+<--- -| Server |
   +------+                                   9 |        |
                                                +--------+

Figure 4: The Associated Model using Two Policy Servers 📊

6.1. Associated Model Message Flows <<using Two Policy Servers>> 💌

okay so in this model we assume there is one Policy Server for the Service Control Domain and a different one for the Resource Control Domain. There are pre-defined trust relationships between the SCD PS and SMS, between the RCD PS and ER, and between the RCD and SCD Policy Servers, and that's what makes all the communication possible. We only describe the originating side flows to keep things simple, and the same ideas apply to the terminating side 💅

1. The End Host sends a session set-up request (e.g., SIP INVITE) to the Session Management Server, telling it, among other things, which media streams it wants to use in the session. As part of this step, the End Host may authenticate itself to the Session Management Server. 🔐
2. The Session Management Server, possibly after waiting for the media streams to finish negotiating, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server to check whether the session set-up request should be allowed to go ahead. 🤔
3. The SCD Policy Server sends a decision (e.g., COPS DEC) back to the Session Management Server, possibly after tweaking the parameters of the media to be used. This response includes a "token" that the SCD Policy Server can later use to identify the session and the media it authorized. 🎟️
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) saying that session set-up is complete or still in progress. This response includes a description of the negotiated media along with the token from the SCD Policy Server. 💖
5. The End Host sends a request (e.g., RSVP PATH) to reserve the resources needed to provide the required QoS for the media stream. This request includes the token from the SCD Policy Server, which came through the Session Management Server. 🙌
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server to check whether the resource reservation request should be allowed to go ahead. This request includes the token from the SCD Policy Server, which the End Host provided. 👀
7. The RCD Policy Server uses this token to figure out which SCD Policy Server authorized the media. It then sends an authorization request [11] to that SCD Policy Server to check whether the resource reservation request should be allowed to go ahead. This request includes the token from the SCD Policy Server, which the End Host provided. 🕵️‍♀️
8. The SCD Policy Server uses this token to match the resource request with the media authorization it previously gave to the Session Management Server. It then sends a decision [11] to the RCD Policy Server on whether the requested resources fall within the bounds it authorized. 🧠
9. The RCD Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after tweaking the parameters of the resources to be reserved. 🛠️
10. The Edge Router, possibly after waiting for end-to-end negotiation of the resources to finish, sends a response to the End Host (e.g., RSVP RESV) saying that resource reservation is complete or still in progress. 🎉

6.2. Associated Model Authorization Token <<using Two Policy Servers>> 🪙

okay so the RCD Policy Server doesn't know which SMS and SCD PS are involved in setting up the session, which means the token MUST include:

• A correlation identifier. This is info the SCD Policy Server can use to match the resource reservation request with the media that got authorized during session set-up. The SCD Policy Server is the only entity that needs to interpret what's inside the correlation identifier, so in this model its contents are implementation dependent. Since the End Host is assumed to be untrusted, the SCD Policy Server SHOULD take measures to make sure the integrity of the correlation identifier is preserved in transit. The exact mechanisms to use are also implementation dependent. 🔑
• The identity of the authorizing entity. The RCD Policy Server uses this to figure out which SCD Policy Server should be used to verify the contents of the resource reservation request. 🆔

In some environments, an RCD Policy Server may have no way of telling whether the identity refers to a legitimate SCD Policy Server. To protect against authorization requests being redirected to a bogus authorizing entity, the token SHOULD include:

• Authentication data. This is calculated over all the other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is out of scope for this document. 🔏

Note that the information in this token is the same as in Section 5.2 for the "One Policy Server" scenario. 💕

The detailed semantics of an authorization token are defined in [4]. 📚

6.3. Associated Model Protocol Impacts <<using Two Policy Servers>> ⚙️

okay so using a media authorization token in this version of the Associated Model means adding new fields to several protocols:

• Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently carry the token from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, RSVP does this with the Policy Data object defined in [8]. 🎁
• Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to carry the token from the SCD Policy Server to the Session Management Server, and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can tell apart the elements of the token described in Section 6.2. For example, COPS-RSVP does this with the Policy Data object defined in [8]. 🧩
• Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently carry the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]). 🦄

Note that these impacts are the same as the ones discussed in Section 5.3 for the "One Policy Server" scenario. However, using two Policy Servers adds one more impact:

• Authorization protocol. A new protocol field or object MUST be added to the authorization protocol to carry the token from the RCD Policy Server to the SCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can tell apart the elements of the token described in Section 6.2. 🌟

7. The Non-Associated Model ✨

okay so this one is the most independent-girl scenario ever 💅 The Session Management Servers and Edge Routers each hang out with a different Policy Server, the network entities don't know the topology a priori 🙈, and there are no pre-established trust relationships between the Resource Control Domain and the Service Control Domain. the key vibes:

• Policy decisions, including media authorization, are made by Policy Servers. 🔥
• The PS in the Resource Control Domain is separate from the PS in the Service Control Domain. 🌸
• There is a pre-defined trust relationship between the SMS and the SCD PS. 🫶
• There is a pre-defined trust relationship between the ER and the RCD PS. 💜
• There are no pre-defined trust relationships between the ER and SMS or between the RCD and SCD Policy Servers. 💀

                                            +--------+
+------+                                    |        |
|      |   1     +--------------------+   2 |  SCD   |
|      |-------->| Session Management |---->| Policy |
|      |<--------|      Server        |<----| Server |
|      |   4     +--------------------+   3 |        |
| End  |                                    +--------+
| Host |
|      |                                    +--------+
|      |   5     +--------------------+  6  |        |
|      |-------->|        Edge        |---->|  RCD   |
|      |<--------|       Router       |<----| Policy |
|      |   8     +--------------------+  7  | Server |
+------+                                    |        |
                                            +--------+

Figure 5: The Non-Associated Model 🦋

7.1. Non-Associated Model Message Flow

so in this model, the policy servers each make their own independent calls for their own domains 🧚. that means no need for them to swap info with each other, and it still works when the policy servers can't talk to each other for whatever reason. it can also be used to speed up session setup while still making sure proper authorization happens ⭐

policy servers can still chat at other times for other stuff (like swapping accounting info) 💅

here's the flow for how the entities talk to each other. only the originating side is shown to keep it simple, but the same ideas apply to the terminating side 🎀

1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server, telling it (among other things) which media streams will be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server. 🌈
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server to figure out whether the session set-up request should be allowed to proceed. 🧠
3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can later be used by the RCD Policy Server to determine what media has been authorized. 🍓
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) saying that session set-up is complete or still in progress. Included in this response is a description of the negotiated media, along with the token from the SCD Policy Server. 🫶
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources needed to provide the required QoS for the media stream. Included in this request is the token from the SCD Policy Server, passed along via the Session Management Server. ✨
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server to figure out whether the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server, which the End Host provided. 👑
7. The RCD Policy Server uses this token to pull out information about the media that the SCD Policy Server authorized. It then uses that info to decide whether the resource reservation should be allowed to proceed. 🔍

The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved. 💖

8. The Edge Router, possibly after waiting for end-to-end negotiation of the resources to be completed, sends a response to the End Host (e.g., RSVP RESV) saying that the resource reservation is complete or still in progress 🌟

7.2. Non-Associated Model Authorization Token

in this model, the token MUST contain enough info for the RCD Policy Server to make resource policy decisions on its own, without needing the SCD Policy Server 🫶 the token gets built from info about the session that the SMS received. the info in the token MUST include:

• Calling party name or IP address (e.g., from SDP "c=" parameter). 📞
• Called party name or IP address (e.g., from SDP "c=" parameter). 📱
• The characteristics of (each of) the media stream(s) authorized for this session (e.g., codecs, maximum bandwidth from SDP "m=" and/or "b=" parameters). 🎶
• The authorization lifetime. To protect against replay attacks, the token should be valid for only a few seconds after the start time of the session. 🛡️
• The identity of the authorizing entity, so the token can be validated. 🪪
• Authentication data used to prevent tampering with the token. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is beyond the scope of this document. 🔐

the token has a bunch of must-haves, so don't skip any of the fields above when you build one 😭

Furthermore, the token MAY include:

• The lifetime of (each of) the media stream(s) (e.g., from SDP "t=" parameter). This field may be useful in pre-paid scenarios to limit the lifetime of the session. 💸
• The Calling and called party port numbers (e.g., from the "m=" parameter). 🔢

The detailed semantics of an authorization token are defined in [4]. 📖

7.3. Non-Associated Model Protocol Impacts

using a media authorization token in the Non-Associated Model means adding new fields to several protocols, so let's see who needs what 🧩

• Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol so the token can ride transparently from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, RSVP does this with the Policy Data object defined in [8]. 🎀
• Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to carry the token from the SCD Policy Server to the Session Management Server, and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so the Policy Servers can tell apart the elements of the token described in Section 7.2. For example, COPS-RSVP does this with the Policy Data object defined in [8]. 🧁
• Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently carry the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]). 🦋

8. Conclusions

---

this document defines three models for session set-up with media authorization 💜

• The Coupled Model, which assumes a priori knowledge of the network topology and where pre-established trust relationships exist between network entities. 🔗
• The Associated Model, where there are common or trusted policy servers but the network topology isn't known a priori. 🤝
• The Non-Associated Model, where the network topology isn't known a priori, different policy servers are involved, and no trust relationship exists between the policy servers. 🌍

the Associated Model is for environments where the network elements involved in setting up a session already have a pre-determined trust relationship, but their identities have to be figured out dynamically during session set-up 🪄 the Non-Associated Model is for environments with a complex network topology and/or where trust relationships between domains don't exist (e.g., when they're different business entities) 🏢

in any given network, one or more of these models might apply 🌷 the model can even be picked dynamically during session establishment, based on what's known about the end points in the call. either way, the End Host and the Session Management Server never need to understand or interpret the authorization token. to them it's an opaque protocol element that just gets copied from one container protocol to another 📦✨

and finally, the framework in this document can be extended to any kind of session management protocol coupled to any one of a number of resource reservation and/or policy management protocols 🌈

9. Security Considerations 🔒✨

Okay bestie, security is where things get serious 😭. This section is about a mechanism for media authorization that stops people from stealing service 🕵️‍♀️💅. For the authorization token to actually work, its integrity MUST be guaranteed as it travels through untrusted network entities like the End Host. Authentication data can do that job 🔐. The token doesn't need encryption, though, because it doesn't hold any confidential information that a bad actor could use 🙅‍♀️.

This document assumes trust relationships already exist between the different network entities, as described in each of the models 🫶. How those relationships get set up is out of scope here, so that's a different story 📖.

The interfaces between the network entities don't all have the same needs, so they need different security characteristics 🎀:

• The edge router and the RCD policy server MUST have a trust relationship 💜. If needed, that relationship can be locked down with a formal security association [14].
• The network policies exchanged over the interface between the edge router and the RCD policy server SHOULD be integrity protected 🛡️. You can do this with integrity mechanisms built into the policy control protocol (for example, the Integrity object in COPS [2]) or with generic IP security mechanisms [14].
• The SCD and RCD policy servers MUST have a trust relationship in the associated model 🤝. If needed, that relationship can be enforced with a formal security association [14].
• The information exchanged between policy servers SHOULD be integrity protected 🔏. This can be handled by integrity mechanisms built into the policy exchange protocol [2] or by generic IP security mechanisms [14].
• The end host SHOULD be authenticated by the RCD so nobody can pull off identity theft 🥸. Network resource requests and responses need protection against corruption and spoofing too, so the interface between the host and the edge router SHOULD provide integrity and authentication of messages 💖. For example, [13] provides integrity and authentication of RSVP messages ✨.
• The end host SHOULD be authenticated by the SCD to protect against identity theft 🙈. Session setup requests and responses need protection against corruption and spoofing as well, so the interface between the host and the SMS SHOULD provide integrity and authentication of messages 🧚.
• The SMS and the SCD policy server MUST have a trust relationship 👑. If needed, that relationship can be enforced with a formal security association [14].
• The network policies exchanged over the interface between the SMS and the SCD policy server SHOULD be integrity protected 🌈. This can be done with integrity mechanisms built into the policy control protocol (for example, the Integrity object in COPS [2]) or with generic IP security mechanisms [14].

---

10. Normative References 📚

Here are the normative references, the must-reads 🤓:

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

[2]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
     Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
     2748, January 2000.

[3]  Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A.
     Sastry, "COPS usage for RSVP", RFC 2749, January 2000.

[4]  Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
     Authorization Policy Element", RFC 3520, April 2003.

[5]  Handley, M. and V. Jacobson, "SDP: session description
     protocol," RFC 2327, April 1998.

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

[7]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
     "Resource ReSerVation protocol (RSVP) --  version 1 functional
     specification," RFC 2205, September 1997.

[8]  Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
     January 2000.

[9]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
     Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
     Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.

---

11. Informative References 💭

And these are the informative ones, the extra reading for the curious 🧐🌸:

[10] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
     G., de Bruijn, B., de Laat, C., Holdrege, M. and P. Spence, "AAA
     Authorization Framework", RFC 2904, August 2000.

[11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D.
     Spence, "Generic AAA Architecture", RFC 2903, August 2000.

[12] "PacketCable Dynamic Quality of Service Specification",
     CableLabs, December 1999.

[13] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
     Authentication", RFC 2747, January 2000.

[14] Kent, S. and R. Atkinson, "Security Architecture for the
     Internet Protocol", RFC 2401, November 1998.

---

12. Acknowledgments 🫶

Big thank-yous to everyone who helped out with useful comments and suggestions on this document 🥰: Kwok Ho Chan, Doug Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois Audet, Bill Marshall, Diana Rawlins and many others 💕✨.

---

13. Authors' Addresses 🏡

Here's where the authors can be found 📬:

Louis-Nicolas Hamer
Nortel Networks
PO Box 3511 Station C
Ottawa, ON
CANADA K1Y 4H7

Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com


Bill Gage
Nortel Networks
PO Box 3511 Station C
Ottawa, ON
CANADA K1Y 4H7

Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com


Hugh Shieh
AT&T Wireless
7277 164th Avenue NE
Redmond, WA
USA 98073-9761

Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com

---

14. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💜🎀.