[dns-operations] Configurable TC=1?

[Roland Dobbins]

On 25 Dec 2015, at 9:05, Paul Vixie wrote:

> it's not, though. (egress the same practically as ingress filtering.)

I meant, in terms of source-address validation, apologies for not making 
that clear.

The bank-shot scenario aside, ingress filtering is far preferable to 
egress filtering because it keeps the spoofed traffic off one's core, as 
well as customer A-vs.-customer B scenarios (this is more common than 
many realize, especially in IDC environments).

> 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!

The big problem for wholesalers isn't their direct downstream customer.  
It's their customers, and their customers, et. al.

While I agree this should be the standard configuration, with exceptions 
made as necessary, the lack of direct relationships with the downstream 
parties affected is a significant issue which mustn't be minimized.

This is one of the reasons why I think network infrastructure default 
source-address validation for Ethernet access ports and broadband 
wireline access gear should be a priority.

> 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.

While having this functionality as a standard would be ideal, it takes a 
huge amount of time and effort to get anything through the standards 
process.  It's better to get something working and somewhat prevalent, 
first, then work the standards process, IMHO.

OS vendors/developers and online game vendors/developers/operators (the 
latter are especially aware of the negative impact of 
reflection/amplification attacks) are a natural constituency for this 
type of effort.  I believe that this is the best direction to take 
tactically, and will socialize same.

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