Hi Marcos,
Thanks for your reply. But I am looking for guidance on traffic
filtering, not BGP prefix filtering.
I have looked at BCP 84, and it's a good overview of the methods
available to an ISP. My questions are more operational in nature and
are not covered by the document. Of the choices presented in BCP 84,
what do folks really use? If it's an ACL, what challenges have there
been with updates? etc.
-Brian
On 2020-10-13 18:52, Marcos Manoni 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@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@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