I have partially implemented the EIP-8 couterproposal for an RLPx upgrade mechanism based on discovery as specified here: https://pad.riseup.net/p/E1qarD8AXWKj
- Compared to EIP-8, the proposal requires less pre-Homestead changes to the implementation. Since the TCP transport protocol is unchanged, no implementation changes are required there. The only change effectively required is relaxing discovery packet parsing so it can handle newer versions of the protocol gracefully.
- However, the sole purpose of the mechanism is facilitating RLPx protocol upgrades.
Therefore it is also necessary to consider the implementation impact when an actual
protocol change needs to be deployed. I tried implementing this part, too. My verdict is
that implementing discovery based upgrades requires more changes than EIP-8, and is way
trickier.
- Tracking remote versions is harder than it seems because the version is carried in the
ping packet. The remote version number cannot be requested on demand because the
remote node would need to ping. It is impossible to reliably solicit a ping packet
because the specification doesn’t define when they get sent.
It can be worked around by also putting the version in the pong packet, which has backwards-compatibility issues. Remember that people will upgrade before the actual switchover block arrives and we can’t really change anything in discovery until after the block has passed and everyone has the new client.
It can also be worked around through a new packet type, but thats a bit messy.
- The proposal contains a deprecation mechanism which degrades connectivity for outdated
nodes, to the point where they can no longer participate at all when the majority of the
network has upgraded. It is supposed to prevent downgrade attacks.
The amount of code required for this is non-trivial and can potentially create an attack surface that shuts a node off the network.
I think the incentives to upgrade should be new protocol features and fixed security issues. If a particular version of the protocol is causing issues on the network (this was one of the reasons presented orally), it can be disabled equally well by refusing communication from newer nodes.
- Tracking remote versions is harder than it seems because the version is carried in the
ping packet. The remote version number cannot be requested on demand because the
remote node would need to ping. It is impossible to reliably solicit a ping packet
because the specification doesn’t define when they get sent.
- Unauthenticated size prefix: Authenticating the size is easily achieved through ECIES and prevents the potential prefix replay attack where replayed ciphertext is prepended to an attacker ciphertext of larger size.
- Connection Filtering concerns:
We need to specify what the expect amount of effort on the attacker side is.
Is the ability to identify RLPx connections through high amount of effort even
part of our threat model?
Even if it is a legitimate concern, it is probably better to keep our options for traffic cloaking open in general. Daniel suggested the following:
- Make the size prefix variable-size as well (e.g. highest bit set means next byte is part of size) and subtract 300. This would make the first bytes uniformly random, increasing attacker effort to identify connections based on data entropy.
- Consider masquerading as SSH or a similar protocol in the future. As long as the magic identification string of the protocol we’re masquerading as can be distinguished from what we have now, this can always be introduced.
My personal take on the filtering issue is that is something we should look at later, when it is causing actual problems. If an adversary is powerful enough to shut down almost all Ethereum communication happening around the globe based on a two byte size prefix, they will surely also be powerful enough to shut it down in a different way.
- On “can’t upgrade handshake ECIES encryption with EIP-8 method”
This one is true, but it is also not the problem that EIP-8 set out to solve. I am open do a discovery-based solution for this one:
- announce optional support for the new handshake
- transition phase: new node <-> new node comms use new handshake, old node <-> new node comms use old
- later: support for the old handshake is retired
- On “metadata belongs in discovery”:
Additional metadata in discovery is nice, but doesn’t solve the problem of nodes getting overwhelmed with useless connections.
I would like to introduce protocol-specific metadata to the first handshake packet in the future, which would allow rejecting useless connections with zero roundtrips. EIP-8 makes this possible.
In general, EIP-8 does not preclude adding more metadata to discovery.