draft-ietf-rap-rsvp-appid-00.txt   rfc2872.txt 
Y.Bernet, Microsoft
R. Pabbati, Microsoft
Internet Draft October, 1999
Document: draft-ietf-rap-rsvp-appid-00.txt expires April, 2000
Application and Sub Application Identity Policy Element for Use with Network Working Group Y. Bernet
RSVP Request for Comments: 2872 R. Pabbati
Category: Standards Track Microsoft
Status of this Memo June 2000
This document is an Internet-Draft and is in full conformance with Application and Sub Application Identity Policy Element for
all provisions of Section 10 of RFC2026. Use with RSVP
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This document specifies an Internet standards track protocol for the
months and may be updated, replaced, or obsoleted by other documents Internet community, and requests discussion and suggestions for
at any time. It is inappropriate to use Internet- Drafts as improvements. Please refer to the current edition of the "Internet
reference material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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.
Distribution of this memo is unlimited. Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright Notice Conventions used in this document
Copyright (C) The Internet Society (1998). All Rights Reserved. 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].
1. Abstract Abstract
RSVP [RFC 2205] signaling messages typically include policy data RSVP [RFC 2205] signaling messages typically include policy data
objects, which in turn contain policy elements. Policy elements may objects, which in turn contain policy elements. Policy elements may
describe user and/or application information, which may be used by describe user and/or application information, which may be used by
RSVP aware network elements to apply appropriate policy decisions to RSVP aware network elements to apply appropriate policy decisions to
a traffic flow. This informational draft details the usage of policy a traffic flow. This memo details the usage of policy elements that
elements that provide application information. provide application information.
2. Overview 1. Overview
RSVP aware network elements may act as policy enforcement points RSVP aware network elements may act as policy enforcement points
(PEPs). These work together with policy decision points (PDPs) to (PEPs). These work together with policy decision points (PDPs) to
enforce QoS policy. Briefly, PEPs extract policy information from enforce QoS policy. Briefly, PEPs extract policy information from
RSVP signaling requests and compare the information against RSVP signaling requests and compare the information against
information stored in a policy database or directory. A policy information stored by a PDP in a (possibly remotely located) policy
decision is made based on the results of the comparison. database or directory. A policy decision is made based on the results
of the comparison.
bernet 1
draft-ietf-rap-rsvp-appid-00.txt October, 1999
One type of policy information describes the application on behalf One type of policy information describes the application on behalf of
of which an RSVP signaling request is generated. When application which an RSVP signaling request is generated. When application policy
policy information is available, network administrators are able to information is available, network administrators are able to manage
manage QoS based on application type. So for example, a network QoS based on application type. So, for example, a network
administrator may establish a policy that prioritizes known mission administrator may establish a policy that prioritizes known mission-
critical applications over games. critical applications over games.
We propose a hierarchical structure for application policy elements. This memo describes a structure for a policy element that can be used
Specifically, the highest level of the hierarchy specifies an to identify application traffic flows. The policy element includes a
application name. The next level specifies a version. At the next number of attributes, one of which is a policy locator. This policy
level, an arbitrary number of sub-applications may be specified. An locator includes the following hierarchically ordered sub-elements
example of a sub-application is 'print data'. (in descending levels of hierarchy):
In this draft, we show the structure of the application policy 1. identifier that uniquely identifies the application vendor
element. We also propose keywords for the various levels of the 2. identifier of the application
hierarchy. However, we do not enumerate values for applications, 3. version number of the application
version numbers or sub-applications. Such an enumeration is beyond 4. sub-application identifier
the scope of this draft.
3. Application Policy Element Structure An arbitrary number of sub-application identifiers may be included in
the policy locator. An example of such an identifier is 'print
transaction'.
General application policy elements are defined in [identity]. These This memo specifies the structure of the application policy element
are policy elements with a P-type of AUTH_APP (value 3). Following and proposes keywords for the sub-elements at each level of the
the policy element header is a list of authentication attributes. hierarchy. It does not enumerate specific values for the sub-
elements: such an enumeration is beyond the scope of this memo.
The first authentication attribute should be of the A-type 2. Simple Application Identity Policy Element Structure
POLICY_LOCATOR (value 1). The sub-type of the POLICY_LOCATOR
attribute should be of type ASCII_DN (value 1) [RFC 1779]. The
actual attribute data is formatted as an X.500 distinguished name
(DN), representing the application, version number and sub-
application.
The second authentication attribute should be of the A-type General application identity policy elements are defined in
CREDENTIAL (value 2). The sub-type of the CREDENTIAL attribute is of [RFC2752]. These are policy elements with a P-type of AUTH_APP.
type ASCII_ID. The actual attribute data is an ASCII string Following the policy element header is a list of authentication
representing the application name. attributes.
This structure is illustrated in the following diagram: 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].
bernet 2 The second authentication attribute is of the A-type CREDENTIAL. The
draft-ietf-rap-rsvp-appid-00.txt October, 1999 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:
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Length (8) | P-type = AUTH_APP |
| PE Length (8) | P-type = 3 (AUTH_APP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = | Sub-type = |
| Attribute Length | A-type = 1 | Sub-type = 1 |
| | POLICY_LOCATOR| ASCII_DN | | | POLICY_LOCATOR| ASCII_DN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application policy locator attribute data in X.500 DN format | | Application policy locator attribute data in X.500 DN format |
| (see below) | | (see below) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = | Sub-type = |
| Attribute Length | A-type = 2 | Sub-type = 1 |
| | CREDENTIAL | ASCII_ID | | | CREDENTIAL | ASCII_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application name as ASCII string | | Application name as ASCII string |
| (e.g. SAP.EXE) | | (e.g. SAP.EXE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The policy locator attribute for an application policy element is The following keywords are recommended although others MAY be used:
conformant with the X.500 DN format[RFC 1779]. We propose the
following keywords:
Key Attribute Key Attribute
-------------- --------------
GUID Globally Unique Identifier (optional)
APP Application Name APP Application Name
VER Application Version Number VER Application Version Number
SAPP Sub Application SAPP Sub Application (optional)
The following is an example of a conformant policy locator: The following are examples of conformant policy locators:
APP=SAP, VER=1.1, SAPP=Print "APP=SAP, VER=1.1, SAPP=Print"
4. Security Considerations "GUID=http://www.microsoft.com/apps, APP=MyApplication, VER=1.2.3"
The proposed simple policy element does not guarantee that element The APP, VER and SAPP attributes SHOULD describe the application to a
is indeed associated with the application it claims to be associated 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.
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 with. In order to provide such guarantees, it is necessary to sign
applications. Signed application policy elements may be proposed at applications. Signed application policy elements may be proposed at a
a future date. Note that typically, the application policy element future date. Note that, typically, the application policy element
will be included in an RSVP message with an encrypted and will be included in an RSVP message with an encrypted and
authenticated user policy element. A level of security is provided authenticated user policy element. A level of security is provided by
by trusting the application policy element only if the user policy trusting the application policy element only if the user policy
element is trusted. element is trusted.
All RSVP integrity considerations apply to the message containing All RSVP integrity considerations apply to the message containing the
the application policy element. application policy element.
5. References 4. References
[RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) [RFC2205] Braden, R., Zhang, L., Berson, L., Herzog, S. and S. Jamin,
- Version 1 Functional Specification", RFC 2205, September 1997. "Resource Reservation Protocol (RSVP) - Version 1
Functional Specification", RFC 2205, September 1997.
bernet 3 [RFC1779] Kille, S., "A String Representation of Distinguished
draft-ietf-rap-rsvp-appid-00.txt October, 1999 Names", RFC 1779, March 1995.
[RFC-1779], Kille, S., A String Representation of Distinguished [RFC2752] Yadav, S., Yavatkar, R., Pabbati, R,. Ford, P., Moore, T.
Names, March 1995 and S. Herzog, "Identity Representation for RSVP", RFC
2752, January 2000.
[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, [ASCII] Coded Character Set -- 7-Bit American Standard Code for
T., Herzog, S., "Identity Representation for RSVP", Internet Draft, Information Interchange, ANSI X3.4-1986.
February 1999.
6. Acknowledgments [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996.
Thanks to Tim Moore and Shai Mohaban for their input. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7. Author's Addresses 5. Acknowledgments
Bernet, Yoram Thanks to Tim Moore, Shai Mohaban, Andrew Smith, Ulrich Homann and
other contributors to the IETF's RAP WG for their input.
6. Authors' Addresses
Yoram Bernet
Microsoft Microsoft
One Microsoft Way, One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 936-9568 Phone: (425) 936-9568
Email: yoramb@microsoft.com EMail: yoramb@microsoft.com
Pabbati, Ramesh Ramesh Pabbati
One Microsoft Way, One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: rameshpa@microsoft.co
This draft expires April, 2000 EMail: rameshpa@microsoft.com
bernet 4 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.
 End of changes. 60 change blocks. 
119 lines changed or deleted 119 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/