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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
