rfc2764.txt

RFC 的详细文档！

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


   Other models of a VPN are also possible.  For example there is a
   model whereby a set of application flows is mapped into a VPN.  As
   the policy rules imposed by a network administrator can get quite
   complex, the number of distinct sets of application flows that are
   used in the policy rulebase, and hence the number of VPNs, can thus
   grow quite large, and there can be multiple overlapping VPNs.
   However there is little to be gained by introducing such new
   complexity into a network.  Instead a VPN should be viewed as a
   direct analogue to a physical network, as this allows the leveraging
   of existing protocols and procedures, and the current expertise and
   skill sets of network administrators and customers.

3.0  VPN Tunneling

   As noted above in section 2.1, VPNs must be implemented using some
   form of tunneling mechanism.  This section looks at the generic
   requirements for such VPN tunneling mechanisms.  A number of
   characteristics and aspects common to any link layer protocol are
   taken and compared with the features offered by existing tunneling
   protocols.  This provides a basis for comparing different protocols
   and is also useful to highlight areas where existing tunneling
   protocols could benefit from extensions to better support their
   operation in a VPN environment.

   An IP tunnel connecting two VPN endpoints is a basic building block
   from which a variety of different VPN services can be constructed.
   An IP tunnel operates as an overlay across the IP backbone, and the
   traffic sent through the tunnel is opaque to the underlying IP
   backbone.  In effect the IP backbone is being used as a link layer
   technology, and the tunnel forms a point-to-point link.

   A VPN device may terminate multiple IP tunnels and forward packets
   between these tunnels and other network interfaces in different ways.
   In the discussion of different types of VPNs, in later sections of
   this document, the primary distinguishing characteristic of these
   different types is the manner in which packets are forwarded between
   interfaces (e.g., bridged or routed).  There is a direct analogy with
   how existing networking devices are characterized today.  A two-port
   repeater just forwards packets between its ports, and does not
   examine the contents of the packet.  A bridge forwards packets using
   Media Access Control (MAC) layer information contained in the packet,
   while a router forwards packets using layer 3 addressing information
   contained in the packet.  Each of these three scenarios has a direct
   VPN analogue, as discussed later.  Note that an IP tunnel is viewed
   as just another sort of link, which can be concatenated with another
   link, bound to a bridge forwarding table, or bound to an IP
   forwarding table, depending on the type of VPN.




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


   The following sections look at the requirements for a generic IP
   tunneling protocol that can be used as a basic building block to
   construct different types of VPNs.

3.1  Tunneling Protocol Requirements for VPNs

   There are numerous IP tunneling mechanisms, including IP/IP [6],
   Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling
   Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label Switching
   (MPLS) [9].  Note that while some of these protocols are not often
   thought of as tunneling protocols, they do each allow for opaque
   transport of frames as packet payload across an IP network, with
   forwarding disjoint from the address fields of the encapsulated
   packets.

   Note, however, that there is one significant distinction between each
   of the IP tunneling protocols mentioned above, and MPLS.  MPLS can be
   viewed as a specific link layer for IP, insofar as MPLS specific
   mechanisms apply only within the scope of an MPLS network, whereas IP
   based mechanisms extend to the extent of IP reachability.  As such,
   VPN mechanisms built directly upon MPLS tunneling mechanisms cannot,
   by definition, extend outside the scope of MPLS networks, any more so
   than, for instance, ATM based mechanisms such as LANE can extend
   outside of ATM networks.  Note however, that an MPLS network can span
   many different link layer technologies, and so, like an IP network,
   its scope is not limited by the specific link layers used.  A number
   of proposals for defining a set of mechanisms to allow for
   interoperable VPNs specifically over MPLS networks have also been
   produced ([10] [11] [12] [13], [14] and [15]).

   There are a number of desirable requirements for a VPN tunneling
   mechanism, however, that are not all met by the existing tunneling
   mechanisms.  These requirements include:

3.1.1  Multiplexing

   There are cases where multiple VPN tunnels may be needed between the
   same two IP endpoints.  This may be needed, for instance, in cases
   where the VPNs are network based, and each end point supports
   multiple customers.  Traffic for different customers travels over
   separate tunnels between the same two physical devices.  A
   multiplexing field is needed to distinguish which packets belong to
   which tunnel.  Sharing a tunnel in this manner may also reduce the
   latency and processing burden of tunnel set up.  Of the existing IP
   tunneling mechanisms, L2TP (via the tunnel-id and session-id fields),
   MPLS (via the label) and IPSec (via the Security Parameter Index
   (SPI) field) have a multiplexing mechanism.  Strictly speaking GRE
   does not have a multiplexing field.  However the key field, which was



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


   intended to be used for authenticating the source of a packet, has
   sometimes been used as a multiplexing field.  IP/IP does not have a
   multiplexing field.

   The IETF [16] and the ATM Forum [17] have standardized on a single
   format for a globally unique identifier used to identify a VPN (a
   VPN-ID).  A VPN-ID can be used in the control plane, to bind a tunnel
   to a VPN at tunnel establishment time, or in the data plane, to
   identify the VPN associated with a packet, on a per-packet basis.  In
   the data plane a VPN encapsulation header can be used by MPLS, MPOA
   and other tunneling mechanisms to aggregate packets for different
   VPNs over a single tunnel.  In this case an explicit indication of
   VPN-ID is included with every packet, and no use is made of any
   tunnel specific multiplexing field.  In the control plane a VPN-ID
   field can be included in any tunnel establishment signalling protocol
   to allow for the association of a tunnel (e.g., as identified by the
   SPI field) with a VPN.  In this case there is no need for a VPN-ID to
   be included with every data packet.  This is discussed further in
   section 5.3.1.

