PE-to-PE IPSec: do you have creative ideas?

Ying would like to have a PE-to-PE IPSec protection for traffic within a single VRF. For example, all traffic in VRF-A sent between PE-1 and PE-2 should be protected with IPSec and the PE-routers should be the endpoints of the IPSec session (CE-to-CE IPSec is trivial).

My first response was “hard to do”, then I started hallucinating about MPLS-over-GRE-over-IPSec-over-IP-over-MPLS tunnels between the PE-routers with tunnel-specific IGP and per-VRF BGP next hops. It can be done (we’ve implemented numerous large-scale MPLS/GRE/IPSec designs), but is there a simpler alternative? Please share your ideas in the comments.

20 comments:

  1. Hi!

    I Think you should take a look on Cisco GET ( Group Encrypted Transport VPN )
    :)
    http://www.cisco.com/en/US/products/ps7180/index.html

    ReplyDelete
  2. Ivan Pepelnjak16 July, 2009 08:20

    GETVPN is a CE-to-CE solution. We're looking for a PE-to-PE solution for a single VRF.

    ReplyDelete
  3. What about VRF aware IPsec feature? So create VRF B on both PEs as transit VRF and then run a VRF aware IP sec through it. Or some variation along those lines. :)

    ReplyDelete
  4. If you don't trust the MPLS VPN of your provider, why would you trust his PE routers?

    ReplyDelete
  5. Ivan Pepelnjak16 July, 2009 09:21

    I don't know the full background, but it could be site-deployed PE routers ... or someone trying to offload the burden of regulatory-enforced encryption to the SP.

    ReplyDelete
  6. You can indeed use IPSEC in a VRF mode.
    2 options:
    you can use the IGP core as tunnel endpoints, you will use global (not VRF!) loopbacks as the source and destination of the tunnel and just use the "ip vrf forwarding" under the tunnel (this is a very nice security feature that will make every successfully(!) decrypted packet enter the VRF specified in the "ip vrf forwad" command).
    If you want the tunnel to initiate from within the VRF itself, you can ADD the " tunnel vrf" command to the tunnel - then, the source and destination will have to belong to the VRF context.

    Hope this helps!

    ReplyDelete
  7. Ivan Pepelnjak16 July, 2009 09:27

    Thanks for the idea. Much better than mine ... but it destroys all the scalability of MPLS VPN, as you have to build per-VRF tunnels between the PE-routers (not to mention the routing mess you could make).

    ReplyDelete
  8. Hmmm, what about running MPLS/VPN over DMVPN between the PE ?

    ReplyDelete
  9. Ivan Pepelnjak16 July, 2009 09:31

    You're making my hallucinations scalable 8-) If nothing better comes along, we can always use this.

    ReplyDelete
  10. I agree MPLSoDMVPN is your friend if you're looking for pure scalability, but MIGRATING from MPLS core to IP core and running mpls on tunnels is quite a change...certainty not feasible for SP (if that's the case)

    ReplyDelete
  11. What about binding a crypto-map on the customer-facing interface(s) of the PE, so incoming traffic should be encrypted, forwarded into the VRF and routed thru the VPN.
    Don't know if this is possible but it may work...?

    ReplyDelete
  12. Because the crypto map works in the output direction.

    ReplyDelete
  13. So I tried, it seems to work (if I didn't make any mistake) with a basic config (ie DMVPN without crypto):

    http://www.ipflow.utc.fr/configs/DMVPN_PE/

    (Sorry I don't have any drawing at this time)

    The "mpls bgp forwarding" command on the tunnel interface did the trick.

    ReplyDelete
  14. Well Explained about the requirement of PE-PE Ip Sec Security

    http://etutorials.org/Networking/MPLS+VPN+security/Part+III+Practical+Guidelines+to+MPLS+VPN+Security/Chapter+6.+How+IPsec+Complements+MPLS/Location+of+the+IPsec+Termination+Points/

    ReplyDelete
  15. Ivan Pepelnjak17 July, 2009 09:09

    Great job. Thanks! Can I use the configs in my other articles?

    BTW, using "mpls ip" on the tunnel interface should also work.

    ReplyDelete
  16. Ivan Pepelnjak17 July, 2009 09:10

    Thanks. Great document (I wonder where it came from, it's too well written for a "free tutorials" web site).

    ReplyDelete
  17. Yes, of course, no problem.

    About using LDP, I read in http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/ngwanempls.html that direct spoke-to-spoke communication is not possible except via the hub acting as a P router (I guess the PE cannot form a LDP adjacency ?)

    ReplyDelete
  18. Hi think I missed your point, I guess the idea was to have "mpls ip" on the interface only to allow MPLS packets, not to establish LDP adjacencies.

    ReplyDelete
  19. google gives the answer ...

    http://my.safaribooksonline.com/1587051834/part01
    MPLS VPN Security, by Michael H. Behringer; Monique J. Morrow

    Back to the topic, for me it's crazy idea
    to have the SP encrypt the traffic of it's customers.
    Possible ? Maybe, but who would like
    to have such a network ?

    ReplyDelete
  20. Its not about the SP encrypting traffic for its users as a "service" , but more about maintaining security when using a carrier of carriers model . That means the SP is using the internet as the core between PEs. Happens frequently with VNOs.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.