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

[Erik Kline <[e-mail]>]

I don't know enough about the lorawan/lpwan architecture to feel
strongly one way or the other.  FWIW, this text looks fine to me (and
my comment was not a Discuss point).

I just often feel that these "here's how you have to do things"
algorithm recommendations work fine up until they don't (for whatever
reason).  And at that point it's important for implementers to
understand the core requirements so they can (re)derive an
implementation strategy that meets those requirements rather than try
to stick to one implementation approach.  And the core requirement for
address privacy AIUI is non-guessability and to my mind "use a good
PRNG" works and might be simpler.

But I see here that the key changes on re-join and thus the generated
address will change, and so that makes sense.  But if the network
gateway is relying on this address formation trick rather than
learning the address the node has chosen for itself, that would be a
very different architectural problem IMHO.

On Tue, Nov 3, 2020 at 10:05 AM Olivier Gimenez <[e-mail]> wrote:
>
> 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.