Subject: [lp-wan] Make MIC optional again

From: <[email-masked]>
Date: Thu, 22 Nov 2018 15:23:22 +0000

Hello all,

There have been requests before the IETF102 meeting to make the SCHC Fragmentation MIC optional.
This has been discussed at the IETF102 meeting.
Pascal reminded us that talking about eliding the UDP checksum and making the MIC optional in the same document  is likely to be a hurdle during the IESG processing.
SCHC draft –17 still mandates the MIC, but all the work behind the scene has been done to make optional MIC possible. We believe it technically works.
The requests for optional MIC are still voiced.
At the IETF103 LPWAN meeting, this topic was discussed again, and Suresh (as the Area Director) told us not ta anticipate a fight at IESG regarding optional MIC, as long as we clearly document the issue and the solution.
As a consequence, I have re-opened Ticket 32<https://trac.ietf.org/trac/lpwan/ticket/32> "make SCHC F/R MIC optional?".
If you care about this discussion, please read the Ticket and comment, preferably by posting your comment directly into the the Ticket (this requires a login into the IETF wiki) and by posting to this mailing list.
Thanks

Dominique

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: ana minaburo <[email-masked]>
Date: Fri, 23 Nov 2018 11:21:18 +0100

Hello Dominique, (I copy this message to the ticket history)

Thanks for opening again this hot topic that makes the discussion going in
circles, maybe because we'are unclear... I'll try to explain my concerns in
a different way, respond to some of your points below,  and then go silent
for a while to let others chime in.

Historically the consensus was done during the IPv6 definition some years
ago. At that time,  the IP checksum has been elided from the IPv6 header to
lean on the UDP checksum which became mandatory because there was a
redundancy and so it was possible to eliminate the IPv6 checksum.

The primary difference that triggered this is that whereas IPv4 has a
header checksum, IPv6 does not, and there have been anecdotal reports of
checksum errors being found in IPv4 packets in the wild. The IPv6
designers, mid-1990s, felt that not having a checksum AT ALL left room for
concern, and leaving it to the application was too lose a rule.

I think we all agree on the need to have a checksum somewhere to protect
against misdelivery to an application and data corruption.

>From my perspective, trying to say that there is no risk with removing the
UDP checksum even for a limited context is like trying to prove a negative.
I'm certain that some environments have very low corruption rates, but
there might be other environments for IPv6 where it is much higher, who
knows?

About SCHC, we need to add as you said that when there is no fragmentation
the compression of UDP checksum is not possible.

Having a robust protocol deployed widely is very important.

Ana

On Thu, Nov 22, 2018 at 4:23 PM <[email-masked]> wrote:

> Pascal reminded us that talking about eliding the UDP checksum and making
> the MIC optional in the same document  is likely to be a hurdle during the
> IESG processing.
> SCHC draft –17 still mandates the MIC, but all the work behind the scene
> has been done to make optional MIC possible. We believe it technically
> works.
> At the IETF103 LPWAN meeting, this topic was discussed again, and Suresh
> (as the Area Director) told us not ta anticipate a fight at IESG regarding
> optional MIC, as long as we clearly document the issue and the solution.
> As a consequence, I have re-opened Ticket 32
> <https://trac.ietf.org/trac/lpwan/ticket/32> "make SCHC F/R MIC
> optional?".
> If you care about this discussion, please read the Ticket and comment,
> preferably by posting your comment directly into the the Ticket (this
> requires a login into the IETF wiki) and by posting to this mailing list.
> Thanks
>
> Dominique
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 26 Nov 2018 15:49:25 +0000

Hello Dominique, Ana,

(copying the message to the Ticket as well)

Thanks Dominique for documenting the issue and thanks Ana for raising your concerns.
I read several important points here, which I think we must dissect to better address the problem:

1- UDP checksum elision - For historical and performance reasons, seems like there is a need to support or even mandate the use of MIC when UDP elision is applied. I think this makes sense to provide a robust protocol supporting UDP compression and fragmentation. There are also some non-deterministic cases (like the one described above by Dominique about UDP compression and fragmentation) which could be simplified if we knew that MIC was going to be used for sure. In this case, we should clearly state the rules for UDP checksum elision - meaning that can only be done if Fragmentation + MIC will be used after compression.

2- MIC optional - Since the fragmentation protocol is independent of the compression part, and it is robust enough to be used for non-UDP traffic, having the MIC optional in the fragmentation section would allow making a more efficient use of the fragmentation functionality. One example could be to use fragmentation for technology-specific control messages that cannot fit in one transmission - These messages will not go in the wild Internet (as they are not IPv6 or UDP packets) so they would not cause issues like the one mentioned above by Ana. On the other hand, saving MIC overhead can help transmitting the control information in fewer fragments and therefore communicate more rapidly on this (potentially) critical info.

Given these different arguments, I support the proposal of always using a MIC for fragmenting UDP/IPv6 traffic, and leaving it optional to the different technologies for fragmenting non-UDP/IPv6 traffic. In that sense, one possible solution could be to follow Dominique's suggestion that "SCHC Packets containing an elided UDP checksum must always be fragmented, even if they fit in one L2 PDU." Alternatively, we can say “UDP checksum elision can only be applied if Fragmentation and MIC will be used after SCHC header compression.”

Juan Carlos

From: lp-wan <[email-masked]> On Behalf Of ana minaburo
Sent: November 23, 2018 5:21 AM
To: BARTHEL Dominique IMT/OLPS <[email-masked]>
Cc: lp-wan <[email-masked]>
Subject: Re: [lp-wan] Make MIC optional again

Thanks for opening again this hot topic that makes the discussion going in circles, maybe because we'are unclear.... I'll try to explain my concerns in a different way, respond to some of your points below,  and then go silent for a while to let others chime in.

Historically the consensus was done during the IPv6 definition some years ago. At that time,  the IP checksum has been elided from the IPv6 header to lean on the UDP checksum which became mandatory because there was a redundancy and so it was possible to eliminate the IPv6 checksum.

The primary difference that triggered this is that whereas IPv4 has a header checksum, IPv6 does not, and there have been anecdotal reports of checksum errors being found in IPv4 packets in the wild. The IPv6 designers, mid-1990s, felt that not having a checksum AT ALL left room for concern, and leaving it to the application was too lose a rule.

I think we all agree on the need to have a checksum somewhere to protect against misdelivery to an application and data corruption.

From my perspective, trying to say that there is no risk with removing the UDP checksum even for a limited context is like trying to prove a negative. I'm certain that some environments have very low corruption rates, but there might be other environments for IPv6 where it is much higher, who knows?

About SCHC, we need to add as you said that when there is no fragmentation the compression of UDP checksum is not possible.

Ana

On Thu, Nov 22, 2018 at 4:23 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

Dominique

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