Subject: Re: [lp-wan] Proposal: MIC optional, especially for non-UDP traffic

From: ana minaburo <[email-masked]>
Date: Tue, 4 Sep 2018 11:20:12 +0200

Hello,

The SCHC draft talks about compression and fragmentation of IP/UDP packets,
so the solution is giving based on this assumption... the uses we can make
of SCHC need to be defined elsewhere...
I want to remind you that the use of MIC is not only for integrity, we are
using it to compress the UDP checksum, and this is very important for the
IETF compression solution. If MIC is not mandatory and UDP is used you will
send 2 bytes more.

Regards
Ana

On Thu, Jul 19, 2018 at 6:05 PM, Juan Carlos Zuniga <
[email-masked]> wrote:

> (I’m separating the three topics so that we can follow different
> discussion threads.)
>
>
>
>
>
> Hello Sothy,
>
>
>
> Thanks for the feedback. It is good to know that you also see some value
> for this option for NB-IoT.
>
>
>
> Best,
>
>
>
> Juan Carlos
>
>
>
>
>
> *From:* sivasothy shanmugalingam [mailto:[email-masked]]
> *Sent:* July 19, 2018 10:21 AM
> *To:* Juan Carlos Zuniga <[email-masked]>
> *Cc:* [email-masked]; lp-wan <[email-masked]>;
> [email-masked]
> *Subject:* Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call
> for SCHC/IP
>
>
>
>
>
>
>
> On Thu, Jul 19, 2018 at 4:59 AM, Juan Carlos Zuniga <
> [email-masked]> wrote:
>
> Hello all,
>
>
>
> I took a look at the draft on the Fragmentation section and I’m happy to
> see that it is getting in a much better shape!
>
>
>
> However, I believe that there are still some clarifications and nits that
> need to be corrected before submitting it for publication.
>
>
>
> There are three main points that I summarize here under, followed by
> suggested text for the draft:
>
>
>
>    1. The SCHC mechanism could be used for transporting non-UDP/IP
>    packets. In this case, if the integrity of the whole fragmented packet can
>    be guaranteed by L2 means, the use of the MIC in the All-1 fragment could
>    sometimes be avoided. If so, the use of the MIC should be made optional,
>    provided there are sufficient L2 means to guarantee the integrity of all
>    the fragments of a packet.
>
>
>
> Hello all, and Zuniga,
>
>
>
> I agree this point and In NB IOT, data delivery can be use of reliable or
> not reliable. If use reliable delivery, MIC and some mechanism in SCHC
> Fragment is overhead. Therefore, I wish to have  fragment over reliable
> delivery network or fragment over not reliable delivery network.
>
>
>
> Best regards
>
> Sothy
>
>
>

---

From: <[email-masked]>
Date: Tue, 11 Sep 2018 13:20:41 +0000

Dear WG

As a typist for the SCHC draft, I want to move toward a conclusion on this request for the MIC to become optional.
So far, I've heard the following contributions to the discussion

  1.  [Juan Carlos + Sothy] There are layer 2 technologies that can ensure that the fragments have all arrived and were all correct, with a confidence level that is as high as with the SCHC F/R MIC. In these conditions, the mandatory SCHC F/R MIC is overhead.
  2.  [Juan Carlos] The SCHC mechanism could be used for transporting non-UDP/IP packets
  3.  [Pascal] The reality of point 1 is beyond the control of IETF for most Layer2 technologies, and this draft needs to get approval from IESG. Be warned that UDP checksum elision is a sensitive issue at IETF.

Pascal, Juan Carlos, please correct the statements above if I misinterpreted them.

My analysis :

  *   I reckon that generic SCHC could be applied to upper protocols that are less sensitive than UDP and the Layer2 could be deemed as secure as a 2 byte MIC by the L2 experts. Therefore, there could be a benefit for the generic SCHC specification to make the use of SCHC F/R MIC optional.
  *   This draft both defines a generic mechanism and applies it to UDP/IPv6. The fact that we want to have a MIC for UDP elision does not constitute ground for the generic mechanism to mandate the use of the MIC.
  *   Even with the generic SCHC specification relaxed to make MIC optional, the text that currently specifies SCHC's application to UDP (Section 10.11) can stay unchanged. See the current text below. it allows for UDP checksum elision in the situation where fragmentation is used and a 2 byte MIC is present, and leaves the detailed specification to the technology-specific document.

