RFC 3182

Identity Representation for RSVP

📅 published October 2001, from ietf

RFC 3182: Identity Representation for RSVP 💖

  • Network Working Group 🎀
  • Category: Standards Track ✨
  • Date: October 2001 📅
  • Obsoletes: RFC 2752 (this one fixes a couple of mistakes in it, so it's a big deal 💅)
  • Authors: S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess 🫶
  • Affiliations: Intel, Microsoft, and PolicyConsulting.Com 🏢

Status of this Memo 📜

Okay so this doc is an Internet standards track protocol spec for the Internet community 🌐. It's also asking people to talk about it and send ideas for making it better, which is so sweet 🥹. If you want to know where it stands in the official standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with everyone 🦋.

Copyright (C) The Internet Society (2001). All Rights Reserved. 🌸

Abstract 🌟

Okay, the main vibe of this doc is putting identity info inside a POLICY_DATA object 🔐. The whole point is to support policy-based admission control in the Resource ReSerVation Protocol (RSVP) 🚦. The goal is for a process on a system to securely figure out who owns the communicating process and what application it is, like a user id, and then send that info in RSVP messages (PATH or RESV) safely 🔒. We cover how identities get encoded as an RSVP policy element 💜, the rules for making identity policy elements for multicast merged flows 🌊, and how user identities work for Kerberos and public key based user authentication ✨. Last but not least, we explain how all of this identity info gets used in a real operational setting 👑.

This memo also fixes two mistakes in RFC 2752 🙈. One is a POLICY_DATA P-Type codepoint assignment error, and the other is a field size definition error in ErrorValue 💀.

1. Conventions used in this document 📝

Here's the key-word situation 🔑. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are read exactly the way they're described in [RFC 2119] 🧐. Don't skip that reference, bestie!

2. Introduction 🎀

Okay so RSVP [RFC 2205] is a resource reservation setup protocol that was built for an integrated services Internet [RFC 1633] 🌈. Hosts use RSVP to ask the network for a specific quality of service (QoS) for certain application data streams or flows 🎯. Routers use it too, to send those QoS requests to every node along the path(s) of the flows and to set up and maintain the state needed to deliver the service ✨. Basically, RSVP requests usually end up reserving resources at every node along the data path 🛤️. It lets certain users get preferential access to network resources, but only under an admission control mechanism 👀. Getting a reservation depends on two things: whether the requested resources are actually available along the data path, and whether the policy rules are satisfied 💅. Being able to do policy-based admission control based on user identity or application is honestly one of the biggest priorities 👑.

To make this work, you have to identify the user and/or application that's making the RSVP request, because that's what identity-based policy control is built on 🔍.

This doc proposes a way to send identification info inside RSVP messages 📨. That info is what lets routers make authorization decisions based on policy and identity 🦋.

Here's the flow. We describe the authentication policy element (AUTH_DATA) that sits inside the POLICY_DATA object 🧚. A user process can generate an AUTH_DATA policy element and hand it to the RSVP process (service) on the originating host 💌. The RSVP service then puts that AUTH_DATA into the RSVP message, so it identifies who (the user and/or application) is asking for network resources 🫶. Network elements, like routers, check the request using the credentials in AUTH_DATA and decide whether to admit the RSVP message based on admission policy 🔐. Once a request is authenticated, the first hop router installs the RSVP state and forwards the new policy element that comes back from the Policy Decision Point (PDP) [POL-FRAME] 🚀.

3. Policy Element for Authentication Data 🧸

3.1 Policy Data Object Format 📦

POLICY_DATA objects hold policy info and travel inside RSVP messages 🚚. If you want the full format details, go read "RSVP Extensions for Policy Control" [POL-EXT] 📖.

3.2 Authentication Data Policy Element 🔐

This section covers a policy element (PE) called authentication data (AUTH_DATA) 💜. An AUTH_DATA policy element holds a list of authentication attributes 🎀.

+-------------+-------------+-------------+-------------+
| Length                    | P-Type = Identity Type    |
+-------------+-------------+-------------+-------------+
// Authentication Attribute List                       //
+-------------------------------------------------------+

Length: The length of the policy element is counted in octets, and it includes the Length and P-Type fields 📏. This value MUST be a multiple of 4 ✅, and it marks where the authentication attribute list ends 🏁.

P-Type (Identity Type): This tells you what kind of identity info the policy element carries, and it's passed in as the policy element type (P-type) 🪪. The Internet Assigned Numbers Authority (IANA) keeps the registry for identity policy element types, as described in [POL-EXT] 🗂️. At the start, the registry has these P-Types for identity:

2   AUTH_USER       Authentication scheme to identify users

3   AUTH_APP        Authentication scheme to identify
                    applications

Authentication Attribute List: Attributes hold info that's specific to the authentication method and the type of AUTH_DATA 🧩. The policy element is what groups a bunch of authentication attributes together 💞.

3.3 Authentication Attributes 🧁

Authentication attributes MUST be encoded as a multiple of 4 octets 🔢. Any attribute that isn't a multiple of 4 octets long MUST be padded out to a 4-octet boundary 🩹.

+--------+--------+--------+--------+
| Length          | A-Type |SubType |
+--------+--------+--------+--------+
| Value ...
+--------+--------+--------+--------+

Length: The length field is two octets long, and it counts the whole attribute in octets, including the Length and A-Type fields 📐. It does NOT count any padding bytes added to the value field to make the attribute a multiple of 4 octets 🙅‍♀️.

A-Type: The authentication attribute type (A-Type) field is one octet 🔤. IANA keeps the registry for A-Types, as described in section 8, IANA Considerations 🗂️. At the start, the registry has these A-Types:

1  POLICY_LOCATOR      Unique string for locating the
                       admission policy (such as X.500 DN
                       described in [RFC 1779]).

2  CREDENTIAL          User credential such as Kerberos
                       ticket, or digital certificate.
                       Application credential such as
                       application ID.

3  DIGITAL_SIGNATURE   Digital signature of the
                       authentication data policy element.

4  POLICY_ERROR_OBJECT Detailed information on policy
                       failures.

SubType: The authentication attribute sub-type field is one octet 🎯. What the SubType means depends on the A-type 💫.

Value: This field holds the attribute-specific info 💎.

3.3.1 Policy Locator 📍

POLICY_LOCATOR is how you find the admission policy for a user or application 🗺️. A Distinguished Name (DN) is unique for each user or application, so a DN is what gets used as the policy locator 🪄.

+-------+-------+-------+-------+
| Length        |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------

Length: This is the attribute length, and it MUST be >= 4 📏.

A-Type: POLICY_LOCATOR 🏷️.

SubType: These POLICY_LOCATOR sub-types are defined. IANA keeps the registry for POLICY_LOCATOR sub-types, as described in section 8, IANA Considerations 🗂️. At the start, the registry has these sub-types for POLICY_LOCATOR:

1  ASCII_DN            OctetString contains the X.500 DN as
                       described in the RFC 1779 as an ASCII
                       string.

2  UNICODE_DN          OctetString contains the X.500 DN described
                       in the RFC 1779 as an UNICODE string.

3  ASCII_DN_ENCRYPT    OctetString contains the encrypted X.500
                       DN.  The Kerberos session key or digital
                       certificate private key is used for
                       encryption.  For Kerberos encryption the
                       format is the same as returned from
                       gss_seal [RFC 1509].

4  UNICODE_DN_ENCRYPT  OctetString contains the encrypted UNICODE
                       X.500 DN.  The Kerberos session key or
                       digital certificate private key is used for
                       encryption.  For Kerberos encryption the
                       format is the same as returned from
                       gss_seal [RFC 1509].

OctetString: This field holds the DN 🧾.

3.3.2 Credential 🪪

CREDENTIAL tells you the credential of the user or application that's getting authenticated 🕵️‍♀️. With Kerberos, the CREDENTIAL object holds the Kerberos session ticket 🎟️. With public key based authentication, this field holds a digital certificate 📜.

Here's a quick look at the CREDENTIAL attribute format. The fields go left to right ➡️.

+-------+-------+-------+-------+
| Length        |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------

Length: This is the attribute length, and it MUST be >= 4 📏.

A-Type: CREDENTIAL 🏷️.

SubType: IANA keeps the registry for CREDENTIAL sub-types, as described in section 8, IANA Considerations 🗂️. At the start, the registry has these sub-types for CREDENTIAL:

1  ASCII_ID       OctetString contains user or application
                  identification in plain ASCII text string.

2  UNICODE_ID     OctetString contains user or application
                  identification in plain UNICODE text string.

3  KERBEROS_TKT   OctetString contains Kerberos ticket.

4  X509_V3_CERT   OctetString contains X.509 V3 digital
                  certificate [X.509].

5  PGP_CERT       OctetString contains PGP digital certificate.

OctetString: This field holds the user or application credential 🫧.

3.3.3 Digital Signature 💖

okay bestie, the DIGITAL_SIGNATURE attribute MUST be the last attribute in the attribute list, no exceptions 🙅‍♀️. It holds the digital signature of the AUTH_DATA policy element, and it signs all the data in that AUTH_DATA policy element up to the DIGITAL_SIGNATURE itself. The algorithm used for the signature depends on which authentication method is named in the CREDENTIAL SubType field 🔐.

here's the layout:

+-------+-------+-------+-------+
| Length        |A-Type |SubType|
+-------+-------+-------+-------+
| OctetString ...
+-------+-------+-------+--------
  • Length: Length of the attribute, which MUST be >= 4.
  • A-Type: DIGITAL_SIGNATURE
  • SubType: No sub types for DIGITAL_SIGNATURE are currently defined. This field MUST be set to 0. 🌸
  • OctetString: OctetString contains the digital signature of the AUTH_DATA.

3.3.4 Policy Error Object 🚨

this attribute carries any specific policy control errors that a node generates while it's processing or validating an Authentication Data Policy Element. When a RSVP policy node (a local policy decision point or a remote PDP) gets a request that fails policy control because of its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE with extra info about why things went wrong 😭. That then causes an appropriate PATH_ERROR or RESV_ERROR message to be generated, carrying the policy element and the right RSVP error code, and it gets sent back to the request's source 💌.

The AUTH_DATA policy element in the PATH or RSVP message SHOULD not contain the POLICY_ERROR_OBJECT attribute. These only get inserted into PATH_ERROR and RESV_ERROR messages when they're generated by policy aware intermediate nodes ✨.

+----------+----------+----------+----------+
| Length              | A-Type   | SubType  |
+----------+----------+----------+----------+
| 0 (Reserved)        | ErrorValue          |
+----------+----------+----------+----------+
| OctetString ...
+----------+----------+----------+----------+
  • Length: Length of the attribute, which MUST be >= 8.
  • A-Type: POLICY_ERROR_CODE
  • SubType: No sub types for POLICY_ERROR_CODE are currently defined. This field MUST be set to 0.
  • ErrorValue: A 16-bit bit code containing the reason that the policy decision point failed to process the policy element. IANA acts as a registry for ErrorValues as described in section 8, IANA Considerations. The following values have been defined 🎀:
1  ERROR_NO_MORE_INFO           No information is available.
2  UNSUPPORTED_CREDENTIAL_TYPE  This type of credentials is
                                not supported.

3  INSUFFICIENT_PRIVILEGES      The credentials do not have
                                sufficient privilege.

4  EXPIRED_CREDENTIAL           The credential has expired.

5  IDENTITY_CHANGED             Identity has changed.
  • OctetString: The OctetString field contains information from the policy decision point that MAY contain additional information about the policy failure. For example, it may include a human-readable message in the ASCII text 📝.

4. Authentication Data Formats 🌈

authentication attributes get grouped into a policy element so they can represent the identity credentials. it's giving organisation, honestly 🗂️.

4.1 Simple User Authentication 🦋

in simple user authentication, the user's login ID (plain ASCII or UNICODE text) gets encoded as a CREDENTIAL attribute. here's what the simple user AUTH_DATA policy element looks like:

+--------------+--------------+--------------+--------------+
| Length                      | P-type = AUTH_USER          |
+--------------+--------------+--------------+--------------+
| Length                      |POLICY_LOCATOR| SubType      |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length                      |CREDENTIAL    | ASCII_ID     |
+--------------+--------------+--------------+--------------+
| OctetString (User's login ID) ...
+--------------+--------------+--------------+--------------+

4.2 Kerberos User Authentication 🎫

Kerberos [RFC 1510] authentication uses a trusted third party (the Kerberos Distribution Center, or KDC) to authenticate the user to a network server. it's assumed that a KDC is present, and that both the host and the verifier of the authentication information (router or PDP) implement Kerberos authentication 🤝.

here's the Kerberos AUTH_DATA policy element:

+--------------+--------------+--------------+--------------+
| Length                      | P-type = AUTH_USER          |
+--------------+--------------+--------------+--------------+
| Length                      |POLICY_LOCATOR|   SubType    |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length                      | CREDENTIAL   | KERBEROS_TKT |
+--------------+--------------+--------------+--------------+
| OctetString (Kerberos Session Ticket) ...
+--------------+--------------+--------------+--------------+

4.2.1. Operational Setting using Kerberos Identities 🧠

an RSVP enabled host gets configured to construct and insert an AUTH_DATA policy element into RSVP messages that designate the Kerberos authentication method (KERBEROS_TKT). when an RSVP session starts up, the user application contacts the KDC to get a Kerberos ticket for the next network node or its PDP. a router, when it generates an RSVP message, does the same thing: it contacts the KDC to get a Kerberos ticket for the next hop network node or its PDP. the identity of the PDP or next network hop can be statically configured, learned via DHCP, or kept in a directory service 📚. the Kerberos ticket then gets sent to the next network node (which may be a router or host) in an RSVP message. the KDC is used to validate the ticket and authenticate the user who sent the RSVP message 🔍.

4.3 Public Key based User Authentication 🔑

in public key based user authentication, a digital certificate gets encoded as the user credentials, and a digital signature is used to authenticate the user 💎. here's the public key user AUTH_DATA policy element:

+--------------+--------------+--------------+--------------+
| Length                      | P-type = AUTH_USER          |
+--------------+--------------+--------------+--------------+
| Length                      |POLICY_LOCATOR|   SubType    |
+--------------+--------------+--------------+--------------+
| OctetString (User's Distinguished Name) ...
+--------------+--------------+--------------+--------------+
| Length                      | CREDENTIAL   |   SubType    |
+--------------+--------------+--------------+--------------+
| OctetString (User's Digital Certificate) ...
+--------------+--------------+--------------+--------------+
| Length                      |DIGITAL_SIGN. | 0            |
+--------------+--------------+--------------+--------------+
| OctetString (Digital signature) ...
+--------------+--------------+--------------+--------------+

4.3.1. Operational Setting for public key based authentication 🗝️

public key based authentication assumes the following:

  • RSVP service requestors have a pair of keys (a private key and a public key).
  • The private key is secured with the user.
  • Public keys are stored in digital certificates, and a trusted party, a certificate authority (CA), issues these digital certificates.
  • The verifier (PDP or router) has the ability to verify the digital certificate.

the RSVP requestor uses its private key to generate the DIGITAL_SIGNATURE. User Authenticators (router or PDP) use the user's public key (stored in the digital certificate) to verify the signature and authenticate the user 🫶.

4.4 Simple Application Authentication 🤖

the application authentication method encodes the application identification, such as an executable filename, as plain ASCII or UNICODE text.

+----------------+--------------+--------------+--------------+
| Length                        | P-type = AUTH_APP           |
+----------------+--------------+--------------+--------------+
| Length                        |POLICY_LOCATOR| SubType      |
+----------------+--------------+--------------+--------------+
| OctetString (Application Identity attributes in
|              the form of  a Distinguished Name) ...
+----------------+--------------+--------------+--------------+
| Length                        | CREDENTIAL   | ASCII_ID     |
+----------------+--------------+--------------+--------------+
| OctetString (Application Id, e.g., vic.exe)
+----------------+--------------+--------------+--------------+

5. Operation 🎬

  +-----+                                                  +-----+
  | PDP |-------+                                          | PDP |
  +-----+       |             ...................          +-----+
                |             :                 :          |
              +--------+      :     Transit     :        +-------+
         +----| Router |------:     Network     : -------| Router|--+
         |    +--------+      :                 :        +-------+  |
         |        |           :.................:             |     |
         |        |                                           |     |
    Host A        B                                           C     D

    Figure 1: User and Application Authentication using AUTH_DATA PE

network nodes (hosts or routers) generate AUTH_DATA policy elements, and what's in them depends on the identity type and the authentication method being used 🧩. these usually contain authentication credentials (a Kerberos ticket or a digital certificate) and policy locators (which can be the X.500 Distinguished Name of the user or network node, or application names). network nodes generate an AUTH_DATA policy element containing the authentication identity when they make an RSVP request or forward an RSVP message 📨.

network nodes generate the user AUTH_DATA policy element using these rules:

  1. For unicast sessions, the user policy locator is copied from the previous hop. The authentication credentials are for the current network node identity.
  2. For multicast messages, the user policy locator is for the current network node identity. The authentication credentials are for the current network node.

network nodes generate the application AUTH_DATA policy element using these rules:

  1. For unicast sessions, the application AUTH_DATA is copied from the previous hop.
  2. For multicast messages, the application AUTH_DATA is either the first application AUTH_DATA in the message or chosen by the PDP 👑.

6. Message Processing Rules 🧚

6.1 Message Generation (RSVP Host) 💌

Okay so when an RSVP host builds a message, it follows [RFC 2205] like normal, with a few extra twists 🎀

  1. An RSVP message MAY contain multiple AUTH_DATA policy elements. 🫶
  2. The authentication policy element (AUTH_DATA) gets created, and its IdentityType field says which identity type it's carrying 🪪
    • The DN goes in as the POLICY_LOCATOR attribute.
    • Credentials, like a Kerberos ticket or a digital certificate, go in as the CREDENTIAL attribute.
  3. The POLICY_DATA object (the one holding the AUTH_DATA policy element) gets slotted into the RSVP message in the right spot. If no INTEGRITY object was computed for the RSVP message, then an INTEGRITY object SHOULD be computed for this POLICY_DATA object, as described in the [POL_EXT], and SHOULD be inserted as a Policy Data option. 🔐

6.2 Message Reception (Router) 🛣️

Now the router gets the message and processes it as [RFC 2205] says, plus these tweaks 💅

  1. If the router isn't policy aware, it SHOULD send the RSVP message to the PDP and wait for a response. If the router is policy unaware, it just ignores the policy data objects and keeps on processing the RSVP message. 🙈
  2. If the PDP's response is negative, reject the message. ❌
  3. Otherwise, keep processing the RSVP message. ✨

6.3 Authentication (Router/PDP) 🕵️‍♀️

This is where the router and PDP team up to check who's who 👑

  1. Grab the AUTH_DATA policy element. Check the PE type field, and return an error if the identity type isn't supported. 🚫
  2. Verify the user's credential, which depends on the type:
    • Simple authentication: for example, get the user ID and validate it, or get the executable name and validate that.
    • Kerberos: send the Kerberos ticket to the KDC to get the session key. Then use that session key to authenticate the user. 🎟️
    • Public Key: make sure the certificate was issued by a trusted Certificate Authority (CA), then authenticate the user or application by verifying the digital signature. 🔏

7. Error Signaling ✨

Here's the drama moment. If the PDP fails to verify the AUTH_DATA policy element, it MUST return policy control failure (Error Code = 02) to the PEP. The error values are described in [RFC 2205] and [POL-EXT]. The PDP SHOULD also supply a policy data object containing an AUTH_DATA Policy Element with A-Type=POLICY_ERROR_CODE, which gives more details on the Policy Control failure (see section 3.3.4). The PEP will then include this Policy Data object in the outgoing RSVP Error message. 😭

8. IANA Considerations 🗂️

Following the policies in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action, as described in [POL-EXT]. So the P-Type values are:

  • P-Type AUTH_USER is assigned the value 2.
  • P-Type AUTH_APP is assigned the value 3.

Also following [IANA-CONSIDERATIONS], authentication attribute types (A-Type) in the range 0-127 are allocated through an IETF Consensus action, and A-Type values between 128-255 are reserved for Private Use and not assigned by IANA. The A-Types are:

  • A-Type POLICY_LOCATOR is assigned the value 1.
  • A-Type CREDENTIAL is assigned the value 2.
  • A-Type DIGITAL_SIGNATURE is assigned the value 3.
  • A-Type POLICY_ERROR_OBJECT is assigned the value 4.

Following the same policies, POLICY_LOCATOR SubType values in the range 0-127 are allocated through an IETF Consensus action, and POLICY_LOCATOR SubType values between 128-255 are reserved for Private Use and not assigned by IANA. The SubTypes are:

  • SubType ASCII_DN is assigned the value 1.
  • SubType UNICODE_DN is assigned the value 2.
  • SubType ASCII_DN_ENCRYPT is assigned the value 3.
  • SubType UNICODE_DN_ENCRYPT is assigned the value 4.

Once again following [IANA-CONSIDERATIONS], CREDENTIAL SubType values in the range 0-127 are allocated through an IETF Consensus action, and CREDENTIAL SubType values between 128-255 are reserved for Private Use and not assigned by IANA. The SubTypes are:

  • SubType ASCII_ID is assigned the value 1.
  • SubType UNICODE_ID is assigned the value 2.
  • SubType KERBEROS_TKT is assigned the value 3.
  • SubType X509_V3_CERT is assigned the value 4.
  • SubType PGP_CERT is assigned the value 5.

And following [IANA-CONSIDERATIONS] one more time, ErrorValues in the range 0-32767 are allocated through an IETF Consensus action, and ErrorValues between 32768-65535 are reserved for Private Use and not assigned by IANA. The ErrorValues are:

  • ErrorValue ERROR_NO_MORE_INFO is assigned the value 1.
  • UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2.
  • INSUFFICIENT_PRIVILEGES is assigned the value 3.
  • EXPIRED_CREDENTIAL is assigned the value 4.
  • IDENTITY_CHANGED is assigned the value 5.

9. Security Considerations 🔒

This is the part you really need to read, bestie 🚨 The whole point of this memo is to describe a way to authenticate RSVP requests based on user identity in a secure manner. The RSVP INTEGRITY object is what protects the policy object holding the user identity information from security (replay) attacks. When you combine the AUTH_DATA policy element with the INTEGRITY object, you get secure access control that enforces authentication based on both the identity of the user and the identity of the originating node. Iconic. 👑

Now the honest tea ☕ Simple authentication doesn't include a credential that can be securely authenticated, so it's inherently less secure.

The Kerberos authentication mechanism is reasonably well secured. 🎟️

User authentication using a public key certificate is known to provide the strongest security. 🏆

10. Acknowledgments 🫶

We would like to thank Andrew Smith, Bob Lindell and many others for their valuable comments on this memo. You all are the real MVPs ✨

11. References 📚

[ASCII]               Coded Character Set -- 7-Bit American Standard
                      Code for Information Interchange, ANSI X3.4-
                      1986.

[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
                      Writing an IANA Considerations Section in
                      RFCs", BCP 26, RFC 2434, October 1998.

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

[POL-FRAME]           Yavatkar, R., Pendarakis, D. and R. Guerin, "A
                      Framework for Policy-based Admission Control
                      RSVP", RFC 2753, January 2000.

[RFC 1510]            Kohl, J. and C. Neuman, "The Kerberos Network
                      Authentication Service (V5)", RFC 1510,
                      September 1993.

[RFC 1704]            Haller, N. and R. Atkinson, "On Internet
                      Authentication", RFC 1704, October 1994.

[RFC 1779]            Killie, S., "A String Representation of
                      Distinguished Names", RFC 1779, March 1995.

[RFC 2205]            Braden, R., Zhang, L., Berson, S., Herzog, S.
                      and S. Jamin, "Resource ReSerVation Protocol
                      (RSVP) - Version 1 Functional Specification",
                      RFC 2205, September 1997.

[RFC 2209]            Braden, R. and L. Zhang, "Resource ReSerVation
                      Protocol (RSVP) - Version 1 Message Processing
                      Rules", RFC 2209, September 1997.

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

[RFC 2751]            Herzog, S., "Signaled Preemption Priority
                      Policy Element", RFC 2751, January 2000.

[UNICODE]             The Unicode Consortium, "The Unicode Standard,
                      Version 2.0", Addison-Wesley, Reading, MA,
                      1996.

[X.509]               Housley, R., Ford, W., Polk, W. and D. Solo,
                      "Internet X.509 Public Key Infrastructure
                      Certificate and CRL Profile", RFC 2459, January
                      1999.

[X.509-ITU]           ITU-T (formerly CCITT) Information technology -
                      Open Systems Interconnection - The Directory:
                      Authentication Framework Recommendation X.509
                      ISO/IEC 9594-8

12. Authors' Addresses 🧑‍💻

Satyendra Yadav
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124

EMail: Satyendra.Yadav@intel.com

Raj Yavatkar
Intel, JF3-206
2111 NE 25th Avenue
Hillsboro, OR 97124

EMail: Raj.Yavatkar@intel.com

Ramesh Pabbati
Microsoft
1 Microsoft Way
Redmond, WA 98054

EMail: rameshpa@microsoft.com

Peter Ford
Microsoft
1 Microsoft Way
Redmond, WA 98054

EMail: peterf@microsoft.com

Tim Moore
Microsoft
1 Microsoft Way
Redmond, WA 98054

EMail: timmoore@microsoft.com

Shai Herzog
PolicyConsulting.Com
200 Clove Rd.
New Rochelle, NY 10801

EMail: herzog@policyconsulting.com

Rodney Hess
Intel, BD1
28 Crosby Drive
Bedford, MA 01730

EMail: rodney.hess@intel.com

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

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

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

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

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ✨🦋

📦 where this page comes from