[dns-operations] Configurable TC=1?

Paul Vixie vixie at tisf.net
Thu Dec 24 04:10:45 UTC 2015


On Thursday, December 24, 2015 10:48:28 AM Roland Dobbins wrote:
> On 24 Dec 2015, at 10:28, Paul Vixie wrote:
> > we should tell IDC's they can do whatever they need to do in-house,
> > but when it's time for a packet to leave the house, it
> > should have an IDC-assigned source IP address, or some other address
> > from a very small list
> > of exceptions.
> 
> But telling people isn't working.

you've dropped the context of what i said.

we need to get everything possible done as soon as possible.

some of the IDC's are saying they can't do BCP 38 at all because it's ingress filtering and that 
would many working customer configs. for them, we need to say, use egress filtering.

some of the IDC's are saying they won't bother to do BCP 38 because of the cable and DSL 
edge being such a large attack surface. for them, we need to say, thank you for your fine 
whine, we've got a fix for that in DOCSIS 3.X, and it's time for you to shoulder your share of 
this global problem.

the one thing we must not do is let anybody get away with their inaction. i am particularly 
incensed by the transit providers who won't do SAV against their wireline customers "because 
they might be multihomed". i tell them, make SAV your default, and open up the filters when 
and if a specific customer needs it.

the larger problem is what randy bush said upthread-- we're asking the people causing the 
problem to take action which will add to their operational costs, but the only beneficiaries will 
be their competitors. for them, i'm pursuing insurance, securities, and liability 
regulatory/legislative solutions. they won't act until their competitors are also forced to act. 
it's like stopping spam, in that sense. so i'm working to force their competitors to act. QED?

see also:

http://www.darkreading.com/perimeter/ddos-and-the-internets-liability-problem/a/d-id/1323197

-- 
P. Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151223/09c0db4b/attachment-0001.html>


More information about the dns-operations mailing list