GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3521

Network Working Group L-N. Hamer Request for Comments: 3521 B. Gage Category: Informational Nortel Networks

                                                              H. Shieh
                                                         AT&T Wireless
                                                            April 2003
       Framework for Session Set-up with Media Authorization

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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

Abstract

 Establishing multimedia streams must take into account requirements
 for end-to-end QoS, authorization of network resource usage and
 accurate accounting for resources used.  During session set up,
 policies may be enforced to ensure that the media streams being
 requested lie within the bounds of the service profile established
 for the requesting host.  Similarly, when a host requests resources
 to provide a certain QoS for a packet flow, policies may be enforced
 to ensure that the required resources lie within the bounds of the
 resource profile established for the requesting host.
 To prevent fraud and to ensure accurate billing, this document
 describes various scenarios and mechanisms that provide the linkage
 required to verify that the resources being used to provide a
 requested QoS are in-line with the media streams requested (and
 authorized) for the session.

Hamer, et al. Informational [Page 1] RFC 3521 Session Set-up with Media Authorization April 2003

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

 Various mechanisms have been defined through which end hosts can use
 a session management protocol (e.g., SIP [6]) to indicate that QoS
 requirements must be met in order to successfully set up a session.
 However, a separate protocol (e.g., RSVP [7]) is used to request the
 resources required to meet the end-to-end QoS of the media stream.
 To prevent fraud and to ensure accurate billing, some linkage is

Hamer, et al. Informational [Page 2] RFC 3521 Session Set-up with Media Authorization April 2003

 required to verify that the resources being used to provide the
 requested QoS are in-line with the media streams requested (and
 authorized) for the session.
 This document describes such a linkage through use of a "token" that
 provides capabilities similar to that of a gate in [12] and of a
 ticket in the push model of [10].  The token is generated by a policy
 server (or a session management server) and is transparently relayed
 through the end host to the edge router where it is used as part of
 the policy-controlled flow admission process.
 In some environments, authorization of media streams can exploit the
 fact that pre-established relationships exist between elements of the
 network (e.g., session management servers, edge routers, policy
 servers and end hosts).  Pre-established relationships assume that
 the different network elements are configured with the identities of
 the other network elements and, if necessary, are configured with
 security keys, etc. required to establish a trust relationship.  In
 other environments, however, such pre-established relationships may
 not exist either due to the complexity of creating these associations
 a priori (e.g., in a network with many elements), or due to the
 different business entities involved (e.g., service provider and
 access provider), or due to the dynamic nature of these associations
 (e.g., in a mobile environment).
 In this document, we describe these various scenarios and the
 mechanisms used for exchanging information between network elements
 in order 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 (e.g.,
 SIP [6], H.323), to resource reservation protocols (e.g., RSVP [4],
 YESSIR) and to policy management protocols (e.g., COPS-PR [9], COPS-
 RSVP [3]) required to realize these scenarios and mechanisms are
 beyond the scope of this document.
 For clarity, this document will illustrate the media authorization
 concepts using SIP for session signalling, RSVP for resource
 reservation and COPS for interaction with the policy servers.  Note,
 however, that the framework could be applied to a multimedia services
 scenario using 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].

Hamer, et al. Informational [Page 3] RFC 3521 Session Set-up with Media Authorization April 2003

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 a device used by a subscriber to
 access network services.  The End Host includes a client for
 requesting network services (e.g., through SIP) and a client for
 requesting network resources (e.g., through RSVP).
 ER - Edge Router: The Edge Router is a network element connecting the
 end host to the rest of the Resource Control Domain.  The Edge Router
 contains a PEP to enforce policies related to resource usage in the
 Resource Control Domain by the End Host.  It also contains a
 signalling agent (e.g., for RSVP) for handling resource reservation
 requests from the End Host.

