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

Versions: 00 01                                                         
Internet Engineering Task Force                            Howard C. Berkowitz
INTERNET-DRAFT                                       Netarchitecture
Mentoring
<draft-berkowitz-vpn-tax-00.txt>
Expires August 1999






            Requirements Taxonomy for Virtual Private Networks


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working 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
   material or to cite them other than as ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Abstract

   Proprietary definitions of virtual private networks proliferate in
   the marketplace, to the confusion of end users. This memorandum
   proposes a taxonomy which can describe a variety of VPN models.
   It does not recommend any specific model, but suggests a consistent
   way of describing specific VPNs.  This document differs from some
   other working papers that go more deeply into the VPN mechanisms.
   In contrast, this document is focused on user requirments.

1. Introduction

   Previous working papers [Gleeson, Muthukrishnan, Rosen] have dealt
   with fairly specific models where specific underlying technologies are
   considered at length.  This document takes a different approach, trying
   to focus on requirements rather than technology.  It may very well be
   appropriate to merge several of these proposals.

   Any VPN will have a minimal set of core capabilities, which, alone,
   are unlikely to satisfy any real-world user requirements.  The taxonomy
   here provides a systematic way for extending the core capabilities to
   meet those requirements.  It also provides a way of describing requirements
   for the shared infrastructure over which the VPN runs.

   A description of a specific VPN requirement will state the core capabilities
   optional user services, and the administrative model.  A response to this
   requirement will state the infrastructure technologies and how the user
   requirements will map to them.

   The taxonomy consists of:

       Core capabilities
       Optional capabilities
       Administrative model
       Mapping of user services to different infrastructures
       Infrastructures

   For a VPN to work, it must be possible to map the user services to
   corresponding capabilities in the infrastructure.   Mechanisms for these
   mappings are outside the scope of this taxonomy.  A quality of service
   user requirement, for example, could map to ATM QoS facilities, to RSVP
   or differentiated services in an IP network, or to priorities in an 802.1p
   LAN.

2. Core Capabilities

   To define a VPN, it is necessary to be able to define an administrative
   mechanism for designating membership in the VPN.  A given host may belong
   to one or more VPNs, as well as the global Internet.

   If there are security requirements for the VPN, the owning enterprise
   should define a security policy that states the allowable connectivity
   over multiple VPNs and public networks.

   The set of members of a VPN will have an identifier [Fox], although that
   identifier might be null.

3. Optional Capabilities

   VPNs of practical use will have one or more optional capabilities in
   addition to the core set.   Not all VPNs will need every capability.

3.1  Quality of Service

   The VPN may provide quality of service support.  It either may accept
   QoS requests from end users signaled with RSVP, IP precedence bits, etc.,
   or may internally assign quality of service requirements to be mapped
   to the transmission infrastructure.  For quality of service to be effective,
   the infrastructure either must support explicit quality of service requests,
   or there must be a high level of confidence that the infrastructure
   consistently provides adequate QoS.  Assumptions about QoS need to be
   stated as part of any VPN design.

3.2  Security

   User connectivity may be defined to include security using a variety
   of security mechanisms, including IPsec, L2TP, etc.  Security may be
   requested on a discretionary basis by end user hosts, or the VPN may
   enforce a mandatory security policy.  Cryptographic protections may
   be under the control of the enterprise, using host-to-host or host-to-
   security gateway methods, or the infrastructure may be trusted to provide
   encryption.  The responsibilities for encryption must be specified as
   part of the design of any practical VPN.

3.3  Addressing and load sharing

   The VPN may provide address assignment, presumably with DHCP.  It also
   may provide network address translation (NAT), network address and port
   translation (NAPT), and load-shared network address translation (LSNAT).

   DNS services may be associated with the VPN, and operated by the enterprise
   or the service provider.

   While VPNs can appear as a single IP prefix (i.e., a single user domain),
   single prefixes will not scale to large size.  The provider may set up
   multiple prefixes to serve user connectivity requirements.  If there are
   multiple prefixes, it needs to be specified if routing among them is
   an enterprise or provider responsibility.

