Re: [TLS] SCHC header compression

[Hannes.Tschofenig]

Thanks, Dominique. This is a useful clarification. The way the document is 
written does not made it clear that you indeed wanted to design a more generic 
compression algorithm. 

I don’t know whether there is still a chance for the LPWAN group to restructure 
the document because there is pretty much nothing in there that gives a reader 
the impression that the work has general applicability. 

 

As you have seen from my post to the LPWAN list I have been wondering about the 
overhead associated with SCHC because the LAKE community seems to be concerned 
about every byte (on the wire, and on flash). Unfortunately, there are no open 
source implementation in C available. Maybe the code in your demo may provide 
some insight into the extra code needed for this compression mechanism. This 
paper https://biblio.ugent.be/publication/8613162/file/8613540.pdf tells me 
that the overhead is roughly 6Kb of flash & 1Kb of RAM for the 
compressor/decompressor plus some code for the rules (maybe 3Kb). The paper 
focused on a different scenario and hence the results may vary based on 
applications. As you can imagine I can already hear someone in the LAKE group 
saying that they don’t have a SCHC stack on their device and the extra ~9Kb is 
a complete no-go for them. So, I am a bit careful about picking up a heavy 
cannon for removing a few fields in the handshake. After all, the biggest 
message in a TLS handshake is the Certificate message. The beauty of cTLS is 
that it does not change the TLS 1.3 security properties nor does it require a 
lot of changes to the implementations. 

 

As you may have seen in the cTLS draft we selectively pick fields that can be 
omitted or replaced. It is not obvious to me how SCHC would be integrated into 
a security protocol like TLS where you have to consider the downgrading 
protection in the compression. I am interested to learn more about your 
thoughts on this issue. 

 

I will re-read the draft to get a better understanding of the SCHC work and its 
applicability to TLS. 

 

Ciao
Hannes

 

From: TLS  On Behalf Of dominique.bart...@orange.com
Sent: Wednesday, November 27, 2019 10:41 AM
To: tls@ietf.org
Cc: draft-ietf-lpwan-ipv6-static-context...@ietf.org
Subject: [TLS] SCHC header compression

 

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  <mailto:hannes.tschofe...@gmx.net> >; 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 mailto:tls-b

[TLS] SCHC header compression

[dominique.barthel]

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 
> ; 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 ; *On 
> Behalf Of *Daniel Migault
> *Sent:* Friday, November 22, 2019 10:20 AM
> *To:* Panos Kampanakis (pkampana) 
> ;
> *Cc:* TLS List ;
> *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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls