This document is a cross-implementation proposal that outlines how we can achieve a smooth transition from RLPx V4 to RLPx V5.
The changes in RLPx V5 are as follows:
- Chunked transfers are used to break up devp2p messages, avoiding head of line blocking when multiple subprotocols share the same TCP connection. They can also be used to transfer multiple packets belonging to the same subprotocol at the same time.
- Packets are dispatched to subprotocols using the protocol-id frame header field instead of looking at packet-id offsets.
- The key establishment handshake has changed to rely on a
peer-reviewed KDF and derives separate keys for ingress and egress
traffic. This change is required to fix a security flaw in the
protocol where an attacker can derive the ephemeral encryption key
by looking at network traffic.
PR to the spec: ethereum/devp2p#34
- We are preparing to make the ECIES variant that we use compliant
with the SEC-1 specification. For RLPx V4, we based all
implementations on the crypto/ecies package from go-ethereum. We
have discovered a few inconsistencies in crypto/ecies:
- IV is part of the ciphertext (SEC-1 section 3.8 specifies all-zeros IV)
- SHA256 is used for the KDF (we should probably use Keccak256)
PR to the spec: forthcoming
There are two ways in which your implementation can handle the upgrade to the new key derivation, message dispatch and chunked transfers:
Implementations should adopt the new handshake and perform key derivation using the new alogrithm, falling back to V4 derivation if the remote version number is > 255 (indicating that the remote end used a random nonce value as required by RLPx V4). If the V5 derivation was used, implementations should enable chunked transfers and protocol-id based message dispatch for the connection.
If compatibility with V4 clients is not required, implementations should delay enabling V5 features until a majority of nodes in the network also supports V5.
For the ECIES upgrade, implementations should attempt to decrypt the initiator auth messages using the new format (Keccak256-based KDF, no IV) if decrypting using the V4 ECIES format fails. I’ll notify you via email when the spec PR for the ECIES handshake is up.
Changes (1), (2), (3) are implemented for go-ethereum in ethereum/go-ethereum#1821.
pyethereum and cpp-ethereum implement (1), (2) but not (3) at this time.
Going ahead with these changes requires consensus about the new handshake. I would like to get cross-implementation testing going before Christmas, preferably earlier. If you have any objections with the handshake proposal, please supply feedback in the devp2p PR.
Test vectors for the current handshake proposal are available at https://github.com/fjl/go-ethereum/blob/rlpx-framing/p2p/rlpx/handshake_tv_test.go