Optimise three-way handshake condition for S_PRE_START to S_START

Optimise three-way handshake condition for S_PRE_START to S_START

We move to the S_START when we have finished the three-way handshake. After
the three way handshake is done, the client will send the TLS Client Hello
packet.

Currently we consider the three way handshake only complete if all
outgoing packets have been acked (which in this case is the one
HARD_RESET_CLIENT or HARD_RESET_SERVER) and also all ACKs for incoming
packets have been sent out.

Waiting for the ack of our own packet is important as it signals that the
other side is really responding. However, the need to also send out all
ACKs for packets we received before moving to the next state breaks
piggybacking the ACKs onto the next control packet.

With this change both server and client will only send a P_CONTROL_V1 with
the TLS Client Hello and the TLS Server Hello with piggybacked ack instead
sending an P_ACK_V1 + P_CONTROL_V1, reducing the number of packets in a
handshake by 2.

This also allows the server to avoid resending P_CONTROL_HARD_RESET_V2
to complete the three-way handshake with HMAC. Only packets with
an ACK contain the remote session id that we need for HMAC session id
verification. The ACK_V1 packet that complets this three-way handshake
can get lost. But the P_CONTROL_V1 with the piggybacked ACK will get
retransmitted. This allows to put the burden of retransmission fully on
the client.

The S_GOT_KEY/S_SENT_KEY -> S_ACTIVE is similar. We do not need to wait
for the ack packet to be sent to move the state forward. This has however
no effect on actual packets since there are normally no outstanding ACKs
here.

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Message-Id: <20220422142953.3805364-14-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg24161.html

Signed-off-by: Gert Doering <gert@greenie.muc.de>