Re: [lp-wan] draft-ietf-lpwan-coap-static-context-hc-14.txt and Magnus Westerlund Discuss

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Magnus

I think there's a confusion here. It is true that this draft discusses how upper layer security and that COSE can be used. But for all I can see it does not affect the SCHC operation or the way it is provisioned. It really affects the deployment since the decompression is done in 2 stages (possibly in 2 different places, the first router and then the application) but that's still SCHC, operating twice, for outer and inner pieces, as described in fig 8.

If a rule matches, say, a source and destination IP address, and the other checked things in the bit stream that follows also match, then the rule applies, and the bit stream is transformed mechanically. Whether that bit stream contains encrypted content is not really the point, this is all bits. SCHC does not do the en/decryption, and is not aware of the content of the security association or the key material. This much happens between the 2 rounds of SCHC but is not part of SCHC.

>From the rule perspective, the cyphertext is inlined as another bit stream that cannot be compressed.

To your point:
> - Discover the peers capability to perform SCHC for COAP or can one opportunistically try?

This is a problem for the security layer between the 2 SCHC stages but SCHC itself is not affected. We do not try anything, we mechanically change a content into another when a rule matches. The security processing is handled in that intermediate layer between the 2 stages and it is what is affected by the architectural change you point out. That layer must be provisioned or must discover / negotiate with its end peers, but that's not SCHC.

> - Taking into account that an COAP application can potentially talk to a number of peers, each having different capabilities.

If the rules are match a particular IP address then we can have different format, with and without the 2 stages, but the cyphertext is an opaque bitstream from a different layer to the outer SCHC operation:

> - Are there need for a redirection/invocation mechanism- The actual context exchange mechanism.

The  SCHC rules (as opposed to say RoHC) are not dynamic and fully provisioned in advance, and this does not change when SCHC compresses CoAP or COSE. Note that we are working separately on the data model for that. But I do not see that the data model is affected by the 2 stages operations. There will just be different sets of rules for inner and outer.

Cc'ed authors, do I have it right ?

Pascal




> -----Original Message-----
> From: lp-wan <[e-mail]> On Behalf Of Magnus Westerlund
> Sent: jeudi 28 mai 2020 17:33
> To: Pascal Thubert (pthubert) <[e-mail]>; draft-ietf-lpwan-coap-
> [e-mail]; Eric Vyncke (evyncke) <[e-mail]>; lp-
> [e-mail]
> Subject: [lp-wan] draft-ietf-lpwan-coap-static-context-hc-14.txt and Magnus
> Westerlund Discuss
> 
> Hi,
> 
> I have looked at the changes in the latest version. However, I don't think they
> resolve my discuss ( https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-
> static-context-hc/ballot/#magnus-westerlund
> ).
> 
> Let me try to re-iterate on why I think my discuss is relevant and you should do
> something credible to address it.
> 
> So my discuss are really only focused on the case where SCHC is used on top of
> a security layer that pushes the SCHC implementation into the COAP stacks at
> the end-points, rather than potentially lower layers on top of the L2
> infrastructure.
> 
> To me it appears that this change results in several architectural considerations
> that didn't existed before for the entity that are going to determine the SCHC
> capability in the peer as well as the context establishment.
> What I am asking for is really only an description of the changed architectural
> context and the requirements on a solution for the SCHC context establishment
> mechanism.
> 
> - Discover the peers capability to perform SCHC for COAP or can one
> opportunisticly try?
> - Taking into account that an COAP application can potentially talk to a number
> of peers, each having different capabilities.
> - Are there need for a redirection/invocation mechanism
> - The actual context exchange mechanism.
> 
> Can we please write a paragraph or two in the suitable section in this
> document rather a single sentence pointing to an appendix. That appending
> containing a single bullet that are supposed to be added:
> 
>    This section extends the RFC8724 Annex D list.
> 
>    o  How to establish the End-to-End context initialization using SCHC
>       for CoAP header only.
> 
> Annex D of RFC 8724 list is preface by:
> "This section lists the information that needs to be provided in the LPWAN
> technology-specific documents."
> 
> That is not really information to be provided, there are procedures that are
> needed.
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan