[FCIX] DDoS mitigation for peers

[Kenneth Finnegan]

The simple answer is that FCIX route servers support no Remote
Triggered Black Hole features.

The route servers are only interested in matching on prefixes allowed
by IRR/RPKI and passing them between peers, with modifications made
based on the 33495:nnn communities tagged on the way in. The fact that
route servers don't support RTBH is a great example of how using route
servers is far from ideal and gives up a significant amount of control
from the source network about the announcement of the prefix. This is
why you'll see many networks (i.e. Hurricane Electric) only announce a
fraction of their their prefixes to the route servers, but be willing
to announce more prefixes if you set up a direct peering session.

Route servers are the easy on-ramp for new networks, and really
shouldn't ever be relied upon to move your magic rainbow colored
packets. This position is backed up by the fact that the route servers
have been rather broken for... months now, and I haven't gotten around
to fixing them while I deal with the overwhelming joys of owning a new
home.

So if there's any network which you really want to pass traffic to
over FCIX, I will always encourage you to set up direct peering
sessions. I even wrote a whitepaper on it!
https://fcix.net/whitepaper/2021/04/02/anatomy-of-a-peering-request.html

As for managing RTBH in this sort of context, a reasonable policy
would be to try and set up direct peering sessions with as many peers
who support RTBH communities over the IXP as possible, and then plan
on simply withdrawing the entire umbrella announcement from route
servers and un-RTBH-able direct peering sessions in lieu of keeping it
up minus the single address if the DDoS issue is really that severe.

But with the exception of Hurricane, IXPs do tend to not see a
staggering amount of DDoS traffic due to the typically smaller ingress
cone of networks attached to them.
--
Kenneth Finnegan
Technical Director, FCIX

On Mon, Jan 23, 2023 at 4:15 PM Mike via Members <members at fcix.net> wrote:
>
> Hi,
>
>      We are an ISP and have a certain amount of DDoS mitigation on our
> ip transit (RTBH advertised to iptransit, and BGP flowspec internal to
> us). This works to squelch ddos flows in most cases, even at the expense
> of that one end user that is the unfortunate target. However, this
> arrangement really only works because our ip transit honors a community
> that triggers RTBH so our transit links don't get smashed. In the case
> of a peer, such as you fine folks on fcix, however, we have no such
> luxury. The route-servers are just playing matchmaker so we know the l2
> nexthop for any route, but there is no direct BGP and thus no way to
> advertise an RTBH even assuming we knew which peer was sending to us in
> a hypothetical flood. In theory then, while ip transit can be mitigated,
> a peer sending a flood cannot (except by locally dropping the bad flows,
> which allows the peering port to be flooded).
>
>      Surely, this situation has been thought about and someone has a
> well engineered solution to this problem? I think we likely could
> establish BGP peering across fcix and only allow peers that support
> RTBH, but that would exclude some who likely we may want peering with
> anyways because they have cool rainbow striped packets we also want in
> our network anyways, even if they might not support RTBH (I'm looking at
> you, AS399306!). I think the likelihood of a ddos being delivered over
> the peering connections is far less than the likelihood of being
> received over iptransit, still, it seems like this would be an issue to
> consider. And if we were to go thru the trouble of establishing BGP with
> everyone who says they can support RTBH, it seems like a huge
> administrative burden. Is there any other best practice solution or are
> we just on our own?
>
>
> Mike Ireton
>
> Your Town Online, Inc
>
> AS11472
>
>
>
>
>
>
> --
> Members mailing list
> Members at fcix.net
> https://mail.fcix.net/mailman/listinfo/members