Therefore, I'm proposing to make the MIC optional in the SCHC F/R generic specification.
Can you please voice your opinion?
Thanks

Dominique

===
CURRENT TEXT

   In a similar fashion, this specification allows a SCHC compressor to
   elide the UDP checks when another layer guarantees an identical or
   better integrity protection for the UDP payload and the pseudo-

   header.  In this case, the TV is not set, the MO is set to "ignore"
   and the CDA is set to "compute-checksum".

   In particular, when SCHC fragmentation is used, a fragmentation MIC
   of 2 bytes or more provides equal or better protection than the UDP
   checksum; in that case, if the compressor is collocated with the
   fragmentation point and the decompressor is collocated with the
   packet reassembly point, then compressor MAY elide the UDP checksum.
   Whether and when the UDP Checksum is elided is to be specified in the
   technology-specific documents.

   Since the compression happens before the fragmentation, implementors
   should understand the risks when dealing with unprotected data below
   the transport layer and take special care when manipulating that
   data.

   In other cases, the checksum SHOULD be explicitly sent.  The TV is
   not set, the MO is set to "ignore" and the CDA is set to "value-
   sent".

De : Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Friday 20 July 2018 16:37
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : RE: Proposal: MIC optional, especially for non-UDP traffic

Hello Dominique,

There could be a case where the underlaying L2 technology could provide information about missing frames (e.g. frame counter). This could be used to infer that a fragment has gone missing. That’s what I was trying to say by integrity of all fragments.

Since this is tech-dependant, the proposal is to relax the baseline text and make the use of MIC optional, provided there are L2 means to guarantee both data integrity and reception of all fragments.

Best,

Juan Carlos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: July 20, 2018 10:24 AM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>; sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc: lp-wan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Proposal: MIC optional, especially for non-UDP traffic

Hello all,

As a quick note before the upcoming brainstorming session, I want to re-iterate that the MIC is not just there for data integrity.
Its second purpose is to make sure all the fragments have reached the receiver, which has no other way of knowing, in the current algorithm.
For example, if the last fragment before the All-1 fragment goes missing, there's nothing else that the receiver will notice, than the MIC mismatch.
Removing the MIC would mean adding a confirmation from the sender to the receiver that the bitmap advertised in the SCHC ACK matched the one in the transmitter.
Best regards

Dominique

De : Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Date : Thursday 19 July 2018 12:05
À : sivasothy shanmugalingam <[email-masked]<mailto:[email-masked]>>
Cc : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, lp-wan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Proposal: MIC optional, especially for non-UDP traffic

(I’m separating the three topics so that we can follow different discussion threads.)

Hello Sothy,

Thanks for the feedback. It is good to know that you also see some value for this option for NB-IoT.

Best,

Juan Carlos

From: sivasothy shanmugalingam [mailto:[email-masked]]
Sent: July 19, 2018 10:21 AM
To: Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; lp-wan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call for SCHC/IP

On Thu, Jul 19, 2018 at 4:59 AM, Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

I took a look at the draft on the Fragmentation section and I’m happy to see that it is getting in a much better shape!

However, I believe that there are still some clarifications and nits that need to be corrected before submitting it for publication.

There are three main points that I summarize here under, followed by suggested text for the draft:

  1.  The SCHC mechanism could be used for transporting non-UDP/IP packets. In this case, if the integrity of the whole fragmented packet can be guaranteed by L2 means, the use of the MIC in the All-1 fragment could sometimes be avoided. If so, the use of the MIC should be made optional, provided there are sufficient L2 means to guarantee the integrity of all the fragments of a packet.

Hello all, and Zuniga,

I agree this point and In NB IOT, data delivery can be use of reliable or not reliable. If use reliable delivery, MIC and some mechanism in SCHC Fragment is overhead. Therefore, I wish to have  fragment over reliable delivery network or fragment over not reliable delivery network.

