I understand now your point on countersign making MITMing ineffective in this case and in the partitioning example.
I was also thinking about scenarios where the attacker’s goal is to censor TXs or blocks. For example, an attacker that intercepts the connections of a mining pool gateway could delay and drop traffic from the victim to its peers when a new block is found. This just requires the attacker to have a connection to the victim node to identify a new block, and be on path to drop / delay encrypted traffic that they intercept.
Agreed - unfortunately I don’t seem to have the option to edit my original post anymore.
I agree, this would be interesting to look into. I’m not very familiar with I2P, but as far as I understand, to evaluate this I would have to run an I2P router, build a copy of the NetDB and perform the above analysis again. I2P might be more resilient to this attack compared to Tor as it forms short lived tunnels using a larger set of peers.
Tor, on the other hand, by default uses a single entry guard node at any given time, which it picks out of a set of 3 entry guards. If I understand correctly, rotating guard nodes introduces a tradeoff: it makes this attack harder, but increases the chances of an attacker deanonymizing the circuit. Tor guard nodes seem to be more centralized than Bitcoin nodes, and ~39% of them are potentially vulnerable to prefix hijack by virtue of them not being covered by RPKI or having overly permissive ROAs.
Clarifications: it is indeed the same AS, and that is right - step 1 is indeed the classic attack, and starting 2 is the new attack (eclipsing via interceptions). I’ll make the suggested edits in any future revised writeups, since I can’t edit the original post.
I am not aware of any widespread detection mechanism beyond ROA/RPKI and custom filters / monitoring that is employed in practice by network operators, but I will look into it a bit more. Being more aggressive is advantageous for the adversary, but features related to the volume of announcements have previously been proposed in the literature for anomaly detection (see Table III).
This sounds interesting, what kind of probing do you have in mind?
The link works now! 
This does make it easier for the attacker to get into outbound connection slots, but as far as I understand, this does not make it make it much easier for the attacker to poison addrman’s tables since outbound and inbound connections seem to be treated equally with regards to received ADDR messages in net_processing.cpp.
There seems to be a weak correlation between the two:
Rotating peers whose paths have changed might be a good heuristic, I’ll also think on this some more.
That’s true, it’s something that an attacker might seek to game. I’ll have to think more on this.
An attacker can evade detection by tunneling if they peer with an AS on the “common stem” of ASes that all traffic traverses out of the victim AS. For instance assume that all traffic from the victim flows from AS A (source) to B1 and on the second hop to ASes C1, C2. The attacker AS X uses AS B1 as a provider, and tunnels traffic to C1 and C2. It also does not decrease the TTL field on packets used for traceroute. This makes X invisible in the trace. If however, the victim node had peers in B2, the attack would be obvious, as the observed trace would change from A → B2 to A → B1 → B2 since the attacker cannot prevent B1 from appearing in the trace via tunneling. Detecting tunneling attackers could perhaps be done by observing other signals, such as new router IPs appearing in the trace (e.g the border router in B1 that connects to X might differ from the one that connects to C1).
As a reactive measure (versus the proactive ones in the post), if we detect route consolidation through a common (potentially adversarial) AS, we perform more traceroutes to peers in our tables trying to find candidates whose routes do not cross the attacker AS.
I think that’s a good idea. I’ll think on this and try to put something together to share.
We can use traceroutes for detecting interception attacks of egress traffic for both inbound and outbound connections. If we want to detect the interception of ingress traffic we would need cooperation from external vantage points or the node to which we are connected.
Agreed, this is important and immediately actionable. Have there been any similar efforts in raising awareness in bitcoin optech that I can look into?
Thank you for the references. I ran the prefix analysis again: Currently, no node prefixes are covered by an ASPA object. I’ll look into how we can model ASPA adoption and reason about the level of security it will offer against this attack.
Correction on ASPA analysis
Previously this post mistakenly mentioned that 0.5% of node prefixes are covered by an ASPA object. This was for Tor node prefixes, not bitcoin. Even then, for all of the supporting ASNs there is at least 1 provider that does not issue an ASPA, meaning that the attacker can still perform a shorter path attack without incurring too big of an AS_PATH length penalty.