Ingress filtering on transits, peers, and IX ports

Wed Oct 14 01:40:31 UTC 2020

Specifically with regards to “Don’t accept your own prefix”, this poses an interesting challenge for the original notice sent out by the security researchers.

It is not uncommon today for various content networks (and others) to operate multiple “island networks” with a single ASN. For example, AS65001 operates in Los Angeles and New York, with no internal connectivity between them - only connectivity via the Internet (loop prevention disablement is done by every tier 1 provider upon request). Los Angeles advertises 192.168.10.0/24 and New York advertises 192.168.20.0/24 to the Internet, and both have relevant anti-spoofing filters (e.g. Los Angeles has an ingress filter to drop traffic with source IP of 192.168.10.0/24, and New York has an ingress filter to drop traffic with a source IP of 192.168.20.0/24). Traffic between Los Angeles and New York is not filtered as they need to legitimately pass traffic to each other over the Internet. This triggers a false positive detection by the system in question that sent the original notification email.

After discussing this with the people running this project and highlighting that this will be generating false positive data as part of their research (and probably quite a lot, this practice is fairly common), the response was to establish some form of tunnel between the AS islands over the Internet. Not realistic for a bunch of the content companies who practice this design pushing tens/hundreds of Gbps over the Internet (if not more). There seemed to be no interest in the discussion that the data being generated by this system is arguably flawed.

Tl;dr - definitely don’t accept your own prefix from the site it originated from, or other sites that have internal connectivity. But also don’t assume that an AS has a full-mesh of internal connectivity behind it and shouldn’t accept its own prefixes for any reason. 

Sent from my iPhone

> On Oct 13, 2020, at 7:54 PM, Marcos Manoni <marcosmanoni at gmail.com> wrote:
> 
> Hi, Brian
> 
> Check RFC3704/BCP84 Ingress Filtering for Multihomed Networks (Updated
> by: RFC8704 Enhanced Feasible-Path uRPF).
> 
>    Ingress Access Lists require typically manual maintenance, but are
>    the most bulletproof when done properly; typically, ingress access
>    lists are best fit between the edge and the ISP when the
>    configuration is not too dynamic if strict RPF is not an option,
>    between ISPs if the number of used prefixes is low, or as an
>    additional layer of protection
> 
> 
> Ingress filters Best Practices
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/BGP-Slides-Single.pdf
> *Don’t accept BOGON ASNs
> *Don’t accept BOGON prefixes
> *Don’t accept your own prefix
> *Don’t accept default (unless you requested it)
> *Don’t accept prefixes that are too specific
> *Don’t accept if AS Path is too long
> *Create filters based on Internet Routing Registries
> 
> And also BGP Best Current Practices by Philip Smith
> http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf
> 
> Regards.
> 
>> El mar., 13 oct. 2020 a las 19:52, Brian Knight via NANOG
>> (<nanog at nanog.org>) escribió:
>> 
>> Hi Mel,
>> 
>> My understanding of uRPF is:
>> 
>> * Strict mode will permit a packet only if there is a route for the source IP in the RIB, and that route points to the interface where the packet was received
>> 
>> * Loose mode will permit a packet if there is a route for the source IP in the RIB.  It does not matter where the route is pointed.
>> 
>> Strict mode won't work for us, because with our multi-homed transits and IX peers, we will almost certainly drop a legitimate packet because the best route is through another transit.
>> 
>> Loose mode won't work for us, because all of our own prefixes are in our RIB, and thus the uRPF check on a transit would never block anything.
>> 
>> Or am I missing something?
>> 
>> Thanks,
>> 
>> -Brian
>> 
>> On 2020-10-13 17:22, Mel Beckman wrote:
>> 
>> You can also use Unicast Reverse Path Forwarding. RPF is more efficient than ACLs, and has the added advantage of not requiring maintenance. In a nutshell, if your router has a route to a prefix in its local RIB, then incoming packets from a border interface having a matching source IP will be dropped.
>> 
>> RPF has knobs and dials to make it work for various ISP environments. Implement it carefully (as is be standing next to the router involved :)
>> 
>> Here's a Cisco brief on the topic:
>> 
>> 
>> https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding
>> 
>> 
>> 
>> 
>> 
>> I think all router vendors support this feature. Here's a similar article by Juniper:
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-unicast-rpf.html
>> 
>> 
>> -mel beckman
>> 
>> On Oct 13, 2020, at 3:15 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
>> 
>> 