<div dir="ltr"><div>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. <br></div><div><br></div><div>I assume you're talking about customer facing recursive/caching resolvers, and not authoritative-only nameservers. </div><div><br></div><div>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. <br></div><div><br></div><div>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?  <br></div><div><br></div><div>What volume of pps or Mbps would appear as spurious traffic as a result of this attack?</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 3:14 PM Brian Knight via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We recently received an email notice from a group of security <br>
researchers who are looking at the feasibility of attacks using spoofed <br>
traffic.  Their methodology, in broad strokes, was to send traffic to <br>
our DNS servers with a source IP that looked like it came from our <br>
network.  Their attacks were successful, and they included a summary of <br>
what they found.  So this message has started an internal conversation <br>
on what traffic we should be filtering and how.<br>
<br>
This security test was not about BCP 38 for ingress traffic from our <br>
customers, nor was it about BGP ingress filtering.  This tested our <br>
ingress filtering from the rest of the Internet.<br>
<br>
It seems to me like we should be filtering traffic with spoofed IPs on <br>
our transit, IX, and peering links.  I have done this filtering in the <br>
enterprise world extensively, and it's very helpful to keep out bad <br>
traffic.  BCP 84 also discusses ingress filtering for SP's briefly and <br>
seems to advocate for it.<br>
<br>
We have about 15 IP blocks allocated to us.  With a network as small as <br>
ours, I chose to go with a static ACL approach to start the <br>
conversation.  I crafted a static ACL, blocking all ingress traffic <br>
sourced from any of our assigned IP ranges.  I made sure to include:<br>
<br>
* Permit entries for P-t-P WAN subnets on peering links<br>
* Permit entries for IP assignments to customers running multi-homed BGP<br>
* The "permit ipv4 any any" at the end :)<br>
<br>
The questions I wanted to ask the SP community are:<br>
<br>
* What traffic filtering do you do on your transits, on IX ports, and <br>
your direct peering links?<br>
* How is it accomplished?  Through static ACL or some flavor of uRPF?<br>
* If you use static ACLs, what is the administrative overhead like?  <br>
What makes it easy or difficult to update?<br>
* How did you test your filters when they were implemented?<br>
<br>
Thanks a lot,<br>
<br>
-Brian<br>
</blockquote></div>