Ingress filtering on transits, peers, and IX ports

Wed Oct 14 14:56:51 UTC 2020

Hi Eric, 

I shot a message over the folk who did the testing for more info about
their test.  If I'm able to find anything useful in our logs from their
detail, I'll post it to the list. 

The message referenced DNS cache poisoning and DDOS amplification, so it
seemed fairly general and more focused on whether ASes accepted spoofed
traffic.  They also referenced the new NXNSAttack, which I did not know
about previously. 

Thanks, 

-Brian 

On 2020-10-13 20:49, Eric Kuhnke wrote:

> Aside from the BCPs currently being discussed for ingress filtering, I would be very interested in seeing what this traffic looked like from the perspective of your DNS servers' logs. 
> 
> I assume you're talking about customer facing recursive/caching resolvers, and not authoritative-only nameservers.  
> 
> Considering that one can run an instance of an anycasted recursive nameserver, under heavy load for a very large number of clients, on a $600 1U server these days... I wonder what exactly the threat model is. 
> 
> Reverse amplification of DNS traffic returning to the spoofed IPs for DoS purposes, such as to cause the nameserver to DoS a single /32 endpoint IP being targeted, as in common online gaming disputes?  
> 
> What volume of pps or Mbps would appear as spurious traffic as a result of this attack? 
> 
> On Tue, Oct 13, 2020 at 3:14 PM Brian Knight via NANOG <nanog at nanog.org> wrote: 
> 
>> We recently received an email notice from a group of security 
>> researchers who are looking at the feasibility of attacks using spoofed 
>> traffic.  Their methodology, in broad strokes, was to send traffic to 
>> our DNS servers with a source IP that looked like it came from our 
>> network.  Their attacks were successful, and they included a summary of 
>> what they found.  So this message has started an internal conversation 
>> on what traffic we should be filtering and how.
>> 
>> This security test was not about BCP 38 for ingress traffic from our 
>> customers, nor was it about BGP ingress filtering.  This tested our 
>> ingress filtering from the rest of the Internet.
>> 
>> It seems to me like we should be filtering traffic with spoofed IPs on 
>> our transit, IX, and peering links.  I have done this filtering in the 
>> enterprise world extensively, and it's very helpful to keep out bad 
>> traffic.  BCP 84 also discusses ingress filtering for SP's briefly and 
>> seems to advocate for it.
>> 
>> We have about 15 IP blocks allocated to us.  With a network as small as 
>> ours, I chose to go with a static ACL approach to start the 
>> conversation.  I crafted a static ACL, blocking all ingress traffic 
>> sourced from any of our assigned IP ranges.  I made sure to include:
>> 
>> * Permit entries for P-t-P WAN subnets on peering links
>> * Permit entries for IP assignments to customers running multi-homed BGP
>> * The "permit ipv4 any any" at the end :)
>> 
>> The questions I wanted to ask the SP community are:
>> 
>> * What traffic filtering do you do on your transits, on IX ports, and 
>> your direct peering links?
>> * How is it accomplished?  Through static ACL or some flavor of uRPF?
>> * If you use static ACLs, what is the administrative overhead like?  
>> What makes it easy or difficult to update?
>> * How did you test your filters when they were implemented?
>> 
>> Thanks a lot,
>> 
>> -Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201014/6fca79a4/attachment.html>