Should I Use L2VPN+MACSEC or L3VPN+GETVPN?

Here are the outlines of an interesting ExpertExpress discussion:

  • A global organization wanted to connect data centers across the globe with a new transport backbone.
  • All the traffic has to be encrypted.

Should they buy L2VPN and use MACsec on it or L3VPN and use GETVPN on it (considering they already have large DMVPN deployments in each region)?

As always, the correct answer is it depends, in this case on how much you value SP independence versus performance, cost and equipment manufacturer independence.

Please note that they were not looking for a highly secure solution. That requirement would totally change the conversation and I’d recommend they get in touch with Christoph Jaggi who knows infinitely more about that topic than I do.

The first recommendation I made was try to be as independent from your Service Provider as you can be. In other words, don’t go for a classic L3VPN where the SP owns your core routing (yes, I know that sounds weird coming from the guy who wrote several MPLS books).

There are (at least) two ways to achieve that goal:

  • Buy L2VPN and run traditional IP routing on top of it.
  • Buy L3VPN and build an overlay (CE-to-CE tunnels) on top of it. Don’t run routing protocol with the SP but rely on PE-CE subnets for transport connectivity (an architecture recently remarketed as SD-WAN).

The beauty of the second approach: you can use it with every VPN service (or even across the Internet) from every SP worldwide, which puts your SP in an awkward spot during the contract negotiation.

Not surprisingly, the customer’s SP contacts strongly suggested staying with traditional L3VPN.

Second recommendation: decide whether you want to use a single VPN design for your access and core networks (in which case go with DMVPN for the core network) or whether you want to optimize other criteria, for example:

  • Price/performance. High-speed MACsec is dirt cheap compared to IPsec or IP-over-GRE-over-IPsec-over-IP (= DMVPN).
  • Equipment vendor independence. Any router or firewall on the market supports point-to-point IPsec tunnels, and it’s reasonably easy to build a multi-vendor solution, giving you more negotiation room when faced with expensive high-speed IPsec hardware from your beloved vendor. DMVPN locks you into Cisco.

Why would I even consider DMVPN for the core network? Because the customer already has extensive DMVPN operational experience, whereas anything else would introduce a learning curve.

Why did I totally ignore GETVPN? GETVPN was designed for a single (end-to-end) routing domain, for example securing customer (CE-to-CE) traffic in classic L3VPN deployment with PE-CE routing protocols, which would make it hard to change SPs on the fly.

Recent posts in the same categories

5 comments:

  1. Anonymous 15 September 2016 12:23
    GETVPN can be used in conjunction with DMVPN stripped of the tunnel protection profile, (so basically just mGRE+NHRP) to enable centralised IPSEC policy. Having the shared TEK is nice too, because it removes IPSEC negotiation time during re-convergence events or new spoke-spoke communication flows and reduces your SA count to 1.

    Having said that, I'll never use GETVPN (or Juniper Group VPN) ever again. Despite four keyservers in two data centres, a combination of a bug + data centre scheduled maintenance brought down every site in an 1000 site network.
  2. Christoph Jaggi 17 September 2016 20:00
    As always it depends. The question should not be using MACSec for a L2VPN or GETVPN for a L3VPN. Once the transport backbone has been determined, operational requirements should be the foundation for technical decisions. MACSec is neither dirt-cheap (the software license still has a price, even when bundled into a security image) nor the smartest way to encrypt Ethernet at layer 2 for WANs and MANs. IEEE MACSec has been designed for LAN use and one key objective has been low hardware cost so that it could be build in every Ethernet network chip and vendors would have an opportunity to sell software licenses. A WAN is a different beast than a LAN, has a different behavior - especially when traversing different Carrier networks - and needs a different level of protection. Embedded MACSec solutions have limited scalability, limited functionality, provide low-assurance security and many of them max out at 90% IMIX throughput at 10G. Specialized solutions developed for Carrier Ethernet networks tend to come with full scalability (up to 1000 peers), much more functionality, provide high-assurance security, full throughput and state-of-the-art key management (including sophisticated and battle-proven group key management).
    For Ethernet encryption for WAN and MAN there are substantially better options than MACSec.
  3. Anonymous 28 September 2016 12:46
    Apparently Cisco does not really support the scenario if there is a device between MACSEC endpoints. Which is pretty much always the case with a provider offering some service.
  4. netwrkr95 31 January 2017 13:29
    @Anonymous. While Cisco was challenged in this scenario, Cisco created a new MACsec framework in, what is now referred to as "WAN MACsec", where they offer the operator the ability to change the MKA (MACsec keying packets) MAC address as well as ethertype to a well-known pair, that public Ethernet carriers and backbone-bridges will not consume and process (and then drop which is the case for current EAP over LAN packets). There is a solutions paper available discussing this solution, in detail. http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/white-paper-c11-737544.html
  5. Unknown 15 September 2017 20:45
    If you overlay a SP's MPLS network and/or Internet then GetVPN is a logical solution as it encrypts the packets - does not do the tunneling (i.e. VxLAN or LISP overlay with GetVPN - GDOI for encryption). MacSec is interesting, but doesn't the SP need to decrypt on ingress and encrypt on egress? I'm paranoid and you should be as well.
Add comment
Home
Sidebar