EIP-8: devp2p Forward Compatibility Requirements for Homestead

Metadata

Status: FinalStandards Track: NetworkingCreated: 2015-12-18

Authors

Links

Abstract

This EIP introduces new forward-compatibility requirements for implementations of the devp2p Wire Protocol, the RLPx Discovery Protocol and the RLPx TCP Transport Protocol. Clients which implement EIP-8 behave according to Postel's Law:

Be conservative in what you do, be liberal in what you accept from others.

Specification

Implementations of the devp2p Wire Protocol should ignore the version number of hello packets. When sending the hello packet, the version element should be set to the highest devp2p version supported. Implementations should also ignore any additional list elements at the end of the hello packet.

Similarly, implementations of the RLPx Discovery Protocol should not validate the version number of the ping packet, ignore any additional list elements in any packet, and ignore any data after the first RLP value in any packet. Discovery packets with unknown packet type should be discarded silently. The maximum size of any discovery packet is still 1280 bytes.

Finally, implementations of the RLPx TCP Transport protocol should accept a new encoding for the encrypted key establishment handshake packets. If an EIP-8 style RLPx auth-packet is received, the corresponding ack-packet should be sent using the rules below.

Decoding the RLP data in auth-body and ack-body should ignore mismatches of auth-vsn and ack-vsn, any additional list elements and any trailing data after the list. During the transitioning period (i.e. until the old format has been retired), implementations should pad auth-body with at least 100 bytes of junk data. Adding a random amount in range [100, 300] is recommended to vary the size of the packet.

Motivation

Changes to the devp2p protocols are hard to deploy because clients running an older version will refuse communication if the version number or structure of the hello (discovery ping, RLPx handshake) packet does not match local expectations.

Introducing forward-compatibility requirements as part of the Homestead consensus upgrade will ensure that all client software in use on the Ethereum network can cope with future network protocol upgrades (as long as backwards-compatibility is maintained).

Rationale

The proposed changes address forward compatibility by applying Postel's Law (also known as the Robustness Principle) throughout the protocol stack. The merit and applicability of this approach has been studied repeatedly since its original application in RFC 761. For a recent perspective, see "The Robustness Principle Reconsidered" (Eric Allman, 2011).

Changes to the devp2p Wire Protocol

All clients currently contain statements such as the following:

These checks make it impossible to change the version or structure of the hello packet. Dropping them enables switching to a newer protocol version: Clients implementing a newer version simply send a packet with higher version and possibly additional list elements.

If such a packet is received by a node with lower version, it will blindly assume that the remote end is backwards-compatible and respond with the old handshake.
If the packet is received by a node with equal version, new features of the protocol can be used.
If the packet is received by a node with higher version, it can enable backwards-compatibility logic or drop the connection.

Changes to the RLPx Discovery Protocol

The relaxation of discovery packet decoding rules largely codifies current practice. Most existing implementations do not care about the number of list elements (an exception being go-ethereum) and do not reject nodes with mismatching version. This behaviour is not guaranteed by the spec, though.

If adopted, the change makes it possible to deploy protocol changes in a similar manner to the devp2p hello change: simply bump the version and send additional information. Older clients will ignore the additional elements and can continue to operate even when the majority of the network has moved on to a newer protocol.

Changes to the RLPx TCP Handshake

Discussions of the RLPx v5 changes (chunked packets, change to key derivation) have faltered in part because the v4 handshake encoding provides only one in-band way to add a version number: shortening the random portion of the nonce. Even if the RLPx v5 handshake proposal were accepted, future upgrades are hard because the handshake packet is a fixed size ECIES ciphertext with known layout.

I propose the following changes to the handshake packets:

Adding the length of the ciphertext as a plaintext header.
Encoding the body of the handshake as RLP.
Adding a version number to both packets in place of the token flag (unused).
Removing the hash of the ephemeral public key (it is redundant).

These changes make it possible to upgrade the RLPx TCP transport protocol in the same manner as described for the other protocols, i.e. by adding list elements and bumping the version. Since this is the first change to the RLPx handshake packet, we can seize the opportunity to remove all currently unused fields.

Additional data is permitted (and in fact required) after the RLP list because the handshake packet needs to grow in order to be distinguishable from the old format. Clients can employ logic such as the following pseudocode to handle both formats simultaneously.

The plain text size prefix is perhaps the most controversial aspect of this document. It has been argued that the prefix aids adversaries that seek to filter and identify RLPx connections on the network level.

This is largely a question of how much effort the adversary is willing to expense. If the recommendation to randomise the lengths is followed, pure pattern-based packet recognition is unlikely to succeed.

For typical firewall operators, blocking all connections whose first two bytes form an integer in range [300,600] is probably too invasive. Port-based blocking would be a more effective measure to filter most RLPx traffic.
For an attacker who can afford to correlate many criteria, the size prefix would ease recognition because it adds to the indicator set. However, such an attacker could also be expected to read or participate in RLPx Discovery traffic, which would be sufficient to enable blocking of RLPx TCP connections whatever their format is.

Backwards Compatibility

This EIP is backwards-compatible, all valid version 4 packets are still accepted.

Implementation

go-ethereum libweb3core pydevp2p

Test Vectors

devp2p Base Protocol

devp2p hello packet advertising version 22 and containing a few additional list elements:

RLPx Discovery Protocol

Implementations should accept the following encoded discovery packets as valid. The packets are signed using the secp256k1 node key

ping packet with version 4, additional list elements:

ping packet with version 555, additional list elements and additional random data:

pong packet with additional list elements and additional random data:

findnode packet with additional list elements and additional random data:

neighbours packet with additional list elements and additional random data:

RLPx Handshake

In these test vectors, node A initiates a connection with node B. The values contained in all packets are given below:

(Auth₁) RLPx v4 format (sent from A to B):

(Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B):

(Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B):

(Ack₁) RLPx v4 format (sent from B to A):

(Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A):

(Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A):

Node B derives the connection secrets for (Auth₂, Ack₂) as follows:

Running B's ingress-mac keccak state on the string "foo" yields the hash