Hamer, et al. Informational [Page 4] RFC 3521 Session Set-up with Media Authorization April 2003

 PDP - Policy Decision Point: The PDP is a logical entity located in
 the Policy Server that is responsible for authorizing or denying
 access to services and/or resources.
 PEP - Policy Enforcement Point: The PEP is a logical entity that
 enforces policy decisions made by the PDP.  Note that other PEPs may
 reside in other network elements not shown in the model of Figure 1,
 however they will not be discussed in this document.
 PS - Policy Server: The Policy Server is a network element that
 includes a PDP.  Note that 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.  Note also that network topology may require
 multiple Policy Servers within either Domain, however they provide
 consistent policy decisions to offer the appearance of a single 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 management of
 resources along the packet forwarding paths.  Note that 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 resides
 in the SCD along with a PS.  Note that there may be one or more SCDs
 within an autonomous domain.
 SMS - Session Management Server: The Session Management Server is a
 network element providing session management services (e.g.,
 telephony call control).  The Session Management Server contains a
 PEP to enforce policies related to use of services by the End Host.
 It also contains a signalling agent or proxy (e.g., for SIP) for
 handling service requests from the End Host.

4. The Coupled Model

 In some environments, a pre-established trust relationship exists
 between elements of the network (e.g., session management servers,
 edge routers, policy servers and end hosts).  We refer to this as the
 "coupled model", indicating the tight relationship between entities
 that is presumed.  The key aspects of this scenario are the
 following:

Hamer, et al. Informational [Page 5] RFC 3521 Session Set-up with Media Authorization April 2003

  1. Policy decisions, including media authorization, are made by a

single Policy Server.

  1. The Edge Router, Session Management Servers and Policy Server

involved in establishing the session are known a priori. For

    example, the End Host may be configured to use a Session
    Management Server associated with the Edge Router to which the EH
    is connected.
  1. There are pre-defined trust relationships between the SMS and the

PS and between the ER and the PS.

                                                 +--------+
    +------+                                     |        |
    |      |   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

 In this model, it is assumed that there is one Policy Server serving
 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.  Communications between these entities are
 then possible as described below.  Only the originating side flows
 are described for simplicity.  The same concepts apply to the
 terminating side.
 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
    the Session Management Server indicating, among other things, the
    media streams to be used in the session.  As part of this step,
    the End Host may authenticate itself to the Session Management
    Server.

Hamer, et al. Informational [Page 6] RFC 3521 Session Set-up with Media Authorization April 2003

 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 Policy Server in order to
    determine if the session set-up request should be allowed to
    proceed.
 3. The 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
    subsequently be used by the Policy Server to identify the session
    and the media it has authorized.
 4. The Session Management Server sends a response to the End Host
    (e.g., SIP 200 or 183) indicating that session set-up is complete
    or is progressing.  Included in this response is a description of
    the negotiated media along with the token from the Policy Server.
 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
    resources necessary to provide the required QoS for the media
    stream.  Included in this request is the token from the Policy
    Server provided 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 Policy Server in
    order to determine if the resource reservation request should be
    allowed to proceed.  Included in this request is the token from
    the Policy Server provided by the End Host.  The Policy Server
    uses this token to correlate the request for resources with the
    media authorization previously provided to the Session Management
    Server.
 7. 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
    for resources to be completed, sends a response to the End Host
    (e.g., RSVP RESV) indicating that resource reservation is complete
    or is progressing.

Hamer, et al. Informational [Page 7] RFC 3521 Session Set-up with Media Authorization April 2003

4.2 Coupled Model Authorization Token

 In the Coupled Model, the Policy Server is the only network entity
 that needs to interpret the contents of the token.  Therefore, in
 this model, the contents of the token are implementation dependent.
 Since the End Host is assumed to be untrusted, the Policy Server
 SHOULD take measures to ensure that the integrity of the token is
 preserved in transit; the exact mechanisms to be used are also
 implementation dependent.

4.3 Coupled Model Protocol Impacts

 The use of a media authorization token in the Coupled Model requires
 the addition of new fields to several protocols:
  1. 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].
  1. 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].
  1. 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»

 In this scenario, there are multiple instances of the Session
 Management Servers, Edge Routers and Policy Servers.  This leads to a
 network of sufficient complexity that it precludes distributing
 knowledge of network topology to all network entities.  The key
 aspects of this scenario are the following:

Hamer, et al. Informational [Page 8] RFC 3521 Session Set-up with Media Authorization April 2003

  1. 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, i.e., on a per policy request basis.
  1. 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 of the Session
    Management Servers may be statically configured to use one of a
    pool of Policy Servers.
    In another example, the End Host may be mobile and continually
    changing the Edge Router that its point of attachment uses to
    communicate with the rest of the network.
  1. There are pre-defined trust relationships between the SMS and the

