[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC tunnels for LAN-to-LAN interop issue



> Which brings up a problem in doing transport mode protected IPinIP. The 
> selector would be for protocol 4 between the two boxes which means that 
> _anything_ could be put into those tunnels.

Some may have viewed that as a feature, but I'm well past that point
myself...

> In tunnel mode the selector would be for whatever protocol in contained in
> the inner packet-- say, UDP port 520-- and then only that could be
> extracted from the tunnel.

Which means if you implement a tunnel as an interface, the tunnel interface
will also have to become a policy enforcement point.

This problem is in transport-mode already, BTW.  TCP detaches connections
when they close, so you don't have convienient socket state to look around
for cached policy.  Not just IP, or generic BSD-style inpcb demuxing, but TCP
itself also has to look at the IPsec processing applied to the inbound
packet, match it against any TCP retransmit state for those dying
connections, and make a decision.  (Not to mention little details like
sending RSTs to ports that aren't there, etc.)

This can apply analogously to a tunnel driver/module/whatever.  It's a b*tch
to implement right, but it's the only way to really enforce per-flow tunnel
policy.

Dan


References: