Re: [TLS] SCHC header compression

[<[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, November 27, 2019 10:41 AM
To: [e-mail]
Cc: [e-mail]
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 <[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.