security risk for 0.0.0.0/0 eq 32

[Eric Guo]

Hi All, 

we are a small service provider, and  trying to provide backhole service for our customers for DDOS attack.  We are using cisco ASR9K platform, and are going to leverage eBGP session with the customer for attack mitigation. 

Current, we are planing to setup automatic recognize the customer /32 host IP address into our network, then we could redirect this IP address into 192.0.2.1.

the prefix-list for ebgp session with the customer is shown below. This intention for 0.0.0.0/0 eq 32 is for accepting any /32 host ip address, if the customer identified this host been under attack. But I don't confident for this approach, as this setting will allow any /32 IP block into our routing table, and mess up our service provider routing engine, it is kinds of routing attack. if the customer make routing prefix advertisement by mistake. So, could someone please help me to prove my concern? or do someone has other security concerns on this approach ? please share with your comment.

prefix-set pfx-example-IN

  2XX.2XX.9X.0/24,

  2XX.2XY.124.0/24,

  0.0.0.0/0 eq 32

thanks in advance!    

Eric 

[xthuijs]

hi eric,

correct the prefix of 0.0.0.0/0 eq32 will match any host route possible that you receive on this neighbor.

you can possibly enhance this one that if you know that your peer only support to advertise say 192.168.1.0/24 addresses and you want to capture the /32's in that range you can do:

192.168.1.0/24 eq 32

or if they have both 192.168.0.0 and 192.168.1.0 you can do:

192.168.0.0/23 eq 32

etc

xander

[Eric Guo]

thanks Aaron and Xander for your input !

could you please or somebody else share more comment on what's risk level we will take if we use this method in our environment that we have 100+ the customer at downstream, public AS 80+ and 300+ public IPv4 block > /24 in total ?

because I  try to highlight this method risk for our team, compared with RTBH or BGP flowspec ?

thanks, 

Eric 

[xthuijs]

hi eric, so there is no true risk factor other then that a "catch-all" will catch ALL.

meaning that if there are stipulations you may erroneously capture prefixes that you may not want to treat that certain way.

the "risk" factor here is merely that if you apply a "blanket policy" are we not capturing to little or too much. depending on your company policies one approach may work better then the other (trust all or trust whomever I decide). Either approach will require some adjustment at some point to be honest is what I see.

I would tend to be on the way of prove your worthiness and I'll open up, but hey that is the same as the dating game you know :)

cheers

xander

[AARON WEINTRAUB]

You could do it like so:

route-policy in-from-customer

if destination in customer-in then

set community your-customer-communities

pass

endif

if destination in 0.0.0.0/0 le 32 and community matches-any your-customer-communities then

set community your-blackhole-community

set next-hop your-blackhole-nexthop

endif

You may want to use 'additive' in the second community set, depending on how your routing policy is set up.

[AARON WEINTRAUB]

I've been alerted that it may not be possible to do this as such, as any 'if' statements only look at the original route, not any modifications that may have happened.