Brandon Zhi wrote on 07/01/2023 15:33:
I've been doing some research on BGP security recently and I've discovered a hijacking method called BGP next-hop hijacking. But I don't know how this will cause harm, as modifying the next-hop only redirects traffic.
The default for ebgp (in general) is for the router receiving the UPDATE to set the next-hop to be the interface IP address of the router sending the UPDATE. The main practical exception for ebgp is that the sending router can set the NH to another IP address in the same subnet of the connecting interface. Unwinding this, if you have a transit connection, the customer won't be able to set the next-hop to someone else, unless the transit provider is servicing different ASNs on the same subnet, or unless the provider has explicitly overridden this using a configuration knob. I.e. not generally an issue there. The main place where you can expect to see NH rewriting is at IXPs, which is described in rfc7948, section 4.8. There are several situations where there are legitimate reasons to rewrite NHs at IXPs, but occasionally it happens that rewriting NHs is done for malicious purposes, for example hijacking third party bandwidth. For this reason, rfc7948 recommends that IXP route server operators protect against this specific issue. You can find example code here:
https://github.com/inex/IXP-Manager/blob/master/resources/views/api/v4/route...
Also, IXP participants should rewrite next-hop to be the IP address of the peer-as router on all IXP bgp sessions. If you use multihop ebgp for data-plane traffic delivery, you probably get what you deserve.
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948. Nick