Internet DRAFT - draft-bernet-appid
draft-bernet-appid
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:49:01 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 02 Mar 1999 22:29:04 GMT
ETag: "2e6ffb-1e0c-36dc6630"
Accept-Ranges: bytes
Content-Length: 7692
Connection: close
Content-Type: text/plain
Y.Bernet, Microsoft
Internet Draft February, 1999
Document: draft-bernet-appid-00.txt expires August, 1999
Application and Sub Application Identity Policy Element for Use with
RSVP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
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
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. 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 informational draft details the usage of policy
elements that provide application information.
2. 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, in conjunction with PDPs extract
policy information from RSVP signaling requests and compare the
information against information stored in a policy database or
directory. A policy decision is made based on the results of the
comparison.
bernet 1
draft-bernet-appid-00.txt February, 1999
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.
We propose a hierarchical structure for the attributes carried in
the application policy elements. Specifically, the highest level of
the hierarchy specifies an application name. The next level
specifies a version. At the next level, an arbitrary number of sub-
applications may be specified. An example of a sub-application is
æprint dataÆ.
In this draft, we show the structure of the application policy
element. We also propose keywords for the various levels of the
hierarchy. However, we do not enumerate values for applications,
version numbers or sub-applications. Such an enumeration is beyond
the scope of this draft.
3. Application Policy Element Structure
General application policy elements are defined in [identity]. These
are policy elements with a P-type of AUTH_APP (value 3). Following
the policy element header is a list of authentication attributes.
The first authentication attribute should be of the A-type
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 name, version number and sub-
application name.
The second authentication attribute should be of the A-type
CREDENTIAL (value 2). The sub-type of the CREDENTIAL attribute is of
type ASCII_ID. The actual attribute data is an ASCII string
representing the application name.
This structure is illustrated in the following diagram:
bernet 2
draft-bernet-appid-00.txt February, 1999
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Length (8) | P-type = 3 (AUTH_APP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = 1 | Sub-type = 1 |
| | POLICY_LOCATOR| ASCII_DN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application policy locator attribute data in X.500 DN format |
| (see below) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = 2 | Sub-type = 1 |
| | CREDENTIAL | ASCII_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application name as ASCII string |
| (e.g. SAP.EXE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The policy locator attribute for an application policy element is
conformant with the X.500 DN format[RFC 1779]. We propose the
following keywords:
Key Attribute
--------------
APP Application Name
VER Application Version Number
SAPP Sub Application
The following is an example of a conformant policy locator:
"APP=SAP, VER=1.1, SAPP=Print"
8. 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.
9. References
bernet 3
draft-bernet-appid-00.txt February, 1999
[RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP)
- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC-1779], Kille, S., A String Representation of Distinguished
Names, March 1995
[identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., "Identity Representation for RSVP", Internet Draft,
February 1999.
10. Acknowledgments
Thanks to Tim Moore, Shai Mohaban and Itzik Parnafes for their input.
11. Author's Addresses
Bernet, Yoram
Microsoft
One Microsoft Way,
Redmond, WA 98052
Phone: (425) 936-9568
Email: yoramb@microsoft.com
Pabbati, Ramesh
One Microsoft Way,
Redmond, WA 98052
Email: rameshpa@microsoft.com
This draft expires August, 1999
bernet 4
