>
> On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote:
> >
> > I'm not blaming the victim, I'm pointing out the contributory
> > negligence on behalf of the ISP that is supplying the
> > attacker bandwidth.
> >
> > BCP 38 is over 7 years old now. The time has past where you can
> > blame the hardware vendors for lack of support. The blame
> > now has to be squarely brought down on the ISP's that have failed
> > to deploy BCP 38.
>
> Really? How many ISPs are you aware of that have
> *decommissioned* every piece of routing gear in their
> network in the past 7 years? The ugly bit here is that
> routers usually are pushed further and further to the
> edge of the network, until they finally fall off. The
> closer to the edge they get to the edge, the less
> feature capability they usually have, while all the more
> you need them.
Again, its the ISP's *choice* to use such equipment. At
some point someone that has been attacked will sue the
connecting ISP's from which the packets originated and I
wouldn't be suprised to see the ISP being fined or otherwise
penalised.
> Furthermore, it's pretty much impossible to explicitly
> filter based on sources from large peers with lots of
> routes and lots of churn, or ever large customers, for
> that matter. Dynamically generated feasible path RPF
> models are the best solution for this, but there's little
> (no?) support.
BCP 38 is about *everyone* filtering as close to the
source as possible.
You do your part and your peer does their part.
> And even those models are derived based on RIB data,
> which means route policy essentially dictates what you'll
> accept for both data plane and control plane. But wait,
> where's the authoritative source for who owns what
> prefixes, and who's permitted to originate/transit what
> prefixes?
>
> BTW: Even NIST "Guidelines on Firewalls and Firewall
> Policy "recommends blocking TCP/53, except for
> external secondaries.
Even NIST can get it wrong.
> -danny
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
