Hi,
On Nov 8, 2005, at 11:23, Mike Silbersack wrote:
I'm open to discussing the change. I plan to revisit that and the
SYN causing a connection reset issue after eurobsdcon.
good to know, thanks!
However, I'm open to clubbing you over the head for not saying
anything throughout the entire 6.0 release cycle and requesting the
change AFTER THE RELEASE HAS SHIPPED. Since 6.0 shipped with this
feature on, I don't think we should flip the setting back to off
until a good reason has been given.
Point taken, and I'm very sorry. I no longer follow -current, so I've
missed this completely until I looked at 6.0.
The argument for switching it back off would be that the RST attack
is probably only effective against long-lived connections between
well-known ports, the canonical example being BGP sessions. I doubt
that the average user has many such connections open and thus will
see little benefit from having this on. The change does increase the
chances of ignoring valid RSTs, which could lead to all sorts of
problems, especially when talking to esoteric TCP stacks. These two
effects (attack resistance vs. compatibility) are hard to trade off.
I'd personally argue for the conservative approach. Also note that
other attacks against long-lived TCP connections are still possible,
e.g., through spoofed ICMP packets.
I do see the release engineering aspects of switching this off by
default. In the end, it's a judgement call.
While we're on the subject of potential problems, I'd like to throw
out an idea. What would people think of a "log perhaps somewhat in
vain" option (turned on by default) that logged unusual looking
packets to /var/log/ip.log - but did it in a ratelimited fashion,
so that it would not be possible for attackers to chew up disk
space. This would of course get written to during an attack, but
it would also log legitimate cases, such as where a RST blocked by
this setting came in. This could also be used to tell if future
changes cause additional incompatibilities.
Such a feature wouldn't cause performance problems, but I could see
there being privacy concerns. If the log was only root readable,
what would people think? Remember that I'm talking only about
logging "odd" packets, and only their TCP/IP flags and fields, not
the data contents.
I think that'd be very useful. I frequently come across entries in
the logs that I wish I had some more information about. I'd even go
as far as (optionally) dumping all such packets in tcpdump format.
Lars
--
Lars Eggert NEC Network Laboratories