PS and between the ER and the PS.

                    +---------------------+    +---------+
                    |       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»

 In this model, it is assumed that a Policy Server can make decisions
 for 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.  Communications between these entities are
 then possible as described below.  Only the originating side flows
 are described for simplicity.  The same concepts apply to the
 terminating side.

Hamer, et al. Informational [Page 9] RFC 3521 Session Set-up with Media Authorization April 2003

 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
    the Session Management Server indicating, among other things, the
    media streams to 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 Policy Server in order to
    determine if the session set-up request should be allowed to
    proceed.
 3. The 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
    subsequently be used by the Policy Server to identify the session
    and the media it has authorized.
 4. The Session Management Server sends a response to the End Host
    (e.g., SIP 200 or 183) indicating that session set-up is complete
    or is progressing.  Included in this response is a description of
    the negotiated media along with the token from the Policy Server.
 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
    resources necessary to provide the required QoS for the media
    stream.  Included in this request is the token from the Policy
    Server provided 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.  It
    then sends a policy decision request to that Policy Server in
    order to determine if the resource reservation request should be
    allowed to proceed.  Included in this request is the token from
    the Policy Server provided by the End Host.  The Policy Server
    uses this token to correlate the request for resources with the
    media authorization previously provided to the Session Management
    Server.
 7. The Policy Server sends a decision 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
    for resources to be completed, sends a response to the End Host
    (e.g., RSVP RESV) indicating that resource reservation is complete
    or is progressing.

Hamer, et al. Informational [Page 10] RFC 3521 Session Set-up with Media Authorization April 2003

5.2 Associated Model Authorization Token «using One Policy Server»

 Since the ER does not know which SMS and PS are involved in session
 establishment, the token MUST include:
  1. A correlation identifier. This is information that the Policy

Server can use to correlate the resource reservation request with

    the media authorized during session set up.  The Policy Server is
    the only network entity that needs to interpret the contents of
    the correlation identifier therefore, in this model, the contents
    of the correlation identifier are implementation dependent.  Since
    the End Host is assumed to be untrusted, the Policy Server SHOULD
    take measures to ensure that the integrity of the correlation
    identifier is preserved in transit; the exact mechanisms to be
    used are also implementation dependent.
  1. The identity of the authorizing entity. This information is used

by the Edge Router to determine which Policy Server should be used

    to solicit resource policy decisions.
 In some environments, an Edge Router may have no means for
 determining if the identity refers to a legitimate Policy Server
 within its domain.  In order to protect against redirection of
 authorization requests to a bogus authorizing entity, the token
 SHOULD also include:
  1. Authentication data. This authentication data is calculated over

all other fields of the token using an agreed mechanism. The

    mechanism used by the Edge Router 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»

 The use of a media authorization token in this version of the
 Associated Model requires the addition of new fields to several
 protocols:
  1. 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 of this object MUST be
    specified so that the Edge Router can distinguish between the
    elements of the token described in Section 5.2.  For example, this
    is achieved in RSVP with the Policy Data object defined in [8].

Hamer, et al. Informational [Page 11] RFC 3521 Session Set-up with Media Authorization April 2003

  1. Policy management protocol. A new protocol field or object MUST

be added to the policy management protocol to transparently

    transport the token -- or at least the correlation identifier --
    from the Edge Router to the Policy Server.  The content and
    internal structure 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].
  1. 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 of this object SHOULD be opaque to the session
    management protocol (e.g., SIP [6]).

5.4 Associated Model Network Impacts «using One Policy Server»

 The use of a media authorization token in this version of the
 Associated Model requires that the Edge Router inspect the token to
 learn which Policy Server authorized the media.  In some
 environments, it may not be possible for the Edge Router to perform
 this function; in these cases, an Associated Model using Two Policy
 Servers (section 6) is required.
 This version of the Associated Model also requires that the Edge
 Router interact with multiple Policy Servers.  Policy decisions are
 made by the same Policy Server for both the Session Management Server
 and the Edge Router, however the Policy Server may change on per-
 transaction basis.  Note that the COPS framework does not currently
 allow PEPs to change PDP on a per-transaction basis.  To use this
 model, a new framework must be defined for policy decision
 outsourcing.  This model also implies that the Policy Servers are
 able to 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 this is accomplished is beyond the scope of this
 document.

