Hi Kristijan, searching through the mailing list I found this mail. So, sorry for the late response.
The CID design in DTLS 1.3 has not been focused on multi-homing use cases. It was not a design goal; you have to design on an extension in the style of what is currently happening with QUIC or what was previously done with MOBIKE. Ciao Hannes From: TLS <tls-boun...@ietf.org> On Behalf Of Kristijan Sedlak Sent: Sunday, December 10, 2023 11:50 AM To: <tls@ietf.org> <tls@ietf.org> Subject: [TLS] [rfc9147] Clarification on DTLS 1.3 CID Retirement and Usage Dear IETF TLS Working Group, I am reaching out to seek clarification on specific aspects of Connection ID (CID) management in DTLS 1.3, as detailed in RFC 9147. The current specification delineates the process for issuing new CIDs via a NewConnectionId message. However, the methodology for retiring old CIDs seems subject to various interpretations. Is it correct to assume that an endpoint dictates the number of active CIDs it manages and that CIDs should be utilized in the sequence they are provided? For example, if the initial negotiated CID is 0 and an endpoint subsequently issues NewConnectionId with CIDs 1, 2, and 3, my interpretation is that upon receiving the first datagram from a new path (which is also applicable for an existing path), the records should ideally be tagged with the next CID (1, 2, or 3) rather than CID 0. This approach suggests that upon the reception of a higher CID, lower CIDs should be considered retired and later removed. This understanding implies that CIDs in DTLS 1.3 are not designed for multipath operations, and it is anticipated that only one path (one CID) would be active at a given time. Could you please confirm if this interpretation is in alignment with the intended specifications, or offer additional insights into the appropriate management of CIDs in DTLS 1.3? Including such clarification in the RFC would be invaluable in mitigating potential confusion. Thank you. Kristijan
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
