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

[Magnus Westerlund <[e-mail]>]

Hi Pascal,

Let me try to explain the issue I see here. So this document defines how to
compress COAP/UDP/IPv6 and that is given in a framework with a certain set of
assumption on how to get SCHC rules in place in the compressor and decompressor.

The issue I am seeing for the case of COAP/DTLS/UDP/IPv6 is that the inner
compression of COAP, although is the same set of rules that would be applied for
the actual compression of COAP in the previous case, the application of these
rules are not building on the same foundation as in the above case. 
There are simply a different architectural constraints for getting these rules
in place at the decompressor. I am not asking you to solve them. I am asking the
WG to describe the changed context and its architectural principles. 

So let me ask the question that may resolve this in another way. 

Is there a specification for some LPWAN to establish the SCHC rules that is
working between the end-point and the gateway? Looking at 
https://datatracker.ietf.org/doc/rfc8724/referencedby/
there appear to be several ongoing work to use SCHC as intended by the
architecture discussed in RFC 8724. 

So does there exist any similar proposal for developing an establishment for the
inner COAP compression within a security layer? 

Are you convinced that the ones that need to write such a document are getting
the support for considerations that are different from what RFC 8724 describes?
Because I do think there are several different considerations. 

First, dynamic capability determination based on destination, i.e. for each COAP
server the client talk to needs to determine if there are SCHC support

Secondly, the choice between trying to rely on the security layer to identify
data objects with SCHC rules as part of them and those without? 

Third, what rule initiation protocol can you run on top of the security layer,
you can't do it below as that would leak information that needs to be secure.
This likely should have its own paragraph in the security consideration. 

I think these all have challenges that are significantly different from when
SCHC implementation is embedded in the network stack between IP and L2. And when
the NGW and its SCHC capabilities are not dependent on IP destination, but
simply if it is going to the NGW at all. 

These are all reasons I think there are need for a discussion of the
architectural changes that COAP/SEC/UDP/IP has compared to both UDP/IP and
COAP/UDP/IP. 

Part of the issue here is that do get the inner COAP establishment correct
require knowledge of both SCHC and the security layer + COAP to get correct
possibly with external methods for service discovery, i.e. DNS etc. Thus I think
it is well motivated that you actually describe the considerations needs to be
taken care for a developer of a SCHC COAP compression above OSCORE or DTLS or
any other security layer. 

I hope this clarifies my discuss.

Cheers

Magnus Westerlund


On Tue, 2020-06-02 at 15:33 +0000, Pascal Thubert (pthubert) wrote:
> 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
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------