[50581] in North American Network Operators' Group
Re: NSPs filter?
daemon@ATHENA.MIT.EDU (Richard A Steenbergen)
Mon Aug 5 12:16:49 2002
Date: Mon, 5 Aug 2002 12:14:49 -0400
From: Richard A Steenbergen <ras@e-gerbil.net>
To: bdragon@gweep.net
Cc: nanog@merit.edu
In-Reply-To: <20020805160318.40776.qmail@sidehack.sat.gweep.net>
Errors-To: owner-nanog-outgoing@merit.edu
On Mon, Aug 05, 2002 at 12:03:18PM -0400, bdragon@gweep.net wrote:
> > Filtering piddly stuff like this without consultation is usually unwelcome
> > at best, and a disruption at worst. It is also a serious investment of
> > time and acl resources which could be better spent somewhere else. And
> > lastly, it sets a bad precedent for what ISPs "can" do to proactively
> > filter. After all, if we "can" do this, why can't we also filter illegal
> > MP3 exchanges too.
>
> One is envelope, the other is payload.
>
> Until there is some technical means of "return to sender" for IP, filtering
> bad envelopes is the next best thing.
They are exactly the same. In the first example you filter based on udp
port 53 source rfc1918 and perhaps dest rootservers, and hope you're only
hitting bad traffic, but you don't really know that the payload is DNS.
You can also filter mp3 exchanging services by header information and
most likely hit only them too.
Poking into anything other than dst ip or src/dest/port flows without
reason is an intrusion IMHO.
Of course in the example Stephen gave, RPF filters on the customer would
have likely solved the problem quite nicely. That is the only kind of
filtering which should be done on customers by default.
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
