Internet Draft 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 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 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-ietf-rap-rsvp-appid-00.txt October, 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 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, version number and sub- application. 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-ietf-rap-rsvp-appid-00.txt October, 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 [RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. bernet 3 draft-ietf-rap-rsvp-appid-00.txt October, 1999 [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 and Shai Mohaban 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.co This draft expires April, 2000 bernet 4