idnits 2.17.1 draft-ietf-ipsp-roadmap-00.txt: 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 219 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** There are 5 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** There are 32 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (September 25, 2000) is 8611 days in the past. Is this intentional? 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: 'RFC2402' is mentioned on line 54, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Unused Reference: 'RFC2119' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 164, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 176, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'RFC2403') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'PCIM' ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSP Working Group L.A. Sanchez 2 INTERNET-DRAFT BBN Technologies 3 Expire in March, 2001 H. Orman 4 Novell Corporation 5 September 25, 2000 7 A Roadmap for IPsec Policy Management 8 draft-ietf-ipsp-roadmap-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes the approach that the IPSP WG will follow 40 to resolve the challenges that IPsec compliant devices phase with 41 respect to modeling, specifying, translating, provisioning, 42 exchanging, negotiating, checking and enforcing IPsec policies. 44 1. What is the IPSP WG trying to solve? 46 The rapid growth of the Internet and the need to control access to 47 network resources (bandwidth, routers, hosts, etc.) has quickly 48 generated the need for representing, discovering, exchanging and 49 managing the policies that control access to these resources in a 50 scalable, secured and reliable fashion. 52 Current IP security protocols and algorithms [RFCs 2401-2412, 2085, 53 2104 and 2451] can exchange keying material using IKE [RFC2409] and 54 protect data flows using the AH [RFC2402] and/or ESP protocols 55 [RFC2406]. The scope of IKE limits the protocol to the authenticated 56 exchange of keying material and associated policy information between 57 the end-points of a security association. 59 However, along the path of a communication, there may be 60 administrative entities that need to impose policy constraints on 61 entities such as security gateways and router filters. There also is 62 a need for end-points of a security association and/or, for their 63 respective administrative entities, to securely discover and 64 negotiate access control information for the end hosts and for the 65 policy enforcement points (security gateways, routers, etc.) along 66 the path of the communication. 68 2. Roadmap to a solution 70 In essence the IPSP WG will produce a set of documents and working 71 code. To accomplish this the IPSP WG will work on the items listed 72 below. Please note, that not all items require code 73 development. Below, you will find a complete list of all 74 items. The IPSP WG will: 76 1) first establish the requirements for IPsec policy 77 management. Any solution developed under the IPSP umbrella 78 MUST meet these requirements. The requirements document 79 will cover all aspects of IPsec policy management including: 81 - IPsec data model 82 - IPsec policy architecture 83 - IPsec policy specification 84 - IPsec policy provisioning 85 - IPsec security gateway discovery 86 - IPsec policy discovery, negotiation, conflict 87 resolution and compliance checking 89 This WG item will produce a standards-track document. 91 2) define a data model for IPsec policies. This model will be 92 compatible with the P-CIM [PCIM]. This WG item will 93 produce a standards-track document. 95 3) develop an architecture for IPsec policy management. The 96 document will discuss and cover the following topics: 98 - IPsec data model 99 - IPsec policy specification 100 - IPsec policy provisioning 101 - IPsec security gateway discovery 102 - IPsec policy discovery, negotiation, conflict 103 resolution and compliance checking 105 This WG item will produce a standards-track document. 107 4) develop a flexible, vendor-independent language to 108 represent IPsec policies. The language MUST follow the 109 IPsec data model which in turns follows the P-CIM. 111 This WG item will produce a standards-track document and 112 parser implementations. 114 5) develop guidelines for the provisioning of IPsec policies 115 using existing policy provisioning protocols. This includes 116 profiles for distributing IPsec policies over protocols 117 such as LDAP, COPS, SNMPCONF, FTP, etc. 119 This WG item will produce standards-track documents and 120 implementations. 122 6) specify and develop adopt or develop an IPsec policy 123 exchange and negotiation protocol. The protocol must be 124 capable of: 126 i) discovering security gateways 127 ii) exchanging and negotiating security policies, and; 128 iii) resolving policy conflicts in both intra/inter 129 domain environments. The protocol must be 130 independent of any security protocol suite and key 131 management protocol. 133 Note that the WG MAY decide to divide the above-mentioned 134 functionality into one or more protocols. This WG item will 135 produce a standards-track document and implementations. 137 3. Roadmap Nutshell 139 Roadmap Document 141 Information Model 143 Specification Language 145 Provisioning Guidelines 147 Gateway Discovery, policy exchange, 149 3. Security Considerations 151 The document provides a framework for applications to identify the 152 relevant policies in place across the network. Policies must be 153 communicated in a secure way so as not to jeopardize the ability 154 of the application to run. It is also important to ensure that the 155 policies that are communicated statically or dynamically to the 156 Policy Enforcement device are doen so, securely. Not doing so could 157 compromise the security of the entire network. 159 REFERENCES 161 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 162 Requirement Levels", RFC2119, March 1997. 164 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 165 Protocol", RFC 2401. 167 [RFC2403] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 169 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 170 (ESP)", RFC 2406. 172 [PCIM] Moore, et al., "Policy Core Information Model -- Version 1 173 Specification" 174 ftp://ftp.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-07.txt 176 [RFC2407] D. Piper, "The Internet IP Security Domain of Interpretation 177 for ISAKMP", RFC 2407. 179 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 180 RFC 2409. 182 Authors' Addresses 184 Luis A. Sanchez 185 BBN Technologies 186 GTE Internetworking 187 10 Moulton Street 188 Cambridge, MA 02140 190 Voice: (617) 873-3351 191 EMail: lsanchez@bbn.com 193 Hilarie Orman 194 Novell, Inc. 195 Net Content Services 196 1800 South Novell Place 197 Provo, UT 84606 199 Voice: (801)861-5278 200 EMail: horman@novell.com