3.4  Frame Sequencing and MTU Support

   There may be requirements to deliver frames or packets in sequence.
   In addition, there may be a requirement to support, efficiently, larger
   MTUs that the provider might normally handle.

3.5  Non-IP Protocol Support

   While the emphasis of this taxonomy is on VPNs that support IP, the VPN may
   provide mechanisms for encapsulating non-IP protocols for transmission over
   an IP infrastructure. Techniques for doing so include NetBIOS over TCP
   [RFC1001/1002], IPX over IP [RFC1234], GRE [RFC1702], etc.

3.6  Multicast Support

   The IP VPN, as seen by end users, may support broadcast or multicast
   addressing.

3.7  Availability

   The enterprise may specify availability requirements for the infrastructure
   and for VPN gateway services.  If redundancy of links or components is
   needed to provide the desired level of redundancy, these redundant
   components may either be visible to, or hidden from, the using enterprise.

3.8  Dynamic Provisioning

   The enterprise may need to be able to signal to the provider that new
   sites and/or users (especially dial users) have been added to the VPN.
   While it should generally be transparent to the VPN if new users are
   added to VPNs at existing sites, security requirements may make it necessary
   to inform the VPN, securely, that a new user has been added or an old user
   deleted.

4.  Administrative Model

   Several administrative issues apply in VPN deployment: whether the
enterprise
   is responsible for any customer premises equipment (CPE) that intelligently
   interoperates with components of the shared infrastructure, whether a
service
   provider is contracted to operate the WAN infrastructure, and how any VPN
   client software in user hosts is managed and operated.

   A service provider may place service-provider operated equipment at a
   customer site, and present a LAN or serial interface to the customer.
   Anything beyond the provider device is contractually a provider
   responsibility, but it cannot be directly controlled by the customer.

   There are two basic models of the administration and management of VPNs,
   although subcategories are perfectly viable.  In the first category, the
   end user organization designs and operates the VPN, often with end user
   access through the public dial network.  In the second, a service provider
   has contractual responsibility for designing and operating the VPN in
   response to specified user requirements.

   Another aspect of the model is whether clients are aware of the VPN, and
   if provider access components are aware of it.  In principle, a client could
   attach to a generic ISP, establish an encrypted tunnel to a destination
   host, and operate transparently to the ISP.  The VPN provider may be the
   ISP.  In such cases, the VPN provider responsibility is to provided logins
   and connectivity.  The login might specify a class of service to be used
   in the provider network.

   In an alternative model, the clients do not contain encryption software.
   Clients connect natively to the provider's access device through an
   administratively trusted link such as the dial telephone network.  The
   client authenticates with the access device, and the access device(s)
   provide cryptographic services.

   Yet another model is traffic driven. Routers at customer sites sense
   when end user devices wish to send across the VPN, and either route
   them to predefined tunnels over dedicated infrastructure, or create
   appropriate dial calls to carry the traffic, encrypting if necessary.

5.  Mapping to the Infrastructure

   The specific means by which end user views of the VPN are mapped onto the
   shared infrastructure generally involves tunneling, virtual circuit setup,
   or the establishment of a set of labels.

   When tunnels are used, they may provide no security (GRE), authentication
   (L2TP, L2F, and PPTP), or a wide range of security services (IPsec).
   Security services may also be provided by hosts, and a less secure tunnel
   mechanism used to carry host-encrypted data.

   Alternatively, the mapping of IP connectiviy may be to virtual circuits
   using Frame Relay or ATM, or to real circuits with ISDN or analog dial.

   When the VPN seen by the user appears to be multicast-capable, but the
   infrastructure is connection-oriented, provisions need to be made for
   supporting multicast. Techniques here might involve point-to-multipoint
   circuits, or the use of multicast replication servers.

   Details of these mappings will be in other, infrastructure-protocol-specific
   documents.

   Tunnel technologies need to be coordinated between the enterprise(s) and the
   provider(s).  There may be single tunnels between sites, or possibly
multiple
   tunnels for loadsharing and increased availability (e.g., with multilink
   PPP over IP).

