Saku, 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! Ryan Hamel ________________________________________ From: Saku Ytti <s...@ytti.fi> Sent: Wednesday, April 18, 2018 3:48 AM To: Ryan Hamel Cc: nanog@nanog.org Subject: Re: Attacks on BGP Routing Ranges Hey Ryan, 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.ha...@quadranet.com> wrote: > Hello, > > 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 -- ++ytti