Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The DTLS handshake phase involves the establishment of a secure connection between the RDG client and the RDG server. After all the data packets have been transmitted during the handshake, the RDG client and RDG server transition into the connection setup phase (section 1.3.3.1.2). Implementation details about the DTLS handshake and retransmission of packets during the handshake are specified in [RFC4347] section 3.2.
The DTLS handshake phase consists of two operations:
The RDG client sends the first packet in a reliable manner: the first packet is retransmitted for a pre-determined number of times until the packet is received from the RDG server. If the first packet is not received from the RDG server after the pre-determined number of attempts, the result of the connection establishment to the UDP channel is marked as a failure.
The remainder of the DTLS handshake is performed in a non-reliable manner: any packet lost on the network is considered to be lost and no attempt is made to retransmit the lost packet. In this case, the RDG client and the RDG server are required to handle packets lost during the handshake and retransmit as necessary.
Figure 9: Message sequence between RDG client and RDG server during DTLS handshake phase
An optional UDP_CORRELATION_INFO structure (section 2.2.11.9) can be appended to the ClientHello request and included in the initial client-to-RDG packet. This structure contains a correlation identifier GUID, containing the same GUID value as described in the custom HTTP header RDG-Correlation-Id (section 2.2.3.2.2.) This structure extends the initial RFC4347 packet's size, but is not included in the DTLS verify_data calculations.