[dns-operations] Configurable TC=1?

[Paul Vixie]

On Friday, December 25, 2015 08:21:08 AM Roland Dobbins wrote:
> On 24 Dec 2015, at 11:11, Paul Vixie wrote:
> > we need to get everything possible done as soon as possible.
> ...
> Is some part of the problem terminology?  Since you've done a good job
> of popularizing the more palatable term 'source-address validation', is
> it time to rev the relevant BCPs/RFCs, also to include the proviso that
> network egress filtering has the same practical effect as network
> ingress filtering from the standpoint of what your network emits?

it's not, though. (egress the same practically as ingress filtering.) i was asked about this 
privately about a week ago, and i advised strongly against egress filtering except when 
ingress filtering was infeasible. my reason is that if customer A can spoof its source address 
toward customer B, then if customer B is running an externally reachable server (DNS 
authority, or any TCP) then customer B can be used as a reflecting amplifier for customer A's 
attacks on noncustomers.

granted, this is easier to detect and correct than the non-SAV case where neither ingress nor 
egress filtering is present. i just want the people who choose egress filtering to know that this 
danger will exist for them, and that they ought to choose ingress filtering if it's feasible.

> > 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.
> 
> I concur, in the context of providing downstream transit to an endpoint network.  However, 
customer-of-my-customer (of my customer, of my customer . . .) wholesaling scenarios are a 
bit more complex.

i am not trying to outlaw complexity; i'm trying to deal with bad defaults. if some customer 
needs non-default treatment, then by all means supply it!

> I'd also like the major OS vendors to incorporate Spoofer Project-like
> functionality into their OSes, with the data and analysis of said data
> made publicly available via a common portal.  I believe it wouldn't be
> too difficult to make the case to them that doing so is in their
> interests, and the interests of their customers.  SAVA - Source Address
> Validation Association, or some such.

ISOC has taken on routing system resilience (http://www.routingmanifesto.org). the MANRS 
(mutually agreed norms for the routing system) effort includes SAV. i'd say that if you wrote 
an RFC describing a ping-like service whereby an end system could be made to participate in 
something like CAIDA Spoofer (was MIT), then ISOC would almost certainly help you socialize 
it to equipment vendors.

-- 
P Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151224/e130f0da/attachment.html>