Date: Sun, 17 Dec 2000 22:47:38 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: "David Schwartz" <davids@webmaster.com> Cc: "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: <200012180347.eBI3lc517024@whizzo.transsys.com> In-Reply-To: Your message of "Sun, 17 Dec 2000 16:23:46 PST." <NCBBLIEPOCNJOAEKBEAKCEFFMIAA.davids@webmaster.com> References: <NCBBLIEPOCNJOAEKBEAKCEFFMIAA.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? louie > > Since we only react to this in "SYN-SENT" I think the window of > > opportunity is rather small in the first place... > > That assumes you don't know exactly when and where a machine is going to > make a particular connection attempt. But there are security-critical tests > wherein the attacker would know this exact information. > > Consider, for example, an ident check. When I connect to you, I know you > are immediately going to make an outbound connection to a particular IP and > port. Similar arguments could be made about NIS. The same goes for proxy > checking. Consider a chat server immediately after a split. I'm sure others > could think of more (and more serious) examples. > > My understanding was that modern operating systems do not follow the RFC in > this respect. They simply store the information and use it to (possibly) > modify the error code they return when/if the connection attempt fails. > > DS > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe cvs-all" in the body of the message 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?200012180347.eBI3lc517024>