On Fri, 21 Jul 2006, Mike Frantzen wrote: > Reassemble TCP does aggressive TCP PAWs checks on the TCP timestamps. > It does the usual PAWs check to make sure a timestamp is not older than > the last echoed value - which is in theory a wrapped sequence number. > It also does its aggressive check to make sure the timestamp did not > increase faster than the fastest clock which the RFC allows - an > attacker can kill a connection by spoofing a higher timestamp. In > order to prevent blind TCP spoofing PF's scrub will require TCP > timestamps on all data packets if the first data packet had a > timestamp. There are some transparent web caches out there that will > allow the 3whs to complete (exchanging timestamp information) and then > they will will hijack the TCP connection. Of course the developers of > the hijacking device took some liberal shortcuts that make them look > just like a blind hijacker instead of a MITM hijacker. If they hijack > in the middle of the data stream (like after they see the HTTP request) > and stop sending TCP Timestamps then PF's reassemble TCP will block > further packets.
How does this interfere with the NAT code? Reassemble tcp has _only_ problems from a machine behind the OpenBSD NAT router. On the router itself or if using a proxy running on it, there is no problem. So I'd think that it is actually an OpenBSD bug in the NAT and/or reassemble tcp code. How can this be verified? Regards, Walter
