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]

 



> 
> 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@xxxxxxx

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]