From owner-freebsd-hackers Sat Nov 18 9:36:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 8B65037B479 for ; Sat, 18 Nov 2000 09:36:34 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id A183D3E5B; Sat, 18 Nov 2000 18:36:32 +0100 (CET) Date: Sat, 18 Nov 2000 18:36:32 +0100 From: Jesper Skriver To: Mike Silbersack Cc: Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001118183632.A99512@skriver.dk> References: <20001118155446.A81075@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Sat, Nov 18, 2000 at 11:04:55AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 18, 2000 at 11:04:55AM -0600, Mike Silbersack wrote: > > 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. I cannot see why we should honor them "in the middle of a connection", the real problem exist when setting up TCP sessions, if someone configure a filter when there are existing connections, they will die due to lack of response, but this would be a one time event. > It would seem simpler to have the ISP in question use proper RST > responses The problem is that the largest router vendor (Cisco) cannot do this. > or just stop filtering totally. Which is not a option in this case, and in the real world it's that uncommon. I'll see if I can get code together which will do this. If we leave this off by default, would people object to putting in this functionality ? /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 freebsd-hackers" in the body of the message