6. The Associated Model «using Two Policy Servers»

 In this scenario, there are multiple instances of the Session
 Management Servers, Edge Routers and Policy Servers.  This leads to a
 network of sufficient complexity that it precludes distributing
 knowledge of network topology to all network entities.  The key
 aspects of this scenario are the following:
  1. Policy decisions, including media authorization, are made by

Policy Servers.

Hamer, et al. Informational [Page 12] RFC 3521 Session Set-up with Media Authorization April 2003

  1. There is a PS in the Resource Control Domain that is separate from

the PS in the Service Control Domain.

  1. The Edge Router, Session Management Server and Policy Servers

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 or the End Host may be mobile
    and continually changing the Edge Router that it uses to
    communicate with the rest of the network.
  1. There is a pre-defined trust relationship between the SMS and the

SCD PS.

  1. There is a pre-defined trust relationship between the ER and the

RCD PS.

  1. 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»

 In this model, it is assumed that there is one Policy Server for the
 Service Control Domain and a different Policy Server 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.  Communications between these entities are then
 possible as described below.  Only the originating side flows are
 described for simplicity.  The same concepts apply to the terminating
 side.

Hamer, et al. Informational [Page 13] RFC 3521 Session Set-up with Media Authorization April 2003

 1.  The End Host issues a session set-up request (e.g., SIP INVITE)
     to the Session Management Server indicating, among other things,
     the media streams to 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 in
     order to determine if 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 subsequently be used by the SCD Policy Server
     to identify the session and the media it has authorized.
 4.  The Session Management Server sends a response to the End Host
     (e.g., SIP 200 or 183) indicating that session set-up is complete
     or is progressing.  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 necessary to provide the required QoS for the media
     stream.  Included in this request is the token from the SCD
     Policy Server provided 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
     in order to determine if the resource reservation request should
     be allowed to proceed.  Included in this request is the token
     from the SCD Policy Server provided by the End Host.
 7.  The RCD Policy Server uses this token to learn which SCD Policy
     Server authorized the media.  It then sends an authorization
     request [11] to that SCD Policy Server in order to determine if
     the resource reservation request should be allowed to proceed.
     Included in this request is the token from the SCD Policy Server
     provided by the End Host.
 8.  The SCD Policy Server uses this token to correlate the request
     for resources with the media authorization previously provided to
     the Session Management Server.  The SCD Policy Server sends a
     decision [11] to the RCD Policy Server on whether the requested
     resources are within the bounds authorized by the SCD Policy
     Server.

Hamer, et al. Informational [Page 14] RFC 3521 Session Set-up with Media Authorization April 2003

 9.  The RCD Policy Server sends a decision (e.g., COPS DEC) to the
     Edge Router, possibly after modifying the parameters of the
     resources to be reserved.
 10. The Edge Router, possibly after waiting for end-to-end
     negotiation for resources to be completed, sends a response to
     the End Host (e.g., RSVP RESV) indicating that resource
     reservation is complete or is progressing

6.2 Associated Model Authorization Token «using Two Policy Servers»

 Since the RCD Policy Server does not know which SMS and SCD PS are
 involved in session establishment, the token MUST include:
  1. A correlation identifier. This is information that the SCD Policy

Server can use to correlate the resource reservation request with

    the media authorized during session set up.  The SCD Policy Server
    is the only network entity that needs to interpret the contents of
    the correlation identifier therefore, in this model, the contents
    of the correlation identifier are implementation dependent.  Since
    the End Host is assumed to be untrusted, the SCD Policy Server
    SHOULD take measures to ensure that the integrity of the
    correlation identifier is preserved in transit; the exact
    mechanisms to be used are also implementation dependent.
  1. The identity of the authorizing entity. This information is used

by the RCD Policy Server to determine 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 means for
 determining if the identity refers to a legitimate SCD Policy Server.
 In order to protect against redirection of authorization requests to
 a bogus authorizing entity, the token SHOULD include:
  1. Authentication data. 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.
 Note that the information in this token is the same as that in
 Section 5.2 for the "One Policy Server" scenario.
 The detailed semantics of an authorization token are defined in [4].

Hamer, et al. Informational [Page 15] RFC 3521 Session Set-up with Media Authorization April 2003

