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.

Recent posts in the same categories

20 comments:

  1. Runar 16 July 2009 08:14
    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
  2. Ivan Pepelnjak 16 July 2009 08:20
    GETVPN is a CE-to-CE solution. We're looking for a PE-to-PE solution for a single VRF.
  3. Drb999 16 July 2009 09:09
    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. :)
  4. Dirk-Jan 16 July 2009 09:17
    If you don't trust the MPLS VPN of your provider, why would you trust his PE routers?
  5. Ivan Pepelnjak 16 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.
  6. Ofer 16 July 2009 09:22
    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!
  7. Ivan Pepelnjak 16 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).
  8. chris 16 July 2009 09:28
    Hmmm, what about running MPLS/VPN over DMVPN between the PE ?
  9. Ivan Pepelnjak 16 July 2009 09:31
    You're making my hallucinations scalable 8-) If nothing better comes along, we can always use this.
  10. Ofer 16 July 2009 10:46
    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)
  11. Christoph 16 July 2009 16:37
    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...?
  12. chris 16 July 2009 17:38
    Because the crypto map works in the output direction.
  13. chris 16 July 2009 23:43
    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.
  14. shivlu jain 17 July 2009 07:06
    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/
  15. Ivan Pepelnjak 17 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.
  16. Ivan Pepelnjak 17 July 2009 09:10
    Thanks. Great document (I wonder where it came from, it's too well written for a "free tutorials" web site).
  17. chris 17 July 2009 09:19
    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 ?)
  18. chris 17 July 2009 12:06
    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.
  19. xls 17 July 2009 14:11
    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 ?
  20. mayurgai 18 July 2009 03:18
    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.
Add comment
Home
Sidebar