draft-ietf-rap-session-auth-04.txt   rfc3521.txt 
RAP Working Group L-N. Hamer Network Working Group L-N. Hamer
Internet Draft B. Gage Request for Comments: 3521 B. Gage
Document: draft-ietf-rap-session-auth-04.txt Nortel Networks Category: Informational Nortel Networks
Hugh Shieh H. Shieh
AT&T Wireless
AT&T Wireless April 2003
Category: Informational June 2002
Framework for session set-up with media authorization Framework for Session Set-up with Media Authorization
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026 [1]. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet- Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. This memo is filed as Copyright (C) The Internet Society (2003). All Rights Reserved.
<draft-ietf-rap-session-auth-04.txt>, and expires November 31, 2002.
Please send comments to the authors.
Abstract Abstract
Establishing multimedia streams must take into account requirements Establishing multimedia streams must take into account requirements
for end-to-end QoS, authorization of network resource usage and for end-to-end QoS, authorization of network resource usage and
accurate accounting for resources used. During session set up, accurate accounting for resources used. During session set up,
policies may be enforced to ensure that the media streams being policies may be enforced to ensure that the media streams being
requested lie within the bounds of the service profile established requested lie within the bounds of the service profile established
for the requesting host. Similarly, when a host requests resources for the requesting host. Similarly, when a host requests resources
to provide a certain QoS for a packet flow, policies may be enforced 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 to ensure that the required resources lie within the bounds of the
resource profile established for the requesting host. resource profile established for the requesting host.
To prevent fraud and to ensure accurate billing, we describe various To prevent fraud and to ensure accurate billing, this document
scenarios and mechanisms that provide the linkage required to verify describes various scenarios and mechanisms that provide the linkage
that the resources being used to provide a requested QoS are in-line required to verify that the resources being used to provide a
with the media streams requested (and authorized) for the session. requested QoS are in-line with the media streams requested (and
authorized) for the session.
Framework for session set-up with media authorization
Contents Table of Contents
Status of this Memo................................................1 1. Introduction....................................................2
Abstract...........................................................1 2. Conventions used in this document...............................3
Contents...........................................................2 3. Definition of terms.............................................4
1. Introduction....................................................3 4. The Coupled Model...............................................5
2. Conventions used in this document...............................4 4.1 Coupled Model Message Flows...............................6
3. Definition of terms.............................................5 4.2 Coupled Model Authorization Token.........................8
4. The Coupled Model...............................................7 4.3 Coupled Model Protocol Impacts............................8
4.1 Coupled Model Message Flows..................................7 5. The Associated Model <<using One Policy Server>>................8
4.2 Coupled Model Authorization Token............................9 5.1 Associated Model Message Flows
4.3 Coupled Model Protocol Impacts...............................9 <<using One Policy Server>>...............................9
5. The Associated Model <<using One Policy Server>>...............10 5.2 Associated Model Authorization Token
5.1 Associated Model Message Flows <<using One Policy Server>>..11 <<using One Policy Server>>..............................11
5.2 Associated Model Authorization Token <<using One Policy 5.3 Associated Model Protocol Impacts
Server>>..........................................................12 <<using One Policy Server>>..............................11
5.3 Associated Model Protocol Impacts <<using One Policy Server>> 5.4 Associated Model Network Impacts
..................................................................12 <<using One Policy Server>>..............................12
5.4 Associated Model Network Impacts <<using One Policy Server>>13 6. The Associated Model <<using Two Policy Servers>>..............12
6.1 Associated Model Message Flows <<using Two Policy Servers>>.15 6.1 Associated Model Message Flows
6.2 Associated Model Authorization Token <<using Two Policy <<using Two Policy Servers>>.............................13
Servers>>.........................................................16 6.2 Associated Model Authorization Token
6.3 Associated Model Protocol Impacts <<using Two Policy Servers>> <<using Two Policy Servers>>.............................15
..................................................................17 6.3 Associated Model Protocol Impacts
7. The Non-Associated Model.......................................18 <<using Two Policy Servers>>.............................16
7.1 Non-Associated Model Message Flow...........................18 7. The Non-Associated Model........................................16
7.2 Non-Associated Model Authorization Token....................20 7.1 Non-Associated Model Message Flow........................17
7.3 Non-Associated Model Protocol Impacts.......................21 7.2 Non-Associated Model Authorization Token.................19
8. Conclusions....................................................21 7.3 Non-Associated Model Protocol Impacts....................19
9. Security Considerations........................................22 8. Conclusions....................................................20
10. Normative References..........................................23 9. Security Considerations........................................21
11. Informative References........................................24 10. Normative References...........................................22
Acknowledgments...................................................24 11. Informative References.........................................23
Authors' Addresses................................................25 12. Acknowledgments................................................23
Full Copyright Statement..........................................25 13. Authors' Addresses.............................................24
RFC Editor Considerations.........................................25 14. Full Copyright Statement.......................................25
Framework for session set-up with media authorization
1. Introduction 1. Introduction
Establishing multimedia streams must take into account requirements Various mechanisms have been defined through which end hosts can use
for end-to-end QoS, authorization of network resource usage and a session management protocol (e.g., SIP [6]) to indicate that QoS
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.
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. 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 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. resources required to meet the end-to-end QoS of the media stream.
To prevent fraud and to ensure accurate billing, some linkage is To prevent fraud and to ensure accurate billing, some linkage is
required to verify that the resources being used to provide the required to verify that the resources being used to provide the
requested QoS are in-line with the media streams requested (and requested QoS are in-line with the media streams requested (and
authorized) for the session. authorized) for the session.
This document describes such a linkage through use of a "token" that 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 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 ticket in the push model of [10]. The token is generated by a policy
server (or a session management server) and is transparently relayed 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 through the end host to the edge router where it is used as part of
the policy-controlled flow admission process. the policy-controlled flow admission process.
In some environments, authorization of media streams can exploit the In some environments, authorization of media streams can exploit the
fact that pre-established relationships exist between elements of fact that pre-established relationships exist between elements of the
the network (e.g. session management servers, edge routers, policy network (e.g., session management servers, edge routers, policy
servers and end hosts). Pre-established relationships assume that servers and end hosts). Pre-established relationships assume that
the different network elements are configured with the identities of the different network elements are configured with the identities of
the other network elements and, if necessary, are configured with the other network elements and, if necessary, are configured with
security keys, etc. required to establish a trust relationship. In security keys, etc. required to establish a trust relationship. In
other environments, however, such pre-established relationships may other environments, however, such pre-established relationships may
not exist either due to the complexity of creating these not exist either due to the complexity of creating these associations
associations a priori (e.g. in a network with many elements), or due a priori (e.g., in a network with many elements), or due to the
to the different business entities involved (e.g. service provider different business entities involved (e.g., service provider and
and access provider), or due to the dynamic nature of these access provider), or due to the dynamic nature of these associations
associations (e.g. in a mobile environment). (e.g., in a mobile environment).
In this document, we describe these various scenarios and the In this document, we describe these various scenarios and the
mechanisms used for exchanging information between network elements mechanisms used for exchanging information between network elements
in order to authorize the use of resources for a service and to co- in order to authorize the use of resources for a service and to
ordinate actions between the session and resource management coordinate actions between the session and resource management
entities. Specific extensions to session management protocols (e.g. entities. Specific extensions to session management protocols (e.g.,
SIP [6], H.323), to resource reservation protocols (e.g. RSVP [4], SIP [6], H.323), to resource reservation protocols (e.g., RSVP [4],
YESSIR) and to policy managements protocols (e.g. COPS-PR [9], COPS- YESSIR) and to policy management protocols (e.g., COPS-PR [9], COPS-
Framework for session set-up with media authorization
RSVP [3]) required to realize these scenarios and mechanisms are RSVP [3]) required to realize these scenarios and mechanisms are
beyond the scope of this document. beyond the scope of this document.
For clarity, this document will illustrate the media authorization For clarity, this document will illustrate the media authorization
concepts using SIP for session signalling, RSVP for resource concepts using SIP for session signalling, RSVP for resource
reservation and COPS for interaction with the policy servers. Note, reservation and COPS for interaction with the policy servers. Note,
however, that the framework could be applied to a multimedia however, that the framework could be applied to a multimedia services
services scenario using different signalling protocols. scenario using different signalling protocols.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in BCP 14, RFC 2119 [1].
Framework for session set-up with media authorization
3. Definition of terms 3. Definition of terms
Figure 1 introduces a generic model for session establishment, QoS Figure 1 introduces a generic model for session establishment, QoS
and policy enforcement. and policy enforcement.
+-------------------------------------+ +---+ +-------------------------------------+ +---+
| SCD - Service Control Domain | | | | SCD - Service Control Domain | | |
| +-----------------------+ +--------+| | I | | +-----------------------+ +--------+| | I |
| |Session management | |Policy || | n | | |Session management | |Policy || | n |
skipping to change at line 194 skipping to change at page 4, line 39
| Host | | |+----------+| |+----------+ | | | N | | Host | | |+----------+| |+----------+ | | | N |
|+--------+| | ||RSVP Agent|| ||PDP | | | | e | |+--------+| | ||RSVP Agent|| ||PDP | | | | e |
||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t | ||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t |
||Client || | |+----------+| | | | | w | ||Client || | |+----------+| | | | | w |
|+--------+| | || PEP || | | | | o | |+--------+| | || PEP || | | | | o |
||SIP User|| | |+----------+| | | | | r | ||SIP User|| | |+----------+| | | | | r |
||Agent || | +------------+ +-------------+ | | k | ||Agent || | +------------+ +-------------+ | | k |
|+--------+| | | | | |+--------+| | | | |
+----------+ +-------------------------------------+ +---+ +----------+ +-------------------------------------+ +---+
Figure 1: Generic media authorization network model Figure 1: Generic media authorization network model
EH - End Host: The End Host is a device used by a subscriber to EH - End Host: The End Host is a device used by a subscriber to
access network services. The End Host includes a client for access network services. The End Host includes a client for
requesting network services (e.g. through SIP) and a client for requesting network services (e.g., through SIP) and a client for
requesting network resources (e.g. through RSVP). requesting network resources (e.g., through RSVP).
ER - Edge Router: The Edge Router is a network element connecting ER - Edge Router: The Edge Router is a network element connecting the
the end host to the rest of the Resource Control Domain. The Edge end host to the rest of the Resource Control Domain. The Edge Router
Router contains a PEP to enforce policies related to resource usage contains a PEP to enforce policies related to resource usage in the
in the Resource Control Domain by the End Host. It also contains a Resource Control Domain by the End Host. It also contains a
signalling agent (e.g. for RSVP) for handling resource reservation signalling agent (e.g., for RSVP) for handling resource reservation
requests from the End Host. requests from the End Host.
Framework for session set-up with media authorization
PDP - Policy Decision Point: The PDP is a logical entity located in PDP - Policy Decision Point: The PDP is a logical entity located in
the Policy Server that is responsible for authorizing or denying the Policy Server that is responsible for authorizing or denying
access to services and/or resources. access to services and/or resources.
PEP - Policy Enforcement Point: The PEP is a logical entity that PEP - Policy Enforcement Point: The PEP is a logical entity that
enforces policy decisions made by the PDP. Note that other PEPs may 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, reside in other network elements not shown in the model of Figure 1,
however they will not be discussed in this document. however they will not be discussed in this document.
PS - Policy Server: The Policy Server is a network element that 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 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 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 the Resource Control Domain to control use of resources along the
packet forwarding path. Note also that network topology may require packet forwarding path. Note also that network topology may require
multiple Policy Servers within either Domain, however they provide multiple Policy Servers within either Domain, however they provide
consistent policy decisions to offer the appearance of a single PDP consistent policy decisions to offer the appearance of a single PDP
in each Domain. in each Domain.
RCD - Resource Control Domain: The Resource Control Domain is a RCD - Resource Control Domain: The Resource Control Domain is a
logical grouping of elements that provide connectivity along the logical grouping of elements that provide connectivity along the
packet forwarding paths to and from an End Host. The RCD contains ER packet forwarding paths to and from an End Host. The RCD contains ER
and PS entities whose responsibilities include management of and PS entities whose responsibilities include management of
resources along the packet forwarding paths. Note that there may be resources along the packet forwarding paths. Note that there may be
one or more RCDs within an autonomous domain. one or more RCDs within an autonomous domain.
SCD - Service Control Domain: The Service Control Domain is a SCD - Service Control Domain: The Service Control Domain is a logical
logical grouping of elements that offer applications and content to grouping of elements that offer applications and content to
subscribers of their services. The Session Management Server resides 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 in the SCD along with a PS. Note that there may be one or more SCDs
within an autonomous domain. within an autonomous domain.
SMS - Session Management Server: The Session Management Server is a SMS - Session Management Server: The Session Management Server is a
network element providing session management services (e.g. network element providing session management services (e.g.,
telephony call control). The Session Management Server contains a telephony call control). The Session Management Server contains a
PEP to enforce policies related to use of services by the End Host. 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 It also contains a signalling agent or proxy (e.g., for SIP) for
handling service requests from the End Host. handling service requests from the End Host.
Framework for session set-up with media authorization
4. The Coupled Model 4. The Coupled Model
In some environments, a pre-established trust relationship exists In some environments, a pre-established trust relationship exists
between elements of the network (e.g. session management servers, between elements of the network (e.g., session management servers,
edge routers, policy servers and end hosts). We refer to this as the edge routers, policy servers and end hosts). We refer to this as the
"coupled model", indicating the tight relationship between entities "coupled model", indicating the tight relationship between entities
that is presumed. The key aspects of this scenario are the that is presumed. The key aspects of this scenario are the
following: following:
- Policy decisions, including media authorization, are made by a - Policy decisions, including media authorization, are made by a
single Policy Server. single Policy Server.
- The Edge Router, Session Management Servers and Policy Server - The Edge Router, Session Management Servers and Policy Server
involved in establishing the session are known a priori. For involved in establishing the session are known a priori. For
example, the End Host may be configured to use a Session example, the End Host may be configured to use a Session
Management Server associated with the Edge Router to which the EH Management Server associated with the Edge Router to which the EH
is connected. is connected.
- There are pre-defined trust relationships between the SMS and the - There are pre-defined trust relationships between the SMS and the
PS and between the ER and the PS. PS and between the ER and the PS.
+--------+ +--------+
+------+ | | +------+ | |
| | 1 +--------------------+ 2 | | | | 1 +--------------------+ 2 | |
| |-------->| Session Management |----->| | | |-------->| Session Management |----->| |
| |<--------| Server |<-----| | | |<--------| Server |<-----| |
| | 4 +--------------------+ 3 | | | | 4 +--------------------+ 3 | |
| End | | Policy | | End | | Policy |
| Host | | Server | | Host | | Server |
| | | | | | | |
| | 5 +--------------------+ 6 | | | | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| | | |-------->| Edge |----->| |
| |<--------| Router |<-----| | | |<--------| Router |<-----| |
| | 8 +--------------------+ 7 | | | | 8 +--------------------+ 7 | |
+------+ | | +------+ | |
+--------+ +--------+
Figure 2: The Coupled Model Figure 2: The Coupled Model
4.1 Coupled Model Message Flows 4.1 Coupled Model Message Flows
In this model, it is assumed that there is one Policy Server serving In this model, it is assumed that there is one Policy Server serving
both the Service Control and Resource Control Domains and that there both the Service Control and Resource Control Domains and that there
are pre-defined trust relationships between the PS and SMS and are pre-defined trust relationships between the PS and SMS and
between the PS and ER. Communications between these entities are between the PS and ER. Communications between these entities are
then possible as described below. Only the originating side flows then possible as described below. Only the originating side flows
Framework for session set-up with media authorization are described for simplicity. The same concepts apply to the
are described for simplicity. The same concepts apply to the
terminating side. terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
the Session Management Server indicating, among other things, the the Session Management Server indicating, among other things, the
media streams to be used in the session. As part of this step, media streams to be used in the session. As part of this step,
the End Host may authenticate itself to the Session Management the End Host may authenticate itself to the Session Management
Server. Server.
2. The Session Management Server, possibly after waiting for 2. The Session Management Server, possibly after waiting for
negotiation of the media streams to be completed, sends a policy negotiation of the media streams to be completed, sends a policy
decision request (e.g. COPS REQ) to the Policy Server in order to decision request (e.g., COPS REQ) to the Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The Policy Server sends a decision (e.g. COPS DEC) to the Session 3. The Policy Server sends a decision (e.g., COPS DEC) to the Session
Management Server, possibly after modifying the parameters of the Management Server, possibly after modifying the parameters of the
media to be used. Included in this response is a "token" that can media to be used. Included in this response is a "token" that can
subsequently be used by the Policy Server to identify the session subsequently be used by the Policy Server to identify the session
and the media it has authorized. and the media it has authorized.
4. The Session Management Server sends a response to the End Host 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 (e.g., SIP 200 or 183) indicating that session set-up is complete
or is progressing. Included in this response is a description of or is progressing. Included in this response is a description of
the negotiated media along with the token from the Policy Server. 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 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the Policy stream. Included in this request is the token from the Policy
Server provided via the Session Management Server. Server provided via the Session Management Server.
6. The Edge Router intercepts the reservation request and sends a 6. The Edge Router intercepts the reservation request and sends a
policy decision request (e.g. COPS REQ) to the Policy Server in policy decision request (e.g., COPS REQ) to the Policy Server in
order to determine if the resource reservation request should be order to determine if the resource reservation request should be
allowed to proceed. Included in this request is the token from allowed to proceed. Included in this request is the token from
the Policy Server provided by the End Host. The Policy Server the Policy Server provided by the End Host. The Policy Server
uses this token to correlate the request for resources with the uses this token to correlate the request for resources with the
media authorization previously provided to the Session Management media authorization previously provided to the Session Management
Server. Server.
7. The Policy Server sends a decision (e.g. COPS DEC) to the Edge 7. The Policy Server sends a decision (e.g., COPS DEC) to the Edge
Router, possibly after modifying the parameters of the resources Router, possibly after modifying the parameters of the resources
to be reserved. to be reserved.
8. The Edge Router, possibly after waiting for end-to-end 8. The Edge Router, possibly after waiting for end-to-end negotiation
negotiation for resources to be completed, sends a response to for resources to be completed, sends a response to the End Host
the End Host (e.g. RSVP RESV) indicating that resource (e.g., RSVP RESV) indicating that resource reservation is complete
reservation is complete or is progressing. or is progressing.
Framework for session set-up with media authorization
4.2 Coupled Model Authorization Token 4.2 Coupled Model Authorization Token
In the Coupled Model, the Policy Server is the only network entity In the Coupled Model, the Policy Server is the only network entity
that needs to interpret the contents of the token. Therefore, in that needs to interpret the contents of the token. Therefore, in
this model, the contents of the token are implementation dependent. this model, the contents of the token are implementation dependent.
Since the End Host is assumed to be untrusted, the Policy Server Since the End Host is assumed to be untrusted, the Policy Server
SHOULD take measures to ensure that the integrity of the token is SHOULD take measures to ensure that the integrity of the token is
preserved in transit; the exact mechanisms to be used are also preserved in transit; the exact mechanisms to be used are also
implementation dependent. implementation dependent.
4.3 Coupled Model Protocol Impacts 4.3 Coupled Model Protocol Impacts
The use of a media authorization token in the Coupled Model requires The use of a media authorization token in the Coupled Model requires
the addition of new fields to several protocols: the addition of new fields to several protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
MUST be added to the resource reservation protocol to MUST be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure (if any) of this Router. The content and internal structure (if any) of this
object SHOULD be opaque to the resource reservation protocol. For object SHOULD be opaque to the resource reservation protocol. For
example, this is achieved in RSVP with the Policy Data object example, this is achieved in RSVP with the Policy Data object
defined in [8]. defined in [8].
- Policy management protocol. A new protocol field or object MUST - Policy management protocol. A new protocol field or object MUST
be added to the policy management protocol to transparently be added to the policy management protocol to transparently
transport the token from the Policy Server to the Session transport the token from the Policy Server to the Session
Management Server and from the Edge Router to the Policy Server. Management Server and from the Edge Router to the Policy Server.
The content and internal structure (if any) of this object SHOULD The content and internal structure (if any) of this object SHOULD
be opaque to the policy management protocol. For example, this is be opaque to the policy management protocol. For example, this is
achieved in COPS-RSVP with the Policy Data object defined in [8]. achieved in COPS-RSVP with the Policy Data object defined in [8].
- Session management protocol. A new protocol field or object MUST - Session management protocol. A new protocol field or object MUST
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure (if any) of this object SHOULD be opaque to the session structure (if any) of this object SHOULD be opaque to the session
management protocol (e.g. SIP [6]). management protocol (e.g., SIP [6]).
Framework for session set-up with media authorization
5. The Associated Model <<using One Policy Server>> 5. The Associated Model <<using One Policy Server>>
In this scenario, there are multiple instances of the Session In this scenario, there are multiple instances of the Session
Management Servers, Edge Routers and Policy Servers. This leads to a Management Servers, Edge Routers and Policy Servers. This leads to a
network of sufficient complexity that it precludes distributing network of sufficient complexity that it precludes distributing
knowledge of network topology to all network entities. The key knowledge of network topology to all network entities. The key
aspects of this scenario are the following: aspects of this scenario are the following:
- Policy decisions, including media authorization, are made by the - Policy decisions, including media authorization, are made by the
same Policy Server for both the Session Management Server and the same Policy Server for both the Session Management Server and the
Edge Router. However, the Policy Server may change on a per- Edge Router. However, the Policy Server may change on a per-
transaction basis, i.e. on a per policy request basis. transaction basis, i.e., on a per policy request basis.
- The Edge Router, Session Management Server and Policy Server - The Edge Router, Session Management Server and Policy Server
involved in establishing the session are not known a priori. For involved in establishing the session are not known a priori. For
example, the End Host may be dynamically configured to use one of example, the End Host may be dynamically configured to use one of
a pool of Session Management Servers and each of the Session a pool of Session Management Servers and each of the Session
Management Servers may be statically configured to use one of a Management Servers may be statically configured to use one of a
pool of Policy Servers. pool of Policy Servers.
In another example, the End Host may be mobile and continually In another example, the End Host may be mobile and continually
changing the Edge Router that its point of attachment uses to changing the Edge Router that its point of attachment uses to
communicate with the rest of the network. communicate with the rest of the network.
- There are pre-defined trust relationships between the SMS and the - There are pre-defined trust relationships between the SMS and the
skipping to change at line 434 skipping to change at page 9, line 42
| End | | Policy | | | End | | Policy | |
| Host | +--------------------+ | Server | | | Host | +--------------------+ | Server | |
| | | ER 'n' | | 1 | | | | | ER 'n' | | 1 | |
| | 5 +-+------------------+ | | | | | | 5 +-+------------------+ | | | |
| |-------->| Edge |-+ 6 | | | | |-------->| Edge |-+ 6 | | |
| |<--------| Router |----->| | | | |<--------| Router |----->| | |
| | 8 +--------------------+ 7 | | | | | 8 +--------------------+ 7 | | |
+------+ <-----| |-+ +------+ <-----| |-+
+--------+ +--------+
Figure 3: The Associated Model using One Policy Server Figure 3: The Associated Model using One Policy Server
Framework for session set-up with media authorization
5.1 Associated Model Message Flows <<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 In this model, it is assumed that a Policy Server can make decisions
for both the Service Control and Resource Control Domains and that for both the Service Control and Resource Control Domains and that
there are pre-defined trust relationships between the PS and SMS and there are pre-defined trust relationships between the PS and SMS and
between the PS and ER. Communications between these entities are between the PS and ER. Communications between these entities are
then possible as described below. Only the originating side flows then possible as described below. Only the originating side flows
are described for simplicity. The same concepts apply to the are described for simplicity. The same concepts apply to the
terminating side. terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
the Session Management Server indicating, among other things, the the Session Management Server indicating, among other things, the
media streams to be used in the session. As part of this step, media streams to be used in the session. As part of this step,
the End Host may authenticate itself to the Session Management the End Host may authenticate itself to the Session Management
Server. Server.
2. The Session Management Server, possibly after waiting for 2. The Session Management Server, possibly after waiting for
negotiation of the media streams to be completed, sends a policy negotiation of the media streams to be completed, sends a policy
decision request (e.g. COPS REQ) to the Policy Server in order to decision request (e.g., COPS REQ) to the Policy Server in order to
determine if the session set-up request should be allowed to determine if the session set-up request should be allowed to
proceed. proceed.
3. The Policy Server sends a decision (e.g. COPS DEC) to the Session 3. The Policy Server sends a decision (e.g., COPS DEC) to the Session
Management Server, possibly after modifying the parameters of the Management Server, possibly after modifying the parameters of the
media to be used. Included in this response is a "token" that can media to be used. Included in this response is a "token" that can
subsequently be used by the Policy Server to identify the session subsequently be used by the Policy Server to identify the session
and the media it has authorized. and the media it has authorized.
4. The Session Management Server sends a response to the End Host 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 (e.g., SIP 200 or 183) indicating that session set-up is complete
or is progressing. Included in this response is a description of or is progressing. Included in this response is a description of
the negotiated media along with the token from the Policy Server. 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 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the Policy stream. Included in this request is the token from the Policy
Server provided via the Session Management Server. Server provided via the Session Management Server.
6. The Edge Router intercepts the reservation request and inspects 6. The Edge Router intercepts the reservation request and inspects
the token to learn which Policy Server authorized the media. It the token to learn which Policy Server authorized the media. It
then sends a policy decision request to that Policy Server in then sends a policy decision request to that Policy Server in
order to determine if the resource reservation request should be order to determine if the resource reservation request should be
allowed to proceed. Included in this request is the token from allowed to proceed. Included in this request is the token from
the Policy Server provided by the End Host. The Policy Server the Policy Server provided by the End Host. The Policy Server
uses this token to correlate the request for resources with the uses this token to correlate the request for resources with the
media authorization previously provided to the Session Management media authorization previously provided to the Session Management
Server. Server.
7. The Policy Server sends a decision to the Edge Router, possibly 7. The Policy Server sends a decision to the Edge Router, possibly
after modifying the parameters of the resources to be reserved. after modifying the parameters of the resources to be reserved.
Framework for session set-up with media authorization 8. The Edge Router, possibly after waiting for end-to-end negotiation
for resources to be completed, sends a response to the End Host
8. The Edge Router, possibly after waiting for end-to-end (e.g., RSVP RESV) indicating that resource reservation is complete
negotiation for resources to be completed, sends a response to or is progressing.
the End Host (e.g. RSVP RESV) indicating that resource
reservation is complete or is progressing.
5.2 Associated Model Authorization Token <<using One Policy Server>> 5.2 Associated Model Authorization Token <<using One Policy Server>>
Since the ER does not know which SMS and PS are involved in session Since the ER does not know which SMS and PS are involved in session
establishment, the token MUST include: establishment, the token MUST include:
- A correlation identifier. This is information that the Policy - A correlation identifier. This is information that the Policy
Server can use to correlate the resource reservation request with Server can use to correlate the resource reservation request with
the media authorized during session set up. The Policy Server is the media authorized during session set up. The Policy Server is
the only network entity that needs to interpret the contents of the only network entity that needs to interpret the contents of
the correlation identifier therefore, in this model, the contents the correlation identifier therefore, in this model, the contents
of the correlation identifier are implementation dependent. Since of the correlation identifier are implementation dependent. Since
the End Host is assumed to be untrusted, the Policy Server SHOULD the End Host is assumed to be untrusted, the Policy Server SHOULD
take measures to ensure that the integrity of the correlation take measures to ensure that the integrity of the correlation
identifier is preserved in transit; the exact mechanisms to be identifier is preserved in transit; the exact mechanisms to be
used are also implementation dependent. used are also implementation dependent.
- The identity of the authorizing entity. This information is used - The identity of the authorizing entity. This information is used
by the Edge Router to determine which Policy Server should be by the Edge Router to determine which Policy Server should be used
used to solicit resource policy decisions. to solicit resource policy decisions.
In some environments, an Edge Router may have no means for In some environments, an Edge Router may have no means for
determining if the identity refers to a legitimate Policy Server determining if the identity refers to a legitimate Policy Server
within its domain. In order to protect against redirection of within its domain. In order to protect against redirection of
authorization requests to a bogus authorizing entity, the token authorization requests to a bogus authorizing entity, the token
SHOULD also include: SHOULD also include:
- Authentication data. This authentication data is calculated over - Authentication data. This authentication data is calculated over
all other fields of the token using an agreed mechanism. The all other fields of the token using an agreed mechanism. The
mechanism used by the Edge Router is beyond the scope of this mechanism used by the Edge Router is beyond the scope of this
document. document.
The detailed semantics of an authorization token are defined in [4]. The detailed semantics of an authorization token are defined in [4].
5.3 Associated Model Protocol Impacts <<using One Policy Server>> 5.3 Associated Model Protocol Impacts <<using One Policy Server>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires the addition of new fields to several Associated Model requires the addition of new fields to several
protocols: protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
MUST be added to the resource reservation protocol to MUST be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Framework for session set-up with media authorization Router. The content and internal structure of this object MUST be
Router. The content and internal structure of this object MUST be
specified so that the Edge Router can distinguish between the specified so that the Edge Router can distinguish between the
elements of the token described in Section 5.2. For example, this elements of the token described in Section 5.2. For example, this
is achieved in RSVP with the Policy Data object defined in [8]. is achieved in RSVP with the Policy Data object defined in [8].
- Policy management protocol. A new protocol field or object MUST - Policy management protocol. A new protocol field or object MUST
be added to the policy management protocol to transparently be added to the policy management protocol to transparently
transport the token -- or at least the correlation identifier -- transport the token -- or at least the correlation identifier --
from the Edge Router to the Policy Server. The content and from the Edge Router to the Policy Server. The content and
internal structure of this object SHOULD be opaque to the policy internal structure of this object SHOULD be opaque to the policy
management protocol. For example, this is achieved in COPS-RSVP management protocol. For example, this is achieved in COPS-RSVP
with the Policy Data object defined in [8]. with the Policy Data object defined in [8].
- Session management protocol. A new protocol field or object MUST - Session management protocol. A new protocol field or object MUST
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object SHOULD be opaque to the session structure of this object SHOULD be opaque to the session
management protocol (e.g. SIP [6]). management protocol (e.g., SIP [6]).
5.4 Associated Model Network Impacts <<using One Policy Server>> 5.4 Associated Model Network Impacts <<using One Policy Server>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires that the Edge Router inspect the token to Associated Model requires that the Edge Router inspect the token to
learn which Policy Server authorized the media. In some learn which Policy Server authorized the media. In some
environments, it may not be possible for the Edge Router to perform environments, it may not be possible for the Edge Router to perform
this function; in these cases, an Associated Model using Two Policy this function; in these cases, an Associated Model using Two Policy
Servers (section 6) is required. Servers (section 6) is required.
This version of the Associated Model also requires that the Edge This version of the Associated Model also requires that the Edge
Router interact with multiple Policy Servers. Policy decisions are Router interact with multiple Policy Servers. Policy decisions are
made by the same Policy Server for both the Session Management made by the same Policy Server for both the Session Management Server
Server and the Edge Router, however the Policy Server may change on and the Edge Router, however the Policy Server may change on per-
per-transaction basis. Note that the COPS framework does not transaction basis. Note that the COPS framework does not currently
currently allow PEPs to change PDP on a per-transaction basis. To allow PEPs to change PDP on a per-transaction basis. To use this
use this model, a new framework must be defined for policy decision model, a new framework must be defined for policy decision
outsourcing. This model also implies that the Policy Servers are outsourcing. This model also implies that the Policy Servers are
able to interact and/or make decisions for the Edge Router in a 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 consistent manner (e.g., as though there is only a single RCD Policy
Server). How this is accomplished is beyond the scope of this Server). How this is accomplished is beyond the scope of this
document. document.
Framework for session set-up with media authorization 6. The Associated Model <<using Two Policy Servers>>
6. The Associated Model <<using Two Policy Servers>>
In this scenario, there are multiple instances of the Session In this scenario, there are multiple instances of the Session
Management Servers, Edge Routers and Policy Servers. This leads to a Management Servers, Edge Routers and Policy Servers. This leads to a
network of sufficient complexity that it precludes distributing network of sufficient complexity that it precludes distributing
knowledge of network topology to all network entities. The key knowledge of network topology to all network entities. The key
aspects of this scenario are the following: aspects of this scenario are the following:
- Policy decisions, including media authorization, are made by - Policy decisions, including media authorization, are made by
Policy Servers. Policy Servers.
- There is a PS in the Resource Control Domain that is separate - There is a PS in the Resource Control Domain that is separate from
from the PS in the Session Control Domain. the PS in the Service Control Domain.
- The Edge Router, Session Management Server and Policy Servers - The Edge Router, Session Management Server and Policy Servers
involved in establishing the session are not known a priori. For involved in establishing the session are not known a priori. For
example, the End Host may be dynamically configured to use one of example, the End Host may be dynamically configured to use one of
a pool of Session Management Servers or the End Host may be a pool of Session Management Servers or the End Host may be mobile
mobile and continually changing the Edge Router that it uses to and continually changing the Edge Router that it uses to
communicate with the rest of the network. communicate with the rest of the network.
- There is a pre-defined trust relationship between the SMS and the - There is a pre-defined trust relationship between the SMS and the
SCD PS. SCD PS.
- There is a pre-defined trust relationship between the ER and the - There is a pre-defined trust relationship between the ER and the
RCD PS. RCD PS.
- There is a pre-defined trust relationship between the RCD and SCD - There is a pre-defined trust relationship between the RCD and SCD
Policy Servers. Policy Servers.
skipping to change at line 630 skipping to change at page 13, line 41
| | 7 ^ | | | 7 ^ |
| Host | +--------------------+ | v 8 | Host | +--------------------+ | v 8
| | | ER 'n' | +--------+ | | | ER 'n' | +--------+
| | 5 +-+------------------+ | | | | | 5 +-+------------------+ | | |
| |-------->| Edge |-+ 6 | RCD | | |-------->| Edge |-+ 6 | RCD |
| |<--------| Router |----->| Policy | | |<--------| Router |----->| Policy |
| | 10 +--------------------+<--- -| Server | | | 10 +--------------------+<--- -| Server |
+------+ 9 | | +------+ 9 | |
+--------+ +--------+
Figure 4: The Associated Model using Two Policy Servers Figure 4: The Associated Model using Two Policy Servers
Framework for session set-up with media authorization
6.1 Associated Model Message Flows <<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 In this model, it is assumed that there is one Policy Server for the
Service Control Domain and a different Policy Server for the Service Control Domain and a different Policy Server for the Resource
Resource Control Domain. There are pre-defined trust relationships Control Domain. There are pre-defined trust relationships between
between the SCD PS and SMS, between the RCD PS and ER and between the SCD PS and SMS, between the RCD PS and ER and between the RCD and
the RCD and SCD Policy Servers. Communications between these SCD Policy Servers. Communications between these entities are then
entities are then possible as described below. Only the originating possible as described below. Only the originating side flows are
side flows are described for simplicity. The same concepts apply to described for simplicity. The same concepts apply to the terminating
the terminating side. 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 1. The End Host issues a session set-up request (e.g., SIP INVITE)
Session Management Server, possibly after modifying the to the Session Management Server indicating, among other things,
parameters of the media to be used. Included in this response is the media streams to be used in the session. As part of this
a "token" that can subsequently be used by the SCD Policy Server step, the End Host may authenticate itself to the Session
to identify the session and the media it has authorized. Management Server.
4. The Session Management Server sends a response to the End Host 2. The Session Management Server, possibly after waiting for
(e.g. SIP 200 or 183) indicating that session set-up is complete negotiation of the media streams to be completed, sends a policy
or is progressing. Included in this response is a description of decision request (e.g., COPS REQ) to the SCD Policy Server in
the negotiated media along with the token from the SCD Policy order to determine if the session set-up request should be
Server. allowed to proceed.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the
resources necessary to provide the required QoS for the media Session Management Server, possibly after modifying the
stream. Included in this request is the token from the SCD Policy parameters of the media to be used. Included in this response is
Server provided via the Session Management Server. a "token" that can subsequently be used by the SCD Policy Server
to identify the session and the media it has authorized.
6. The Edge Router intercepts the reservation request and sends a 4. The Session Management Server sends a response to the End Host
policy decision request (e.g. COPS REQ) to the RCD Policy Server (e.g., SIP 200 or 183) indicating that session set-up is complete
in order to determine if the resource reservation request should or is progressing. Included in this response is a description of
be allowed to proceed. Included in this request is the token from the negotiated media along with the token from the SCD Policy
the SCD Policy Server provided by the End Host. Server.
7. The RCD Policy Server uses this token to learn which SCD Policy 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
Server authorized the media. It then sends an authorization resources necessary to provide the required QoS for the media
request [11] to that SCD Policy Server in order to determine if stream. Included in this request is the token from the SCD
the resource reservation request should be allowed to proceed. Policy Server provided via the Session Management Server.
Framework for session set-up with media authorization 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.
Included in this request is the token from the SCD Policy Server 7. The RCD Policy Server uses this token to learn which SCD Policy
provided by the End Host. 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 8. The SCD Policy Server uses this token to correlate the request
for resources with the media authorization previously provided to for resources with the media authorization previously provided to
the Session Management Server. The SCD Policy Server sends a the Session Management Server. The SCD Policy Server sends a
decision [11] to the RCD Policy Server on whether the requested decision [11] to the RCD Policy Server on whether the requested
resources are within the bounds authorized by the SCD Policy resources are within the bounds authorized by the SCD Policy
Server. Server.
9. The RCD Policy Server sends a decision (e.g. COPS DEC) to the 9. The RCD Policy Server sends a decision (e.g., COPS DEC) to the
Edge Router, possibly after modifying the parameters of the Edge Router, possibly after modifying the parameters of the
resources to be reserved. resources to be reserved.
10. The Edge Router, possibly after waiting for end-to-end 10. The Edge Router, possibly after waiting for end-to-end
negotiation for resources to be completed, sends a response to negotiation for resources to be completed, sends a response to
the End Host (e.g. RSVP RESV) indicating that resource the End Host (e.g., RSVP RESV) indicating that resource
reservation is complete or is progressing reservation is complete or is progressing
6.2 Associated Model Authorization Token <<using Two Policy Servers>> 6.2 Associated Model Authorization Token <<using Two Policy Servers>>
Since the RCD Policy Server does not know which SMS and SCD PS are Since the RCD Policy Server does not know which SMS and SCD PS are
involved in session establishment, the token MUST include: involved in session establishment, the token MUST include:
- A correlation identifier. This is information that the SCD Policy - A correlation identifier. This is information that the SCD Policy
Server can use to correlate the resource reservation request with Server can use to correlate the resource reservation request with
the media authorized during session set up. The SCD Policy Server the media authorized during session set up. The SCD Policy Server
is the only network entity that needs to interpret the contents is the only network entity that needs to interpret the contents of
of the correlation identifier therefore, in this model, the the correlation identifier therefore, in this model, the contents
contents of the correlation identifier are implementation of the correlation identifier are implementation dependent. Since
dependent. Since the End Host is assumed to be untrusted, the SCD the End Host is assumed to be untrusted, the SCD Policy Server
Policy Server SHOULD take measures to ensure that the integrity SHOULD take measures to ensure that the integrity of the
of the correlation identifier is preserved in transit; the exact correlation identifier is preserved in transit; the exact
mechanisms to be used are also implementation dependent. mechanisms to be used are also implementation dependent.
- The identity of the authorizing entity. This information is used - The identity of the authorizing entity. This information is used
by the RCD Policy Server to determine which SCD Policy Server by the RCD Policy Server to determine which SCD Policy Server
should be used to verify the contents of the resource reservation should be used to verify the contents of the resource reservation
request. request.
In some environments, an RCD Policy Server may have no means for In some environments, an RCD Policy Server may have no means for
determining if the identity refers to a legitimate SCD Policy determining if the identity refers to a legitimate SCD Policy Server.
Server. In order to protect against redirection of authorization In order to protect against redirection of authorization requests to
requests to a bogus authorizing entity, the token SHOULD include: a bogus authorizing entity, the token SHOULD include:
- Authentication data. This authentication data is calculated over - Authentication data. This authentication data is calculated over
all other fields of the token using an agreed mechanism. The all other fields of the token using an agreed mechanism. The
mechanism used by the RCD Policy Server is beyond the scope of mechanism used by the RCD Policy Server is beyond the scope of
this document. this document.
Framework for session set-up with media authorization
Note that the information in this token is the same as that in Note that the information in this token is the same as that in
Section 5.2 for the "One Policy Server" scenario. Section 5.2 for the "One Policy Server" scenario.
The detailed semantics of an authorization token are defined in [4]. The detailed semantics of an authorization token are defined in [4].
6.3 Associated Model Protocol Impacts <<using Two Policy Servers>> 6.3 Associated Model Protocol Impacts <<using Two Policy Servers>>
The use of a media authorization token in this version of the The use of a media authorization token in this version of the
Associated Model requires the addition of new fields to several Associated Model requires the addition of new fields to several
protocols: protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
MUST be added to the resource reservation protocol to MUST be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure of this object SHOULD Router. The content and internal structure of this object SHOULD
be opaque to the resource reservation protocol. For example, this be opaque to the resource reservation protocol. For example, this
is achieved in RSVP with the Policy Data object defined in [8]. is achieved in RSVP with the Policy Data object defined in [8].
- Policy management protocol. A new protocol field or object MUST - Policy management protocol. A new protocol field or object MUST
be added to the policy management protocol to transport the token be added to the policy management protocol to transport the token
from the SCD Policy Server to the Session Management Server and from the SCD Policy Server to the Session Management Server and
from the Edge Router to the RCD Policy Server. The content and from the Edge Router to the RCD Policy Server. The content and
internal structure of this object MUST be specified so that the internal structure of this object MUST be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
described in Section 6.2. For example, this is achieved in COPS- described in Section 6.2. For example, this is achieved in COPS-
RSVP with the Policy Data object defined in [8]. RSVP with the Policy Data object defined in [8].
- Session management protocol. A new protocol field or object MUST - Session management protocol. A new protocol field or object MUST
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object SHOULD be opaque to the session structure of this object SHOULD be opaque to the session
management protocol (e.g. SIP [6]). management protocol (e.g., SIP [6]).
Note that these impacts are the same as those discussed in Section 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 5.3 for the "One Policy Server" scenario. However the use of two
Policy Servers has one additional impact: Policy Servers has one additional impact:
- Authorization protocol. A new protocol field or object MUST be - Authorization protocol. A new protocol field or object MUST be
added to the authorization protocol to transport the token from added to the authorization protocol to transport the token from
the RCD Policy Server to the SCD Policy Server. The content and the RCD Policy Server to the SCD Policy Server. The content and
internal structure of this object MUST be specified so that the internal structure of this object MUST be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
described in Section 6.2. described in Section 6.2.
Framework for session set-up with media authorization
7. The Non-Associated Model 7. The Non-Associated Model
In this scenario, the Session Management Servers and Edge Routers In this scenario, the Session Management Servers and Edge Routers are
are associated with different Policy Servers, the network entities associated with different Policy Servers, the network entities do not
do not have a priori knowledge of the topology of the network and have a priori knowledge of the topology of the network and there are
there are no pre-established trust relationships between entities in no pre-established trust relationships between entities in the
the Resource Control Domain and entities in the Service Control Resource Control Domain and entities in the Service Control Domain.
Domain. The keys aspects of this scenario are the following: The key aspects of this scenario are the following:
- Policy decisions, including media authorization, are made by - Policy decisions, including media authorization, are made by
Policy Servers. Policy Servers.
- The PS in the Resource Control Domain is separate from the PS in - The PS in the Resource Control Domain is separate from the PS in
the Session Control Domain. the Service Control Domain.
- There is a pre-defined trust relationship between the SMS and the - There is a pre-defined trust relationship between the SMS and the
SCD PS. SCD PS.
- There is a pre-defined trust relationship between the ER and the - There is a pre-defined trust relationship between the ER and the
RCD PS. RCD PS.
- There are no pre-defined trust relationships between the ER and - There are no pre-defined trust relationships between the ER and
SMS or between the RCD and SCD Policy Servers. SMS or between the RCD and SCD Policy Servers.
skipping to change at line 825 skipping to change at page 17, line 36
| End | +--------+ | End | +--------+
| Host | | Host |
| | +--------+ | | +--------+
| | 5 +--------------------+ 6 | | | | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| RCD | | |-------->| Edge |----->| RCD |
| |<--------| Router |<-----| Policy | | |<--------| Router |<-----| Policy |
| | 8 +--------------------+ 7 | Server | | | 8 +--------------------+ 7 | Server |
+------+ | | +------+ | |
+--------+ +--------+
Figure 5: The Non-Associated Model Figure 5: The Non-Associated Model
7.1 Non-Associated Model Message Flow 7.1 Non-Associated Model Message Flow
In this model it is assumed that the policy servers make independent In this model it is assumed that the policy servers make independent
decisions for their respective domains, obviating the need for decisions for their respective domains, obviating the need for
information exchange between policy servers. This model also enables information exchange between policy servers. This model also enables
Framework for session set-up with media authorization
session authorization when communication between policy servers is session authorization when communication between policy servers is
not possible for various reasons. It may also be used as a means to not possible for various reasons. It may also be used as a means to
speed up session setup and still ensure proper authorization is speed up session setup and still ensure proper authorization is
performed. performed.
This model does not preclude the possibility that the policy servers This model does not preclude the possibility that the policy servers
may communicate at other times for other purposes (e.g. exchange of may communicate at other times for other purposes (e.g., exchange of
accounting information). accounting information).
Communications between network entities in this model is described Communications between network entities in this model is described
below. Only the originating side flows are described for simplicity. below. Only the originating side flows are described for simplicity.
The same concepts apply to the terminating side. The same concepts apply to the terminating side.
1. The End Host issues a session set-up request (e.g. SIP INVITE) to 1. The End Host issues a session set-up request (e.g., SIP INVITE) to
the Session Management Server indicating, among other things, the the Session Management Server indicating, among other things, the
media streams to be used in the session. As part of this step, media streams to be used in the session. As part of this step,
the End Host may authenticate itself to the Session Management the End Host may authenticate itself to the Session Management
Server. Server.
2. The Session Management Server, possibly after waiting for 2. The Session Management Server, possibly after waiting for
negotiation of the media streams to be completed, sends a policy negotiation of the media streams to be completed, sends a policy
decision request (e.g. COPS REQ) to the SCD Policy Server in decision request (e.g., COPS REQ) to the SCD Policy Server in
order to determine if the session set-up request should be order to determine if the session set-up request should be allowed
allowed to proceed. to proceed.
3. The SCD Policy Server sends a decision (e.g. COPS DEC) to the 3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the
Session Management Server, possibly after modifying the Session Management Server, possibly after modifying the parameters
parameters of the media to be used. Included in this response is of the media to be used. Included in this response is a "token"
a "token" that can subsequently be used by the RCD Policy Server that can subsequently be used by the RCD Policy Server to
to determine what media has been authorized. determine what media has been authorized.
4. The Session Management Server sends a response to the End Host 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 (e.g., SIP 200 or 183) indicating that session set-up is complete
or is progressing. Included in this response is a description of or is progressing. Included in this response is a description of
the negotiated media along with the token from the SCD Policy the negotiated media along with the token from the SCD Policy
Server. Server.
5. The End Host issues a request (e.g. RSVP PATH) to reserve the 5. The End Host issues a request (e.g., RSVP PATH) to reserve the
resources necessary to provide the required QoS for the media resources necessary to provide the required QoS for the media
stream. Included in this request is the token from the SCD Policy stream. Included in this request is the token from the SCD Policy
Server provided via the Session Management Server. Server provided via the Session Management Server.
6. The Edge Router intercepts the reservation request and sends a 6. The Edge Router intercepts the reservation request and sends a
policy decision request (e.g. COPS REQ) to the RCD Policy Server policy decision request (e.g., COPS REQ) to the RCD Policy Server
in order to determine if the resource reservation request should in order to determine if the resource reservation request should
be allowed to proceed. Included in this request is the token from be allowed to proceed. Included in this request is the token from
the SCD Policy Server provided by the End Host. the SCD Policy Server provided by the End Host.
7. The RCD Policy Server uses this token to extract information 7. The RCD Policy Server uses this token to extract information about
about the media that was authorized by the SCD Policy Server. The the media that was authorized by the SCD Policy Server. The RCD
Framework for session set-up with media authorization Policy Server uses this information in making its decision on
RCD Policy Server uses this information in making its decision on
whether the resource reservation should be allowed to proceed. whether the resource reservation should be allowed to proceed.
The Policy Server sends a decision (e.g. COPS DEC) to the Edge The Policy Server sends a decision (e.g., COPS DEC) to the Edge
Router, possibly after modifying the parameters of the resources Router, possibly after modifying the parameters of the resources
to be reserved. to be reserved.
8. The Edge Router, possibly after waiting for end-to-end 8. The Edge Router, possibly after waiting for end-to-end negotiation
negotiation for resources to be completed, sends a response to for resources to be completed, sends a response to the End Host
the End Host (e.g. RSVP RESV) indicating that resource (e.g., RSVP RESV) indicating that resource reservation is complete
reservation is complete or is progressing or is progressing
7.2 Non-Associated Model Authorization Token 7.2 Non-Associated Model Authorization Token
In this model, the token MUST contain sufficient information to In this model, the token MUST contain sufficient information to allow
allow the RCD Policy Server to make resource policy decisions the RCD Policy Server to make resource policy decisions autonomously
autonomously from the SCD Policy Server. The token is created using from the SCD Policy Server. The token is created using information
information about the session received by the SMS. The information about the session received by the SMS. The information in the token
in the token MUST include: MUST include:
- Calling party name or IP address (e.g. from SDP "c=" parameter). - Calling party name or IP address (e.g., from SDP "c=" parameter).
- Called 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 - The characteristics of (each of) the media stream(s) authorized
for this session (e.g. codecs, maximum bandwidth from SDP "m=" for this session (e.g., codecs, maximum bandwidth from SDP "m="
and/or "b=" parameters). and/or "b=" parameters).
- The authorization lifetime. To protect against replay attacks, - The authorization lifetime. To protect against replay attacks,
the token should be valid for only a few seconds after the start the token should be valid for only a few seconds after the start
time of the session. time of the session.
- The identity of the authorizing entity to allow for validation of - The identity of the authorizing entity to allow for validation of
the token. the token.
- Authentication data used to prevent tampering with the. This - Authentication data used to prevent tampering with the token.
authentication data is calculated over all other fields of the This authentication data is calculated over all other fields of
token using an agreed mechanism. The mechanism used by the RCD the token using an agreed mechanism. The mechanism used by the
Policy Server is beyond the scope of this document. RCD Policy Server is beyond the scope of this document.
Furthermore, the token MAY include: Furthermore, the token MAY include:
- The lifetime of (each of) the media stream(s) (e.g. from SDP "t=" - 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 parameter). This field may be useful in pre-paid scenarios in
order to limit the lifetime of the session. order to limit the lifetime of the session.
- The Calling and called party port numbers (e.g. from the "m=" - The Calling and called party port numbers (e.g., from the "m="
parameter). parameter).
Framework for session set-up with media authorization
The detailed semantics of an authorization token are defined in [4]. The detailed semantics of an authorization token are defined in [4].
7.3 Non-Associated Model Protocol Impacts 7.3 Non-Associated Model Protocol Impacts
The use of a media authorization token in the Non-Associated Model The use of a media authorization token in the Non-Associated Model
requires the addition of new fields to several protocols: requires the addition of new fields to several protocols:
- Resource reservation protocol. A new protocol field or object - Resource reservation protocol. A new protocol field or object
MUST be added to the resource reservation protocol to MUST be added to the resource reservation protocol to
transparently transport the token from the End Host to the Edge transparently transport the token from the End Host to the Edge
Router. The content and internal structure of this object SHOULD Router. The content and internal structure of this object SHOULD
be opaque to the resource reservation protocol. For example, this be opaque to the resource reservation protocol. For example, this
is achieved in RSVP with the Policy Data object defined in [8]. is achieved in RSVP with the Policy Data object defined in [8].
- Policy management protocol. A new protocol field or object MUST - Policy management protocol. A new protocol field or object MUST
be added to the policy management protocol to transport the token be added to the policy management protocol to transport the token
from the SCD Policy Server to the Session Management Server and from the SCD Policy Server to the Session Management Server and
from the Edge Router to the RCD Policy Server. The content and from the Edge Router to the RCD Policy Server. The content and
internal structure of this object MUST be specified so that the internal structure of this object MUST be specified so that the
Policy Servers can distinguish between the elements of the token Policy Servers can distinguish between the elements of the token
described in Section 7.2. For example, this is achieved in COPS- described in Section 7.2. For example, this is achieved in COPS-
RSVP with the Policy Data object defined in [8]. RSVP with the Policy Data object defined in [8].
- Session management protocol. A new protocol field or object MUST - Session management protocol. A new protocol field or object MUST
be added to the session management protocol to transparently be added to the session management protocol to transparently
transport the media authorization token from the Session transport the media authorization token from the Session
Management Server to the End Host. The content and internal Management Server to the End Host. The content and internal
structure of this object SHOULD be opaque to the session structure of this object SHOULD be opaque to the session
management protocol (e.g. SIP [6]). management protocol (e.g., SIP [6]).
8. Conclusions 8. Conclusions
This document defines three models for session set-up with media This document defines three models for session set-up with media
authorization: authorization:
- The Coupled Model which assumes a priori knowledge of network - The Coupled Model which assumes a priori knowledge of network
topology and where pre-established trust relationships exist topology and where pre-established trust relationships exist
between network entities. between network entities.
- The Associated Model where there are common or trusted policy - The Associated Model where there are common or trusted policy
servers but knowledge of the network topology is not known a servers but knowledge of the network topology is not known a
priori. priori.
- The Non-Associated Model where knowledge of the network topology - The Non-Associated Model where knowledge of the network topology
is not known a priori, where there are different policy servers is not known a priori, where there are different policy servers
involved and where a trust relationship does not exist between involved and where a trust relationship does not exist between the
the policy servers. policy servers.
Framework for session set-up with media authorization
The Associated Model is applicable to environments where the network The Associated Model is applicable to environments where the network
elements involved in establishing a session have a pre-determined elements involved in establishing a session have a pre-determined
trust relationship but where their identities must be determined trust relationship but where their identities must be determined
dynamically during session set up. The Non-Associated Model is dynamically during session set up. The Non-Associated Model is
applicable to environments where there is a complex network topology applicable to environments where there is a complex network topology
and/or where trust relationships between domains do not exist (e.g. and/or where trust relationships between domains do not exist (e.g.,
when they are different business entities). when they are different business entities).
In any given network, one or more of these models may be applicable. In any given network, one or more of these models may be applicable.
Indeed, the model to be used may be chosen dynamically during Indeed, the model to be used may be chosen dynamically during session
session establishment based on knowledge of the end points involved establishment based on knowledge of the end points involved in the
in the call. In all cases, however, there is no need for the End call. In all cases, however, there is no need for the End Host or
Host, the Edge Router or the Session Management Server to understand the Session Management Server to understand or interpret the
or interpret the authorization token - to them it is an opaque authorization token - to them it is an opaque protocol element that
protocol element that is simply copied from one container protocol is simply copied from one container protocol to another.
to another.
Finally, the framework defined in this document is extensible to any Finally, the framework defined in this document is extensible to any
kind of session management protocol coupled to any one of a number kind of session management protocol coupled to any one of a number of
of resource reservation and/or policy management protocols. resource reservation and/or policy management protocols.
9. Security Considerations 9. Security Considerations
The purpose of this document is to describe a mechanism for media The purpose of this document is to describe a mechanism for media
authorization to prevent theft of service. authorization to prevent theft of service.
For the authorization token to be effective, its integrity MUST be For the authorization token to be effective, its integrity MUST be
guaranteed as it passes through untrusted network entities such as guaranteed as it passes through untrusted network entities such as
the End Host. This can be achieved by using authentication data. the End Host. This can be achieved by using authentication data.
There is no requirement for encryption of the token since it does There is no requirement for encryption of the token since it does not
not contain confidential information that may be used by malicious contain confidential information that may be used by malicious users.
users.
This document assumes that trust relationships exist between various This document assumes that trust relationships exist between various
network entities, as described in each of the models. The means for network entities, as described in each of the models. The means for
establishing these relationships are beyond the scope of this establishing these relationships are beyond the scope of this
document. document.
The different interfaces between the network entities described in The different interfaces between the network entities described in
this document have different natures requiring different security this document have different natures requiring different security
characteristics: characteristics:
- The edge router and RCD policy server MUST have a trust - The edge router and RCD policy server MUST have a trust
relationship. If necessary, this relationship can be enforced relationship. If necessary, this relationship can be enforced
through a formal security association [14]. through a formal security association [14].
- 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
Framework for session set-up with media authorization
control protocol (e.g. the Integrity object in COPS [2]) or through - The network policies exchanged over the interface between edge
generic IP security mechanisms [14]. 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].
- The SCD and RCD policy servers MUST have a trust relationship in - The SCD and RCD policy servers MUST have a trust relationship in
the associated model. If necessary, this relationship can be the associated model. If necessary, this relationship can be
enforced through a formal security association [14]. enforced through a formal security association [14].
- The information exchanged over the interface between policy - The information exchanged over the interface between policy
servers SHOULD be integrity protected. This can be accomplished servers SHOULD be integrity protected. This can be accomplished
using integrity mechanisms built into the policy exchange protocol using integrity mechanisms built into the policy exchange protocol
[2] or through generic IP security mechanisms [14]. [2] or through generic IP security mechanisms [14].
- The end host SHOULD be authenticated by the RCD to protect against - The end host SHOULD be authenticated by the RCD to protect against
identity theft. The network resource request/responses should be identity theft. The network resource request/responses should be
protected against corruption and spoofing. Thus, the interface protected against corruption and spoofing. Thus, the interface
between host and edge router SHOULD provide integrity and between host and edge router SHOULD provide integrity and
authentication of messages. For example, [13] provides integrity and authentication of messages. For example, [13] provides integrity
authentication of RSVP messages. and authentication of RSVP messages.
- The end host SHOULD be authenticated by the SCD to protect against - The end host SHOULD be authenticated by the SCD to protect against
identity theft. The session setup request/response should be identity theft. The session setup request/response should be
protected against corruption and spoofing. Thus, the interface protected against corruption and spoofing. Thus, the interface
between host and SMS SHOULD provide integrity and authentication of between host and SMS SHOULD provide integrity and authentication
messages. of messages.
- The SMS and the SCD policy server MUST have a a trust - The SMS and the SCD policy server MUST have a a trust
relationship. If necessary, this relationship can be enforced relationship. If necessary, this relationship can be enforced
through a formal security association [14]. through a formal security association [14].
- The network policies exchanged over the interface between the SMS - The network policies exchanged over the interface between the SMS
and SCD policy server SHOULD be integrity protected. This can be and SCD policy server SHOULD be integrity protected. This can be
accomplished using integrity mechanisms built into the policy accomplished using integrity mechanisms built into the policy
control protocol (e.g. the Integrity object in COPS [2]) or through control protocol (e.g., the Integrity object in COPS [2]) or
generic IP security mechanisms [14]. through generic IP security mechanisms [14].
10. Normative References 10. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
BCP 9, RFC 2026, October 1996. Levels", BCP 14, RFC 2119, March 1997.
[2] D. Durham et al., "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[3] S. Herzog et al., "COPS usage for RSVP", RFC 2749, January [2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
2000. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[4] L-N. Hamer et al. "Session Authorization for RSVP", Internet- [3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A.
Draft, draft-ietf-rap-rsvp-authsession-03.txt, June 2002. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
Framework for session set-up with media authorization [4] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[5] M. Handley and V. Jacobson, "SDP: session description [5] Handley, M. and V. Jacobson, "SDP: session description
protocol," RFC 2327, Apr.1998. protocol," RFC 2327, April 1998.
[6] Handley, Schulzrinne, Schooler & Rosenberg, RFC 2543, "SIP: [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Session Initiation Protocol", March 1999. Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[7] R. Braden et al.,"Resource ReSerVation protocol (RSVP) -- [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
version 1 functional specification," RFC 2205, Sept.1997. "Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," RFC 2205, September 1997.
[8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, [8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000. January 2000.
[9] K. Chan et al., "COPS Usage for Policy Provisioning (COPS-PR)", [9] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
RFC 3084, March 2001. Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
11. Informative References 11. Informative References
[10] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, [10] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
August 2000. G., de Bruijn, B., de Laat, C., Holdrege, M. and P. Spence, "AAA
Authorization Framework", RFC 2904, August 2000.
[11] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August [11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D.
2000. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[12] "PacketCable Dynamic Quality of Service Specification", [12] "PacketCable Dynamic Quality of Service Specification",
CableLabs, December 1999. CableLabs, December 1999.
[13] F. Baker et al., "RSVP Cryptographic Authentication", RFC2747, [13] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
January 2000. Authentication", RFC 2747, January 2000.
[14] Atkinson, R., "Security Architecture for the Internet [14] Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", RFC 1825, August 1995. Internet Protocol", RFC 2401, November 1998.
Acknowledgments 12. Acknowledgments
The authors would like to thank to following people for their useful The authors would like to thank to following people for their useful
comments and suggestions related to this document: Kwok Ho Chan, comments and suggestions related to this document: Kwok Ho Chan, Doug
Doug Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois
Francois Audet, Bill Marshall, Diana Rawlins and many others. Audet, Bill Marshall, Diana Rawlins and many others.
Framework for session set-up with media authorization
Authors' Addresses 13. Authors' Addresses
Louis-Nicolas Hamer Louis-Nicolas Hamer
Nortel Networks Nortel Networks
PO Box 3511 Station C PO Box 3511 Station C
Ottawa, ON Ottawa, ON
CANADA K1Y 4H7 CANADA K1Y 4H7
Email: nhamer@nortelnetworks.com
Phone: +1 613.768.3409 Phone: +1 613.768.3409
EMail: nhamer@nortelnetworks.com
Bill Gage Bill Gage
Nortel Networks Nortel Networks
PO Box 3511 Station C PO Box 3511 Station C
Ottawa, ON Ottawa, ON
CANADA K1Y 4H7 CANADA K1Y 4H7
Email: gageb@nortelnetworks.com
Phone: +1 613.763.4400 Phone: +1 613.763.4400
EMail: gageb@nortelnetworks.com
Hugh Shieh Hugh Shieh
AT&T Wireless AT&T Wireless
7277 164th Avenue NE 7277 164th Avenue NE
Redmond, WA Redmond, WA
USA 98073-9761 USA 98073-9761
Email: hugh.shieh@attws.com
Phone: +1 425.580.6898 Phone: +1 425.580.6898
EMail: hugh.shieh@attws.com
Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. This Copyright (C) The Internet Society (2003). All Rights Reserved.
document and translations of it may be copied and furnished to
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into. followed, or as required to translate it into languages other than
English.
RFC Editor Considerations The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document references an IETF Internet-Draft that is in the IESG This document and the information contained herein is provided on an
last call stage. Please use the corresponding RFC number prior to "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
publishing of this document as a RFC. The referenced IETF I-D is TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
[4]. 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.
 End of changes. 207 change blocks. 
508 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/