Date: Sat, 18 Nov 2000 17:23:54 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Mike Silbersack <silby@silby.com> Cc: Jesper Skriver <jesper@skriver.dk>, Alfred Perlstein <bright@wintelcom.net>, hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <200011182223.eAIMNs747524@whizzo.transsys.com> In-Reply-To: Your message of "Sat, 18 Nov 2000 11:04:55 CST." <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com> References: <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Sat, 18 Nov 2000, Jesper Skriver wrote: > > > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote: > > > > > > Probably not, what if one started a stream of spoofed ICMP lying > > > about the state of the route between the two machines? I have > > > the impression that the Linux box wouldn't be able to connect > > > because of this behavior. > > > > Correct, a attacker could in theory make sure we couldn't connect to > > a given remote box, but as I see it, it's mostly in teory. > > > > We could only react to this if we had a TCP session where we was > > waiting for a SYN/ACK from this specific host, this only leaves a very > > narrow window for a attacker to abuse, as he had to know both > > destination and time. > > > > Do you agree ? > > > > /Jesper > > Well, if you honor such messages, don't you have to honor them in the > middle of a connection too? Then you could cause a connection drop at any > time. No, you don't. This is a replay of discussions that happened literally 20 years ago as the first TCP implementations were being done. I believe the acceptable practice at the time was to honor an ICMP advisory (e.g., pass it to TCP to have it abort the pending connection) while in SYN-SENT state. That is, when initially trying to open the connection, give up sooner based on the ICMP message, rather than waiting for an ACK timeout. If an ICMP message associated with a connection was received after the connection passed to ESTABLISHED state, then you could choose to pass an advisory to the application, but not abort the connection. The Berkeley network stack did this, and a variety of applications would give up and die should they get an error return from a read() or write() system call on the connection, even though it was still alive. I think that behavior may have changed, but I haven't check anytime recently. At the time, the anticipated source of ICMP messages were Destination Unreachable advisories, provoked by either permanant or transient routing failures to the destination. > It would seem simpler to have the ISP in question use proper RST > responses, or just stop filtering totally. This behavior, while widely implemented, is a hack and a kludge. An intermediate network element isn't supposed to spoof source address and return responses on behalf of some other system. This only works for TCP, and only if you can see the headers (e.g., not encrypted with IPSEC). louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011182223.eAIMNs747524>