[dns-operations] Configurable TC=1?
paul at redbarn.org
Fri Dec 25 02:05:24 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations