EIP-8: further clarifications

EIPS/eip-8.md

@@ -12,28 +12,33 @@
 
 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
+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.
+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.
+Finally, implementations of **the RLPx TCP Transport protocol** should accept (but not
+send) 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.
+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.
 
 ```text
 auth-vsn         = 4
@@ -75,6 +80,12 @@ 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)](http://queue.acm.org/detail.cfm?id=1999945).
+
 #### Changes to the devp2p Wire Protocol
 
 All clients currently contain statements such as the following:
@@ -87,7 +98,7 @@ if data['version'] != proto.version:
     return proto.send_disconnect(reason=reasons.incompatibel_p2p_version)
 ```
 
-These checks make it impossible to change the version or structure of the initial packet.
+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.
 
@@ -98,6 +109,18 @@ version simply send a packet with higher version and possibly additional list el
 * 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 clients do not care about the number of list elements (a notable 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
@@ -119,8 +142,9 @@ version. Since this is the first change to the RLPx handshake packet, we can sei
 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:
+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.
 
 ```go
 packet = read(307, connection)
@@ -136,8 +160,21 @@ if decrypt(packet) {
 }
 ```
 
-Implementations may choose to add a random amount of bytes to vary the size of the packet.
-Doing so helps prevent signature-based traffic classification.
+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.
+
+Whether this is an issue depends on the attacker's budget and the availability
+of other indicators. 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 is likely to
+  be a more effective measure for filtering most RLPx traffic.
+* For an attacker who can afford to correlate many criteria, the size prefix will ease
+  recognition because it adds to the indicator set. However, such an attacker can also be
+  expected to read and or participate in RLPx Discovery traffic, in which case effective
+  blocking is possible irrespective of the size prefix.
 
 ### Backwards Compatibility