Subject: [lp-wan] Minutes from today's meeting

From: Alexander Pelov <[email-masked]>
Date: Tue, 5 Dec 2017 18:10:20 +0100

Dear all,

You can find the minutes from today’s meeting on the Datatracker: https://datatracker.ietf.org/doc/minutes-interim-2017-lpwan-12-201712051700/

We have our 2 main TODOs: 
- propose default MIC algorithm
- publish SCHC draft and ready for WGLC

Best,
Pascal and Alexander

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Dec 2017 20:13:44 +0100

> - propose default MIC algorithm

Did we discuss requirements/objectives for those?

— implementation footprint (quantify how?)
— CPU consumption
— scalability to different MIC sizes
— hamming distance and other quality criteria (for different MIC sizes)

(Hamming distance is probably not very useful because one of the objectives is to deal with the erasure of an entire pair of windows.)

Grüße, Carsten

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 5 Dec 2017 21:17:20 +0100

Hi Carsten,

> Le 5 déc. 2017 à 20:13, Carsten Bormann <[email-masked]> a écrit :
> 

From what we discussed, it should be lightweight, and mostly for interoperability purposes. Also, should be fully software solution (which *could* have nice HW acceleration on some platforms, but we can’t count on that).

Other than this, ideally it should provide protection equivalent or greater to UDP Checksum.

Not sure about the MIC sizes, but I’d say if we manage to fix one size, that would be best.

Further MIC definition can be specified in the SCHC-over-FOO drafts if necessary. I’d say that it would be nice if we can provide something that is sufficiently good and that works for most use-cases, but that’s a personal view on this.

So, in order of importance on the design goals, from what I got from the discussion is:
- lightweight (code + complexity)
- simple 
- min UDP Checksum-level protection

We will explicitly not consider MICs that require more than 2 weeks to get included in the text (so, nothing that requires a PhD in cryptography)

Any thoughts ?
Alexander

> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 6 Dec 2017 09:47:35 +0100

Hi Carsten,

The goal is to detect frag losses, this is important in no Ack mode or in
the last window. For instance, if the MIC is a sum (like IETF checksum in
UDP) the a fragment loss with only 0 will not be detected. A CRC16 seems
reacting better and is easy to implement.

Laurent

On Tue, Dec 5, 2017 at 9:17 PM, Alexander Pelov <[email-masked]> wrote:

> From what we discussed, it should be lightweight, and mostly for
> interoperability purposes. Also, should be fully software solution (which
> *could* have nice HW acceleration on some platforms, but we can’t count on
> that).
>
> Further MIC definition can be specified in the SCHC-over-FOO drafts if
> necessary. I’d say that it would be nice if we can provide something that
> is sufficiently good and that works for most use-cases, but that’s a
> personal view on this.
>
> We will explicitly not consider MICs that require more than 2 weeks to get
> included in the text (so, nothing that requires a PhD in cryptography)
>
> Any thoughts ?
> Alexander
>
>
> > (Hamming distance is probably not very useful because one of the
> objectives is to deal with the erasure of an entire pair of windows.)
> >
> > Grüße, Carsten
> >