> >>>>>> "Mike" == Mike Sullenberger <[email protected]> writes: > Mike> We use other tunnel mechanisms (GRE), because IPsec tunneling mode > Mike> is lacking in functionality. For example, when you use GRE for the > Mike> tunneling you also reduce the IPsec SA's that are needed to > Mike> "describe" > Mike> the traffic for IPsec to encrypt. If you use IPsec tunnel mode only > Mike> then for each pairing of subnets behind each peer you need a separate > Mike> IPsec SA. For example if there are 5 subnets each behind two peers > Mike> then you need up to 25 SA pairs to describe exactly what needs to be > Mike> encrypted and nothing more. If you tunnel the data traffic first > Mike> then > Mike> you only need 1 SA pair for all traffic, since IPsec encrypts the > Mike> tunnel itself and not the traffic within the tunnel. > >So, you trade IPsec SAs ("security ACLs") for extended access-lists and >routing tables. I don't see a difference if both are automatically >updated by a policy engine. > >I can see that this might matter for devices with fixed purpose ASICs >that accelerate one kind of access list, but not another..
I am not sure where you are getting a set of extended access-lists. There aren't any extended access-lists added. If a packet is routed through the tunnel it is encapsulated and then encrypted. There isn't any access-list necessary. As for routing table, you have that in either case. With pure IPsec you don't run a routing protocol over the "tunnel" but the peer (hub at least) still needs to advertise what subnets are reachable through the VPN, especially in cases where you have alternate paths to get to the remote network. > Mike> What you call other fancy features is what I call functional > Mike> separation. > Mike> IPsec does encryption well, but in reality it does a fairly > Mike> poor job of > Mike> tunneling. So lets have IPsec do what it does well and have > Mike> GRE do what > Mike> it does well and that is tunneling. Then you add NHRP do to > Mike> next-hop > >I'm curious if you've worked with any other vendor's IPsec? >Because the issues you describe seem to be implementation limitations. I have worked some with other vendor's IPsec when troubleshooting interaction issues. I still believe that IPsec at the base is not a good tunneling protocol. >Still, I think that NHRP over GRE is a pretty good solution to the >problem, particularily if in the end, you didn't want to actually have >any ACLs on the resulting tunnels. Mike. >-- >] He who is tired of Weird Al is tired of life! | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ >] [email protected] http://www.sandelman.ottawa.on.ca/ |device >driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. +------------------------------------------------+ | Mike Sullenberger; DSE | | [email protected] .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
