>>>>> "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 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..
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.
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.
--
] 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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