6.  Infrastructure Capabilities

   When different kinds of infrastructure are proposed, the main requiremment
   if for the infrastructure provider to take responsibility that all relevant
   user capabilities have matching capabilities in the infrastructure.  The
   actual mappings are technology-specific and outside the scope of this
   document.

   This section does not attempt to define the specific infrastructure
   technologies that can be used for VPNs.  Rather, it examines the
   capabilities that may be needed if a user capability is to be mapped
   successfully into one or more infrastructures.

   Specific VPNs may well be provisioned over one or more infrastructure
   types.  In such cases, the designer needs to ensure the user capabilities
   map into each of the infrastructures.

6.1  Quality of Service

   When the user or the enterprise can request explicit QoS, either the
   infrastructure must be able to understand the explicit requests, or it
   must consistently supply a QoS that meets the most stringent user
   requirement.

6.2  Security

   Users may be responsible for cryptographic security, transparently to
   the provider.  Alternatively, the VPN provider may offer encryption.

   If the user operates firewalls, VPN tunnels typically will terminate
   at the firewall.  If the firewall is operated by the service provider,
   or if the user has stringent security requirements requiring end-to-end
   encryption, there may be compatibility issues of authenticated firewall
   traversal.

6.3  Addressing

   Providers can use registered or RFC1918 addresses internally in their
   networks.  These may or may not be visible to the enterprise.  When they
   are not, there should be a well-defined operational procedure that allows
   the user to request traceroutes through IP infrastructures.

   When the provider uses VPN identifiers to distinguish between routing
   tables for different VPNs, the same addresses, especially from the
   private address space, may be reused.  Provider engineers should take
   care that

6.4  Non-IP Protocol Support

   Comnmonly, the enterprise will provide the tunneling necessary to carry
   non-IP protocols over the enterprise.  When the VPN is offered as a service,
   however, the provider may offer appropriate encapsulation services.  If
   the infrastructure is layer 2 and supports a protocol type field, it may
   be appropriate for the provider to encapsulate non-IP traffic with explicit
   protocol identification.

6.5  Availability

   When a specific availability requirement is defined for the enterprise VPN,
   it is a provider responsibility to ensure the infrastructure has the
   component reliability, diversity, etc., to meet these needs.  It can be
   useful to distinguish between availability in the access part of a VPN,
   such as modem pools, and the backbone which carries the tunnels over the
   long-haul shared infrastructure.

6.6  Interprovider Connectivity

   It may be necessary to provision the VPN infrastructure through multiple
   service providers.  In such cases, the providers will need inter-provider
   provisioning and VPN identification.

   Much as a BGP confederation presents a single AS number to the outside
   but contains multiple internal ASNs, a multiprovider VPN identifier may
   map to a set of publicly visible ASNs. While BGP may be
   used to convey VPN reachability information among providers, the actual
   destinations may be prefixed with VPN IDs, and carried using the BGP-4
   Multiprotocol Extensions.  When VPN IDs are used in this manner, the
   routes carried need not be visible on the global Internet, but simply
   used to exchange information between ISPs with bilateral agreements.


References



   [Gleeson] Gleeson, Heinanen, Lin, Armitage, "A Framework for IP Based
Virtual
    Private Networks", draft-gleeson-vpn-framework-00.txt.

   [Muthukrishnan] Muthukrishnan, Malis, "Core IP VPN Architecture",
    draft-muthukrishnan-corevpn-arch-00.txt.

   [RFC1001]  1001 Protocol standard for a NetBIOS service on a TCP/UDP
     transport:
     Concepts and methods. NetBIOS Working Group. Defense Advanced
     Research Projects Agency, Internet Activities Board, End-to-End
     Services Task Force. Mar-01-1987.

  [RFC1234]  Tunneling IPX traffic through IP networks. D. Provan.
     Jun-01-1991

  [RFC1702]  Hanks, S., et al  "Generic Routing Encapsulation over Ipv4
   Networks", RFC 1702

Author Information


   Howard C. Berkowitz
   Netarchitecture Mentoring
   PO Box 6897
   Arlington VA 22206
   phone: +1-703-998-5819
   email: hcb@clark.net