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: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf