[dns-operations] Configurable TC=1?
rdobbins at arbor.net
Fri Dec 25 01:21:08 UTC 2015
On 24 Dec 2015, at 11:11, Paul Vixie wrote:
> we need to get everything possible done as soon as possible.
I agree with this. And influencing network infrastructure vendors to
default to source-address validation wherever practical should be a
> 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.
If you don't know what ought to be ingressing your network at your
customer aggregation edges, you don't know what ought to be egressing
your network at your peering/upstream transit edges.
If you do know what ought to be ingressing your network at your customer
aggregation edges, then you can do the requisite filtering on the
coreward interfaces of your peering-/transit-edge boxes, if you must.
It's ingress filtering from the perspective of those particular boxes,
egress filtering from the perspective of your network as a whole.
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?
Should we consider using the terms 'network emission control' or
'Internet emission control', which evokes both electronic warfare and
environmental pollution imagery? Would 'Internet pollution' and/or
'Internet toxicity' be useful concepts to push, to help non-specialists
> 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.
We all know that simply saying isn't working. Network infrastructure
vendors should be able to implement source-address validation as a
default in their broadband wireline access devices without breaking the
world, should they not?
> 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.
> 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
Yes, everybody here knows that.
> 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?
I'm an advocate of these approaches, as you know. However, network
infrastructure vendors should also be part of the solution-set, when and
where they can be, from a topological perspective. In point of fact,
they've the potential to be more effective than all the above, IMHO.
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 somesuch.
Yes, I read it when you posted it, and agree wholeheartedly.
However, getting action in the legal/liability/regulatory (this last has
the potential to be iatrogenic, it must be a last resort) spheres
Getting Spoofer Project-like functionality embedded in the major OSes
and the resultant data would be a way to construct a broad enough data
horizon to support both technical and non-technical approaches, IMHO.
Convening a Source-Address Validation Summit or Internet Pollution
Summit or somesuch with the right participants would be a way to
kickstart this effort.
Roland Dobbins <rdobbins at arbor.net>
More information about the dns-operations