Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Achim Kraus <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>