Ingress filtering on transits, peers, and IX ports

Tue Oct 13 22:13:41 UTC 2020

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