Subject: (NAT) I-D on VPN definition including NAT considerations

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 21 Oct 1999 15:43:22 -0400

I've attached a draft of a document on defining external requirements for
VPNs, which includes a good deal of material on NAT considerations. It's
another aspect of NAT design considerations that I believe fits within the
scope of the WG, and I'd like to speak briefly on it in DC.

Howard

-------

Internet Engineering Task Force                            Howard C. Berkowitz
INTERNET-DRAFT                                             Gett Communications
<draft-berkowitz-vpn-tax-01.txt>
October 1999                                               Expires April 2000

            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."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   Most useful networking ideas involve some level of abstraction.
   Virtual private networks (VPN) map an abstraction of an user-defined
   interface onto an infrastructure. Multihoming strategies are
   virtualizations in the infrastructure [Berkowitz multihome]
   that should be invisible to the VPN.  Proprietary definitions of VPNs
   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.

   Useful definitions of VPNs include several policy statements beyond the
   administrative policies that define membership. An operational policy needs
   to be specified, which defines the organizations, inside or outside the
   enterprise, which are responsible for moves and changes, troubleshooting,
   performance monitoring, audit, etc.  There should be a security
   policy and a QoS policy, even if these policy statements state there are no
   specific security or QoS requirements.

   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.

   For the purposes of this document, VPNs use IP addressing as part of their
   core capabilities.  Other protocol families may be mapped to the IP
structure
   that defines the main IP topology.  Relationships of a specific VPN's
address
   space to that of the provisioning provider, or to the general Internet, are
   optional capabilities specific to each VPN.

   While the focus of many VPN discussions is on a system primarily defined
   at the network layer, there are an increasing number of functions that
   require capabilities at higher layers.  In particular, there may need to
   be optional capabilities that choose paths, set quality of service
signaling,
   etc., based on transport or network layer information.

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  Addressing and naming

   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).
   When providers support multiple VPNs, and/or the VPN must participate in
   end-to-end security, Realm-Specific IP (RSIP) may be a viable alternative
   to more traditional NAT.

   DNS services may be associated with the VPN, and operated by the enterprise
   or the service provider.  When the VPN provides dynamic addressing, the
   dynamic address server (DHCP, IPCP, etc.) should dynamically update the
   DNS zone seen by the members of the VPN.

   While VPNs can appear as a single IP prefix (i.e., a single subnet),
   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.

   If end-to-end address significance is not preserved, applications that
   embed addresses in application traffic may not work properly through
   traditional NAT functions. Alternative technologies may be needed, such
   as application layer gateways (ALG) or tunneling that preserves the
   original packet. When defining VPN requirements, analysts should identify
   upper-layer protocols whose use is expected, and evaluate each to see if
   there is sensitivity to address manipulation mechanisms used in the VPN.
   Do not limit these evaluations to pure application protocols, but also
   consider tunnels internal to the VPN (e.g., for carrying non-IP protocols),
   security protocols, and special transports such as RTP.

3.2  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.

   In particular, if IP fragmentation is to be avoided when the infrastructure
   has an MTU that is less than the length of a full payload packet plus tunnel
   and delivery header, manual MTU limitations on end hosts, or dynamic MTU
   path discovery, need to be used.

3.3  Security

   User connectivity may be defined to include security using a variety
   of security mechanisms, including IPsec, L2TP, etc. These various mechanisms
   may provide other services, such as connectivity. L2TP can provide per-user
   authentication, or may have no security functions.  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 user authentication, device
   authentication, encryption, logging, and audit must be specified as
   part of the design of any practical VPN.

3.4  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.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.  Multicast addresses should ba assigned in conformity with
   the Multicast Allocation framework [Handley].

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.

   When the VPN is an extranet connecting multiple addressing realms, RSIP may
   be needed.

4.  Operational Model

   Several operational issues apply in VPN deployment: whether the
   enterprise   is responsible for any customer premises equipment (CPE) that
   intelligently interoperates with components of the shared provider
   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. Some organizations
   consider a VPN using all dial facilities, or other public facilities
   operated by a service provider that is not aware of the VPN, to have a
   customer-operated shared infrastructure.

   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.

   When the provider uses multihoming techniques inside the infrastructure
   to provide the availability agreed to by the providers, those multihomed
   services are not
   part of the VPN.  When the enterprise uses application or transport layer
   multihoming to provide the availability required by the enterprise, and
   the VPN simply provides connectivity among the multihomed hosts, such
   multihoming is outside the scope of the VPN.

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

   [Berkowitz] Berkowitz, H. "To be Multihomed" Work in Progress, IETF,
   1999.

   [Borelia] M. Borella et al., "Realm Specific IP: Framework", Work in
   Progress, IETF NAT Working Group <draft-ietf-nat-rsip-framework-02.txt>

   [Handley] M. Handley, D. Thaler, D. Estrin.   "The Internet Multicast
   Allocation Architecture." Work in progress, IETF MALLOC WG,
    <draft-ietf-malloc-arch-02.txt>

   [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] 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
   Gett Communications
   PO Box 6897
   Arlington VA 22206
   phone: +1-703-998-5819
   email: [email-masked]

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.