This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages.
The extension type is specified as follows.
The extension_data field of this extension, when included in the ClientHello, MUST
contain the ConnectionId structure. This structure contains the CID value the client wishes the server to use when sending messages to the client. A zero-length CID value indicates that the client is prepared to send using a CID but does not wish the server to use one when sending.
A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it. A zero-length value indicates that the server will send using the client's CID but does not wish the client to include a CID when sending.
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a deployment-specific constant length for such connection identifiers. This can in turn ease parsing and connection lookup -- for example, by having the length in question be a compile-time constant. Such implementations MUST
still be able to send CIDs of different lengths to other parties. Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.
In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only. There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes. When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh.
If DTLS peers have not negotiated the use of CIDs, or a zero-length CID has been advertised for a given direction, then the record format and content type defined in RFC 6347 MUST
be used to send in the indicated direction(s).
If DTLS peers have negotiated the use of a non-zero-length CID for a given direction, then once encryption is enabled, they MUST
send with the record format defined in Figure 3
(see Section 4
) with the new Message Authentication Code (MAC) computation defined in Section 5
and the content type tls12_cid. Plaintext payloads never use the new record format or the CID content type.
When receiving, if the tls12_cid content type is set, then the CID is used to look up the connection and the security association. If the tls12_cid content type is not set, then the connection and the security association are looked up by the 5-tuple and a check MUST
be made to determine whether a non-zero-length CID is expected. If a non-zero-length CID is expected for the retrieved association, then the datagram MUST
be treated as invalid, as described in Section 126.96.36.199
of RFC 6347
When receiving a datagram with the tls12_cid content type, the new MAC computation defined in Section 5 MUST
be used. When receiving a datagram with the record format defined in RFC 6347
, the MAC calculation defined in Section 4.1.2
of RFC 6347 MUST