Subject: [lp-wan] proposed text for the UDP checksum compression

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Jun 2018 13:18:15 +0000

Dear all:

I has an action point to propose text on when UDP checksum can be elided with SCHC. Here is  proposal:

  The UDP checksum operation is mandatory with IPv6 [RFC8200<https://tools.ietf.org/html/rfc8200>] for most

   Packets but recognizes that there are exceptions to that default

   Behavior.

   For instance, protocols that use UDP as a tunnel encapsulation may

   Enable zero-checksum mode for a specific port (or set of ports) for

   sending and/or receiving. [RFC8200<https://tools.ietf.org/html/rfc8200>] also stipulates that any node

   implementing zero-checksum mode must follow the requirements specified

   in "Applicability Statement for the Use of IPv6 UDP Datagrams with

   Zero Checksums" [RFC6936<https://tools.ietf.org/html/rfc6936>].

   6LoWPAN Header Compression [RFC6282<https://tools.ietf.org/html/rfc6282>] also authorizes to send UDP

   datagram that are deprived of the checksum protection when an upper

   layer guarantees the integrity of the UDP payload and pseudo-header

   all the way between the compressor that elides the UDP checksum and

   the decompressor that computes again it. A specific example of this is

   when a Message Integrity Check (MIC) protects the compressed message

   all along that path with a strength that is identical or better to

   the UDP checksum.

   In a similar fashion, this specification allows a SCHC compressor to

   elide the UDP checks when another layer guarantees a an identical or

   better integrity protection for the UDP payload and pseudo-header. In

   particular, when SCHC fragmentation is used, a fragmentation MIC of

   2 bytes or more provides equal or better protection that UDP checksum;

   In that case, if the decompressor is collocated with the fragment

   reassembly point, then compressor MAY elide the UDP checksum.

Comments welcome !

Pascal

---

From: ana minaburo <[email-masked]>
Date: Tue, 5 Jun 2018 10:30:04 +0200

Hello Pascal

Thanks for this input, it completes what we have already

I have some comments and questions

1. Where in the draft can we add the text? As it is today, the section 7.2
Fragmentation Tools is the based

In the draft-13, there are 3 sections where the UDP Checksum is treated:

In section 6.5.6 Compute-checksum. In SCHC C/D how to manage the
compression of the UDP checksum
In section 7.2 Fragmentation Tools. In the MIC part, the MIC will enable
the compression of UDP checksum, which means that when the fragmentation is
not used the UDP Checksum must not be compressed
In section 9.11 UDP Checksum field. Gives the way to compress the UDP
Checksum field, and has a link to section 7 for more details...

I suggest creating a section after padding a section for UDP Checksum or
used the MIC part of section 7.2

2. Are we defining the correct solution for the option to the specific
technologies? Doesn't the length need to be at least as long as the UDP
Checksum as you define in your text?
 In the MIC section, we say 'Nevertheless, other algorithms
      MAY be required and are defined in the technology-specific
      documents, as well as the length in bits of the MIC used.'

Thanks
Ana

On Fri, Jun 1, 2018 at 3:18 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>   The UDP checksum operation is mandatory with IPv6 [RFC8200 <https://tools.ietf.org/html/rfc8200>] for most
>
>    sending and/or receiving. [RFC8200 <https://tools.ietf.org/html/rfc8200>] also stipulates that any node
>
>    Zero Checksums" [RFC6936 <https://tools.ietf.org/html/rfc6936>].
>
>
>
>    6LoWPAN Header Compression [RFC6282 <https://tools.ietf..org/html/rfc6282>] also authorizes to send UDP
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: <[email-masked]>
Date: Tue, 5 Jun 2018 13:48:15 +0000

Helo Pascal, Ana,

Indeed, I think the generic SCHC draft should define a CDA that elides the UDP checksum but should defer to the technology document to allow its use (based on the strength of MIC).
Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 5 June 2018 10:30
À : Pascal Thubert <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] proposed text for the UDP checksum compression

Hello Pascal

1. Where in the draft can we add the text? As it is today, the section 7.2 Fragmentation Tools is the based

In section 6.5.6 Compute-checksum. In SCHC C/D how to manage the compression of the UDP checksum
In section 7.2 Fragmentation Tools. In the MIC part, the MIC will enable the compression of UDP checksum, which means that when the fragmentation is not used the UDP Checksum must not be compressed
In section 9.11 UDP Checksum field. Gives the way to compress the UDP Checksum field, and has a link to section 7 for more details...

I suggest creating a section after padding a section for UDP Checksum or used the MIC part of section 7.2

2. Are we defining the correct solution for the option to the specific technologies? Doesn't the length need to be at least as long as the UDP Checksum as you define in your text?
 In the MIC section, we say 'Nevertheless, other algorithms
      MAY be required and are defined in the technology-specific
      documents, as well as the length in bits of the MIC used.'

Thanks
Ana

On Fri, Jun 1, 2018 at 3:18 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

 Dear all:

   Behavior.

   6LoWPAN Header Compression [RFC6282<https://tools.ietf...org/html/rfc6282>] also authorizes to send UDP

   the UDP checksum.

Comments welcome !

Pascal

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

_________________________________________________________________________________________________________________________

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Jun 2018 17:55:46 +0000

Hello Ana and Dominique

I agree with both of you. Also there’s text missing to be on par with rfc 6282; I wanted to know if the text was ok so far.

So yes we need a section that the other places that Ana indicated will point to.

Also I’d remove the “must not “ quoted below since the rules on whether the UDP checksum can be elided will be in the new section.

I’ll propose text tomorrow, in a plane right now...

Take care

Pascal

Le 5 juin 2018 à 15:48, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> a écrit :

Helo Pascal, Ana,

Dominique

Hello Pascal

Thanks
Ana

 Dear all:

   Behavior.

   the UDP checksum.

Comments welcome !

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Jun 2018 12:13:39 +0000

Dear all:

Please find an update of the text after our discussions:

   Behavior.

   the UDP checksum.

   elide the UDP checks when another layer guarantees an identical or

   better integrity protection for the UDP payload and the pseudo-header.

   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 not manipulating that data.

Take care,

Pascal

From: Pascal Thubert (pthubert)
Sent: mardi 5 juin 2018 19:56
To: [email-masked]
Cc: ana minaburo <[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] proposed text for the UDP checksum compression

Hello Ana and Dominique

Take care

Pascal

Dominique

Hello Pascal

Thanks
Ana

 Dear all:

   Behavior.

   the UDP checksum.

Comments welcome !

Pascal

Thank you.