From owner-cvs-all Mon Dec 18 4: 2:49 2000 From owner-cvs-all@FreeBSD.ORG Mon Dec 18 04:02:44 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 603F237B402; Mon, 18 Dec 2000 04:02:44 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id BDA9F3E4B; Mon, 18 Dec 2000 13:02:42 +0100 (CET) Date: Mon, 18 Dec 2000 13:02:42 +0100 From: Jesper Skriver To: "Louis A. Mamakos" Cc: David Schwartz , Poul-Henning Kamp , Kris Kennaway , 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> References: <200012180347.eBI3lc517024@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012180347.eBI3lc517024@whizzo.transsys.com>; from louie@TransSys.COM on Sun, Dec 17, 2000 at 10:47:38PM -0500 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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_ 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_ 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