Any way to use BGP ASN as 'source' in an ACL?

[hostasaurus]

Hi all, my edge routers are running IOS-XR 7.7.21.  We have quite a bit of intentionally exposed customer public address space and have endless problems with garbage traffic from a select few ASN's who don't police their networks (14061 Digital Ocean, 16276 OVH, etc.), nor respond to abuse reports.  I'm curious if anyone knows of a way to use a BGP ASN as the source in an ACL, to allow us to drop those sources for specific target ports but otherwise not affect some traffic we're forced to let through?  I can't add an ASN to an object group (which I can use in an ACL), I don't think I can use an as-path-set in an ACL, and can't use an ASN in an ACL as far as I can tell, but I obviously don't want to hand-maintain a prefix list for each ASN, nor do I want to blackhole those ASN's whether manually or via blackhole router.  I need to just block certain destination ports.

Thanks!

[MHM Cisco World]

Can you more elaborate 

Thanks 

MHM

[hostasaurus]

Sure, I want to use BGP ASN 14061 as the source in an access list that blocks destination tcp port 21 and 22.  So, I drop port 21 and 22 in port group, and then this would take the format:

 510 deny tcp ??? any port-group PortGroupName

Now, typically one would create a net group of every ipv4 or ipv6 prefix they need, and in place of ??? you'd use "net-group NetGroupName".  I don't want to manually maintain a net group, prefix list, etc.  I want to use bgp asn 14061 (and others).  I can create an as-path-set with the ones I want, for example:

as-path-set AbusiveHosts
 originates-from '14061'
end-set

but as best I can tell, you can't use as-path-set in an ACL.  I can use it in a route policy to just drop their routes, but then I lose connectivity to these horrible ISP's, and we unfortunately have some customers who have a need to exchange email or https API interactions with customers of theirs.

So I'm at a loss on how to block just certain target tcp port traffic from certain BGP ASN's without dropping everything or having to maintain a prefix list manually.

[Joseph W. Doherty]

Possibly you can use a route-map to set ToS or QoS groups based on ASNs, and then use a policy map classes to filter out the traffic you want to drop.

[Joseph W. Doherty]

A follow up . . .

Just wondering whether you've considered what I suggested, or perhaps what I suggested had insufficient detail how it might work?  If the latter, let me know.

[David Ruess]

Hello,

Ive never tried it but logically it might work. You can create an AS path ACL with the offending ASNs and create a separate regular ACL with the protocols needing to be dropped and then apply both of those to a route map to deny traffic which i believe is a logical AND within the same route-map. I'll try to lab it up and see if I can get some good results.

Edit to my original response:

After labbing I was able to accomplish what I believe is your goal. I made 2 lists and a route map explained below.

An EXTENDED ACL to block source/destination and ports as your intention states. I just did an IP for testing.

Extended IP access list test
10 permit ip host 1.1.1.1 any <- needs to be a permit statement to go with our route-map

An AS-Path ACL to match on ASNs as you see fit.

AS path access list 1
permit ^100$ <- this states permit anything that originated from ASN 100. This is flexible and uses REGEX so you can say anything that originates from a specific ASN, or traffic that has passed through a specific ASN, etc.

R4#sh route-map
route-map TEST, deny, sequence 10 <-first statement is a deny to deny anything that matches the criteria below
Match clauses:
ip address (access-lists): test
as-path (as-path filter): 1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map TEST, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

In order this route-map called TEST does the following: 

DENY:the following based on being match

MATCH: Match Extended ACL AND the AS-PATH ACL <- based on my statements here is how the route-map will read:

DENY anything that matches the network in the extended ACL of test AND matches the AS-PATH ACL 1 which is anything sourced from ASN 100.

Lastly apply it inbound on the offending neighbor

neighbor 10.10.24.2 route-map TEST in

I had 2 networks coming from ASN 100. The 1.1.1.1 was blocked an the 1.1.1.11 was allowed through.

Hope this helps

-David

[Joseph W. Doherty]

A better approach than what I had in mind, I believe.

I wasn't sure about match ASN(s) and ports in the same route-map statement so I had in mind matching the ASN(s) in a route-map, which would "tag" matched packets, and then a subsequent service policy would match the "tag" and an ACL, and drop such matches.

What @David Ruess proposes is more streamlined.

[hostasaurus]

Thanks all.  Will try this out in a few days.  I've got a new environment coming online with XR edge routers and will have the perfect opportunity to test.

[MHM Cisco World]

Route-map use bgp as is match and filter control plane traffic 

Route-map use for data traffic only match something appear in IP packet like

IP header 

L4 port 

And route-map using for data traffic is work with PBR' and that I think what you looking for.

What is in my mind 

Match acl for traffic IP header + L4 port

Match interface <- this can use to specify for which next-hop is used for this traffic 

MHM