3.1.2  Signalling Protocol

   There is some configuration information that must be known by an end
   point in advance of tunnel establishment, such as the IP address of
   the remote end point, and any relevant tunnel attributes required,
   such as the level of security needed.  Once this information is
   available, the actual tunnel establishment can be completed in one of
   two ways - via a management operation, or via a signalling protocol
   that allows tunnels to be established dynamically.

   An example of a management operation would be to use an SNMP
   Management Information Base (MIB) to configure various tunneling
   parameters, e.g., MPLS labels, source addresses to use for IP/IP or
   GRE tunnels, L2TP tunnel-ids and session-ids, or security association
   parameters for IPSec.

   Using a signalling protocol can significantly reduce the management
   burden however, and as such, is essential in many deployment
   scenarios.  It reduces the amount of configuration needed, and also
   reduces the management co-ordination needed if a VPN spans multiple
   administrative domains.  For example, the value of the multiplexing
   field, described above, is local to the node assigning the value, and
   can be kept local if distributed via a signalling protocol, rather
   than being first configured into a management station and then
   distributed to the relevant nodes.  A signalling protocol also allows
   nodes that are mobile or are only intermittently connected to
   establish tunnels on demand.




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


   When used in a VPN environment a signalling protocol should allow for
   the transport of a VPN-ID to allow the resulting tunnel to be
   associated with a particular VPN.  It should also allow tunnel
   attributes to be exchanged or negotiated, for example the use of
   frame sequencing or the use of multiprotocol transport.  Note that
   the role of the signalling protocol need only be to negotiate tunnel
   attributes, not to carry information about how the tunnel is used,
   for example whether the frames carried in the tunnel are to be
   forwarded at layer 2 or layer 3. (This is similar to Q.2931 ATM
   signalling - the same signalling protocol is used to set up Classical
   IP logical subnetworks as well as for LANE emulated LANs.

   Of the various IP tunneling protocols, the following ones support a
   signalling protocol that could be adapted for this purpose: L2TP (the
   L2TP control protocol), IPSec (the Internet Key Exchange (IKE)
   protocol [18]), and GRE (as used with mobile-ip tunneling [19]). Also
   there are two MPLS signalling protocols that can be used to establish
   LSP tunnels. One uses extensions to the MPLS Label Distribution
   Protocol (LDP) protocol [20], called Constraint-Based Routing LDP
   (CR-LDP) [21], and the other uses extensions to the Resource
   Reservation Protocol (RSVP) for LSP tunnels [22].

3.1.3  Data Security

   A VPN tunneling protocol must support mechanisms to allow for
   whatever level of security may be desired by customers, including
   authentication and/or encryption of various strengths.  None of the
   tunneling mechanisms discussed, other than IPSec, have intrinsic
   security mechanisms, but rely upon the security characteristics of
   the underlying IP backbone.  In particular, MPLS relies upon the
   explicit labeling of label switched paths to ensure that packets
   cannot be misdirected, while the other tunneling mechanisms can all
   be secured through the use of IPSec.  For VPNs implemented over non-
   IP backbones (e.g., MPOA, Frame Relay or ATM virtual circuits), data
   security is implicitly provided by the layer two switch
   infrastructure.

   Overall VPN security is not just a capability of the tunnels alone,
   but has to be viewed in the broader context of how packets are
   forwarded onto those tunnels.  For example with VPRNs implemented
   with virtual routers, the use of separate routing and forwarding
   table instances ensures the isolation of traffic between VPNs.
   Packets on one VPN cannot be misrouted to a tunnel on a second VPN
   since those tunnels are not visible to the forwarding table of the
   first VPN.






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


   If some form of signalling mechanism is used by one VPN end point to
   dynamically establish a tunnel with another endpoint, then there is a
   requirement to be able to authenticate the party attempting the
   tunnel establishment.  IPSec has an array of schemes for this
   purpose, allowing, for example, authentication to be based on pre-
   shared keys, or to use digital signatures and certificates.  Other
   tunneling schemes have weaker forms of authentication.  In some cases
   no authentication may be needed, for example if the tunnels are
   provisioned, rather than dynamically established, or if the trust
   model in use does not require it.

   Currently the IPSec Encapsulating Security Payload (ESP) protocol
   [23] can be used to establish SAs that support either encryption or
   authentication or both.  However the protocol specification precludes
   the use of an SA where neither encryption or authentication is used.
   In a VPN environment this "null/null" option is useful, since other
   aspects of the protocol (e.g., that it supports tunneling and
   multiplexing) may be all that is required.  In effect the "null/null"
   option can be viewed as just another level of data security.