Hi, Hannes, Achim and I are working on the DTLS return routability check (RRC) draft [1].
In the process, we realised that what we were building was heartbeat (RFC6520) just with a different name. If one looks at RFC6520's use cases [2], path MTU discovery and path liveliness are listed already. So we could update the existing RFC with a path validation use case and profile the probing algorithm to support the more subtle threat model that QUIC assumes, which we are reasonably sure we want to do. Enhancing the heartbeat mechanism with a "path validation" sub-protocol for DTLS seems quite logical (to us). This would be incremental work rather than reinventing the wheel. To us, this appears to be an attractive approach. One problem is - as Hannes put it - that heartbeat has a "somewhat tricky history", making its marketing a slightly intricate operation, and the code reuse story a bit more complicated than desired (see for example [3]). So, we are not entirely sure what we should do, and on Chris's suggestion we are bringing this to the group to ask for direction. Thanks in advance for any thought, opinion, ideas you may want to share with us. [1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-rrc [2] https://www.rfc-editor.org/rfc/rfc6520#section-5 [3] https://github.com/openssl/openssl/pull/1928 -- Thomas _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
