Internet DRAFT - draft-declercq-bgp-mpls-vpn-sec-ext
draft-declercq-bgp-mpls-vpn-sec-ext
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
<draft-declercq-bgp-mpls-vpn-sec-ext-00.txt>
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]
