Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Nov 2000 18:36:32 +0100
From:      Jesper Skriver <jesper@skriver.dk>
To:        Mike Silbersack <silby@silby.com>
Cc:        Alfred Perlstein <bright@wintelcom.net>, hackers@FreeBSD.ORG
Subject:   Re: React to ICMP administratively prohibited ?
Message-ID:  <20001118183632.A99512@skriver.dk>
In-Reply-To: <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com>; from silby@silby.com on Sat, Nov 18, 2000 at 11:04:55AM -0600
References:  <20001118155446.A81075@skriver.dk> <Pine.BSF.4.21.0011181102540.52996-100000@achilles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001118183632.A99512>