6.3 Associated Model Protocol Impacts «using Two Policy Servers»

 The use of a media authorization token in this version of the
 Associated Model requires the addition of new fields to several
 protocols:
  1. 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 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].
  1. Policy management protocol. A new protocol field or object MUST

be added to the policy management protocol to transport 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 distinguish between the elements of the token
    described in Section 6.2.  For example, this is achieved in COPS-
    RSVP with the Policy Data object defined in [8].
  1. 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 of this object SHOULD be opaque to the session
    management protocol (e.g., SIP [6]).
 Note that these impacts are the same as those discussed in Section
 5.3 for the "One Policy Server" scenario.  However the use of two
 Policy Servers has one additional impact:
  1. Authorization protocol. A new protocol field or object MUST be

added to the authorization protocol to transport 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 distinguish between the elements of the token
    described in Section 6.2.

7. The Non-Associated Model

 In this scenario, the Session Management Servers and Edge Routers are
 associated with different Policy Servers, the network entities do not
 have a priori knowledge of the topology of the network and there are
 no pre-established trust relationships between entities in the
 Resource Control Domain and entities in the Service Control Domain.
 The key aspects of this scenario are the following:

Hamer, et al. Informational [Page 16] RFC 3521 Session Set-up with Media Authorization April 2003

  1. Policy decisions, including media authorization, are made by

Policy Servers.

  1. The PS in the Resource Control Domain is separate from the PS in

the Service Control Domain.

  1. There is a pre-defined trust relationship between the SMS and the

SCD PS.

  1. There is a pre-defined trust relationship between the ER and the

RCD PS.

  1. 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

 In this model it is assumed that the policy servers make independent
 decisions for their respective domains, obviating the need for
 information exchange between policy servers.  This model also enables
 session authorization when communication between policy servers is
 not possible for various reasons.  It may also be used as a means to
 speed up session setup and still ensure proper authorization is
 performed.
 This model does not preclude the possibility that the policy servers
 may communicate at other times for other purposes (e.g., exchange of
 accounting information).

Hamer, et al. Informational [Page 17] RFC 3521 Session Set-up with Media Authorization April 2003

 Communications between network entities in this model is described
 below.  Only the originating side flows are described for simplicity.
 The same concepts apply to the terminating side.
 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
    the Session Management Server indicating, among other things, the
    media streams to 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 in
    order to determine if 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 subsequently 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) indicating that session set-up is complete
    or is progressing.  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 necessary to provide the required QoS for the media
    stream.  Included in this request is the token from the SCD Policy
    Server provided 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
    in order to determine if the resource reservation request should
    be allowed to proceed.  Included in this request is the token from
    the SCD Policy Server provided by the End Host.
 7. The RCD Policy Server uses this token to extract information about
    the media that was authorized by the SCD Policy Server.  The RCD
    Policy Server uses this information in making its decision on
    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.

Hamer, et al. Informational [Page 18] RFC 3521 Session Set-up with Media Authorization April 2003

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

7.2 Non-Associated Model Authorization Token

 In this model, the token MUST contain sufficient information to allow
 the RCD Policy Server to make resource policy decisions autonomously
 from the SCD Policy Server.  The token is created using information
 about the session received by the SMS.  The information in the token
 MUST include:
  1. Calling party name or IP address (e.g., from SDP "c=" parameter).
  1. Called party name or IP address (e.g., from SDP "c=" parameter).
  1. 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).
  1. 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.
  1. The identity of the authorizing entity to allow for validation of

the token.

  1. 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.
 Furthermore, the token MAY include:
  1. The lifetime of (each of) the media stream(s) (e.g., from SDP "t="

parameter). This field may be useful in pre-paid scenarios in

    order to limit the lifetime of the session.
  1. 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

 The use of a media authorization token in the Non-Associated Model
 requires the addition of new fields to several protocols:

Hamer, et al. Informational [Page 19] RFC 3521 Session Set-up with Media Authorization April 2003

  1. 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 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].
  1. Policy management protocol. A new protocol field or object MUST

be added to the policy management protocol to transport 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 distinguish between the elements of the token
    described in Section 7.2.  For example, this is achieved in COPS-
    RSVP with the Policy Data object defined in [8].
  1. 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 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:
  1. The Coupled Model which assumes a priori knowledge of network

