Ingress filtering on transits, peers, and IX ports

Tue Oct 20 18:22:07 UTC 2020

> On 15 Oct 2020, at 05:43, Brian Knight via NANOG <nanog at 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 at netscout.com>