I took a slightly different approach for my mental exercise, expressed in IOS pigeon: object-group ip address AS65001 192.0.2.0 255.255.255.0 end object-group v6-network AS65001 2001:DB8::/32 end object-group ip address TwentyFiveGigE1/0/1 192.0.2.0 255.255.255.254 end object-group v6-network TwentyFiveGigE1/0/1 FE80::/10 2001:DB8::/127 end ip access-list extended TwentyFiveGigE1/0/1_IPV4_IN permit ip addrgroup TwentyFiveGigE1/0/1 any deny ip addrgroup AS65001 any permit ip any any end ipv6 access-list TwentyFiveGigE1/0/1_IPV6_IN permit ipv6 object-group TwentyFiveGigE1/0/1 any deny ipv6 object-group AS65001 any permit ipv6 any any end interface TwentyFiveGigE1/0/1 ip access-group TwentyFiveGigE1/0/1_IPV4_IN in ipv6 traffic-filter TwentyFiveGigE1/0/1_IPV6_IN in end I believe this is the minimum necessary to protect your AS from your netblock(s) ingress. Note: there may be technical and business reasons why you need to permit your netblock(s) ingress to your AS. I believe this concept could be used on any EBGP Inter-AS link, including peering addressed out of your own netblock. I remain unconvinced, but shrewd is the one who sees the calamity... Tim:> On Mon, Oct 19, 2020 at 8:40 PM Brian Knight via NANOG <nanog@nanog.org> wrote:
Thanks to the folks who responded to my messages on and off-list. A couple of folks have asked me to summarize the responses that I received.
* Static ACL is currently the best way to protect a multi-homed network. Loose RPF may be used if bogon filtering is more important, but it does not provide anti-spoofing security.
* Protect your infrastructure subnets with the ingress ACL [BCP 84 sec 3.2]. Loopbacks and point-to-point circuits can benefit from this. In the draft ACL, for example, I permit ICMP and traceroute over UDP, and block all else.
* Do an egress ACL also, to prevent clutter from reaching the rest of the 'Net. Permit only your aggregate and customer prefixes going outbound.
* As I worked through putting the ACLs together, I found that if one implements an egress ACL, then customer prefixes must be enumerated anyway. Once those are in an object group, it's easy to add an entry to the ingress ACL permitting traffic destined to customer PI space and aggregate space. Seems better than just permitting all traffic in.
Our ACLs, both v4 and v6, now look like the following:
Ingress
* Deny to and from bogon networks, where bogon is either source or dest * Permit to and from WAN PtP subnets * For IPv6, also permit link-local IPs (fe80::/10) * Deny to and from multicast ranges 224.0.0.0/4 and ff00::/8 * Permit ICMP / traceroute over UDP to infrastructure * Deny all other traffic to infrastructure * Permit from customer PI / PA space * Deny from originated aggregate space * Permit all traffic to customer PI / PA space * Permit all traffic to aggregate space * Deny any any
Egress
* Deny to and from bogon networks * Permit to and from WAN PtP subnets * For IPv6, also permit link-local IPs * Deny to and from multicast range * Permit all traffic from customer PI / PA space * Permit all traffic from aggregate space * Deny any any
We have started implementing the ACLs by blocking the bogon traffic only. The other deny rules are set up as permit rules for now with logging turned on. I'll review matching traffic before I switch the rules to deny.
Future work also includes automating the updates to the object groups via IRR.
BTW, Team Cymru didn't have any guidance around IPv6 bogons, so I put together the below object group based on the IANA IPv6 allocation list:
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unica....
Obviously this is only for space not yet allocated to RIRs.
object-group network ipv6 IPV6-BOGON description Invalid IPV6 networks ::/3 4000::/3 6000::/3 8000::/3 a000::/3 c000::/3 e000::/4 f000::/5 f800::/6 fc00::/7 fe00::/9 fec0::/10 exit
Thanks,
-Brian
On 2020-10-14 17:43, Brian Knight wrote:
So I have put together what I think is a reasonable and complete ACL. From my time in the enterprise world, I know that a good ingress ACL filters out traffic sourcing from:
* Bogon blocks, like 0.0.0.0/8, 127.0.0.0/8, RFC1918 space, etc (well-documented in
https://team-cymru.com/community-services/bogon-reference/bogon-reference-ht... )
* RIR-assigned blocks I am announcing to the rest of the world
However, I recognized a SP-specific case where we could receive legitimate traffic sourcing from our own IP blocks: customers running multi-homed BGP where we have assigned PA space to them. So I added "permit" statements for traffic sourcing from these blocks.
Also, we have direct peering links that are numbered within our assigned prefixes. So we can use the same ACL with these peer interfaces and continue to have BGP work, I added "permit" statements for these point-to-point subnets.
So the order of the statements is:
* Permit where source is direct peer PtP networks * Permit where source is BGP customer PA prefix * Deny where source is bogon * Deny where source is our advertised prefixes * Permit all other traffic
I considered BGP customer PI prefixes to be out of scope for ingress filtering, since the customer is likely to be multi-homing. Should we consider filtering them?
The Team Cymru Secure IOS Template [https://www.cymru.com/Documents/secure-ios-template.html] also references an ICMP fragment drop entry on the ingress ACL. I think that's good for an enterprise network, but as an SP, I'm very hesitant to include this. Is this included in anyone else's transit / peer / IX ACL?
Is there anything else that I'm not thinking of?
Thanks,
-Brian
On 2020-10-14 09:25, Brian Knight via NANOG wrote:
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-t...
*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_forwa...
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/...
-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
-- Tim:>