Network Working Group Jeremy De Clercq Internet Draft Yves T'Joens Expiration Date: August 2001 Olivier Paridaens Alcatel Chandru Sargor Vijay Srinivasan Cosine February 2001 Considerations about possible security extensions to BGP/MPLS VPN 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract Purpose of this document The aim of this text is to contribute to the design work of the Provider Provisioned VPN Working Group. This text contains the motivation and requirements for extending the BGP/MPLS VPN model with security measures. Further, the draft explores some possible extensions to meet the listed requirements. Note that the procedures discussed in this draft relate to the backbone of the architecture De Clercq, et al. Expires August 2001 [Page 1] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 (between peer PEs), and not to the CE-PE communication. It is assumed that the reader is familiar with the concepts and mechanisms of BGP/MPLS VPN [RFC2547bis]. 1. Motivation With the possible large deployment of Provider Provisioned VPNs as a major service in provider networks, the motivation to extend a largely supported model as BGP/MPLS VPN is manyfold: - BGP/MPLS VPN relies on a completely MPLS-aware provider network. As some service providers might want to offer PP-VPN services before their core network is completely MPLS-capable (transition scenario), and as inter-SP VPN scenarios might use non-MPLS capable pieces of the network, an extension of BGP/MPLS VPN, to make the model applicable in non-MPLS networks, in a secure and scalable way, would be very usuable. - As "data separation" (see section 2) might not offer a sufficient level of security in many of the currently available network architectures, a scalable way to integrate stronger security offerings into the existing BGP/MPLS VPN model should be provided. Even if an MPLS backbone is used, stronger security measures are useful. 2. Security Requirements for the Service Provider's Backbone network This section lists some possible requirements for the security measures applied in the Service Provider's backbone network. These apply to every possible piece of the path between two Provider Edge Devices. - Possibility to offer different levels of security. The BGP/MPLS VPN model in itself offers inherent data privacy by means of "data separation". This means that the data traffic belonging to different VPNs is always handled in different contexts. BGP/MPLS VPN does this by using separate VRFs in the PE boxes and by using the MPLS label stacking functionality. The result of this data separation is that traffic from a certain VPN (context) cannot be injected deliberately or accidentally into another VPN, and that traffic belonging to a certain VPN (context) cannot be deliberately or accidentally received in another VPN (context). While this technique to assure data privacy might be sufficient in network environments where the service provider is in full control of every network element, it might not be sufficient in network De Clercq, et al. Expires August 2001 [Page 2] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 environments where the service provider's network consists of a 'dark fiber' network that belongs to a third party, and where the 'data privacy' security aspect relies on a 'trusting' relationship. Moreover, as we can assume that the scope of VPNs will in certain situations not be restrained to one single domain, it is very likely that the 'backbone network' might consist of different parts owned by different parties. Based on these observations, a PP-VPN model should be easily extendable to allow for the offering of e.g. encryption security in a scalable way. - The application of different possible granularities in the offering of different security levels. Possible granularities include : PE-PE security offering, per-VPN security offering, per-route security offering. * PE-PE security offering In this scenario, the security levels are specified between two PE devices. This means that all the VPN traffic between two PEs is subject to the same level of security. * per-VPN security offering In this scenario, the security levels are specified per VPN context between two PE devices. This means that the traffic between two PEs, belonging to different VPNs can be subject to a different level of security. * per-route security offering This scenario gives the finest granularity of security offering, the security level to be applied between both PEs can be specified for every individual VPN route. - distribution of the required level of security, according to a specific granularity The communication of the level of security to be used for a certain part of the data traffic would be an added value to the VPN deployment model. This would mean that a PE device that peers with a certain customer site would announce to its peer PE devices which level of security to use to send traffic to the considered site. Depending on the possible granularity, this announced level De Clercq, et al. Expires August 2001 [Page 3] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 of security would apply to all the VPN traffic sent to the announcing PE, to the traffic sent to a specific VPN, or to the traffic sent to a specific VPN route. 3. BGP/MPLS VPN extensions 3.1 BGP/IPSEC VPN The Internet-Draft [bgp/ipsec] describes a method that allows to extend BGP/MPLS VPN over non-MPLS parts of the network and to offer IPsec [RFC2401] security in a scalable way. 3.1.1 Mapping on the requirements - possibility for different levels of security : the model inherits implicitely the IPsec security features for all VPN traffic between two PE devices. - possibility for the announcement of different security granularities : as the label that is announced via BGP in BGP/IPSEC VPN is meant to be inserted in the SPI-suffix part of the SPI (and as such identifying a certain security association), and as the egress PE chooses and distributes this label-value, this label can also implicitely indicate a security level to use. This allows for a per- route security-level announcement. 3.1.2 Changes to existing protocols/models - BGP/IPsec VPN does not require any changes to BGP and does not require any new BGP attributes compared to [RFC2547bis]. - BGP/IPsec VPN requires changes in the interpretation of the SPI- field in the IKE [IKE] and IPsec [RFC2401] processing, but doesn't require changes to the IPsec framework. - An optimisation of BGP/IPSec VPN requires the source IP address to be taken into account during the Security Association selection process. 3.2 BGP/'MPLS-IN-IP' VPN An alternative method to achieve BGP/MPLS VPN functionality in non- MPLS networks and to add PE-to-PE IPsec security in a scalable way is by using "MPLS-IN-IP" [mpls-in-ip]. This method uses normal IP- forwarding in the backbone SP network, and distributes the VPN-routes with BGP, as in [RFC2547bis]. The separation of the contexts in the shared backbone is achieved by encapsulating a labelled MPLS frame into an ordinary IP packet. De Clercq, et al. Expires August 2001 [Page 4] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 3.2.1 VPN Route Distribution The VPN Route Distribution is as in [RFC2547bis]. A PE announces its customer routes via BGP. Such a BGP-message contains a labelled VPN- IPv4 address/prefix. 3.2.2 End-to-end packet flow The customer CE device sends a private IP packet (that might have a private destination IP address) towards his PE. In the PE, a lookup for that IP packet is done in the appropriate VRF. This lookup will result in a next hop PE destination address and an MPLS label L to use. The PE will now encapsulate the private IP packet in an MPLS frame with 1 label in the shim header : the label L. As the provider's backbone is not MPLS-aware, the PE will encapsulate the constructed MPLS frame in a new IP packet, with the next hop PE as the destination address. At this stage, the packet that will be sent into the PE's backbone consists of the following parts : ___________________________________________________________________ | new IP hdr | MPLS shim (1 label) | priv IP hdr | priv payload ... | ------------------------------------------------------------------- Based on the destination address in the outer IP header, the packet will be forwarded correctly through the SP's backbone towards the 'next hop PE'. Based on the outer IP header, the receiving PE will know that the payload is an MPLS frame and based on the MPLS label that is contained in the MPLS shim header, the receiving PE will handle the private IP packet appropriately (in the correct VPN context). This method does not imply any MPLS knowledge in the core of the SP network. The only SP MPLS-aware network elements are the Provider Edge Devices. 3.2.3 Mapping on the requirements - possibility for different levels of security : - no extra security is implicit - IPsec mechanisms directly applicable by using IPsec transport mode for the VPN traffic between 2 PEs. The complete MPLS frame is covered by IPsec then. - possibility for the announcement of different security De Clercq, et al. Expires August 2001 [Page 5] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 granularities : by adding a new BGP attribute containing the SPI that identifies a specific Security Association to the BGP distribution of VPN addresses, a per-route security level can be announced when distributing VPN routes from PE to PE. This requires the definition of a new BGP attribute, containing an SPI value. - possibility for the announcement of per-VPN security at VPN set-up as is described in "BGP/VPN: VPN information discovery for Network- based VPNs"[BGP/VPN]. This allows the egress PE device to announce to the ingress PE devices which IPsec tunnel to use for what specific routes. This scenario assumes that the egress PE chooses the SPI indexes and is able to use the same SPI value for different ingress PE devices. 3.2.4 Changes to existing protocols/models - A new BGP attribute is required to be able to announce the per- route security level. - No changes to IKE/IPsec framework are required. - An optimization for the announcement of different security levels requires the IP source address to be used for the Security Association selection process. - The PE devices must be able to encapsulate MPLS frames in IP packets and to appropriately handle such packets. 3.3 Example 3.3.1 Different Levels of Security Assume that a SP offers two levels of security over its backbone. Assume that for that purpose, PE1 can receive VPN traffic through two different tunnels from both PE2 and PE3. Assume that these two tunnels are represented by two security associations : SA_strong and SA_weak. Assume now that PE1 has chosen the SPI-indexes to identify these SA's, and that it chooses SPI_S for SA_strong and SPI_W for SA_weak. De Clercq, et al. Expires August 2001 [Page 6] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 ___ ___ ___ | | | | | | | |________SA_S________ | |____SA_S_______| | |PE2|-------------------- |PE1|---------------|PE3| | |________SA_W________ | |____SA_W_______| | | |-------------------- | |---------------| | --- --- --- - In BGP/IPSEC VPN, PE1 will announce its customers' routes to PE2 and PE3, and the label that PE1 announces with these routes will not only be used to identify the correct VPN context, but PE2 and PE3 must be able to interprete (parts of) the announced label to choose the appropriate IPsec SA to use for that particular traffic. - In "MPLS-IN-IP", PE1 will announce its customers routes via BGP to PE2 and PE3, and must add a new BGP attribute to its message to identify the SA to use for that particular traffic (for per-route security granularity). For per-VPN security granularity, the SPI to use (or another identifier) might have been distributed as in [BGP/VPN] during the information discovery. 3.3.2 Differences between the two proposed models The model presented in [bgp/ipsec] offers the least data overhead, but requires a new interpretation of the SPI-field in the IKE and IPsec processing. The model that we called BGP/MPLS-IN-IP needs no changes to the IKE nor IPSEC interpretation of the SPI field, but it requires more data overhead, and a new BGP attribute to bind the security level to a labelled route. 4. Security Considerations This draft focuses on the security considerations of BGP/MPLS VPN [RFC2547bis]. 5. Acknowledgements We would like to thank Eric Rosen for his valuable comments that lead to the section "MPLS-IN-IP" and all the contributors to the discussions on the NB-VPN exploder. 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 De Clercq, et al. Expires August 2001 [Page 7] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 [RFC2547] Rosen, E. and Rekhter, Y., "BGP/MPLS VPN", RFC 2547, March 1999. [RFC2547bis] Rosen E., Rekhter Y., et al., "BGP/MPLS VPN", Work in Progress. [RFC2401] Kent, S. and Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [bgp/ipsec] De Clercq, J. et al, "BGP/IPsec VPN", Work in Progress. [mpls-in-ip] Worster, T., et al, "MPLS Label Stack Encapsulation in IP", Work in Progress. [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange", RFC 2409, November 1998. [BGP/VPN] Ouldbrahim, H., et al., "BGP/VPN: VPN information discovery for Network-based VPNs", Work in progress 7. Authors' Addresses Jeremy De Clercq Alcatel Francis Wellesplein 1 2018 Antwerpen, Belgium Phone: +32 3 240 4752 Email: jeremy.de_clercq@alcatel.be Yves T'joens Alcatel Francis Wellesplein 1 2018 Antwerpen, Belgium Phone : +32 3 240 7890 Email : yves.tjoens@alcatel.be Olivier Paridaens Alcatel Francis Wellesplein 1 2018 Antwerpen, Belgium Phone: +32 3 240 9320 Email: olivier.paridaens@alcatel.be Chandru Sargor CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 Email: csargor@cosinecom.com De Clercq, et al. Expires August 2001 [Page 8] Draft draft-declercq-bgp-mpls-vpn-sec-ext-00.txt February 2001 Vijay Srinivasan CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 Email: vijay@cosinecom.com De Clercq, et al. Expires August 2001 [Page 9]