The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17812 (config, test: asmap functional tests and feature refinements by jonatack)
• #17809 (rpc: Auto-format RPCResult by MarcoFalke)
• #17804 (doc: Misc RPC help fixes by MarcoFalke)
• #17428 (p2p: Try to preserve outbound block-relay-only connections during restart by hebasto)
• #17399 (validation: Templatize ValidationState instead of subclassing by jkczyz)
• #17383 (Refactor: Move consts to their correct translation units by jnewbery)
• #16748 ([WIP] Add support for addrv2 (BIP155) by dongcarl)
• #16673 (Relog configuration args on debug.log rotation by LarryRuane)
• #16115 (On bitcoind startup, write config args to debug.log by LarryRuane)
• #10102 ([experimental] Multiprocess bitcoin by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

FWIW, the asmap generated from https://dev.maxmind.com/geoip/geoip2/geolite2/ is 988387 bytes in size.

Encoding the map as bool[] array in the source code will add to the executable 4 bytes per bit in the map, that's a bit excessive. You should probably encode it as a encode it as a uint8_t[] instead (with 8 bits per array element).

@sipa Would you mind providing the python script used to generate the asmap? I think Bitcoiners like @TheBlueMatt and myself who maintain their own BGP full table view of the Internet would like to generate their own asmap instead of trusting maxmind, or at least verify it.

Concept ACK

@wiz The script is here: https://gist.github.com/sipa/b90070570597b950f29a6297772a7636 though we need more tooling to convert from common dump formats, sanity check, ... I'll publish some when they're a bit cleaned up and usable.

Thanks for the script, it helps a lot with my own implementation and I also wanted to point out a few potential attack vectors to circumvent the asmap protection:

1. Private ASN ranges

There are several ASN ranges which can be used as originating ASNs without registration or verification and could be used to circumvent the asmap protection. For example I could announce one /24 from 65000, one /24 from 65001, and so on, all behind my actual ASN, in order to launch an Erebus attack. I propose that we map any IP blocks originating from the following invalid ASNs to the next-valid ASN upstream of it:

0                       # Reserved RFC7607                                     
23456                   # AS_TRANS RFC6793                                     
64496-64511             # Reserved for use in docs and code RFC5398            
64512-65534             # Reserved for Private Use RFC6996                     
65535                   # Reserved RFC7300                                     
65536-65551             # Reserved for use in docs and code RFC5398            
65552-131071            # Reserved                                             
4200000000-4294967294   # Reserved for Private Use RFC6996                     
4294967295              # Reserved RFC7300                                     

2. Multiple originating ASNs

There are actually around 50 routing prefixes on the Internet that legitimately have multiple originating ASNs, so it's not always a strict 1:1 mapping. For example, a valid use case could be an ISP that aggregates multiple customer /29 or /30 prefixes into a single /24 announcement (since /24 is the smallest globally routable prefix size that would be generally accepted) and my router indicates all of the multiple originating ASNs in curly braces like this:

141.145.0.0/19 {AS7160,43898} 
144.21.0.0 {AS7160,AS43894}
158.13.154.0/24 {AS367,AS1479,AS1504,AS1526,AS1541}
160.34.0.0/20 {AS4192,AS7160}
160.34.16.0/20 {AS7160,AS43898} 

Of course this could be used to circumvent the asmap protection as well, so for this case I also propose we instead identify the upstream aggregating ASN as the originating ASN. For my implementation I'm simply going to use a regex to strip out the curly braces aggregation to ignore it.

@wiz Very good points!

1. Private ASN ranges

Besides using private ASN ranges another obvious attack vector would be to make use of non-reserved but unused or unallocated AS-numbers as a faux downstream for a specific attacker controlled prefix:

Assume that AS54321 is a non-private but unused or unallocated ASN.

An attacker AS666 with upstream transit provider AS123 could fake having AS54321 as a downstream transit customer with the network 200.201.202.0/24.

The global view would hence be:

• 200.201.202.0/24: AS123 AS666 AS54321

Traffic to 200.201.202.0/24 would end up in the hands of AS666 who get a free extra slot our ASN lottery :-) This could obviously be repeated with N additional prefixes to get N extra slots.

Assuming that AS54321 is not in active use by any organisation no one will complain about this behaviour. (In contrast to "prefix hijacking" where the hijacked network will notice that their traffic is routed in a strange way and complain.)

How can we guard against this attack?

To guard against an attacker making use of non-IANA allocated ASNs as faux specific attacker controlled prefix:

Instead of blacklisting known reserved AS numbers, we could be stricter and apply a whitelisting approach: allow only AS number ranges that have been been allocated to the five Regional Internet Registries (AFRINIC, APNIC, ARIN, LACNIC and RIPE) by IANA. That data is available in machine readable form.

To guard against an attacker making use of IANA allocated but RIR unallocated ASNs as faux downstream for a specific attacker controlled prefix:

I believe all five RIR:s provide machine readable lists of the individual ASNs they have assigned to organisations.

(Note that this data comes with the country code for the organisation that has been assigned the AS-number. That could be handy if we some time in the future would like to implement logic for avoiding country or region based netsplits. If incorporated in the asmap data we could say not only what ASN a peer belongs to but also the region (based on which RIR that handed out the ASN) and also which country the organisation announcing the peers prefix belongs to. This would be a good approximation for the actual country/region of the peer.)

To guard against an attacker making use of IANA allocated and RIR allocated ASNs as faux downstreams for a specific attacker controlled prefix:

This is harder to guard against.

Perhaps we could require that a prefix-to-ASN mapping has been stable over say N months before being included in the asmap. That would make the described attack harder to carry out without being noticed.

Another approach would be to analyse a full routing table when creating the asmap and reason about the ASNs that are in the path to the announcing origin AS. Could be tricky to distinguish between tier-1:s and attackers :-\

Yeah, the AS map mitigation may be flawed. How about requiring everyone to also have a few Tor peers, presumably bypassing the network partition attack?

Indeed. ASN mappings are not a foolproof solution, but they're better than just using /16s (after all, there are lots of unused /16s you could announce if you wanted to). Ultimately some monitoring and building up filtering lists over time as we observe malicious behavior may improve things, but, indeed, ensuring redundant connectivity is the only ultimate solution. Once #15759 lands, I'd really like to propose a default of 2 additional blocksonly Tor connections if Tor support is enabled (see-also https://twitter.com/TheBlueMatt/status/1160620919775211520, in which someone suggested their ISP was censoring Bitcoin P2P traffic, and only after setting bitcoind to Tor-only did it manage to connect).

One thing we can play with after we build an initial table is to look at the paths, instead of looking only at the last ASN in the path. eg if, from many vantage points on the internet, a given IP block always passes from AS 1 to AS 2, we could consider it as a part of AS 1 (given it appears to only have one provider - AS 1). In order to avoid Western bias we'd need to do it across geographic regions and from many vantage points (eg maybe contact a Tier 1 and get their full routing table view, not just the selected routes), but once we get the infrastructure in place, further filtering can be played with.