[MPLS-in-IP-GRE]. If it is desired to use such tunnels to carry VPN
packets, then the security considerations described in Section 8 of
that document must be fully understood. Any implementation of
BGP/MPLS IP VPNs that allows VPN packets to be tunneled as described
in that document MUST contain an implementation of IPsec that can be
used as therein described. If the tunnel is not secured by IPsec,
then the technique of IP address filtering at the border routers,
described in Section 8.2 of that document, is the only means of
ensuring that a packet that exits the tunnel at a particular egress
PE was actually placed in the tunnel by the proper tunnel head node
(i.e., that the packet does not have a spoofed source address).
Since border routers frequently filter only source addresses, packet
filtering may not be effective unless the egress PE can check the IP
source address of any tunneled packet it receives, and compare it to
a list of IP addresses that are valid tunnel head addresses. Any
implementation that allows MPLS-in-IP and/or MPLS-in-GRE tunneling to
be used without IPsec MUST allow the egress PE to validate in this
manner the IP source address of any tunneled packet that it receives.
In the case where a number of CE routers attach to a PE router via a
LAN interface, to ensure proper security, one of the following
conditions must hold:
1. All the CE routers on the LAN belong to the same VPN, or
2. A trusted and secured LAN switch divides the LAN into multiple
VLANs, with each VLAN containing only systems of a single VPN;
in this case, the switch will attach the appropriate VLAN tag
to any packet before forwarding it to the PE router.
Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible with
the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study.
13.2. Control Plane
The data plane security of the previous section depends on the
security of the control plane. To ensure security, neither BGP nor
LDP connections should be made with untrusted peers. The TCP/IP MD5
authentication option [TCP-MD5] should be used with both these
protocols. The routing protocol within the SP’s network should also
be secured in a similar manner.
13.3. Security of P and PE Devices
If the physical security of these devices is compromised, data plane
security may also be compromised.
The usual steps should be taken to ensure that IP traffic from the
public Internet cannot be used to modify the configuration of these
devices, or to mount Denial of Service attacks on them.
14. 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 [MPLS-ENCAPS], or, where ATM
is used as the backbone, through the use of ATM QoS capabilities.
The traffic engineering work discussed in [MPLS-RSVP] is also
directly applicable to MPLS/BGP VPNs. Traffic engineering could even
be used to establish label switched paths 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 [PASTE] may be useful. An SP may apply
either intserv (Integrated Services) or diffserv (Differentiated
Services) capabilities to a particular VPN, as appropriate.
15. 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 (that are neither PE routers nor
Route Reflectors), and, in the case of multi-provider VPNs, (d)
ASBRs.
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 maintains VPN routes, but only for those VPNs to which it
is directly attached.
Route reflectors can be partitioned among VPNs so that each partition
carries routes for only a subset of the VPNs supported by the Service
Provider. Thus, no single route reflector is required to maintain
routes for all VPNs.
For inter-provider VPNs, if the ASBRs maintain and distribute VPN-
IPv4 routes, then the ASBRs can be partitioned among VPNs in a
similar manner, with the result that no single ASBR is required to
maintain routes for all the inter-provider VPNs. If multi-hop EBGP
is used, then the ASBRs need not maintain and distribute VPN-IPv4
routes at all.
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.
16. IANA Considerations
The Internet Assigned Numbers Authority (IANA) has created a new
registry for the "Route Distinguisher Type Field" (see Section 4.2).
This is a two-byte field. Types 0, 1, and 2 are defined by this
document. Additional Route Distinguisher Type Field values with a
high-order bit of 0 may be allocated by IANA on a "First Come, First
Served" basis [IANA]. Values with a high-order bit of 1 may be
allocated by IANA based on "IETF consensus" [IANA].
This document specifies (see Section 4.3.4) the use of the BGP
Address Family Identifier (AFI) value 1, along with the BGP
Subsequent Address Family Identifier (SAFI) value 128, to represent
the address family "VPN-IPv4 Labeled Addresses", which is defined in
this document.
The use of AFI value 1 for IP is as currently specified in the IANA
registry "Address Family Identifier", so IANA need take no action
with respect to it.
The SAFI value 128 was originally specified as "Private Use" in the
IANA "Subsequent Address Family Identifier" registry. IANA has
changed the SAFI value 128 from "private use" to "MPLS-labeled VPN
address".
17. Acknowledgements
The full list of contributors can be found in Section 18.
Significant contributions to this work have also been made by Ravi
Chandra, Dan Tappan, and Bob Thomas.
We also wish to thank Shantam Biswas for his review and
contributions.
18. Contributors
Tony Bogovic
Telcordia Technologies
445 South Street, Room 1A264B
Morristown, NJ 07960
EMail: tjb@research.telcordia.com
Stephen John Brannon
Swisscom AG
Postfach 1570
CH-8301
Glattzentrum (Zuerich), Switzerland
EMail: stephen.brannon@swisscom.com
Marco Carugi
Nortel Networks S.A.
Parc d’activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE
EMail: marco.carugi@nortelnetworks.com
Christopher J. Chase
AT&T
200 Laurel Ave
Middletown, NJ 07748
USA
EMail: chase@att.com
Ting Wo Chung
Bell Nexxia
181 Bay Street
Suite 350
Toronto, Ontario
M5J2T3
EMail: ting_wo.chung@bellnexxia.com
Eric Dean
Jeremy De Clercq
Alcatel Network Strategy Group
Francis Wellesplein 1
2018 Antwerp, Belgium
EMail: jeremy.de_clercq@alcatel.be
Luyuan Fang
AT&T
IP Backbone Architecture
200 Laurel Ave.
Middletown, NJ 07748
EMail: luyuanfang@att.com
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK
EMail: paul.hitchen@bt.com
Manoj Leelanivas
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043 USA
EMail: manoj@juniper.net
Dave Marshall
Worldcom
901 International Parkway
Richardson, Texas 75081
EMail: dave.marshall@wcom.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Monique Jeanne Morrow
Cisco Systems, Inc.
Glatt-com, 2nd floor
CH-8301
Glattzentrum, Switzerland
EMail: mmorrow@cisco.com
Ravichander Vaidyanathan
Telcordia Technologies
445 South Street, Room 1C258B
Morristown, NJ 07960
EMail: vravi@research.telcordia.com
Adrian Smith
BT
BT Adastral Park
Martlesham Heath,
Ipswich IP5 3RE
UK
EMail: adrian.ca.smith@bt.com
Vijay Srinivasan
1200 Bridge Parkway
Redwood City, CA 94065
EMail: vsriniva@cosinecom.com
Alain Vedrenne
Equant
Heraklion, 1041 route des Dolines, BP347
06906 Sophia Antipolis, Cedex, France
EMail: Alain.Vedrenne@equant.com
19. Normative References
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000.
[BGP-EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP
Extended Communities Attribute", RFC 4360, February
2006.
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label
Information in BGP-4", RFC 3107, May 2001.
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
20. Informative References
[BGP-AS4] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
AS Number Space", Work in Progress, March 2004.
[BGP-ORF] Chen, E. and Y. Rekhter, "Cooperative Route
Filtering Capability for BGP-4", Work in Progress,
March 2004.
[BGP-RFSH] Chen, E., "Route Refresh Capability for BGP-4", RFC
2918, September 2000.
[BGP-RR] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS
using LDP and ATM VC Switching", RFC 3035, January
2001.
[MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., T’Joens,
Y., and C. Sargor, "Architecture for the Use of
PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in
Progress, March 2004.
[MPLS-FR] Conta, A., Doolan, P., and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-in-IP-GRE] Worster, T., Rekhter, Y., and E. Rosen,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
A., and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[PASTE] Li, T. and Y. Rekhter, "A Provider Architecture for
Differentiated Services and Traffic Engineering
(PASTE)", RFC 2430, October 1998.
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault,
"Using an LSA Options Bit to Prevent Looping in
BGP/MPLS IP VPNs", Work in Progress, March 2004.
[TCP-MD5] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
[VPN-MCAST] Rosen, E., Cai, Y., and J. Wijsnands, "Multicast in
MPLS/BGP VPNs", Work in Progress, May 2004.
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF
as the PE/CE Protocol in BGP/MPLS VPNs", Work in
Progress, February 2004.
Authors’ Addresses
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).