Re: [lp-wan] SCHC over LoRaWAN - IID algorithm

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Olivier




“

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

I agree with the intention. Now; this formulation could be read as “the GW and the device have the same IID” while you mean that “the GW and the device must obtain the same value as IID of the device”.

Keep safe;

Pascal

From: lp-wan <[e-mail]> On Behalf Of Olivier Gimenez
Sent: mardi 24 novembre 2020 15:21
To: [e-mail]
Subject: [lp-wan] SCHC over LoRaWAN - IID algorithm

Hello working group,

I did not got any feedback on the following proposition related to the IID computation algorithm, which is currently mandatory to implement and to use, and we want some implementations to be able to use something else if they need. Any thoughts ?

Thank you
Olivier

From: Olivier Gimenez
Sent: 03 November 2020 19:05
To: 'Erik Kline' <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Subject: RE: Erik Kline's No Objection on draft-ietf-lpwan-schc-over-lorawan-13: (with COMMENT)


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]<mailto:[e-mail]>>

> Sent: 03 November 2020 06:26

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

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

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

> [e-mail]<mailto:[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<http://www.semtech.com/legal>.