RFC 916, "Reliable Asynchronous Transfer Protocol (RATP)", October 1984

Errata ID: 7321
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jules Maselbas
Date Reported: 2023-01-25

Section 5.3 says:

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:

   <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>

This will cause the other end, currently in the SYN-SENT state,
to close.  Flush the retransmission queue, inform the user
"Error: Connection reset", discard the packet, delete the TCB,
and go to the CLOSED state without any further processing.

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:

It should say:

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:

   <SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>

This will cause the other end, currently in the SYN-SENT state,
to close.  Flush the retransmission queue, inform the user
"Error: Connection reset", discard the packet, delete the TCB,
and go to the CLOSED state without any further processing.

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:

Notes:

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:
1. side A is in the CLOSED state and side B is in the LISTEN state;
2. side A open a new connection and send a SYN packet and is received by
side B which enters the SYN_RECEIVED state and send back a SYN-ACK;
3. side A receive the SYN-ACK packet from B;
4. side A respond with 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 changes:
[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:

Report New Errata