Ingress filtering on transits, peers, and IX ports

Blake Hudson blake at ispn.net
Thu Oct 15 15:22:47 UTC 2020


Speaking as an ISP:
     Most of the ISP networks I manage are multi-homed, and I don't 
think uRPF provides the knobs to ensure legitimate traffic doesn't get 
dropped in some cases, so we use static ACLs at the upstream edge on 
ingress (and egress). These need updated any time new IP space is added 
to the network (not very often).
         Ingress ACL: Discard if source or destination is a bogon, RFC 
1912, RFC1918; discard any traffic sourced from our own IP space 
(spoofed); discard any traffic that is not destined for our IP space 
(bad/mis-routed).
         Egress ACL: Discard if source or destination is a bogon, RFC 
1912, RFC1918; discard any traffic that is not sourced from our IP space 
(spoofed).
         I believe in a policy of non-blocking and being net neutral, 
but if any TCP/UDP ports, IP protocols, or IP options are blocked you 
might add them to the above ACLs.

     On customer facing ports we use uRPF strict. Why? It's easy (one 
line to implement, zero maintenance, and it works well on our Cisco 
ASR1k/9k platforms)! Our customers are all single homed.

For a single homed enterprises, service providers, and end-users I'd 
recommend uRPF strict. Why? Again, it's dead simple. I would love to see 
this be the default on all home, prosumer, and branch office oriented 
platform. Linux does this by default with the rp_filter kernel option. I 
suspect that networking gear based on Linux probably leaves this at the 
default setting (strict mode).

In practice I don't know that I've ever used uRPF loose mode. ACLs have 
counters to verify they are working. I might have confirmed uRPF was 
working as intended the first time I implemented it, but otherwise I've 
used ACLs often enough to trust they are working as configured and trust 
the same for uRPF.

--Blake


On 10/13/2020 5:13 PM, Brian Knight via NANOG 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



More information about the NANOG mailing list