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

[Ricardo Andreasen <[e-mail]>]

Dear All,

The initial phase with context establishment has come up a number of times
in the discussion, and it is my understanding that it will be handled in a
separate document more focused on implementation.

It is true that if running end-to-end encryption at the application level
the compression mechanism has to take this into account. This is why
compression/decompression is separated into inner and outer SCHC rules for
the OSCORE stack. I agree that the additional requirements on the
architecture are an implementation concern. The draft describes how to
apply SCHC rules in a stack with encryption, assuming that the appropriate
context is present on each end.

Ricardo

El mié., 3 jun. 2020 a las 10:19, Magnus Westerlund (<
[e-mail]>) escribió:

> 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]
> ----------------------------------------------------------------------
>
>