INTERNET-DRAFT Q. Liu
Expires in six months VPNet Technologies
December 1997
Definition of a Common Management Interface Format
for Virtual Private Networks
<draft-liu-ipsec-vpn-management-00.txt>
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
<File format version>
<VPN Description Object 1>
<VPN Description Object 2>
<VPN Description Object 3>
:
:
<VPN Description Object N>
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:
<vpn mode type>
<mode-dependent information>
<reserved field>
<endpoint policy information object 1>
<endpoint policy information object 2>
<endpoint policy information object 3>
:
:
<endpoint policy information object N>
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:
<shared key>
<encryption algorithm>
<authentication algorithm>
<ESP or AH authentication>
<compression algorithm>
<key lifetime-time>
<key lifetime-bytes>
<diffiehellmangroup>
<pfs>
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:
<shared key>
<encryption algorithm>
<authentication algorithm>
<compression algorithm>
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:
<encryption key>
<authentication key>
<encryption algorithm>
<authentication algorithm>
<ESP or AH authentication>
<compression algorithm>
<securityparametersindex>
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
<Endpoint object address>
<Local, protected address/mask pair 1>
<Local, protected address/mask pair 2>
<Local, protected address/mask pair 3>
:
:
<Local, protected address/mask pair N>
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:
<File format version>
-- vpn #1
<vpn mode type>
<vpn mode-dependent information>
-- endpoint object #1.1
<Endpoint object address>
<Local, protected address/mask pair 1>
:
<Local, protected address/mask pair N>
Q. Liu [Page 7]
INTERNET-DRAFT December 1997 Expires June 1998
-- endpoint object #1.2
<Endpoint object address>
<Local, protected address/mask pair 1>
:
<Local, protected address/mask pair N>
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" <draft-ietf-ipsec-doc-roadmap-01.txt>, 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