Date: Mon, 18 Dec 2000 13:02:42 +0100 From: Jesper Skriver <jesper@skriver.dk> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: David Schwartz <davids@webmaster.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Kris Kennaway <kris@FreeBSD.ORG>, cvs-all@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h Message-ID: <20001218130242.E99044@skriver.dk> In-Reply-To: <200012180347.eBI3lc517024@whizzo.transsys.com>; from louie@TransSys.COM on Sun, Dec 17, 2000 at 10:47:38PM -0500 References: <NCBBLIEPOCNJOAEKBEAKCEFFMIAA.davids@webmaster.com> <200012180347.eBI3lc517024@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 17, 2000 at 10:47:38PM -0500, Louis A. Mamakos wrote: > > The historical reason for why you'd only want to react to an ICMP > destination unreachable on SYN segments is so that intermittant > routing failures don't kill your connection. It was reasonable > to assume that a destination unreachable on the SYN segment probably > meant that there was no path to the host you were trying to connect > to, and you might as well give up. If you managed to open the connection, > than an unreachable was likely to be transient in nature. > > This made sense when most ICMP destination unreachable messages were due > to "route to host" or "route to network" doesn't exist reasons. Today, > they also include these pesky "administratively unreachable" message types. > Perhaps there needs to be an addition of a new PRC_<foo> message type > to encode the "administratively unreachable" semantic seperately from a > routing failure type error? Still, the problem we're trying to solve here is primary when setting up the session, I cannot see that it's a major problem to wait for the TCP timeout if someone applies a filter denying existing sessions. This would also simplify the code somewhat, as we always start with a window of zero, thus I don't have to take the window size into account. What is the general feeling about this, as I see it we have 2 options here. 1) Only zap connections in SYN-SENT state => simpler check for sequence number 2) Zap connections in any state (given it's a "administratively unreachable"), need a new PRC_<foo> and a more complex check for sequence number. My vote is for 1), as it solve 99.9% of the real life problem. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001218130242.E99044>