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-unicast-address-assignments.xhtml. > > 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-http/ > ) > > * 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-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 > >>>> > >>>> > -- Tim:>
