net: option to disallow v1 connection on ipv4 and ipv6 peers

stratospher commented at 12:23 pm on September 23, 2024: contributor

resolves #29618.

This PR adds a config flag option -v2onlyclearnet which disallows outbound v1 connections on ipv4 and ipv6 networks since they’re unencrypted. outbound v1 connections are still possible from tor/i2p/cjdns peers since they’re encrypted networks.

v1 outbound connections to peers are not attempted
v1 reconnections are not attempted (if peer is falsely advertised as v2 peer and we attempt a v2 connection but it fails, we do not attempt a v1 reconnection when -v2onlyclearnet is switched on)

Currently 35 - 39% of reachable nodes in network supporting v2 (according to https://21.ninja/reachable-nodes/node-service-share/ and https://bitnodes.io/nodes). Also found 41-45 % of addresses supporting v2 in the addrman of nodes I checked - personal node and the nodes in peer.observer. (You can use this branch to check the % of v2 addresses in a node’s addrman.)

DrahtBot commented at 12:23 pm on September 23, 2024: contributor

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/30951.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	vasild, 1440000bytes
Concept ACK	mzumsande, dergoegge

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#30988 (Split CConnman by vasild)
#29418 (rpc: provide per message stats for global traffic via new RPC ‘getnetmsgstats’ by vasild)

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.

DrahtBot added the label P2P on Sep 23, 2024

DrahtBot added the label CI failed on Sep 23, 2024

stratospher force-pushed on Sep 24, 2024

DrahtBot removed the label CI failed on Sep 24, 2024

stratospher force-pushed on Sep 25, 2024

vasild commented at 4:40 pm on September 26, 2024: contributor

In #29618 and here, I don’t see the motivation to forbid v1 connections. In other words, what is the purpose of this?

In addition to the concerns expressed in #29618, there is one more - if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

I see possible downsides and 0 benefit of a v2only option.

mzumsande commented at 3:54 pm on September 27, 2024: contributor

Concept ACK

In #29618 and here, I don’t see the motivation to forbid v1 connections.

Well, to gain the benefits of BIP324. For example if you are concerned about someone inspecting the traffic to your node it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection. You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split. If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

if V2-only is widespread

that would be a problem, but -onlynet, -blocksonly etc. have that exact same problem. I see this as an option you would only choose if you actually need it because you are concerned about unencrypted traffic.

jonatack commented at 9:35 pm on September 27, 2024: member

You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split.

Our docs address this to an extent here and here. As those docs point out, -onlynet only affects outbound connections (not inbound and manual ones), and we suggest that it be used with multiple networks. My blog goes further into it here and here.

If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

Agree. My node, for instance, runs over tor/i2p/cjdns and makes manual connections to trusted clearnet peers.

if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

Agree. With this change, clearnet node operators may need to accept v2, whether they wish to or not. We generally try to avoid forcing users to do things. I suppose my concept ack on this would depend on that tradeoff.

vasild commented at 4:28 am on September 28, 2024: contributor

For example if you are concerned about someone inspecting the traffic to your node it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

in src/init.cpp:553 in ab5f8759ab outdated

549@@ -550,6 +550,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
550     argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
551     argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
552     argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
553+    argsman.AddArg("-v2onlyclearnet", strprintf("Disallow v1 connections on IPV4/IPV6 (default: %u). Enabling this is not recommended unless absolutely necessary, as it may risk network partitions if all users enable it.", false), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

jonatack commented at 1:21 pm on September 28, 2024:

Enabling this is not recommended unless absolutely necessary, as it may risk network partitions

This is unfortunately only one brigading campaign by one or more prominent bitcoiners on social media away from being potentially adopted by many nodes.

With -onlynet, the network partition risk is in practice opt-in, i.e. chosen by a minority subset for themselves. Whereas here, the network partitioning and the lack of peers risks could be imposed on a future minority of users that are running earlier versions of Bitcoin Core. This seems at odds with maintaining backward compatibility for that minority.

in src/net.h:1583 in ab5f8759ab outdated

1576@@ -1572,6 +1577,13 @@ class CConnman
1577      */
1578     bool whitelist_relay;
1579 
1580+    /**
1581+     * option for disabling v1 connections on IPV4 and IPV6.
1582+     * connections on IPV4/IPV6 need to be v2 connections.
1583+     * connections on Tor/I2P/CJDNS maybe v1 or v2 connections.

jonatack commented at 1:22 pm on September 28, 2024:

“may be” or “can be”

0     * connections on Tor/I2P/CJDNS can be v1 or v2 connections.

mzumsande commented at 7:54 pm on September 28, 2024: contributor

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.
Transaction privacy

In both of these cases, if you accept inbounds they could just connect to you as an alternative (but they would need to have a suspicion, whereas detection of bitcoin-related network data could be automated). So another alternative would be to only disallow v1 connections for outbound peers. In that case, if you don’t want any v1 connections at all you’d have to run with -nolisten.

DrahtBot added the label CI failed on Sep 29, 2024

DrahtBot removed the label CI failed on Sep 29, 2024

vasild commented at 4:51 pm on September 29, 2024: contributor

what are the reasons to be concerned about somebody inspecting the traffic to my node?

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.

This is what is worrying me - V2-only will not hide the fact that I am running a bitcoin node, but may give the false impression that it does. This is dangerous. My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough. No need to inspect the traffic itself.

Another possible misunderstanding is that V2-only makes the traffic impossible to spy. I can imagine a blatant MITM, which is detectable because the session keys would differ, should somebody bother to check them. Once I detect this, whom am I going to complain to? My oppressive gov/ISP/whatever, same one that is doing the spying? Or the ISP can outright redirect my connections to addr:port to their spy node at spyaddr:port (I think I am talking to addr, but addr does not even have a connection from me). The point is that the traffic is spyable. Then, what is it so much that I want to keep away from spies? The data being transferred is all public, except if we are talking about me broadcasting my own transactions, there you go:

Transaction privacy

V2-only may give the false impression that it breaks the link between transaction origin and IP address / geolocation. Even with unspyable p2p encryption, I may have a connection to a spy bitcoin node which then sees my traffic. Like you said “it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection” I think this is the same as “it does not matter even if all your connections are encrypted, if you have just one (encrypted) connection to a spy node”.

stratospher commented at 6:20 pm on September 29, 2024: contributor

@vasild V2 only doesn’t protect against active attacks like the ones you’ve mentioned which require resources from the other party to run a node to spy the traffic.

V2 only protects against a cheaper attack vectors possible because of passive inspection of network traffic flowing through different medium. They don’t need the other party to run a node to spy.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.

Transaction privacy

Yes, for the same reason as wanting to encrypt network traffic in the first place and this just offers a stronger guarantee when running a node with v2 support that unencrypted clearnet bitcoin traffic is not being collected and sold by other parties. Deep packet inspection, keyword filtering are cheaper for ISPs/firewalls to pull off and v2 only would protect against this.

vasild commented at 11:53 am on October 2, 2024: contributor

A V2-only option will:

not hide the fact that one runs bitcoin node (that is true regardless of encryption) and
not stop even moderately motivated actor from spying for transaction origin (either by opening a P2P connection to the target or bricking V2 encryption or outright redirecting connections to their node)

but it will give the false impression that it does those two things. Further, it will make it more difficult for old nodes to find peers to connect to.

Concept NACK because of that.

dergoegge commented at 12:45 pm on October 2, 2024: member

Concept ACK

This option seems useful for users that want to:

prevent passive spying on their connections
increase the cost of tampering with the data exchanged on their connections
increase the cost of detecting that they run a bitcoin node

Currently 59.71% of network supports v2

Have you checked how diverse these ~60% of v2 supporting nodes are? An extreme example: if they are all on running on AWS then I don’t think we should add the option at this time.

vasild commented at 2:19 pm on October 2, 2024: contributor

increase the cost of detecting that they run a bitcoin node

How? Given that the spy does not need to inspect the traffic at all:

My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough.

sipa commented at 2:27 pm on October 2, 2024: member

@vasild That assumes the attacker has sufficient monitoring infrastructure in place to maintain an accurate list of Bitcoin P2P ip:ports. That’s obviously not impossible, but it is a significantly larger effort than stateless packet inspection looking for the string “\xf9\xbe\xb4\xd9version\x00\x00\x00\x00\x00”.

And yes, very little in BIP324 protects against an attacker deliberately targetting specific individuals - its goal is increasing costs for large-scale monitoring. From that perspective I agree there is a risk for a false sense of security when introducing options like these, but I think it’s a stretch to say that that makes it pointless. I can very well imagine this makes it possible to run a node at all for some users.

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn’t better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

jonatack commented at 2:59 pm on October 2, 2024: member

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn’t better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

Yes. I may be potentially concept/approach ack here if this proposal adopts the suggestion above / in #29618 (comment) or #29618 (comment). (Along with perhaps additional user documentation for node runners, maybe in the relevant config option helps and/or in /doc.)

1440000bytes commented at 9:15 pm on October 3, 2024: none

I think it’s too early to add this option but it will remain unused by most and off by default. I don’t see anything wrong with some users testing it.

This doesn’t hide the fact that a user is running a bitcoin node (most IPv4 nodes use default port). It just ensures all peers are using v2 for P2P.

DrahtBot added the label Needs rebase on Oct 9, 2024

brunoerg commented at 8:22 pm on October 10, 2024: contributor

A mutation testing report for this PR is available at: https://brunoerg.xyz/mutation-core-front

laanwj commented at 10:15 am on October 24, 2024: member

Well, to gain the benefits of BIP324. For example if you are concerned about someone inspecting the traffic to your node it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection.

Right. Would it maybe make sense to have an option to restrict transaction broadcast and relay to v2-only, for IPv4 and IPv6 connections? Instead of not connect at all? Eg consider v1 connections blocks-only (except those over Tor/I2P). This alleviates the risk of network partition of consensus. While still providing a bit of added privacy for where it matters.

net: add option in CConman to disable v1 clearnet connections

a boolean option `disable_v1conn_clearnet` is introduced in CConman
which will (in a later commit) store if the user wishes to disable
outbound v1 connections on IPV4 and IPV6 networks since they are
unencrypted.

this option is accessible outside CConman using
`DisableV1OnClearnet()` function with the network we're trying to
connect to passed as an argument.

eb2fba9bce

init: add -v2onlyclearnet config option

if this option is set by the user, v1 connections on unencrypted
networks like IPV4/IPV6 will be disallowed. Only users with real
need are recommended to turn this on because it could risk network
partitioning in the unlikely scenario that everyone turns it on.

2f8eb3cb8c

net: disable v1 connections, reconnections on clearnet

if `-v2onlyclearnet` is turned on,
- v1 addresses from addrman aren't selected and manual connections
aren't attempted for outbound connections if it's from IPV4/IPV6
networks.
- v1 downgrade mechainm is not attempted if v2 connection wasn't
successful

d8abfef433

test: Check that v1 connections to clearnet peers don't work

when `-v2onlyclearnet` is turned on:
- v1 connections to clearnet peers don't work
- v2 connections to clearnet peers work
- v1 conneections to tor/i2p/cjdns peer works

a proxy is used because otherwise NET_UNROUTABLE is the default
network in the tests.

b434583fbb

stratospher force-pushed on Oct 28, 2024

stratospher commented at 5:50 am on October 28, 2024: contributor

I’ve rebased and changed the approach in the PR to have v2 only outbound connections. So there’s null partition risk because of the option now.

Right. Would it maybe make sense to have an option to restrict transaction broadcast and relay to v2-only, for IPv4 and IPv6 connections? Instead of not connect at all? Eg consider v1 connections blocks-only (except those over Tor/I2P). This alleviates the risk of network partition of consensus. While still providing a bit of added privacy for where it matters.

I don’t think just sending transactions over encrypted connections gives that much extra privacy.

Passive attackers can still:

cheaply tell you’re running a bitcoin node looking at the network magic bytes.
there’s transaction lengths which can be used to distinguish 1 transaction from another.

Having all network traffic as encrypted would give better privacy when dealing with 1.

DrahtBot removed the label Needs rebase on Oct 28, 2024

laanwj commented at 11:26 am on October 30, 2024: member

I don’t think just sending transactions over encrypted connections gives that much extra privacy.

i’m not advicating to send just transactions, v2 connections would have blocks+transactions, all of it. Not sending transactions over v1 makes sure that transactions aren’t sent over the network in plaintext.

In the long term, if the idea is to phase out P2P v1, i think demotiing it to a blocksonly-protocol makes sense. It holds the network together against eclipse attacks and accidental partitioning, but doesn’t reveal anything privacy sensitive.

Sure, passive attackers can still see packet sizes in the v2 connections, but that doesn’t actually change if you refuse to accept and/or make v1 connections at all?

cheaply tell you’re running a bitcoin node looking at the network magic bytes.

i still don’t believe there is any hiding like that. There’s so many tells for passive attackers: using the DNS seeds, connecting to certain nodes, using port 8333 (in and/or out), using P2P address gossip. Sure, if you manage to avoid all of those, it’s less apparent, but that’s so much work and easy to screw up with a small mistake.

vasild commented at 2:30 pm on November 6, 2024: contributor

Before I could see the purpose of the full v2only option: 1. to hide the fact that a bitcoin node is running and 2. hide its own transactions. However I think it would achieve neither of those, but I could see how it looked like it would. Now it is changed:

I’ve rebased and changed the approach in the PR to have v2 only outbound connections

Does it still have the same motivation: 1. and 2.? I think the idea in #29618 is that v1 connections are somehow harmful and we must not have any of them. Now with this PR we would allow v1 inbound connections? @iotamega, do you think this would resolve #29618? Once the node has e.g. 30 connections and some of them are v1 and some v2, I think it is irrelevant which are inbound and which are outbound.

Consider outbound v1 connections to clearnet but via the Tor proxy (via the Tor network and Tor exit nodes), if -proxy= is given. Assuming there is some reason to avoid v1 outbound (which I don’t see), should those be avoided as well?

1440000bytes changes_requested

1440000bytes commented at 6:02 pm on November 6, 2024: none

NACK

This pull request and related efforts are bad for bitcoin in lot of ways not just partition risk.

We need to fix other things before trying to achieve this. Disappointed that some devs keep repeating it will hide that you are running a node.

net: option to disallow v1 connection on ipv4 and ipv6 peers #30951

Code Coverage & Benchmarks

Reviews

Conflicts