Hello Éric, > This specification addresses the IPv4-mainly issue of NAT binding and is still required.
Yes, that is the main initial trigger. It helps also for peers, which use only temporary assigned IP-addresses which may change (e.g during a power-saving-sleep-wake-up cycle in some CAT-NB solutions). And there are also some advanced use-cases, e.g. CID based load-balancer. For your other points, Thomas created an issue on github (https://github.com/tlswg/dtls-conn-id/issues/103). I left some comments there. best regards Achim Kraus Am 19.04.21 um 09:47 schrieb Éric Vyncke via Datatracker:
Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
