[TLS] SCHC header compression

[<[e-mail]>]

Hello Hannes, all,

I'm a co-author of the SCHC draft (https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/), which has passed IESG review.

I may be unfortunate that the draft contains 3 distinct deliverables in one document

- a generic header compression mechanism, which uses a static context for compression (Static Context Header Compression = SCHC) (Section 7)

- a fragmentation protocol, which comes in 3 flavors, some of which have ack/retransmissions built-in. (Section 8)

- an application of the compression mechanism to compress UDP+IPv6 headers (Section 10)

This situation may lead to the conclusion that the header compression and fragmentation work together, or that SCHC only applies to UDP+IPv6 headers.

The truth is different.

The draft clearly states that fragmentation is optional: "If needed by the underlying layer, the optional SCHC Fragmentation MAY be applied to the SCHC Packet."

Typically, some lower layers already have a fragmentation mechanism (e.g. NB-IoT), and don't need another one.

As another data point, we have a demo showing the benefits of compressing CoAP headers, over a natively-IP network (LTE-m). We only use the generic compression mechanism of the above-mentioned draft, and we only use it to compress the CoAP headers.

We believe that other protocols could benefit from the generic header compression framework established by SCHC and could save design time and code size by instantiating a set of SCHC compression rules for their own headers.

If you are interested, we'd be happy to tell you a bit more about SCHC, either at an upcoming IETF meeting or during a dedicated conf call.

Best regards,


Dominique

> Hi Hannes,
>
> My reading is that only compression/decompression applies to our case.
> Fragmentation is optional and only concerns ipv6. I did not intent to make
> the comment at an inappropriate time, but if so, please consider it when it
> is appropriate.
>
> Yours,
> Daniel
>
> On Thu, Nov 21, 2019 at 10:34 PM <[e-mail]><mailto:[e-mail]&gt>; wrote:
>
> Hi Daniel
>
>
>
> Although inappropriate to discuss at the time of the adoption call I
> wanted to point out that I looked at SCHC and was surprised to learn that
> it is more than a compression scheme but also includes a protocol for
> adding reliability. In my reading is essentially a replacement for 6lowpan.
> Unfortunately, this design decision does not make it a well suited
> mechanism for a generic compression mechanism. I am happy to get convinced
> otherwise.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS <[e-mail]><mailto:[e-mail]&gt>; *On Behalf Of *Daniel Migault
> *Sent:* Friday, November 22, 2019 10:20 AM
> *To:* Panos Kampanakis (pkampana) <[e-mail]><mailto:[e-mail]&gt>;
> *Cc:* TLS List <[e-mail]><mailto:[e-mail]&gt>;
> *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls
>
>
>
> I clearly support the adoption of the work, but it seems important to
> ensure cTLS integrates or remains in line with the work on compression that
> has been accomplished at the IETF - SCHC defined in lpwan might be a
> starting point. It also seems important to me that cTLS defines mechanisms
> that could be reused as TLS 1.3 evolves.
>
>
>
> Yours,
>
> Daniel

_________________________________________________________________________________________________________________________

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.