The idea for this write-up is to look at potential scenarios an attacker could try in order to use the ASMap file feature to their advantage and lower security for nodes contrary to the feature's intention.
Some attack scenarios that might be of concern are then contrasted with mitigation mechanisms. These are measures that we can take automatically and without manual verification (i.e. very low false positives rate) that might help us detect potential issues in the ASMap file.
Overview of measures suggested:
- Size of file/count of entries
- Coverage of the know Bitcoin network
- Coverage of the global routable address space
- ASN diversity of the Bitcoin network
An ASMap file edited after creation with bad intentions, as well as a malicious build process or altered intermediate artifacts, should all be dealt with by using a transparent, fully FOSS-based, and reproducible build process. In the case of ASMap, we achieve this by sharing the raw collected data from the different input sources along with logs and the result files. Using these and the FOSS used in the process, it should be possible for anyone to rerun the process and verify that they end up with the same result files.
This leaves us with tampering cases that focus on input files before they enter the ASMap file build process.
This section discusses malicious data that was inserted into the input files not via editing the input files after they were created but rather false/malicious data that got into the input files in a "natural way". This could for example via BGP leaks or hijacks, false records in IRR databases, etc.
To mitigate this we are using the data sources as inputs that have the highest quality first and then fill up the missing address space from the next best quality resource. The quality ranking we are working with is 1. RPKI, 2. IRR (RIR run), 3. Collectors (Routeviews, RIPE RIS). I have written extensively on the background for this particular choice here.
Using the state of the art for inputs doesn't make this problem go away completely though. BGP leaks, hijacks, etc. are still happening on the internet very regularly and we can not prevent/catch all of these cases without full adoption of RPKI and further technologies like ASPA.
This section discusses different scenarios of tampered input data after download in more detail since this seems to be the easiest scenario in that an attacker could try to generate and distribute a malicious ASMap file. The attacker downloads input files, alters them in a way that benefits them, and then runs the build process. With this scenario, the attacker does not have to go through the hassle of inserting malicious data into the input sources and the attacker can also show a reproducible build of the ASMap file. This still doesn't mean that these attacks are as easy as changing a line in a single file. The attacker would still need to analyze all input source files and potentially make edits in all of them to get the results they want in the finalized ASMap file.
An attacker could be adding malicious mappings for address space that is not already covered. The fact that we test for coverage and aim at 99+% means that there are only a few nodes that the attacker could send into a specific bucket rather than them being uncovered. A scenario where this could make a bit more sense is if the attacker had knowledge of a new node being launched in a not-yet-covered IP range. For this scenario see the final section "4 Future nodes".
Another potentially more interesting attack would be to insert false mappings on IP ranges that are already covered but where the new entries are more specific than the entries that are currently covering this IP range.
Note: The attacker is prevented from doing this on RPKI-covered address space because they can not fake the signature for such an entry.
Measuring the size/entries count of the ASMap of course would show these changes. But in reality, it may not be very interesting because only a small number of added mappings may already have the effect that the attacker desires and so these edits could also be easily explained with daily fluctuations of the routing table.
Measuring coverage on the Bitcoin network doesn't work because these attacks will not lead to lower coverage. Likewise for measuring coverage for the global routable address space.
Measuring ASN diversity is an interesting way to detect such an attack. The attacker's intention could be to map large parts of the Bitcoin network to a single AS, which then could make eclipse attacks easier for them. So an unusual drop in the number of AS buckets could be a hint for such an attack. This is addressed in the health check as it shows the total number of mapped ASNs. This is the first step to make a potential issue visible, as we learn more about what values are typical we may give more decisive warnings in the future when we detect an unusually low number of ASNs.
The attacker can remove valid mapping entries, for example, to make certain IP ranges appear unmapped or to map them to a different ASN that is covering the IP range but was less specific than the removed mapping.
Removal of entries that are covered by another, less specific entry may not be very appealing to attackers, since usually in that situation the different ASNs are still associated with the same entity or the two entities controlling these ASNs are in a close economic relationship.
The attacker can remove RPKI entries but it may be interesting to look into detecting that by re-validating the result file against RPKI. RPKI entries usually don't just disappear but instead are revoked or expire. They also have timestamps for their validity periods. Taken together this may be good enough data that can be used as a canary for such an attack while not producing too much noise.
Same as for adding entries, the size/count of the ASMap of course would show these changes. But in reality, it may not be very interesting because only a small number of added mappings may already have the effect that the attacker desires and so these edits could also be easily explained with daily fluctuations of the routing table.
Measuring the coverage of the Bitcoin network should show these attacks as they will lead to lower coverage unless there is another entry covering the same IP range. Likewise for measuring coverage for the global routable address space.
Measuring ASN diversity should also make it possible to detect such an attack at a certain scale, same as for additions above.
The attacker can change the ASN that is associated with a specific IP range in an otherwise valid entry.
The attacker is prevented from doing this on RPKI-covered address space because they can not fake the signature for such an edited entry.
Size/Count does not change at all so it is of no use.
Measuring the coverage of the overall network as well as the coverage on the global routable address space also doesn't because there is no change either.
Again, ASN diversity in the nodes' known addresses can show some issues if the attacker's goal is to make nodes either appear more or less diverse than they actually are.
Note that attackers may also combine the options above to disguise their attack. For example, they may remove some entries but then also add new ones to even out the count of entries. They may also change some entries to make a certain group of interesting peers look less diverse, forcing them into the same bucket while making another (less interesting) group look more diverse, evening out the ASN diversity stats overall.
Note that the strongest mitigation strategies suggested in this document rely on comparing the input data with the known addresses of nodes in the network. This means that nodes that have not entered the Bitcoin network yet but may do so soon and in a new part of the internet that currently does not have any known bitcoin nodes, they are not protected by these measures. This means that if an attacker would know that a new node that is interesting to them will be going online sometime soon, they could try to insert malicious mappings for the prefixes where they expect the new node to be hosted. At the moment of the creation of the ASMap file, this is very hard to detect.
As mitigation, we should recommend users that spin up economic nodes in "unventured territory" check if their new IPs are actually already covered by the ASMap file in the latest release and that they are mapped to the correct AS. We still need documentation and better tooling for this.