On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: > 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.
No, I want security, and this goes back to the administrative domain issue. If I have installed and configured all of the gateways in the overlay network, I could trust them enough to have the packets routed through any of them. With that assumption gone, I agree that your peer can spoof you. > >>> 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. I think this can be accomplished by adding some table entries in user.def, and the support database has instructions on this, but I'll admin that it's obscure enough that I can't find that out from here. The UI is designed according to marketing requirements to answer what they believe customer needs are. I think that is true for all vendors. >> 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. Yeah, we do something similar. We are a stateful firewall, so every packet is associated with a "connection" (well defined for TCP, SCTP; kind of bogus for UDP), and every connection is associated with a tunnel, so outbound packets get to use the correct SA (or at least one matching the SA that inbound packets came through). > >> 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. I think that is a narrow, IPsec-centric view. It says that IPsec is secure and does not support dynamic SPDs in order to be secure. If you need dynamic tunnels, then use GRE, and then it's BGP (or RIP or OSPF) problem. For network administrators (and thus vendors) it's their problem: they want both the security and the ability to get around failed links and nodes that routing provides for the Internet. I would be happy to have an IKE/IPsec-only solution. But I don't think there is one now. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
