Re: Ingress filtering on transits, peers, and IX ports

["Dobbins, Roland" <Roland.Dobbins () netscout com>]

> On 15 Oct 2020, at 05:43, Brian Knight via NANOG <nanog () nanog org> wrote:
>
> I think that's good for an enterprise network, but as an SP, I'm very hesitant to include this.  Is this included in 
> anyone else's transit / peer / IX ACL?

This must not be done on peering links and on transit networks generally, as it breaks EDNS0, & everything that depends 
upon it, as well as some games, VoIP applications, etc.

For consumer eyeball access networks only, making use of flow telemetry to analyze non-initial fragments destined for 
*those networks only, and excepting both one’s own recursive DNS server farms and well-known/well-operated public DNS 
recursive farms*, one can determine the normal rate of non-initial fragments in that very specific context and utilize 
QoS to police it down, leaving plenty of headroom for upticks in legitimate traffic.

And with regards to disallowing one’s own address space except in special topological circumstances, it’s great to see 
that this initial topic has sparked renewed interest in both ingress and egress filtering.  It’s highly laudable, and 
some good example are being posted and useful discussion taking place.

It should be noted, however, that filtering one’s own prefixes at one’s peering edge in the more general cases isn’t a 
new concept; this has been a BCP recommendation for more than 20 years.  For example, it’s referenced on p.75 of this 
.pdf slide deck on the topic of infrastructure self-protection, which was last revised 11 years ago:

<https://app.box.com/s/osk4po8ietn1zrjjmn8b>

From the way this ’new’ set of findings has been promulgated, it sounds as if the authors of the paper didn’t 
necessarily understand that this is a longstanding recommendation.  That doesn’t in any way detract from the value of 
their study, mind; and perhaps they were aware, and that information simply hasn’t been communicated in this context.

Also, a more proximate risk than DNS cache-poisoning or the specific, impractical, never-seen-in-the-wild DNS DDoS 
attack methodology cited, is for operators who aren’t filtering their own prefixes on ingres, and  who’re also relying 
solely on iACLs to prevent off-net access to their recursive DNS server farms, thus allowing their abuse in DNS 
reflection/amplification attacks against their own infrastructure and access customers from outside their network.

Filtering one’s own prefixes on ingress whenever possible and to the degree of granularity possible, along with making 
use not only of iACLs but on-server configurations to disallow off-network abuse of recursive DNS servers, are highly 
recommended.

--------------------------------------------
Roland Dobbins <roland.dobbins () netscout com>