Attacks on BGP Routing Ranges
Ryan.Hamel at quadranet.com
Wed Apr 18 11:03:57 UTC 2018
The attacks are definitely inbound on the border router interface. I have tracked outbound attacks before and wish it was this simple, but its not.
> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses
While I can implement an edge filter to drop such traffic, it's impacting our clients traffic as well.
> b) do not advertise link networks in iBGP
This has never been an issue.
> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255
Could you explain how this can resolve my issue? I am not sure how this would work.
Thanks for your input!
From: Saku Ytti <saku at ytti.fi>
Sent: Wednesday, April 18, 2018 3:48 AM
To: Ryan Hamel
Cc: nanog at nanog.org
Subject: Re: Attacks on BGP Routing Ranges
I'm assuming edge link in your network facing another administrative domain.
You'll have two scenarios
1) attack coming from your side
2) attack coming from far side
You can easily stop 1, obviously.
But for 2, you really need to have far-side who is cooperative and
understanding of best practices and there isn't any magic you alone
can do with entirely uncooperative far-end.
Things to consider at both ends:
a) edge filter, on all edge interfaces ensure that only udp
traceroute, icmp are sent (policed) to infrastructure addresses
b) do not advertise link networks in iBGP
c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255
On 18 April 2018 at 13:37, Ryan Hamel <Ryan.Hamel at quadranet.com> wrote:
> I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's).
> I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences.
> Thanks in advance for everyone's suggestions.
> Ryan Hamel
More information about the NANOG