Is it possible to implement IPSEC over MPLS?

Question

On a high level, I understand that the data-traffic(original ip packet) is encrypted and encapsulated in ESP header (imagine a IPSEC in tunnel mode). Generally, this IPSEC tunnel is triggered by Crypto-map(ACL matching the source and destination IP addresses and ports).

Is it possible to construct a Crypto-MAP based on MPLS labels ? So, that the user-data can be encrypted and sent over a IPSEC tunnel which in turn is sent over a MPLS tunnel.

If it is possible does the ESP next-header has the value 137 (MPLS in IP) ?

Answer 1

If your MPLS L3VPN supports IP transport from endpoint A to/from endpoint B at the other site (which is their primary purpose), there's nothing to stop you from letting A and B talk IPSec (in one or another variety) to each other.

That would be IPSEC-over-MPLS-L3VPN, and to the underlying MPLS network (or the L3VPN service it offers), this would be just like any other IP traffic from A to B, it would just happen to look like IP protocol 50 or udp/4500, with some udp/500, occasionally.

Actually, GETVPN is something quite like that: A carrier/service provider offers a service interconnecting many sites with "native" spoke-to-spoke capablity, and the (usually) enterprisey customer attach their endpoints (their GETVPN speaking routers) to it. The GETVPN routers orchestrate their GETVPN over the provider's service, using their variant of IPSec. Done.

But I think you were rather looking in the direction of what usually is/was answered by running MPLS-over-GRE-over-IP(Sec), to extend label switching connectivity across a (secured) tunnel over an (untrusted) network.

Yes, that can be done, but there's quite a few caveats.

Just some that spring to mind:

• SLA: MPLS based VPN services used to be built and bought with SLAs and QoS in mind. There's no SLA on the open Internet. Reconvergence times (minutes) are not comparable to an SP's backbone (seconds).
• QoS: You can copy the inner header's DSCP bits to the outermost IPSec header as much as you like - once the packets the leave your network, no one can tell what's inside, and the DSCP bits in the outermost header are going to be disregarded (in any case) or nullified (probably) by the ISPs.
• Hardening/Security Policy: Exposing an MPLS speaking node (P or PE) to the open Internet is going to lead to debates, and would certainly demand rigid hardening. Depending on the given security policy, the MPLS speakers might have to resort to running MPLS-over-GRE, while a dedicated security device (attached to the Internet) would do the IPSec part.
• MTU and fragmentation: While an enterprise's or carrier's MPLS backbone usually just doesn't care because it is jumbo frame enabled, be prepared to be bitten by the old PathMTU snake when running MPLS-o-GRE-o-IP(Sec). Label stack, GRE header, outer IPSec header, PPPoE headers are all going to eat into your end to end PathMTU to begin with. And just when you think you figured it all out, there's a device in the path that ignores the DF-bits and fragments the packets anyway (sometimes unnoticeably, sometimes at a detrimental performance impact), or a combination of PPPoE and NAT-T crops up, and another 8 bytes are gone.

Answer 2

Yes. Cisco's VRF-Aware IPsec documentation indicates:

The VRF-Aware IPsec feature introduces IP Security (IPsec) tunnel mapping to Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). By using the VRF-Aware IPsec feature, you can map IPsec tunnels to Virtual Routing and Forwarding (VRF) instances using a single public-facing address.

Restrictions for VRF-Aware IPsec

• If you are configuring VRF-Aware IPsec using a crypto map configuration and the Inside VRF (IVRF) is not the same as the Front Door VRF (FVRF), this feature is not interoperable with unicast reverse path forwarding (uRPF) if uRPF is enabled on the crypto map interface. If your network requires uRPF, it is recommended that you use Virtual Tunnel Interface (VTI) for IPsec instead of crypto maps.
• The VRF-Aware IPsec feature does not allow IPsec tunnel mapping between VRFs. For example, it does not allow IPsec tunnel mapping from VRF vpn1 to VRF vpn2.
• When the VRF-Aware IPsec feature is used with a crypto map, this crypto map cannot use the global VRF as the IVRF and a non-global VRF as the FVRF. However, configurations based on virtual tunnel interfaces do not have that limitation.

VRF Instance

A VRF instance is a per-VPN routing information repository that defines the VPN membership of a customer site attached to the Provider Edge (PE) router. A VRF comprises an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included in the routing table. A separate set of routing and CEF tables is maintained for each VPN customer.

MPLS Distribution Protocol

The MPLS distribution protocol is a high-performance packet-forwarding technology that integrates the performance and traffic management capabilities of data link layer switching with the scalability, flexibility, and performance of network-layer routing.

VRF-Aware IPsec Functional Overview

Front Door VRF (FVRF) and Inside VRF (IVRF) are central to understanding the feature.

Each IPsec tunnel is associated with two VRF domains. The outer encapsulated packet belongs to one VRF domain, which we shall call the FVRF, while the inner, protected IP packet belongs to another domain called the IVRF. Another way of stating the same thing is that the local endpoint of the IPsec tunnel belongs to the FVRF while the source and destination addresses of the inside packet belong to the IVRF.

One or more IPsec tunnels can terminate on a single interface. The FVRF of all these tunnels is the same and is set to the VRF that is configured on that interface. The IVRF of these tunnels can be different and depends on the VRF that is defined in the Internet Security Association and Key Management Protocol (ISAKMP) profile that is attached to a crypto map entry.