multistream-select 1.0: simultaneous open protocol extension

connections/simopen.md

@@ -41,11 +41,15 @@ If both peers believe they are the initiator, then they both send
 `iamclient`. If this is the case, they enter an initiator selection
 phase, where one of the peers is selected to act as the initiator. In
 order to do so, they both generate a random 256-bit integer and send
-it as response to the `iamclient` directive. The peer with the highest
-integer is selected to act as the initator and sends an `initiator`
-message. The peer with the lowest integer responds with `responder`
-message and both peers transition to protocol negotiation with a
-distinct initiator.
+it as response to the `iamclient` directive, prefixed with the
+`select:` string. The peer with the highest integer is selected to act
+as the initator and sends an `initiator` message. The peer with the
+lowest integer responds with `responder` message and both peers
+transition to protocol negotiation with a distinct initiator.
+
+Note the importance of the prefix in the random integer, as it allows
+peers to match the selection token and ignore potentially pipelined
+security protocol negotiation messages.
 
 The following schematic illustrates, for the case where A's integer is
 higher than B's integer:
@@ -55,18 +59,30 @@ A ---> B: iamclient
 B ---> A: iamclient
 A: generate random integer IA
 B: generate random integer IB
-A ---> B: {IA}
-B ---> A: {IB}
+A ---> B: select:{IA}
+B ---> A: select:{IB}
 A ---> B: initiator
 B ---> A: responder
 ```
 
 In the unlikely case where both peers selected the same integer, they
-generate a fresh one and enter another round of the protocol.
+generate a fresh one and enter another round of the protocol. If
+multiple rounds of the protocol result in the same integers, this is
+indicative of a bug and both peers should abort the connection.
 
 ## Implementation Considerations
 
 The protocol is simple to implement and is backwards compatible with
-vanilla multistream-select.  In the common case of a single initiator,
-we can ensure that there there is no latency overhead by sending the
-`iamclient` message together with the multistream header.
+vanilla multistream-select. An important consideration is avoiding RTT
+overhead in the common case of a single initiator. In this case, the
+initiator pipelines the security protocol negotiation together with the
+selection, sending `multistream,iamclient,secproto`.  If the receiving
+peer is a responder, then it replies with `multistream,na,secproto`,
+negotiating the security protocol without any overhead.
+
+If the peer is also a client, then it also sends
+`multistream,iamclient,secproto`.  On seeing the `iamclient` message,
+both peers enter the initiator selection protocol and ignore the
+`secproto` in the original packet. They can do so because the random
+integer is prefixed with the `select:` string, allowing peers to match
+the selection and ignore pipelined protocols.