rfc2764.txt

RFC 的详细文档！

   outlines suggested approaches to their implementation, hence also
   pointing to areas for future standardization.

   Note also that this document only discusses implementations of VPNs
   across IP backbones, be they private IP networks, or the public
   Internet.  The models and mechanisms described here are intended to
   apply to both IPV4 and IPV6 backbones.  This document specifically
   does not discuss means of constructing VPNs using native mappings
   onto switched backbones - e.g., VPNs constructed using the LAN
   Emulation over ATM (LANE) [1] or Multiprotocol over ATM (MPOA) [2]
   protocols operating over ATM backbones.  Where IP backbones are
   constructed using such protocols, by interconnecting routers over the
   switched backbone, the VPNs discussed operate on top of this IP
   network, and hence do not directly utilize the native mechanisms of
   the underlying backbone.  Native VPNs are restricted to the scope of
   the underlying backbone, whereas IP based VPNs can extend to the
   extent of IP reachability.  Native VPN protocols are clearly outside
   the scope of the IETF, and may be tackled by such bodies as the ATM
   Forum.

2.0  VPN Application and Implementation Requirements

2.1  General VPN Requirements

   There is growing interest in the use of IP VPNs as a more cost
   effective means of building and deploying private communication
   networks for multi-site communication than with existing approaches.



Gleeson, et al.              Informational                      [Page 5]

RFC 2764           IP Based Virtual Private Networks       February 2000


   Existing private networks can be generally categorized into two types
   - dedicated WANs that permanently connect together multiple sites,
   and dial networks, that allow on-demand connections through the
   Public Switched Telephone Network (PSTN) to one or more sites in the
   private network.

   WANs are typically implemented using leased lines or dedicated
   circuits - for instance, Frame Relay or ATM connections - between the
   multiple sites.  CPE routers or switches at the various sites connect
   these dedicated facilities together and allow for connectivity across
   the network.  Given the cost and complexity of such dedicated
   facilities and the complexity of CPE device configuration, such
   networks are generally not fully meshed, but instead have some form
   of hierarchical topology.  For example remote offices could be
   connected directly to the nearest regional office, with the regional
   offices connected together in some form of full or partial mesh.

   Private dial networks are used to allow remote users to connect into
   an enterprise network using PSTN or Integrated Services Digital
   Network (ISDN) links.  Typically, this is done through the deployment
   of Network Access Servers (NASs) at one or more central sites.  Users
   dial into such NASs, which interact with Authentication,
   Authorization, and Accounting (AAA) servers to verify the identity of
   the user, and the set of services that the user is authorized to
   receive.

   In recent times, as more businesses have found the need for high
   speed Internet connections to their private corporate networks, there
   has been significant interest in the deployment of CPE based VPNs
   running across the Internet.  This has been driven typically by the
   ubiquity and distance insensitive pricing of current Internet
   services, that can result in significantly lower costs than typical
   dedicated or leased line services.

   The notion of using the Internet for private communications is not
   new, and many techniques, such as controlled route leaking, have been
   used for this purpose [3].  Only in recent times, however, have the
   appropriate IP mechanisms needed to meet customer requirements for
   VPNs all come together.  These requirements include the following:

2.1.1 Opaque Packet Transport:

   The traffic carried within a VPN may have no relation to the traffic
   on the IP backbone, either because the traffic is multiprotocol, or
   because the customer's IP network may use IP addressing unrelated to
   that of the IP backbone on which the traffic is transported.  In
   particular, the customer's IP network may use non-unique, private IP
   addressing [4].



Gleeson, et al.              Informational                      [Page 6]

RFC 2764           IP Based Virtual Private Networks       February 2000


2.1.2 Data Security

   In general customers using VPNs require some form of data security.
   There are different trust models applicable to the use of VPNs.  One
   such model is where the customer does not trust the service provider
   to provide any form of security, and instead implements a VPN using
   CPE devices that implement firewall functionality and that are
   connected together using secure tunnels.  In this case the service
   provider is used solely for IP packet transport.

   An alternative model is where the customer trusts the service
   provider to provide a secure managed VPN service.  This is similar to
   the trust involved when a customer utilizes a public switched Frame
   Relay or ATM service, in that the customer trusts that packets will
   not be misdirected, injected into the network in an unauthorized
   manner, snooped on, modified in transit, or subjected to traffic
   analysis by unauthorized parties.

   With this model providing firewall functionality and secure packet
   transport services is the responsibility of the service provider.
   Different levels of security may be needed within the provider
   backbone, depending on the deployment scenario used.  If the VPN
   traffic is contained within a single provider's IP backbone then
   strong security mechanisms, such as those provided by the IP Security
   protocol suite (IPSec) [5], may not be necessary for tunnels between
   backbone nodes.  If the VPN traffic traverses networks or equipment
   owned by multiple administrations then strong security mechanisms may
   be appropriate.  Also a strong level of security may be applied by a
   provider to customer traffic to address a customer perception that IP
   networks, and particularly the Internet, are insecure.  Whether or
   not this perception is correct it is one that must be addressed by
   the VPN implementation.

