rfc2547.txt

RFC 的详细文档！

9.1. Point-to-Point Security Tunnels between CE Routers

   A security-conscious VPN user might want to ensure that some or all
   of the packets which traverse the backbone are authenticated and/or
   encrypted. The standard way to obtain this functionality today would
   be to create a "security tunnel" between every pair of CE routers in
   a VPN, using IPSEC Tunnel Mode.

   However, the procedures described so far do not enable the CE router
   transmitting a packet to determine the identify of the next CE router
   that the packet will traverse.  Yet that information is required in
   order to use Tunnel Mode IPSEC.  So we must extend those procedures
   to make this information available.

   A way to do this is suggested in [6].  Every VPN-IPv4 route can have
   an attribute which identifies the next CE router that will be
   traversed if that route is followed.  If this information is provided
   to all the CE routers in the VPN, standard IPSEC Tunnel Mode can be
   used.

   If the CE and PE are BGP peers, it is natural to present this
   information as a BGP attribute.

   Each CE that is to use IPSEC should also be configured with a set of
   address prefixes, such that it is prohibited from sending insecure
   traffic to any of those addresses.  This prevents the CE from sending
   insecure traffic if, for some reason, it fails to obtain the
   necessary information.

   When MPLS is used to carry packets between the two endpoints of an
   IPSEC tunnel, the IPSEC outer header does not really perform any
   function.  It might be beneficial to develop a form of IPSEC tunnel
   mode which allows the outer header to be omitted when MPLS is used.

9.2. Multi-Party Security Associations

   Instead of setting up a security tunnel between each pair of CE
   routers, it may be advantageous to set up a single, multiparty
   security association. In such a security association, all the CE
   routers which are in a particular VPN would share the same security
   parameters (.e.g., same secret, same algorithm, etc.). Then the
   ingress CE wouldn't have to know which CE is the next one to receive
   the data, it would only have to know which VPN the data is going to.
   A CE which is in multiple VPNs could use different security
   parameters for each one, thus protecting, e.g., intranet packets from
   being exposed to the extranet.





Rosen & Rekhter              Informational                     [Page 21]

RFC 2547                     BGP/MPLS VPNs                    March 1999


   With such a scheme, standard Tunnel Mode IPSEC could not be used,
   because there is no way to fill in the IP destination address field
   of the "outer header".  However, when MPLS is used for forwarding,
   there is no real need for this outer header anyway; the PE router can
   use MPLS to get a packet to a tunnel endpoint without even knowing
   the IP address of that endpoint; it only needs to see the IP
   destination address of the "inner header".

   A significant advantage of a scheme like this is that it makes
   routing changes (in particular, a change of egress CE for a
   particular address prefix) transparent to the security mechanism.
   This could be particularly important in the case of multi-provider
   VPNs, where the need to distribute information about such routing
   changes simply to support the security mechanisms could result in
   scalability issues.

   Another advantage is that it eliminates the need for the outer IP
   header, since the MPLS encapsulation performs its role.

10. Quality of Service

   Although not the focus of this paper, Quality of Service is a key
   component of any VPN service.  In MPLS/BGP VPNs, existing L3 QoS
   capabilities can be applied to labeled packets through the use of the
   "experimental" bits in the shim header [10], or, where ATM is used as
   the backbone, through the use of ATM QoS capabilities.  The traffic
   engineering work discussed in [1] is also directly applicable to
   MPLS/BGP VPNs.  Traffic engineering could even be used to establish
   LSPs with particular QoS characteristics between particular pairs of
   sites, if that is desirable.  Where an MPLS/BGP VPN spans multiple
   SPs, the architecture described in [7] may be useful.  An SP may
   apply either intserv or diffserv capabilities to a particular VPN, as
   appropriate.

11. Scalability

   We have discussed scalability issues throughout this paper.  In this
   section, we briefly summarize the main characteristics of our model
   with respect to scalability.

   The Service Provider backbone network consists of (a) PE routers, (b)
   BGP Route Reflectors, (c) P routers (which are neither PE routers nor
   Route Reflectors), and, in the case of multi-provider VPNs, (d)
   ASBRs.







Rosen & Rekhter              Informational                     [Page 22]

RFC 2547                     BGP/MPLS VPNs                    March 1999


   P routers do not maintain any VPN routes.  In order to properly
   forward VPN traffic, the P routers need only maintain routes to the
   PE routers and the ASBRs. The use of two levels of labeling is what
   makes it possible to keep the VPN routes out of the P routers.

   A PE router to maintains VPN routes, but only for those VPNs to which
   it is directly attached.

   Route reflectors and ASBRs can be partitioned among VPNs so that each
   partition carries routes for only a subset of the VPNs provided by
   the Service Provider. Thus no single Route Reflector or ASBR is
   required to maintain routes for all the VPNs.

   As a result, no single component within the Service Provider network
   has to maintain all the routes for all the VPNs.  So the total
   capacity of the network to support increasing numbers of VPNs is not
   limited by the capacity of any individual component.

12. Intellectual Property Considerations

   Cisco Systems may seek patent or other intellectual property
   protection for some of all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Cisco Systems, Cisco
   intends to disclose those patents and license them on reasonable and
   non-discriminatory terms.

13. Security Considerations

   Security issues are discussed throughout this memo.

14. Acknowledgments

   Significant contributions to this work have been made by Ravi
   Chandra, Dan Tappan and Bob Thomas.
















Rosen & Rekhter              Informational                     [Page 23]

RFC 2547                     BGP/MPLS VPNs                    March 1999


15. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   EMail: [e-mail]


   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   EMail: [e-mail]

16. References

   [1] Awduche, Berger,  Gan, Li, Swallow, and Srinavasan,  "Extensions
       to RSVP for LSP Tunnels", Work in Progress.

   [2] Bates, T. and R. Chandrasekaran, "BGP Route Reflection: An
       alternative to full mesh IBGP", RFC 1966, June 1996.

   [3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol
       Extensions for BGP4", RFC 2283, February 1998.

   [4] Gleeson, Heinanen, and Armitage, "A Framework for IP Based
       Virtual Private Networks", Work in Progress.

   [5] Kent and Atkinson, "Security Architecture for the Internet
       Protocol", RFC 2401, November 1998.

   [6] Li, "CPE based VPNs using MPLS", October 1998, Work in Progress.

   [7] Li, T. and Y. Rekhter, "A Provider Architecture for
       Differentiated Services and Traffic Engineering (PASTE)", RFC
       2430, October 1998.

   [8] Rekhter and Rosen, "Carrying Label Information in BGP4", Work in
       Progress.

   [9] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching
       Architecture", Work in Progress.

  [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS
       Label Stack Encoding", Work in Progress.



Rosen & Rekhter              Informational                     [Page 24]

RFC 2547                     BGP/MPLS VPNs                    March 1999


17.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Rosen & Rekhter              Informational                     [Page 25]