[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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