Idle Disconnect

[fjl]

Geth should occasionally disconnect a peer to ensure some churn in the peer set.

Related: #29329

[1033309821]

Dear @fjl,

In the process of developing tools, we found that we may not need a complete Ethereum node client to establish a normal connection with the node. At the network protocol level, I only need to construct a fixed handshake message, which only contains static values. The only dynamic thing may be my own key, but this can be generated without restriction, and I can even continue to try to establish a connection with the attacked node by switching this identity. This step is very easy to pass, and the important thing is the second step, statusExchange. Here, our attack program only needs to wait for the Status packet of the node, and then use the Status packet sent by the node to reconstruct a correct Status packet and return it to the node to successfully establish a peer relationship with the node. The key point here is that I do not need to provide my own real "have" information, but directly use the "want" information of the attacked node. This will cause my attack program to not even need any chain status data, greatly reducing the cost of the attack. There is no need to understand the current chain status of the node, because the node will actively "share" it with our attack program.Just like the one used in the geth test program
So we initially believe that there may be no measures to prevent attackers from establishing peers with it during the peer establishment process.Because we use the above test program to establish a connection with a normally operating node and can further send eth68 protocol data packets to obtain data normally. Then use this data to further construct data that needs to be constructed based on ethdata and send it to the node. In this process, I don’t need to know genesis and chaindata. I am not sure whether this is a loophole.
handshake

I am not sure whether modifying this part (go-ethereum/eth/protocols/eth
/handshake.go) can have an effect on node slot attacks, but previous discussions may be more focused on go-ethereum/p2p/. But perhaps you can try to let the link requester send the status first for authentication. Another way is to not provide all the authentication data, but only provide part of it, and the other part is provided by the other party, so as to avoid the other party directly modifying it to the correct data. I think the method I provided may alleviate node slot attacks or increase the cost of synchronizing data for attackers. I hope it helps you!

[cskiraly]

Hi @1033309821,
In this issue we are focusing on here is to make sure we disconnect peers occasionally, so that slots do free up. The behavior you describe is more about filtering inbound connections a-priori, as part of the handshake. Can you crate a separate issue for the discussion about the status exchange during handshake? Thanks

[1033309821]

Hi @1033309821, In this issue we are focusing on here is to make sure we disconnect peers occasionally, so that slots do free up. The behavior you describe is more about filtering inbound connections a-priori, as part of the handshake. Can you crate a separate issue for the discussion about the status exchange during handshake? Thanks

Sure, We have created a new issue

[fjl]

Implemented in #31476