Exploiting VRF

Question for my fellow nerds that enjoy looking under the hood.

Goal

New VPN Hub for terminating hundreds of site-to-site VPNs.

Design

Due to budget constraints, use existing 2x Cisco ASR1K as the hub VPN routers. Existing VRFs are for a handful of internal segments (interconnects). You make 2 new VRFs for this to work:

corporate-vrf: for decrypted, internal traffic.

FVRF: aka ipsec-aware VRF. Internet facing, for ipsec terminations.

As each remote site has static IP, you only have /32 static routes in the FVRF. No default route.

ACLs are configured to only allow the remote sites' IP addresses, and only ipsec related protocols (esp, Ike, nat-t, ICMP echo and echo-reply).

Palo Alto firewalls sit between the FVRF and Internet, fully loaded with IPS capability, AppID, etc. They also only allow required ipsec protocols.

The hurdle

You pass your design to Infosec Team and they reject it. Reason:

"The FVRF could get hacked and give the attacker direct access to the corporate network."

They are willing to approve if you put physical firewalls between the corporate network and the ASRs, which of course impacts the other VRFs. However, you have no budget, so new firewalls or routers is out of the question. You decide your only hope is to prove the risk is acceptable.

Determining risk

I believe the risk is extremely low, maybe even impractical, of having the ASR get hacked from the FVRF. Nevertheless, I suppose it is possible under these conditions:

1. The attacker must hijack one of the remote site's public IP.

2. The attacker must know a zero-day that exploits VRF and IPsec enough to gain full access to the router.

3. The attacker must do this undetected by internal monitoring systems, especially when the victim remote site is down due to the IP hijack.

4. The attacker must go undetected by the Palo Alto firewalls. The only way for this to happen is for attacks to ride in ESP payloads and/or for a zero day to also be exploited on PANOS. Sending attacks via IKE, NAT-T or ICMP should be nearly impossible because of AppID.

The real concern

I'm wondering in particular about how VRF could be exploited. How are packets going from FVRF to corporate-vrf, electrically? I believe the VRF technology is based on Linux LXC containers, or something similar, in which protected memory copies happen or some crazy shit like that. I just can't wrap my head around this design being hacked.

Of course, if a government entity is the attacker, I suppose they may have some crazy way of getting in, but at that point, if your attackers are government entities, then no solution is sufficient

Thus, I believe the design is solid, without needing an extra set of internal firewalls for the decrypted traffic. What do you think?