summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2872.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2872.txt')
-rw-r--r--doc/rfc/rfc2872.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2872.txt b/doc/rfc/rfc2872.txt
new file mode 100644
index 0000000..d179493
--- /dev/null
+++ b/doc/rfc/rfc2872.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group Y. Bernet
+Request for Comments: 2872 R. Pabbati
+Category: Standards Track Microsoft
+ June 2000
+
+
+ Application and Sub Application Identity Policy Element for
+ Use with 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.
+
+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 [RFC2119].
+
+Abstract
+
+ RSVP [RFC 2205] signaling messages typically include policy data
+ objects, which in turn contain policy elements. Policy elements may
+ describe user and/or application information, which may be used by
+ RSVP aware network elements to apply appropriate policy decisions to
+ a traffic flow. This memo details the usage of policy elements that
+ provide application information.
+
+1. Overview
+
+ RSVP aware network elements may act as policy enforcement points
+ (PEPs). These work together with policy decision points (PDPs) to
+ enforce QoS policy. Briefly, PEPs extract policy information from
+ RSVP signaling requests and compare the information against
+ information stored by a PDP in a (possibly remotely located) policy
+ database or directory. A policy decision is made based on the results
+ of the comparison.
+
+
+
+
+
+
+Bernet & Pabbati Standards Track [Page 1]
+
+RFC 2872 Application Identifiers for RSVP June 2000
+
+
+ One type of policy information describes the application on behalf of
+ which an RSVP signaling request is generated. When application policy
+ information is available, network administrators are able to manage
+ QoS based on application type. So, for example, a network
+ administrator may establish a policy that prioritizes known mission-
+ critical applications over games.
+
+ This memo describes a structure for a policy element that can be used
+ to identify application traffic flows. The policy element includes a
+ number of attributes, one of which is a policy locator. This policy
+ locator includes the following hierarchically ordered sub-elements
+ (in descending levels of hierarchy):
+
+ 1. identifier that uniquely identifies the application vendor
+ 2. identifier of the application
+ 3. version number of the application
+ 4. sub-application identifier
+
+ An arbitrary number of sub-application identifiers may be included in
+ the policy locator. An example of such an identifier is 'print
+ transaction'.
+
+ This memo specifies the structure of the application policy element
+ and proposes keywords for the sub-elements at each level of the
+ hierarchy. It does not enumerate specific values for the sub-
+ elements: such an enumeration is beyond the scope of this memo.
+
+2. Simple Application Identity Policy Element Structure
+
+ General application identity policy elements are defined in
+ [RFC2752]. These are policy elements with a P-type of AUTH_APP.
+ Following the policy element header is a list of authentication
+ attributes.
+
+ The first authentication attribute is of the A-type POLICY_LOCATOR.
+ The sub-type of the POLICY_LOCATOR attribute is of type ASCII_DN
+ [RFC1779] or UNICODE_DN. The actual attribute data is formatted as an
+ X.500 distinguished name (DN), representing a globally unique
+ identifier, the application, version number and sub-application in a
+ hierarchical structure. The POLICY_LOCATOR attribute contains
+ keywords as described in section 2. For further details on the format
+ of the POLICY_LOCATOR attribute, see [RFC2752].
+
+ The second authentication attribute is of the A-type CREDENTIAL. The
+ sub-type of the CREDENTIAL attribute is of type ASCII_ID or
+ UNICODE_ID. The actual attribute data is an ASCII or Unicode string
+ representing the application name. This structure is illustrated in
+ the following diagram:
+
+
+
+Bernet & Pabbati Standards Track [Page 2]
+
+RFC 2872 Application Identifiers for RSVP June 2000
+
+
+ 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PE Length (8) | P-type = AUTH_APP |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length | A-type = | Sub-type = |
+ | | POLICY_LOCATOR| ASCII_DN |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Application policy locator attribute data in X.500 DN format |
+ | (see below) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attribute Length | A-type = | Sub-type = |
+ | | CREDENTIAL | ASCII_ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Application name as ASCII string |
+ | (e.g. SAP.EXE) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The following keywords are recommended although others MAY be used:
+
+ Key Attribute
+ --------------
+ GUID Globally Unique Identifier (optional)
+ APP Application Name
+ VER Application Version Number
+ SAPP Sub Application (optional)
+
+ The following are examples of conformant policy locators:
+
+ "APP=SAP, VER=1.1, SAPP=Print"
+
+ "GUID=http://www.microsoft.com/apps, APP=MyApplication, VER=1.2.3"
+
+ The APP, VER and SAPP attributes SHOULD describe the application to a
+ human reader in as unique and unambiguous a way as possible. The GUID
+ attribute MAY be used when absolute uniqueness of application
+ identification is required and its contents MUST be an identifier
+ from a globally-unique source (e.g. domain names as assigned by the
+ corresponding registration authorities). Note that publication of the
+ chosen identifiers in a suitable format is strongly encouraged.
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati Standards Track [Page 3]
+
+RFC 2872 Application Identifiers for RSVP June 2000
+
+
+3. Security Considerations
+
+ The proposed simple policy element does not guarantee that element is
+ indeed associated with the application it claims to be associated
+ with. In order to provide such guarantees, it is necessary to sign
+ applications. Signed application policy elements may be proposed at a
+ future date. Note that, typically, the application policy element
+ will be included in an RSVP message with an encrypted and
+ authenticated user policy element. A level of security is provided by
+ trusting the application policy element only if the user policy
+ element is trusted.
+
+ All RSVP integrity considerations apply to the message containing the
+ application policy element.
+
+4. References
+
+ [RFC2205] Braden, R., Zhang, L., Berson, L., Herzog, S. and S. Jamin,
+ "Resource Reservation Protocol (RSVP) - Version 1
+ Functional Specification", RFC 2205, September 1997.
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC2752] Yadav, S., Yavatkar, R., Pabbati, R,. Ford, P., Moore, T.
+ and S. Herzog, "Identity Representation for RSVP", RFC
+ 2752, January 2000.
+
+ [ASCII] Coded Character Set -- 7-Bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
+ 2.0", Addison-Wesley, Reading, MA, 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5. Acknowledgments
+
+ Thanks to Tim Moore, Shai Mohaban, Andrew Smith, Ulrich Homann and
+ other contributors to the IETF's RAP WG for their input.
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati Standards Track [Page 4]
+
+RFC 2872 Application Identifiers for RSVP June 2000
+
+
+6. Authors' Addresses
+
+ Yoram Bernet
+ Microsoft
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: (425) 936-9568
+ EMail: yoramb@microsoft.com
+
+
+ Ramesh Pabbati
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: rameshpa@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati Standards Track [Page 5]
+
+RFC 2872 Application Identifiers for RSVP June 2000
+
+
+7. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati Standards Track [Page 6]
+