Identity Representation for RSVP
RFC 2752

Document Type RFC - Proposed Standard (January 2000; No errata)
Obsoleted by RFC 3182
Authors Shai Herzog  , Raj Yavatkar  , Ramesh Pabbati  , Tim Moore  , Satyendra Yadav  , Peter Ford 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2752 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           S. Yadav
Request for Comments: 2752                                   R. Yavatkar
Category: Standards Track                                          Intel
                                                              R. Pabbati
                                                                 P. Ford
                                                                T. Moore
                                                               S. Herzog
                                                            January 2000

                    Identity Representation for RSVP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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


   This document describes the representation of identity information in
   POLICY_DATA object [POL-EXT] for supporting policy based admission
   control in RSVP. The goal of identity representation is to allow a
   process on a system to securely identify the owner and the
   application of the communicating process (e.g. user id) and convey
   this information in RSVP messages (PATH or RESV) in a secure manner.
   We describe the encoding of identities as RSVP policy element. We
   describe the processing rules to generate identity policy elements
   for multicast merged flows. Subsequently, we describe representations
   of user identities for Kerberos and Public Key based user
   authentication mechanisms. In summary we describe the use of this
   identity information in an operational setting.

1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC-2119].

Yadav, et al.               Standards Track                     [Page 1]
RFC 2752            Identity Representation for RSVP        January 2000

2. Introduction

   RSVP [RFC 2205] is a resource reservation setup protocol designed for
   an integrated services Internet [RFC 1633]. RSVP is used by a host to
   request specific quality of service (QoS) from the network for
   particular application data streams or flows. RSVP is also used by
   routers to deliver QoS requests to all nodes along the path(s) of the
   flows and to establish and maintain state to provide the requested
   service. RSVP requests will generally result in resources being
   reserved in each node along the data path. RSVP allows particular
   users to obtain preferential access to network resources, under the
   control of an admission control mechanism. Permission to make a
   reservation is based both upon the availability of the requested
   resources along the path of the data and upon satisfaction of policy
   rules. Providing policy based admission control mechanism based on
   user identity or application is one of the prime requirements.

   In order to solve these problems and implement identity based policy
   control it is required to identify the user and/or application making
   a RSVP request.

   This document proposes a mechanism for sending identification
   information in the RSVP messages and enables authorization decisions
   based on policy and identity.

   We describe the authentication policy element (AUTH_DATA) contained
   in the POLICY_DATA object. User process can generate an AUTH_DATA
   policy element and gives it to RSVP process (service) on the
   originating host. RSVP service inserts AUTH_DATA into the RSVP
   message to identify the owner (user and/or application) making the
   request for network resources. Network elements, such as routers,
   authenticate request using the credentials presented in the AUTH_DATA
   and admit the RSVP message based on admission policy. After a request
   has been authenticated, first hop router installs the RSVP state and
   forwards the new policy element returned by the Policy Decision Point

3. Policy Element for Authentication Data

3.1 Policy Data Object Format

   POLICY_DATA objects contain policy information and are carried by
   RSVP messages. A detail description of the format of POLICY_DATA
   object can be found in "RSVP Extensions for Policy Control" [POL-

Yadav, et al.               Standards Track                     [Page 2]
RFC 2752            Identity Representation for RSVP        January 2000

3.2 Authentication Data Policy Element
Show full document text