2.1.3 Quality of Service Guarantees

   In addition to ensuring communication privacy, existing private
   networking techniques, building upon physical or link layer
   mechanisms, also offer various types of quality of service
   guarantees.  In particular, leased and dial up lines offer both
   bandwidth and latency guarantees, while dedicated connection
   technologies like ATM and Frame Relay have extensive mechanisms for
   similar guarantees.  As IP based VPNs become more widely deployed,
   there will be market demand for similar guarantees, in order to
   ensure end to end application transparency.  While the ability of IP
   based VPNs to offer such guarantees will depend greatly upon the
   commensurate capabilities of the underlying IP backbones, a VPN
   framework must also address the means by which VPN systems can
   utilize such capabilities, as they evolve.



Gleeson, et al.              Informational                      [Page 7]

RFC 2764           IP Based Virtual Private Networks       February 2000


2.1.4 Tunneling Mechanism

   Together, the first two of the requirements listed above imply that
   VPNs must be implemented through some form of IP tunneling mechanism,
   where the packet formats and/or the addressing used within the VPN
   can be unrelated to that used to route the tunneled packets across
   the IP backbone.  Such tunnels, depending upon their form, can
   provide some level of intrinsic data security, or this can also be
   enhanced using other mechanisms (e.g., IPSec).

   Furthermore, as discussed later, such tunneling mechanisms can also
   be mapped into evolving IP traffic management mechanisms.  There are
   already defined a large number of IP tunneling mechanisms.  Some of
   these are well suited to VPN applications, as discussed in section
   3.0.

2.2  CPE and Network Based VPNs

   Most current VPN implementations are based on CPE equipment.  VPN
   capabilities are being integrated into a wide variety of CPE devices,
   ranging from firewalls to WAN edge routers and specialized VPN
   termination devices.  Such equipment may be bought and deployed by
   customers, or may be deployed (and often remotely managed) by service
   providers in an outsourcing service.

   There is also significant interest in 'network based VPNs', where the
   operation of the VPN is outsourced to an Internet Service Provider
   (ISP), and is implemented on network as opposed to CPE equipment.
   There is significant interest in such solutions both by customers
   seeking to reduce support costs and by ISPs seeking new revenue
   sources.  Supporting VPNs in the network allows the use of particular
   mechanisms which may lead to highly efficient and cost effective VPN
   solutions, with common equipment and operations support amortized
   across large numbers of customers.

   Most of the mechanisms discussed below can apply to either CPE based
   or network based VPNs.  However particular mechanisms are likely to
   prove applicable only to the latter, since they leverage tools (e.g.,
   piggybacking on routing protocols) which are accessible only to ISPs
   and which are unlikely to be made available to any customer, or even
   hosted on ISP owned and operated CPE, due to the problems of
   coordinating joint management of the CPE gear by both the ISP and the
   customer.  This document will indicate which techniques are likely to
   apply only to network based VPNs.







Gleeson, et al.              Informational                      [Page 8]

RFC 2764           IP Based Virtual Private Networks       February 2000


2.3  VPNs and Extranets

   The term 'extranet' is commonly used to refer to a scenario whereby
   two or more companies have networked access to a limited amount of
   each other's corporate data.  For example a manufacturing company
   might use an extranet for its suppliers to allow it to query
   databases for the pricing and availability of components, and then to
   order and track the status of outstanding orders.  Another example is
   joint software development, for instance, company A allows one
   development group within company B to access its operating system
   source code, and company B allows one development group in company A
   to access its security software.  Note that the access policies can
   get arbitrarily complex.  For example company B may internally
   restrict access to its security software to groups in certain
   geographic locations to comply with export control laws, for example.

   A key feature of an extranet is thus the control of who can access
   what data, and this is essentially a policy decision.  Policy
   decisions are typically enforced today at the interconnection points
   between different domains, for example between a private network and
   the Internet, or between a software test lab and the rest of the
   company network.  The enforcement may be done via a firewall, router
   with access list functionality, application gateway, or any similar
   device capable of applying policy to transit traffic.  Policy
   controls may be implemented within a corporate network, in addition
   to between corporate networks.  Also the interconnections between
   networks could be a set of bilateral links, or could be a separate
   network, perhaps maintained by an industry consortium.  This separate
   network could itself be a VPN or a physical network.

   Introducing VPNs into a network does not require any change to this
   model.  Policy can be enforced between two VPNs, or between a VPN and
   the Internet, in exactly the same manner as is done today without
   VPNs.  For example two VPNs could be interconnected, which each
   administration locally imposing its own policy controls, via a
   firewall, on all traffic that enters its VPN from the outside,
   whether from another VPN or from the Internet.

   This model of a VPN provides for a separation of policy from the
   underlying mode of packet transport used.  For example, a router may
   direct voice traffic to ATM Virtual Channel Connections (VCCs) for
   guaranteed QoS, non-local internal company traffic to secure tunnels,
   and other traffic to a link to the Internet.  In the past the secure
   tunnels may have been frame relay circuits, now they may also be
   secure IP tunnels or MPLS Label Switched Paths (LSPs)