idnits 2.17.1 draft-liu-ipsec-vpn-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1997) is 9622 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: 'RFC-1825' is mentioned on line 367, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Unused Reference: 'Arch' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'Draft' is defined on line 369, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Arch' -- Possible downref: Non-RFC (?) normative reference: ref. 'Draft' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Q. Liu 2 Expires in six months VPNet Technologies 3 December 1997 5 Definition of a Common Management Interface Format 6 for Virtual Private Networks 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mater- 19 ial or to cite them other than as "work in progress". 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document defines a common interface format for describing the 30 configuration of a Virtual Private Network (VPN) in the context of 31 IPSec and equipment from different vendors. The configuration 32 format would be both importable and exportable by various vendors of 33 VPN equipment and software that is IPSec compliant, facilitating an 34 uniform and perhaps automated method of interoperability (creating 35 a VPN) between VPN products from different vendors. 37 This document will only discuss the proposed configuration format. 38 The mechanism by which the file is propagated is beyond the scope of 39 this document and will not be discussed. 41 A security association is not mandatory between two management 42 stations from different vendors wishing to employ this method of VPN 43 configuration, as this configuration format can easily be packaged in 44 a file and propagated out of band. 46 1. Introduction 48 The main goal of this document is to define a standardized method of 49 describing VPN configuration information between VPN configuration 50 utilities from various vendors of VPN software and hardware. 52 Presently, different vendors have different methods of configuring 53 the equipment they produce, denoted by "B" in the figure below. 55 Vendor ABC Products Vendor XYZ Products 56 +---------+ +---------+ 57 | ABC Mgr | <<<==================>>> | XYZ Mgr | 58 +---------+ "A" "A" +---------+ 59 /|\ /|\ 60 / | \ "B" / | \ "B" 61 / | \ / | \ 62 +---+ +---+ +---+ +---+ +---+ +---+ 63 |ABC| |ABC| |ABC| |XYZ| |XYZ| |XYZ| 64 +---+ +---+ +---+ +---+ +---+ +---+ 66 Any Virtual Private Network that involves both an "ABC" object and a 67 "XYZ" object requires that an exchange of VPN information must occur 68 between the ABC management tool and the XYZ management tool in order 69 to implement the VPN. The VPN information is then manually 70 entered into each configuration tools. This method of entering in 71 VPN information into the configuration tool is vendor-specific and 72 varies widely, meaning that a system administrator needs to 73 "translate" the configuration information into something the config- 74 uration tool understands. This point of data entry is denoted by "A" 75 in the figure above. 77 This document defines a common interface format so that no matter 78 what vendor generated VPN configuration information, any other 79 vendor supporting this interface format will be able to understand 80 the information without a manual "translation" process. In essence, 81 this proposed interface will standardize "A" in the figure above and 82 provide a vendor-independent method of defining Virtual Private 83 Networking configuration data, helping to facilitate an automated 84 entry method which will obsolete manual entry of new VPN data. 86 The configuration data itself will be binary, encoded using the ASN.1 87 notation. Format-wise, the configuration structure will always begin 88 with the version of the common interface format. Currently the 89 version number of the file format is one (1). Following the version 90 number is zero or more VPN Description Objects, which are defined 91 below. Conceptually, the configuration structure is constructed as 92 follows: 94 95 96 97 98 : 99 : 100 102 The VPN Description Objects are not ordered in any fashion. VPN 103 Description Objects are the object type which specifies the 104 characteristics of a VPN and detailed information on how it is 105 implemented. 107 2. File format version 109 Versioning will become crucial as this proposed specification grows 110 over time, allowing implementations to negotiate for the least common 111 denominator of supported file formats. The file format version is 112 currently one (1). 114 FileFormatVersionType ::= 115 INTEGER 117 3. VPN Description Object 119 The VPN description object is a variable length structure that spec- 120 ifies the characteristics and membership of a Virtual Private 121 Network. The layout of the description object is relatively straight- 122 forward. 124 Format-wise, a VPN Description object will always begin with the VPN 125 mode type, defined below. Following the VPN mode type is the mode- 126 dependent information object, defined below. A reserved field of 127 eight octets follows the mode-dependant information. Immediately 128 following the mode-dependent information object is zero or more end- 129 point policy information objects, also defined below. The endpoint 130 policy information objects are order-independent. 132 Conceptually, the VPN description object is constructed as follows: 134 135 136 137 138 139 140 : 141 : 142 144 3.1 VPN Mode Type 146 The first element shall always be the type of VPN the description 147 object is identifying. Currently, there are five types of VPNs 148 defined: 150 ISAKMP Tunnel mode 151 ISAKMP Transport mode 152 SKIP Tunnel mode 153 SKIP Transport mode 154 Manual Keyed Tunnel mode 155 Manual Keyed Transport mode 157 VPNModeType ::= 158 INTEGER { isakmptunnel(0), isakmptunnel(1), skiptunnel(2), 159 skiptransport(3), manualkeytunnel(4), 160 manualkeytransport(5) } 162 3.2 VPN Mode-dependent information 164 The second element in a VPN description object is the VPN mode- 165 dependent information structure. This structure is a variable length 166 object that contains characteristics of the VPN being described. The 167 contents and layout of this structure, however, is dependent on the 168 VPN mode specified in section 3.1 above. 170 If the VPN Type is ISAKMP Tunnel Mode (0), or ISAKMP Transport Mode 171 (1), then the VPN mode-dependent information structure is defined as: 173 174 175 176 177 178 179 180 181 183 SharedKeyType ::= 184 OCTET STRING 186 EncryptionAlgorithmType ::= 187 INTEGER { noencryption(0), des(1), tripledes(2) } 189 AuthenticationAlgorithmType ::= 190 INTEGER { noauthentication(0), md5(1), sha1(2), 191 hmac-md5(3), hmac-sha1(4) } 193 -- value id ignored if the authentication algorithm is (0) or (1) 194 -- or (2) 195 AuthenticationLocationType ::= 196 INTEGER { esptrailer(0), ah(1) } 198 CompressionAlgorithmType ::= 199 INTEGER { noencryption(0), des(1), tripledes(2) } 201 -- the key lifetime in seconds 202 KeyLifetimeTimeType ::= 203 INTEGER 205 -- the key lifetime in number of kilobytes 206 KeyLifetimeByteType ::= 207 INTEGER 209 DiffieHellmanGroupType ::= 210 INTEGER { group1(0), group2(1) } 212 PerfectForwardSecrecyType ::= 213 INTEGER { off(0), on(1) } 215 If the VPN Type is SKIP Tunnel Mode (2), or SKIP Transport Mode (3), 216 then the VPN mode-dependent information structure is defined as: 218 219 220 221 223 SharedKeyType ::= 224 OCTET STRING 226 EncryptionAlgorithmType ::= 227 INTEGER { noencryption(0), des(1), tripledes(2) } 229 AuthenticationAlgorithmType ::= 230 INTEGER { noauthentication(0), md5(1), sha1(2), 231 hmac-md5(3), hmac-sha1(4) } 233 CompressionAlgorithmType ::= 234 INTEGER { noencryption(0), des(1), tripledes(2) } 236 If the VPN Type is Manual Key Tunnel Mode (4), or Manual Key 237 Transport Mode (5), then the VPN mode-dependent information 238 structure is defined as: 240 241 242 243 244 245 246 248 EncryptionKeyType ::= 249 OCTET STRING 251 AuthenticationKeyType ::= 252 OCTET STRING 254 EncryptionAlgorithmType ::= 255 INTEGER { noencryption(0), des(1), tripledes(2) } 257 AuthenticationAlgorithmType ::= 258 INTEGER { noauthentication(0), md5(1), sha1(2), 259 hmac-md5(3), hmac-sha1(4) } 261 -- value id ignored if the authentication algorithm is (0) or (1) 262 -- or (2) 263 AuthenticationLocationType ::= 264 INTEGER { esptrailer(0), ah(1) } 266 CompressionAlgorithmType ::= 267 INTEGER { noencryption(0), des(1), tripledes(2) } 269 SecurityParamtersIndexType ::= 270 INTEGER 272 3.3 Reserved field 274 The third element in a VPN description object is a field consisting 275 of eight (8) octets reserved for future use. The value in this field 276 should be ignored in version (1). 278 3.4 Endpoint policy information object 280 Immediately following the VPN mode-dependent information is zero or 281 more endpoint policy information objects, as defined below. 283 An endpoint object typically will be the entity enforcing VPN policy, 284 whether it be a dedicated hardware unit or a software-based work- 285 station protecting a private network. An endpoint object may even be 286 an endstation. Deriving from the definition of an endpoint object, an 287 endpoint policy information object is a variable-length structure 288 that specifies characteristics of an endpoint object and the part of 289 the VPN policy that it is responsible for. 291 Format-wise, an endpoint policy information object will always begin 292 with the public IP address of the endpoint object if the VPN is in 293 tunnel mode. The value of the endpoint object IP address will be 294 zeros and ignored if the VPN is in transport mode. Following the 295 address of the endpoint object is zero or more Local address/mask 296 pairs. The address/mask pairs are order-independent. 298 Conceptually, an endpoint policy information object is constructed as 299 follows: 301 302 303 304 305 : 306 : 307 309 3.4.1 Endpoint object address 311 Specifically, the first element in an endpoint policy information 312 object is the IP address of the endpoint object. This must be a valid 313 public IP address if the VPN is in tunnel mode and filled with zeros 314 if the VPN is in transport mode. 316 Alternatively, the endpoint object address can be a unique identifier 317 in Name Space Identifier (NSID-4) that represents a unicast address. 318 An NSID-4 identifier (MD5 of a DNS name) would typically be used in a 319 situation where the endpoint object is an endstation that does not 320 have a permanent IP address associated with it. 322 3.4.2 Local protected address/mask pair 324 Immediately following the endpoint object address is zero or more 325 local protected address/mask pairs. These may be public IP addresses, 326 Network Address Translation (NAT) addresses, or private addresses 327 that may not be valid IP addresses depending on the VPN mode. 329 Literally, the protected address mask pair is eight octets con- 330 sisting of the IP address of the the network to be protected 331 immediately followed by the network mask. 333 4. Summary 335 Using the definitions described above, the proposed file format in 336 detail will conceptually and hierarchically be constructed as follows 337 for an example involving a single VPN implemented by two endpoint 338 objects: 340 342 -- vpn #1 343 344 346 -- endpoint object #1.1 347 348 349 : 350 352 -- endpoint object #1.2 353 354 355 : 356 358 Acknowledgments 360 Thanks to Rodney Thayer (Sable Technology Corp.), Henk Bots 361 (VPNet Technologies) and Idris Kothari (VPNet Technologies) for 362 their input. 364 References 366 [Arch] Atkinson, R., "Security Architecture for the Internet 367 Protocol" [RFC-1825], July 1995 369 [Draft] Thayer, R., Doraswamy, N., Glenn, R.,"IP Security Document 370 Roadmap" , July 1997 372 Editor's Address 374 Quentin Liu 375 VPNet Technologies, Inc. 376 1530 Meridian Avenue 377 San Jose, CA 95125 378 USA 380 Phone: 1-408-445-6600 381 Fax: 1-408-445-6611 382 Email: qliu@vpnet.com