Securing an eBGP session with a static VTI while using physical interface for data plane.

A common and reasonable requirement would be to secure communications of the control plane for BGP between two neighbors to provide data authentication, confidentiality and anti-replay.  Since BGP does not possess any inherent security mechanism other than MD5 authentication (and some session based protections for eBGP) the only option is to use some other feature to provide this.  The most common protocol for IP based security is IPsec.

One approach to this is to use a tunneling method, such as GRE or VTI,  to establish the BGP session between the two peers.  The problem with this is that a tunnel may have an undesirable effect on the data plane for various reasons including issues of fragmentation, reduced MTU, and performance.  Moreover path MTU discovery does not always work correctly when IPsec is involved. (It can work if you configure IPsec to copy the df-bit from the IP headers and the transit path is not blocking ICMP. )

This problem of data following control plan can be overcome with a route-map applied inbound to all updates from the eBGP on the far end of the tunnel to point to the physical interface next-hop.  The end result is that the eBGP session is established across the VTI yet the BGP table has the next hop of the physical interface of the peer, not the tunnel IP.

Screen Shot 2015-04-22 at 11.29.48 PM


Sample config from R1:

!First we need to define phase 1 policy:
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
!
crypto isakmp key CISCO address 12.0.0.2
!
!We then create our transform set & IPsec profile:
!
crypto ipsec transform-set XSET esp-aes esp-md5-hmac
mode tunnel
!
crypto ipsec profile PROFILE1
set transform-set XSET
!
!A VTI is created using the directly connected subnet between R1 and R2:
!
interface Tunnel12
ip address 1.1.1.1 255.255.255.0
tunnel source Ethernet0/0
tunnel mode ipsec ipv4
tunnel destination 12.0.0.2
tunnel protection ipsec profile PROFILE1
!
!The BGP session is establish to R2 using the tunnel IP:
!
router bgp 100
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
neighbor 1.1.1.2 remote-as 200
neighbor 1.1.1.2 route-map SET-NEXT-HOP in
!
!Our route-map modifies all updates from R2 to point to its physical interface.
!This must be applied INBOUND:

!
route-map SET-NEXT-HOP permit 10
set ip next-hop 12.0.0.2
!


The end result is that the networks advertised from R2 have the next hop PA of the physical interface of R2, not the tunnel. Therefore the data plane traffic will use the directly connect subnet for transit rather than the VTI:

Screen Shot 2015-04-22 at 11.54.41 PM

Notice that the eBGP session is established over the VTI:

Screen Shot 2015-04-23 at 12.00.17 AM

However we can send the full sized packet to the eBGP peer.  No MTU issues here:

Screen Shot 2015-04-23 at 12.04.40 AM

We cannot say the same for the VTI which will not support the standard 1500 byte MTU:

Screen Shot 2015-04-23 at 12.06.06 AM

Mission completed. The BGP control plane has been secured using an IPSec VTI and the data plane follows the directly connected interface rather than the tunnel. Please note that while the IPsec settings used here are suitable for lab purpose, consider using stronger cipher suites and hashing for a production network. (And never used the shared key of “CISCO” except in lab!)

Advertisements
About

Network Engineer interested in many areas including switches/routers/firewalls, SAN, and virtualization. I am currently employed by Cisco Systems. While I like to think that everything I write is well reasoned and insightful, the opinions expressed are solely mine and do not represent my employer.

Posted in Projects, Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Charles Stizza

Enter your email address to follow this blog and receive notifications of new posts by email.

April 2015
M T W T F S S
« Dec   Oct »
 12345
6789101112
13141516171819
20212223242526
27282930  
  • Optimize Data Center Infrastructure: Build an Optimized Fabric November 17, 2017
    I published the last part of my Optimize Data Center Infrastructure series: build an optimized data center fabric.To learn more about data center fabric designs, check the new online course or enroll into the Spring 2018 session of Building Next-Generation Data Center course.More on www.ipSpace.net
    Ivan Pepelnjak
%d bloggers like this: