Hello Nick Antonio and Gert,
you can find an in-depth analysis on the topic here:
http://clathomasprime.github.io/papers/NextHopBGP.pdf
Thanks for the paper, I will continue reading it.
I would consider this to be as bad as any sort of "in-flight manipulation
of BGP reachability information" - either changing prefixes, or changing
next-hop would permit an attacker to redirect "user traffic", and then
interfere with *that*.
When network A is under DDoS attack, and network A switches all of its prefixes to network B in an IXP, I assume this is going on. This may be harmful to network B?
Not sure how hard it is today to inject a BGP segment into an existing
TCP session without being able to see the actual TCP stream (IXP filters
should prevent ARP/MAC spoofing).
I think every internet exchange has port security, which will be able to filter out unauthorised Mac addresses. But for members binding another member's IP address to their own IX LAN, maybe the internet exchange has checks against Macs and IPs? By scanning ARP and NDP?
(This said, I've never actually seen or heard about an actual attack
on a BGP session - it can obviously done, but seems to be either so
stealthy that nobody notices, or uninteresting enough that nobody
does it)
I think there are three cases of modifying or attacking the next-hop aspect.
Case1:
Assume that Network A and an ISP (Network B) are in the same IXP and Network A sets the next hop of all routes to the IP address of the ISP without authorization or purchase of IP Transit. This will allow the ISP's routes to be used without purchasing the service (output traffic only), which also requires another ISP(Network C) for incoming traffic. The graph is shown below.
I have heard of instances where these have been caused by a lack of source address validation by the ISP.
Case2:
However, as Nick says, this is more likely to happen with multi-hop BGP, as it is difficult for network C to modify packets restricted to BGP when A is directly connected to B.
Case3:
Suppose network A is under DDos attack and network A announces the next hop of the prefixes it sends for network B so that network B will carry this traffic.
But it looks like all of these methods are easily prevented, and I recently came up with a method which can even pass RPKI. I call it AS-SET-based BGP hijacking.
AS-SET-based BGP hijacking
Assume network A is hosting a banking website. As compared to the other networks, the AS-PATH between the attacker (network B) and network A is shorter.
Attacker Network B can add the victim's (Network A) ASN to its own AS-SET so that filters on other networks will add Network B's prefixes. Network B can then announce Network A's prefix to the other networks.
In response, an attacker could deploy a reverse proxy to the source site (the bank's website) on Network A. and use HTTP authentication to request a TLS/SSL certificate as a way to perform a man-in-the-middle attack. If the bank will monitor the issuance of TLS/SSL certificates, the hijacker can use HTTP directly, which will reduce the likelihood of detection.
If the prefix of network A has an RPKI, the attacker network B can pass the RPKI authentication by prepending the ASN of network A to the prefix.
It may seem like these conditions are a bit harsh, but they would be much easier if the attacker had created a fake bank website.
I don't know much about ASPA, but I think that if "enable first as" is not enabled upstream, the attacker may can still pass the filter?
Best,
Brandon Zhi
HUIZE LTD
www.huize.asia | www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.