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 Microsoft S. Herzog IPHighway 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. Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 (PDP) [POL-FRAME]. 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- EXT]. Yadav, et al. Standards Track [Page 2] RFC 2752 Identity Representation for RSVP January 2000 3.2 Authentication Data Policy ElementShow full document text