topology and where pre-established trust relationships exist

    between network entities.
  1. The Associated Model where there are common or trusted policy

servers but knowledge of the network topology is not known a

    priori.
  1. The Non-Associated Model where knowledge of the network topology

is not known a priori, where there are different policy servers

    involved and where a trust relationship does not exist between the
    policy servers.
 The Associated Model is applicable to environments where the network
 elements involved in establishing a session have a pre-determined
 trust relationship but where their identities must be determined
 dynamically during session set up.  The Non-Associated Model is
 applicable to environments where there is a complex network topology
 and/or where trust relationships between domains do not exist (e.g.,
 when they are different business entities).

Hamer, et al. Informational [Page 20] RFC 3521 Session Set-up with Media Authorization April 2003

 In any given network, one or more of these models may be applicable.
 Indeed, the model to be used may be chosen dynamically during session
 establishment based on knowledge of the end points involved in the
 call.  In all cases, however, there is no need for the End Host or
 the Session Management Server to understand or interpret the
 authorization token - to them it is an opaque protocol element that
 is simply copied from one container protocol to another.
 Finally, the framework defined in this document is extensible 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

 The purpose of this document is to describe a mechanism for media
 authorization to prevent theft of service.
 For the authorization token to be effective, its integrity MUST be
 guaranteed as it passes through untrusted network entities such as
 the End Host.  This can be achieved by using authentication data.
 There is no requirement for encryption of the token since it does not
 contain confidential information that may be used by malicious users.
 This document assumes that trust relationships exist between various
 network entities, as described in each of the models.  The means for
 establishing these relationships are beyond the scope of this
 document.
 The different interfaces between the network entities described in
 this document have different natures requiring different security
 characteristics:
  1. The edge router and RCD policy server MUST have a trust

relationship. If necessary, this relationship can be enforced

    through a formal security association [14].
  1. The network policies exchanged over the interface between edge

router and RCD policy server SHOULD be integrity protected. This

    can be accomplished using integrity mechanisms built into the
    policy control protocol (e.g., the Integrity object in COPS [2])
    or through generic IP security mechanisms [14].
  1. The SCD and RCD policy servers MUST have a trust relationship in

the associated model. If necessary, this relationship can be

    enforced through a formal security association [14].

Hamer, et al. Informational [Page 21] RFC 3521 Session Set-up with Media Authorization April 2003

  1. The information exchanged over the interface between policy

servers SHOULD be integrity protected. This can be accomplished

    using integrity mechanisms built into the policy exchange protocol
    [2] or through generic IP security mechanisms [14].
  1. The end host SHOULD be authenticated by the RCD to protect against

identity theft. The network resource request/responses should be

    protected against corruption and spoofing.  Thus, the interface
    between host and edge router SHOULD provide integrity and
    authentication of messages.  For example, [13] provides integrity
    and authentication of RSVP messages.
  1. The end host SHOULD be authenticated by the SCD to protect against

identity theft. The session setup request/response should be

    protected against corruption and spoofing.  Thus, the interface
    between host and SMS SHOULD provide integrity and authentication
    of messages.
  1. The SMS and the SCD policy server MUST have a a trust

relationship. If necessary, this relationship can be enforced

    through a formal security association [14].
  1. The network policies exchanged over the interface between the SMS

and SCD policy server SHOULD be integrity protected. This can be

    accomplished using integrity mechanisms built into the policy
    control protocol (e.g., the Integrity object in COPS [2]) or
    through generic IP security mechanisms [14].

10. Normative References

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

Hamer, et al. Informational [Page 22] RFC 3521 Session Set-up with Media Authorization April 2003

 [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

 [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

 The authors would like to thank to following people for their useful
 comments and suggestions related to this document: Kwok Ho Chan, Doug
 Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois
 Audet, Bill Marshall, Diana Rawlins and many others.

Hamer, et al. Informational [Page 23] RFC 3521 Session Set-up with Media Authorization April 2003

13. Authors' Addresses

 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

Hamer, et al. Informational [Page 24] RFC 3521 Session Set-up with Media Authorization April 2003

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.

Hamer, et al. Informational [Page 25]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3521.txt · Last modified: 2003/04/10 15:58 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki