INTERNET-DRAFT Q. Liu Expires in six months VPNet Technologies December 1997 Definition of a Common Management Interface Format for Virtual Private Networks Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mater- ial or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a common interface format for describing the configuration of a Virtual Private Network (VPN) in the context of IPSec and equipment from different vendors. The configuration format would be both importable and exportable by various vendors of VPN equipment and software that is IPSec compliant, facilitating an uniform and perhaps automated method of interoperability (creating a VPN) between VPN products from different vendors. This document will only discuss the proposed configuration format. The mechanism by which the file is propagated is beyond the scope of this document and will not be discussed. A security association is not mandatory between two management stations from different vendors wishing to employ this method of VPN configuration, as this configuration format can easily be packaged in a file and propagated out of band. Q. Liu [Page 1] INTERNET-DRAFT December 1997 Expires June 1998 1. Introduction The main goal of this document is to define a standardized method of describing VPN configuration information between VPN configuration utilities from various vendors of VPN software and hardware. Presently, different vendors have different methods of configuring the equipment they produce, denoted by "B" in the figure below. Vendor ABC Products Vendor XYZ Products +---------+ +---------+ | ABC Mgr | <<<==================>>> | XYZ Mgr | +---------+ "A" "A" +---------+ /|\ /|\ / | \ "B" / | \ "B" / | \ / | \ +---+ +---+ +---+ +---+ +---+ +---+ |ABC| |ABC| |ABC| |XYZ| |XYZ| |XYZ| +---+ +---+ +---+ +---+ +---+ +---+ Any Virtual Private Network that involves both an "ABC" object and a "XYZ" object requires that an exchange of VPN information must occur between the ABC management tool and the XYZ management tool in order to implement the VPN. The VPN information is then manually entered into each configuration tools. This method of entering in VPN information into the configuration tool is vendor-specific and varies widely, meaning that a system administrator needs to "translate" the configuration information into something the config- uration tool understands. This point of data entry is denoted by "A" in the figure above. This document defines a common interface format so that no matter what vendor generated VPN configuration information, any other vendor supporting this interface format will be able to understand the information without a manual "translation" process. In essence, this proposed interface will standardize "A" in the figure above and provide a vendor-independent method of defining Virtual Private Networking configuration data, helping to facilitate an automated entry method which will obsolete manual entry of new VPN data. The configuration data itself will be binary, encoded using the ASN.1 notation. Format-wise, the configuration structure will always begin with the version of the common interface format. Currently the version number of the file format is one (1). Following the version number is zero or more VPN Description Objects, which are defined below. Conceptually, the configuration structure is constructed as follows: Q. Liu [Page 2] INTERNET-DRAFT December 1997 Expires June 1998 : : The VPN Description Objects are not ordered in any fashion. VPN Description Objects are the object type which specifies the characteristics of a VPN and detailed information on how it is implemented. 2. File format version Versioning will become crucial as this proposed specification grows over time, allowing implementations to negotiate for the least common denominator of supported file formats. The file format version is currently one (1). FileFormatVersionType ::= INTEGER 3. VPN Description Object The VPN description object is a variable length structure that spec- ifies the characteristics and membership of a Virtual Private Network. The layout of the description object is relatively straight- forward. Format-wise, a VPN Description object will always begin with the VPN mode type, defined below. Following the VPN mode type is the mode- dependent information object, defined below. A reserved field of eight octets follows the mode-dependant information. Immediately following the mode-dependent information object is zero or more end- point policy information objects, also defined below. The endpoint policy information objects are order-independent. Conceptually, the VPN description object is constructed as follows: : : Q. Liu [Page 3] INTERNET-DRAFT December 1997 Expires June 1998 3.1 VPN Mode Type The first element shall always be the type of VPN the description object is identifying. Currently, there are five types of VPNs defined: ISAKMP Tunnel mode ISAKMP Transport mode SKIP Tunnel mode SKIP Transport mode Manual Keyed Tunnel mode Manual Keyed Transport mode VPNModeType ::= INTEGER { isakmptunnel(0), isakmptunnel(1), skiptunnel(2), skiptransport(3), manualkeytunnel(4), manualkeytransport(5) } 3.2 VPN Mode-dependent information The second element in a VPN description object is the VPN mode- dependent information structure. This structure is a variable length object that contains characteristics of the VPN being described. The contents and layout of this structure, however, is dependent on the VPN mode specified in section 3.1 above. If the VPN Type is ISAKMP Tunnel Mode (0), or ISAKMP Transport Mode (1), then the VPN mode-dependent information structure is defined as: SharedKeyType ::= OCTET STRING EncryptionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } AuthenticationAlgorithmType ::= INTEGER { noauthentication(0), md5(1), sha1(2), hmac-md5(3), hmac-sha1(4) } -- value id ignored if the authentication algorithm is (0) or (1) -- or (2) AuthenticationLocationType ::= INTEGER { esptrailer(0), ah(1) } Q. Liu [Page 4] INTERNET-DRAFT December 1997 Expires June 1998 CompressionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } -- the key lifetime in seconds KeyLifetimeTimeType ::= INTEGER -- the key lifetime in number of kilobytes KeyLifetimeByteType ::= INTEGER DiffieHellmanGroupType ::= INTEGER { group1(0), group2(1) } PerfectForwardSecrecyType ::= INTEGER { off(0), on(1) } If the VPN Type is SKIP Tunnel Mode (2), or SKIP Transport Mode (3), then the VPN mode-dependent information structure is defined as: SharedKeyType ::= OCTET STRING EncryptionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } AuthenticationAlgorithmType ::= INTEGER { noauthentication(0), md5(1), sha1(2), hmac-md5(3), hmac-sha1(4) } CompressionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } If the VPN Type is Manual Key Tunnel Mode (4), or Manual Key Transport Mode (5), then the VPN mode-dependent information structure is defined as: EncryptionKeyType ::= OCTET STRING Q. Liu [Page 5] INTERNET-DRAFT December 1997 Expires June 1998 AuthenticationKeyType ::= OCTET STRING EncryptionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } AuthenticationAlgorithmType ::= INTEGER { noauthentication(0), md5(1), sha1(2), hmac-md5(3), hmac-sha1(4) } -- value id ignored if the authentication algorithm is (0) or (1) -- or (2) AuthenticationLocationType ::= INTEGER { esptrailer(0), ah(1) } CompressionAlgorithmType ::= INTEGER { noencryption(0), des(1), tripledes(2) } SecurityParamtersIndexType ::= INTEGER 3.3 Reserved field The third element in a VPN description object is a field consisting of eight (8) octets reserved for future use. The value in this field should be ignored in version (1). 3.4 Endpoint policy information object Immediately following the VPN mode-dependent information is zero or more endpoint policy information objects, as defined below. An endpoint object typically will be the entity enforcing VPN policy, whether it be a dedicated hardware unit or a software-based work- station protecting a private network. An endpoint object may even be an endstation. Deriving from the definition of an endpoint object, an endpoint policy information object is a variable-length structure that specifies characteristics of an endpoint object and the part of the VPN policy that it is responsible for. Format-wise, an endpoint policy information object will always begin with the public IP address of the endpoint object if the VPN is in tunnel mode. The value of the endpoint object IP address will be zeros and ignored if the VPN is in transport mode. Following the address of the endpoint object is zero or more Local address/mask pairs. The address/mask pairs are order-independent. Conceptually, an endpoint policy information object is constructed as follows: Q. Liu [Page 6] INTERNET-DRAFT December 1997 Expires June 1998 : : 3.4.1 Endpoint object address Specifically, the first element in an endpoint policy information object is the IP address of the endpoint object. This must be a valid public IP address if the VPN is in tunnel mode and filled with zeros if the VPN is in transport mode. Alternatively, the endpoint object address can be a unique identifier in Name Space Identifier (NSID-4) that represents a unicast address. An NSID-4 identifier (MD5 of a DNS name) would typically be used in a situation where the endpoint object is an endstation that does not have a permanent IP address associated with it. 3.4.2 Local protected address/mask pair Immediately following the endpoint object address is zero or more local protected address/mask pairs. These may be public IP addresses, Network Address Translation (NAT) addresses, or private addresses that may not be valid IP addresses depending on the VPN mode. Literally, the protected address mask pair is eight octets con- sisting of the IP address of the the network to be protected immediately followed by the network mask. 4. Summary Using the definitions described above, the proposed file format in detail will conceptually and hierarchically be constructed as follows for an example involving a single VPN implemented by two endpoint objects: -- vpn #1 -- endpoint object #1.1 : Q. Liu [Page 7] INTERNET-DRAFT December 1997 Expires June 1998 -- endpoint object #1.2 : Acknowledgments Thanks to Rodney Thayer (Sable Technology Corp.), Henk Bots (VPNet Technologies) and Idris Kothari (VPNet Technologies) for their input. References [Arch] Atkinson, R., "Security Architecture for the Internet Protocol" [RFC-1825], July 1995 [Draft] Thayer, R., Doraswamy, N., Glenn, R.,"IP Security Document Roadmap" , July 1997 Editor's Address Quentin Liu VPNet Technologies, Inc. 1530 Meridian Avenue San Jose, CA 95125 USA Phone: 1-408-445-6600 Fax: 1-408-445-6611 Email: qliu@vpnet.com