Hi Éric, Thank you very much for your review, there's now a ticket to track it here:
https://github.com/tlswg/dtls-conn-id/issues/103 Re: > -- 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 ? No, it means that we delegate the application using DTLS to do the Validation (*). Specifically, the DTLS API on the receiver must be able to: (1) forward the "peer address update" signal to the application so that it can carry out validation of the new address using some minimal application traffic exchange (e.g., CoAP has the Echo option for that purpose); (2) update the new address if requested by the application - in case the action triggered by (1) is successful in confirming that the new address is effectively the known peer. This should be already captured in the penultimate paragraph of Section 6. If that is not the case, could you suggest text to improve it? Cheers, thanks! (*) Note that an in-protocol solution [1] has been proposed but it is not (yet) adopted. [1] https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-01 On 19/04/2021, 08:48, "Éric Vyncke via Datatracker" <[email protected]> wrote: > > É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. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
