Draft of an errata for RFC916

[Jules Maselbas]

Hi, 

Here is a revised version of my previous mail, I might propose this
as an errata for RFC916, any comments and insights would be greatly
appreciated.


Side A                                             Side B
1. CLOSED                                          LISTEN
2. [OPEN request]
   SYN_SENT    -->  <SN=0><CTL=SYN>            --> SYN_RECEIVED
3. ESTABLISHED <--  <SN=0><AN=1><CTL=SYN,ACK>  <--
4.             -->  <SN=1><AN=0><CTL=ACK>      ...
5.             ...  <SN=0><AN=1><CTL=SYN,ACK>  <-- (retransmit)
6. (packet sent by A at 4. finally arrives to B)
               ...                             --> ESTABLISHED
7. (packet resent by B at 5. finally arrives to A)
   CLOSED (C2) <--                             ...
8.             -->  <SN=1><AN=1><CTL=RST>      --> (connection reset)

The Figure above illustrate the current issue RATP can face during the
three-way handshake, and how behavior C2 can cause a connection to be
closed immediately after being established.

In the Figure above, side A try to establish a connection with side B,
which is in the LISTEN state.  Commented line:
 4. side A receive the SYN-ACK packet from B and respond an ACK packet
    and move to the ESTABLISHED state.  Meanwhile;
 5. side B hasn't received yet the ACK from side A and decide to
    retransmit the SYN-ACK packet;
 6. side B finally receive the ACK from side A and move to the
    ESTABLISHED state;
 7. side A finally receive the duplicated SYN-ACK packet from side B,
    execute behavior C2: the received packet doesn't have the expected
    SN and has the SYN flag set, thus respond by sending a legal reset.
 8. side B receive the reset and close the connection.

One solution could be to tweak the initial RTO value of side B in order
to prevent sending a duplicated SYN-ACK packet, however the initial RTT
value is likely inaccurate during the handshake.  This solution seems a
bit brittle.

The second solution would be to consider that a host has crashed only if
the packet received has the SYN flag set but not the ACK flag.  The
rational is that the first step during handshake is to send a packet
only containing the SYN flag, however a packet containing both ACK and
SYN flags must have come after the initial handshake exchange and can
be considered as a duplicated and be dropped.

I propose the following errata to the RFC916:
[Page 29]
- If SYN was set we assume that the other end crashed and has
- attempted to open a new connection.  We respond by sending a
- legal reset:
+ If the SYN flag was set but the ACK was not set then we assume
+ that the other end crashed and has attempted to open a new connection.
+ We respond by sending a legal reset:

[Page 30]
- If neither RST, FIN, nor SYN flags were set it is assumed that
- this packet is a duplicate of one already received.  Send an
- ACK back:
+ If neither RST nor FIN flags were set, or if SYN and ACK flags
+ were set, it is assumed that this packet is a duplicate of one
+ already received.  Send an ACK back:

Thanks
-- Jules