[dns-operations] Configurable TC=1?

[Roland Dobbins]

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.

The power of the default continues to hold sway.  My contention is that 
source-address validation can potentially become a default setting in 
two topological scenarios without breaking the world:

1.  Wireline broadband access layer.

2.	IDC access layer (with VMotion-like scenarios being the most 
significant caveat).

> actually, it's a gigantic problem.

I don't have any statistics, but my (totally subjective) gut feeling is 
that CPE NATs passing along out-of-scope packets unmodified isn't that 
common.  Is it your gut feeling that it is in fact a fairly commonplace 
problem, and/or do you know if anyone has any data on the popularity of 
CPE NATs which exhibit this particular flavor of brokenness?   
Correction is very welcome, if indeed this is an issue with a relatively 
high degree of prevalence.

Of course, source-address validation by default in the wireline 
broadband access layer would mask this issue, irrespective of its 
prevalence.  But we need a better feel for the scope of the CPE NAT 
scope problem, just the same, because we must press this issue on 
multiple fronts.

What I would really like to see is a conclave involving the major 
operating system vendors - Microsoft, Apple, Google, the appropriate 
Linux distros, FreeBSD - with the aim of convincing them that it's in 
their interest to incorporate Spoofer Project-type functionality 
(<http://spoofer.caida.org/>) into the operating systems they produce, 
with the resultant data published and analyzed on a pubicly-accessible 
portal, said data also made available for all and sundry to analyze for 
themselves, should they wish to do so.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>