[31509] in North American Network Operators' Group
FW: netscan.org update
daemon@ATHENA.MIT.EDU (Roeland M.J. Meyer)
Tue Sep 26 15:13:09 2000
Message-ID: <1148622BC878D411971F0060082B042C371B@hawk.lvrmr.mhsc.com>
From: "Roeland M.J. Meyer" <rmeyer@MHSC.com>
To: "NANOG (E-mail)" <nanog@merit.edu>
Date: Tue, 26 Sep 2000 12:10:54 -0700
MIME-Version: 1.0
Content-Type: text/plain
Errors-To: owner-nanog-outgoing@merit.edu
> > Simpler than what you suggest is to read RFC 2644, then turn off
> > directed broadcasts in routers being deployed, and making the
> > default be
> > DISABLED on new routers.
>
> I agree. But, for some reason, that isn't working as well as
> it should. BTW, one feature that has been enabled for years
> is a default ingress filter that blocks inbound packets that
> have a source addr from inside the net-block (obviously wrong
> or an attack). Because bcast addrs values are configuration
> dependent, it is not possible to use such a generic filter.
> However, it should be possible to build dynamic bcast
> scanning into a router such that it scans the internal net
> for bcast addrs and subsequently ingress filters all packets
> to those source addrs that do not originate on the local
> netblock. This will not solve the immediate problem with
> existing routers. But, that same method can be used to scan
> the /24 and auto-generate the required filter statements for
> the firewall. The upstream can run it the other way, for the
> client, except that they would be egress filtering. This
> method requires no in-addr.arpa edits.
>
> > I'd rather see sites spend their time on that rather than
> > adding INADDR entries to their domains. Remember that
> delegations to other
> > organizations (i.e. clients of ISPs) are able to subdivide networks
> > further, and that won't be apparent to the ISP.
>
> Agreed, that's why I also wrote about dynamic bcast discovery methods.
>
> In case anyone missed my point, using BGP blackholing becomes
> anti-social behavior when more surgical techniques are
> available. Moreso when such techniques aren't even explored
> before implementing the blackhole method.
>
> MAPS has only gained a modicum of acceptability because more
> socially acceptable methods were tried and subsequently
> failed. Moreover, they have been shown to not even be
> feasible. This is NOT the case with the smurf-amp problem. I,
> for one, am NOT convinced that sufficient thought has been
> directed at more socially acceptable alternative solutions.
>
