Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt




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.

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.

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.

-danny




_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.