[tcpinc] Simultaneous open tie breaking

[Tero Kivinen <[e-mail]>]

[I changed the subject to make the discussion easier to follow.]

Watson Ladd writes:
> On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres
> <[e-mail]> wrote:
> > No, encryption fails 100% of the time, because the b bit defaults to 0.
> > As currently written, TCP-ENO requires application involvement to enable
> > encryption under simultaneous open.
> 
> Ok, I got confused about what b was doing. I thought it was
> disambiguating and picked randomly.

I do not think the b bit is really going to work, and I agree with
others that we need proper tie-breaker to solve this issue.

On the other hand I do not think we need to add large tie breaker to
the frame, we can most likely use something like very small tie
breaker and sequence numbers for tie-breaker. I.e. whoever has smaller
8-bit (or 6-bit) tie breaker is winner, if the tie breakers are same,
then we compare initial sequence numbers, and whoever has smaller
initial sequence number is the initiator and other end responder.

After that we just need to have rules specifying how we pick up the
protocol from two ordered list. The most simple solution would be to
just say we take initiators list, remove all of the protocols not in
the responders list, and then take first item from initiators list
that is also supported by responder.

I.e. the negotiation would be (with same tie breaker selected randomly
in both ends):

A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y
B->A(0x434945e5) SYN: Tie breaker=33; I can speak X, Y, Z

As tie breaker is same, we will check sequence numbers, and as B has
smaller he is the winner, and both ends know this. Following the rules
above, the protocol to be used is Y.

There are of course some middleboxes who do mess up with sequence
numrbers. To detect this we want to tell the result of the exchange to
both ends:

A->B(0x9453f455) ACK: We are using protocol Y
B->A(0x434945e6) ACK: We are using protocol Y, I am initiator

If both ends claim to be initiator, or neither end claims to be
initiator, both ends will know that immediately when they get receive
ACK, and will know that someone messed up the sequence numbers
(provided they didn't happen to be exactly same initially :-).

In that case we need to do something more complicated, or we could
simply say we drop the connection and try again. This is such rare
happening, that wasting extra round trips is much more preferred to
having more complicated protocol solving the tie (simultaneous opens
are rare, both ends happening to select same 8-bit (or 6-bit or
whatever) tie breaker is not very common, having exactly same initial
sequence number is rare, or even if we have middle box messing up
sequence numbers, there is 50% them being in right order anyways).

On the next try both ends will pick new random tie breaker, and this
time they most likely will not be same, and then the simulatenous open
will succeed (or there might even be timing differences, causing one
of them be bit faster, and one of the ends might receive SYN before it
has time to send his SYN out, in which case this will not be
simultaneous open anymore). 

Also if application will know it will NEVER do simulatenous opens
(like web server, or web client), it can do setsockopt that will
disable the Tie breaker option from the option list, saving byte or
two.

Normal open would be:

A->B(0x9453f454) SYN: Tie breaker=33; I can speak Z, Y
B->A(0x434945e5) SYN-ACK: We are using protocol Y
A->B(0x9453f455) ACK: We are using protocol Y, I am initiator

"We are using protocol Y" could also include the initial key exchange
messages for protocol Y, if they fit in option space.
-- 
[e-mail]