idnits 2.17.1 draft-ietf-rap-rsvp-appid-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 74 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2205]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2205' is mentioned on line 37, but not defined == Missing Reference: 'RFC 1779' is mentioned on line 131, but not defined ** Obsolete undefined reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) == Unused Reference: 'RFC2205' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC-1779' is defined on line 167, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Y.Bernet, Microsoft 2 R. Pabbati, Microsoft 3 Internet Draft October, 1999 4 Document: draft-ietf-rap-rsvp-appid-00.txt expires April, 2000 6 Application and Sub Application Identity Policy Element for Use with 7 RSVP 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 1. Abstract 37 RSVP [RFC 2205] signaling messages typically include policy data 38 objects, which in turn contain policy elements. Policy elements may 39 describe user and/or application information, which may be used by 40 RSVP aware network elements to apply appropriate policy decisions to 41 a traffic flow. This informational draft details the usage of policy 42 elements that provide application information. 44 2. Overview 46 RSVP aware network elements may act as policy enforcement points 47 (PEPs). These work together with policy decision points (PDPs) to 48 enforce QoS policy. Briefly, PEPs extract policy information from 49 RSVP signaling requests and compare the information against 50 information stored in a policy database or directory. A policy 51 decision is made based on the results of the comparison. 53 bernet 1 54 draft-ietf-rap-rsvp-appid-00.txt October, 1999 56 One type of policy information describes the application on behalf 57 of which an RSVP signaling request is generated. When application 58 policy information is available, network administrators are able to 59 manage QoS based on application type. So for example, a network 60 administrator may establish a policy that prioritizes known mission 61 critical applications over games. 63 We propose a hierarchical structure for application policy elements. 64 Specifically, the highest level of the hierarchy specifies an 65 application name. The next level specifies a version. At the next 66 level, an arbitrary number of sub-applications may be specified. An 67 example of a sub-application is 'print data'. 69 In this draft, we show the structure of the application policy 70 element. We also propose keywords for the various levels of the 71 hierarchy. However, we do not enumerate values for applications, 72 version numbers or sub-applications. Such an enumeration is beyond 73 the scope of this draft. 75 3. Application Policy Element Structure 77 General application policy elements are defined in [identity]. These 78 are policy elements with a P-type of AUTH_APP (value 3). Following 79 the policy element header is a list of authentication attributes. 81 The first authentication attribute should be of the A-type 82 POLICY_LOCATOR (value 1). The sub-type of the POLICY_LOCATOR 83 attribute should be of type ASCII_DN (value 1) [RFC 1779]. The 84 actual attribute data is formatted as an X.500 distinguished name 85 (DN), representing the application, version number and sub- 86 application. 88 The second authentication attribute should be of the A-type 89 CREDENTIAL (value 2). The sub-type of the CREDENTIAL attribute is of 90 type ASCII_ID. The actual attribute data is an ASCII string 91 representing the application name. 93 This structure is illustrated in the following diagram: 95 bernet 2 96 draft-ietf-rap-rsvp-appid-00.txt October, 1999 98 0 1 2 3 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | PE Length (8) | P-type = 3 (AUTH_APP) | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Attribute Length | A-type = 1 | Sub-type = 1 | 108 | | POLICY_LOCATOR| ASCII_DN | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Application policy locator attribute data in X.500 DN format | 114 | (see below) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Attribute Length | A-type = 2 | Sub-type = 1 | 120 | | CREDENTIAL | ASCII_ID | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Application name as ASCII string | 126 | (e.g. SAP.EXE) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 The policy locator attribute for an application policy element is 131 conformant with the X.500 DN format[RFC 1779]. We propose the 132 following keywords: 134 Key Attribute 135 -------------- 136 APP Application Name 137 VER Application Version Number 138 SAPP Sub Application 140 The following is an example of a conformant policy locator: 142 APP=SAP, VER=1.1, SAPP=Print 144 4. Security Considerations 146 The proposed simple policy element does not guarantee that element 147 is indeed associated with the application it claims to be associated 148 with. In order to provide such guarantees, it is necessary to sign 149 applications. Signed application policy elements may be proposed at 150 a future date. Note that typically, the application policy element 151 will be included in an RSVP message with an encrypted and 152 authenticated user policy element. A level of security is provided 153 by trusting the application policy element only if the user policy 154 element is trusted. 156 All RSVP integrity considerations apply to the message containing 157 the application policy element. 159 5. References 161 [RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) 162 - Version 1 Functional Specification", RFC 2205, September 1997. 164 bernet 3 165 draft-ietf-rap-rsvp-appid-00.txt October, 1999 167 [RFC-1779], Kille, S., A String Representation of Distinguished 168 Names, March 1995 170 [identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 171 T., Herzog, S., "Identity Representation for RSVP", Internet Draft, 172 February 1999. 174 6. Acknowledgments 176 Thanks to Tim Moore and Shai Mohaban for their input. 178 7. Author's Addresses 180 Bernet, Yoram 181 Microsoft 182 One Microsoft Way, 183 Redmond, WA 98052 184 Phone: (425) 936-9568 185 Email: yoramb@microsoft.com 187 Pabbati, Ramesh 188 One Microsoft Way, 189 Redmond, WA 98052 190 Email: rameshpa@microsoft.co 192 This draft expires April, 2000 194 bernet 4