05-12-2016 01:23 PM
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
05-13-2016 05:06 AM
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
05-16-2016 08:06 AM
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
05-16-2016 08:23 AM
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
05-13-2016 12:52 PM
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.
05-13-2016 12:59 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide