Re: [Lake] Zaheduzzaman Sarker's No Objection on draft-ietf-lake-edhoc-20: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

Hi Göran,

I have left my suggestion as a comment in the github PR.

//Zahed

On Fri, Aug 25, 2023 at 10:12 AM Göran Selander <[e-mail]>
wrote:

> Hi Zahed, and all,
>
>
>
> We made a small PR on top of -21 clarifying the preference for reliable
> transport:
>
> https://github.com/lake-wg/edhoc/pull/434/files
>
>
>
> Please let us know if this change is preferred and if there is anything
> missing.
>
>
>
> Thanks,
>
> Göran
>
>
>
>
>
>
>
> *From: *Göran Selander <[e-mail]>
> *Date: *Thursday, 24 August 2023 at 13:08
> *To: *Zaheduzzaman Sarker <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: Zaheduzzaman Sarker's No Objection on
> draft-ietf-lake-edhoc-20: (with COMMENT)
>
> Hi Zahed, and all,
>
>
>
> Thanks for quick response. Inline.
>
>
>
> *From: *Zaheduzzaman Sarker <[e-mail]>
> *Date: *Thursday, 24 August 2023 at 10:59
>
>
>    - I also like section 3.4, however, it is not clear to me if the list
>    provided, is a "must to meet" criteria for any transport or fulfilling
> any
>    subset of features is good enough. If the later then this specification
>    should describe how the missing criteria should be fulfilled or ignore
> or
>    describe the impact.
>
> [GS] The security protocol does not depend on any of the transport
> criteria listed in section 3.4. The consequence of the transport producing
> something else than the next message according to protocol state is that
> the session will be aborted.
>
> OK.
>
>
>
> The application decides on transport to use and which criteria in the list
> to fulfil, and thereby what risks it is prepared to take for potential
> termination of the protocol due to shortcomings of the transport.
>
> This is however, still not clear in the text in 3.4. Lets say, for some
> reasons the application just opens up an UDP socket to send the EDHOC
> messages, in that case the transport protocol would not be able to provide
> those listed as expect in the specification - "In order to avoid
> unnecessary message processing or protocol termination, the transport is
> responsible to handle", so either the application take cares of all the
> transport responsibilities or does not select UDP, but there is nothing in
> the specification that prohibits the application to pick UDP in the socket.
> This is to me is not a good situation and need clarification. (As I wrote
> in the my previous comment, the specification seems to prefer reliable
> transport and may be that should be default ask).
>
>
>
> [GS] I’m open for guidance here (from IESG, LAKE WG/chairs,  or others).
>
>
>
> Section 3.4 in #429 is intended to explain (may be improved!) that
>
> ·         if you just run UDP then your EDHOC session may be aborted,
> because the message received is not always the expected next message
> according to protocol state.
>
> ·         If you add CoAP in reliable mode it should work just fine.
>
> ·         If you don’t use CoAP then you need to use something else that
> handles the listed transport properties or risk the session unnecessarily
> being aborted.
>
>
>
> In A.2 we recommend using CoAP in reliable mode. We could make that
> recommendation more general. Not sure how to best do that in the context of
> the existing list.
>
>
>
> Is your view of the problem with the current text that people may get
> wrong expectations, or that we allow settings where the EDHOC session
> sometimes doesn’t complete due to limitations in the transport?
>
>
>
> Thanks,
>
> Göran
>
>
>