Re: pf blocks ACK response

[Daniel Hartmeier <daniel@benzedrine.cx>]

On Fri, Mar 22, 2002 at 01:36:52PM +1100, Darren Reed wrote:

> It sounds like you need to fix the way you use the AVL tree, to me,
> but then what would I know ?

I don't think you suggest supporting parallel states for the same
addresses/ports pairs where only the sequence number windows are
different. That's nonsense. No RFC compliant stack will use or need
this. Packets that match a state's addresses/ports pair but mismatch the
sequence number window are never an indication of a second, independant
connection. They are late retransmissions or (very) out of order
arrivals of packets, or (in most cases) quirks from broken stacks like
in this particular case.
   
So, we don't want to create an additional state. Sure, we could evaluate
the rules for such packets to make the pass/block decision configurable.
But silently dropping the packet (without returning an RST) is really
the only sane choice: imagine two hosts establishing a TCP connection,
both of which return RST for out-of-window packets. Now a malicious
third host sends an out-of-window packet to one of them, spoofing the
others source address. The RST would bounce repeatedly. Or terminate
the legitimate connection, if one of the peers is not strict enough to
ignore the wrong sequence number.
   
I'm running with pfctl -m x for a long time now, and I regularly
investigate such state mismatches. Not in a singular case would I want
to do anything else than drop the out-of-window packet silently.
 
Coming back to the particular case that triggered this discussion: while
it might appear clever using the packet filter to compensate for the
external host's broken stack (and broken it is, the RFC does not require
us to send an RST in this case. You couldn't connect to it without the
packet filter, either), I wouldn't do that. With such a rule set, you'll
inevitably send an RST for some late retransmission and break a
legitimate connection that would have otherwise worked.
   
BTW, it seems that host has been fixed, it does a regular TCP handshakes
now.
 
Daniel