Re: [lp-wan] Erik Kline's No Objection on draft-ietf-lpwan-schc-over-lorawan-13: (with COMMENT)

[Olivier Gimenez <[e-mail]>]

Hi Erik,



Thank you for your review, your comment raised some discussions during today's lpwan interim:

First thoughts: it cannot be changed because we want to use the same IID on the device and the gateway, but if it is respected we might be less restrictive as long as all implementation include at least the algorithm written in the draft. So I propose the following changes:



In order to mitigate the risks described in [RFC8064] and [RFC8065], implementation MUST implement the following algorithm and SHOULD use it.



   1.  key = LoRaWAN AppSKey



[...]



   out of scope of this document and left to the implementation.



Note: Implementation also using another IID source MUST have same IID value on both device and SCHC gateway.



> -----Original Message-----

> From: Erik Kline via Datatracker <[e-mail]>

> Sent: 03 November 2020 06:26

> To: The IESG <[e-mail]>

> Cc: [e-mail]; [e-mail]; lp-

> [e-mail]; Dominique Barthel <[e-mail]>;

> [e-mail]

> Subject: Erik Kline's No Objection on draft-ietf-lpwan-schc-over-lorawan-13:

> (with COMMENT)

>

> Warning - External Email

> ________________________________

>

> Erik Kline has entered the following ballot position for

> draft-ietf-lpwan-schc-over-lorawan-13: 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 IESG DISCUSS and COMMENT positions.

>

>

> The document, along with other ballot positions, can be found here:

> https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/

>

>

>

> ----------------------------------------------------------------------

> COMMENT:

> ----------------------------------------------------------------------

>

> [[ questions ]]

>

> [ section 5.3 ]

>

> * Is this MUST really necessary?  If an implementation wanted to, say, read

>   8 bytes from a good /dev/urandom source wouldn't that also be okay?  Seems

>   like SHOULD would suffice (with a MUST NOT comment about not just using

>   DevEUI etc).

>

>



To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.