Subject: [lp-wan] review of draft-ietf-lpwan-coap-static-context-hc-04

From: Francesca Palombini <[email-masked]>
Date: Thu, 19 Jul 2018 16:01:40 +0000

Hi authors,

As I mentioned during the f2f in Montreal, I read this draft, with particular emphasis on OSCORE, and have a couple of comments for you.

  *   It would be useful in the OSCORE Examples (section 7.4) to actually show the inner compression. I.e. it would be good to have the "middle step" of the inner compression before the second compression is done, in Figure 14 and 15.

  *   It seems clear that if OSCORE is used, one needs to have 2 sets of rules: one for the inner part, one for the outer part. If that's the case, it would be good to have that explicitly stated in the doc.

  *   In the Examples (Sec 7.4) the CoAP OSCORE_ctxt field is not in the rules. I think that all the OSCORE fields should all be in the rules if OSCORE is used, even though the rule for them is "this field is equal to 0 bytes/not sent". If that's correct, it would be good to have that explicitly stated in the doc. BUT this might be a misunderstanding from my part (in which case, please clarify).

  *   The CoAP OSCORE_piv is defined to also include all the flag bits; this is not a problem, but just a bit confusing; I would suggest adding an additional field for the flag byte.

  *   Using the compression for the Partial IV parameter actually reduces the number of "usable sequence numbers" that can be used. What happens when these reduce number finish? (In OSCORE, this field is max 5 bytes long) I think the draft should at least mention this, as well as maybe suggest what to do if there is no more seq numbers available: update the OSCORE context and the SCHC context?

  *   Note that compressing the OSCORE flag byte means part of it is fixed. This is the same as making an assumption that some CoAP options are never used, since this flag byte is dependent on some options... I think this is not a problem because if decompression succeeds, and if the options and flag bytes don't match, the message will still fail on OSCORE layer. However, I think a note about this would be useful (for example a very drafty draft: "if you compress the flag byte, you need to be aware that this might prevent you from using certain options, such as Observe".

I hope this is useful! Let me know if anything was not clear.
Francesca

---

From: Göran Selander <[email-masked]>
Date: Thu, 19 Jul 2018 20:46:29 +0000

Hi,

Adding a few additional comments:

- As I mentioned in the meeting today: “Ciphertext” is used in OSCORE as defined in RFC 5116, which is the single output from the AEAD, i.e. also contains the authentication tag, which   obviously cannot be compressed. As far as I understand this is not accounted for in the current draft.

- Section 7.3: "In the Outer Header, the original message code is hidden
   and replaced by a default value (POST or FETCH) depending on whether
   the original message was a Request or a Response.”

The Outer Code FETCH is used if and only if the original CoAP message is a GET request with the Observe option. The Outer Code for responses are determined by the Outer Code of the requests, see section 4.1.3.5 of OSCORE.

- If the Outer SCHC compression is used with an intermediary performing operations on the CoAP message, e.g. a CoAP forward proxy, then the intermediary needs to implement the compression. This may be obvious but may be worth mentioning in the draft.

- The draft would not suffer from more details in the OSCORE example. The slides have more such details that are useful for understanding the details.

- Do a spellcheck (“Intergrity”, “Enrypted”, “mesages”, . . .)

Again, thanks for interesting work!

Göran

From: Francesca Palombini <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 July 2018 at 12:01
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: review of draft-ietf-lpwan-coap-static-context-hc-04
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Göran Selander <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>, Francesca Palombini <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, 19 July 2018 at 12:01

Hi authors,

  *   It would be useful in the OSCORE Examples (section 7.4) to actually show the inner compression. I.e. it would be good to have the “middle step” of the inner compression before the second compression is done, in Figure 14 and 15.

  *   It seems clear that if OSCORE is used, one needs to have 2 sets of rules: one for the inner part, one for the outer part. If that’s the case, it would be good to have that explicitly stated in the doc.

  *   In the Examples (Sec 7.4) the CoAP OSCORE_ctxt field is not in the rules. I think that all the OSCORE fields should all be in the rules if OSCORE is used, even though the rule for them is “this field is equal to 0 bytes/not sent”. If that’s correct, it would be good to have that explicitly stated in the doc. BUT this might be a misunderstanding from my part (in which case, please clarify).

  *   Note that compressing the OSCORE flag byte means part of it is fixed. This is the same as making an assumption that some CoAP options are never used, since this flag byte is dependent on some options... I think this is not a problem because if decompression succeeds, and if the options and flag bytes don’t match, the message will still fail on OSCORE layer. However, I think a note about this would be useful (for example a very drafty draft: “if you compress the flag byte, you need to be aware that this might prevent you from using certain options, such as Observe”.