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

Re: pps or other unknown upper bound?

On 11/17/05, Daniel Hartmeier <[email protected]> wrote:
> The address/port pairs are probably clear (there's three pairs,
> two are equal unless the state involves translation).
. . .
Thanks for the detailed explanation, that makes a a lot more sense.
> This all makes sense. Assuming you're fetching a tiny document
> from the web server in a fast loop, the client will run out of
> random source ports.  It's probably honouring 2MSL up to the point where
> it simply has no choice (other than stalling further connect(2) calls),
> until ports free up
In the original message, Jon mentions that the client and server are Debian;
I'd venture that the client may have different timeouts, or may just
not be honouring 2MSL in the same way as the firewall?
> The reason we keep a state in FIN_WAIT or TIME_WAIT is that there might
> be spurious packets arriving late (like packets that travelled through
> slower alternative paths across the network). By keeping the state
> entry, those are associated with the state and don't cause pflog logging
> (they'd usually not have a SYN flag and would get blocked and logged
So when pf does see a packet come in matching the address/port pairs for
any existing state entry (TIME_WAIT or otherwise) it always blocks the
packet, whether or not there is a SYN flag?
> according to your policy). So you'll likely not break anything by
> lowering the timeout values, but you might be getting some more packets
> logged as ordinary blocks.
In the specific case of TIME_WAIT, it reads as if when a stateful filter
or IP stack sees a SYN arriving with a "greater sequence number", one
which otherwise matches a state entry currently in TIME_WAIT,
it may be legal to flush the state earlier than 2MSL (see RFC 1337)?
Assuming  "aggressive" already makes assumptions about timeouts and
spurious packets arriving late, flushing old state entries when a "new" SYN
is seen would seem to be at least as secure and effective as lowering the
timeout values, but without the CPU overhead?
Kevin "showing the limits of my TCP knowledge" Kadow