Best regards
Sothy

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 11 Sep 2018 13:46:03 +0000

Hello Dominique,

Thanks for the nice and concise summary.

I agree with your interpretation and I also support the proposal to make it optional.

Best,

Juan Carlos

From: [email-masked] <[email-masked]>
Sent: September 11, 2018 2:21 PM
To: lp-wan <[email-masked]>
Cc: [email-masked]; Juan Carlos Zuniga <[email-masked]>; Pascal Thubert <[email-masked]>
Subject: Re: Proposal: MIC optional, especially for non-UDP traffic

Dear WG

My analysis :

Dominique

===
CURRENT TEXT

   data.

   sent".

Hello Dominique,

Best,

Juan Carlos

Hello all,

Dominique

Hello Sothy,

Best,

Juan Carlos

Hello all, and Zuniga,

Best regards
Sothy

Thank you.

Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Sep 2018 10:22:55 +0000

Works for me, Dominique. Great synthesis!

Regards,

Pascal

Le 11 sept. 2018 à 15:20, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> a écrit :

Dear WG

My analysis :

Dominique

===
CURRENT TEXT

Hello Dominique,

Best,

Juan Carlos

Hello all,

Dominique

Hello Sothy,

Best,

Juan Carlos

Hello all, and Zuniga,

Best regards
Sothy

Thank you.

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Sep 2018 10:16:20 -0400

The L2 integrity check is not end-to-end, especially if there is a bridge in the path.  It seems that this should come out in the text in some way or another.

Regards,
  Russ

On 11 Sept. 2018 at 15:20, Dominique Barthel <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> said:

> [Juan Carlos + Sothy] There are layer 2 technologies that can ensure that the fragments have all arrived and were all correct, with a confidence level that is as high as with the SCHC F/R MIC. In these conditions, the mandatory SCHC F/R MIC is overhead.
> [Juan Carlos] The SCHC mechanism could be used for transporting non-UDP/IP packets
> [Pascal] The reality of point 1 is beyond the control of IETF for most Layer2 technologies, and this draft needs to get approval from IESG. Be warned that UDP checksum elision is a sensitive issue at IETF.
> I reckon that generic SCHC could be applied to upper protocols that are less sensitive than UDP and the Layer2 could be deemed as secure as a 2 byte MIC by the L2 experts. Therefore, there could be a benefit for the generic SCHC specification to make the use of SCHC F/R MIC optional.
> This draft both defines a generic mechanism and applies it to UDP/IPv6. The fact that we want to have a MIC for UDP elision does not constitute ground for the generic mechanism to mandate the use of the MIC.
> Even with the generic SCHC specification relaxed to make MIC optional, the text that currently specifies SCHC's application to UDP (Section 10.11) can stay unchanged. See the current text below. it allows for UDP checksum elision in the situation where fragmentation is used and a 2 byte MIC is present, and leaves the detailed specification to the technology-specific document.
> 
> De : Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>>
> À : Dominique Barthel <[email-masked] <mailto:[email-masked]>>, sivasothy shanmugalingam <[email-masked] <mailto:[email-masked]>>
> Cc : lp-wan <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>>; sivasothy shanmugalingam <[email-masked] <mailto:[email-masked]>>
> Cc: lp-wan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> De : Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>>
> À : sivasothy shanmugalingam <[email-masked] <mailto:[email-masked]>>
> Cc : Dominique Barthel <[email-masked] <mailto:[email-masked]>>, lp-wan <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: sivasothy shanmugalingam [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; lp-wan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Thu, Jul 19, 2018 at 4:59 AM, Juan Carlos Zuniga <[email-masked] <mailto:[email-masked]>> wrote:
> Hello all,
>  
> The SCHC mechanism could be used for transporting non-UDP/IP packets. In this case, if the integrity of the whole fragmented packet can be guaranteed by L2 means, the use of the MIC in the All-1 fragment could sometimes be avoided. If so, the use of the MIC should be made optional, provided there are sufficient L2 means to guarantee the integrity of all the fragments of a packet.
>  
> Hello all, and Zuniga,
>  
_______________________________________________
lp-wan mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>