On Thu, 17 Nov 2011, Yoav Nir wrote:
Not necessarily. If your device drops packets that come through the "wrong"
tunnel, you're safe. Typically in a complex network you will allow multiple paths through
the overlay network, and then some spoofing can happen.
So you want privacy, not security. IPsec is meant to deliver both.
CISCO IOS IPsec is a poor tunneling protocol.
Many other vendors do a better job.
Ohhh (blush)
Don't worry, we have interop issues with checkpoint too :)
I'll buy dinner to the firs person showing me how to use the gui tools
to build rfc1918/XX <-> 0/0 on tcp 443 tunnel. Heck, I'll buy dinner
if you can do it with the cli command too.
But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs are
static, so there is only one peer where a particular source IP might come from.
Openswan supports MARKing the packet based on which SPI the packet
came out of, ip_conntrack then follows its around and reply packets
get the MARK as well, so we know which tunnel to send it to despite the
overlapping IP address on the client end. We even provide a setsockopt()
option so you MARK your socket before connecting to 192.168.1.1 and the
kernel knows which SPI to send the packet to. And each IPsec policy can
optin to allowing a range that would overlap.
That is good for security, but poor for traffic engineering. We would like to
have more than one path through the overlay network, and that requires some
kind of routing protocol. And yes, such a routing protocol needs to be secure
and not degenerate into a free-for-all. Whether any vendor provides that now is
a subject for (intense) debate.
If you need that, just run GRE with BGP on your routers connected with
simple static IPsec tunnels. Don't degrade the IPsec security within
the tunnels.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
