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

[Ana Minaburo <[e-mail]>]

Hello Magnus,

We try to reflect your input in the document, we have done changes in the
following sections.

Introduction
new text:

CoAP {{rfc7252}} is designed to easily interop with HTTP (Hypertext
Transfer Protocol) and is optimized for REST-based (Representational state
transfer) services. Although CoAP was designed for constrained devices, the
size of a CoAP header still is too large for the constraints of LPWAN (Low
Power Wide Area Networks) and some compression is needed to reduce the
header size.

The {{rfc8724}} defines SCHC, a header compression mechanism for LPWAN
network based on a static context. Section 5 of the {{rfc8724}} explains
the architecture where compression and decompression are done. The context
is known by both ends before transmission. The way the context is
configured, provisioned or exchanged is out of the scope of this document.

*CoAP is an End-to-End protocol at the application level, so CoAP
compression requires to install common Rules between two hosts and IP
Routing may be needed to allow End-to-End communication. Therefore, SCHC
compression may apply at two different levels, one to compress IP and UDP
as described in {{rfc8724}} in the LPWAN network and another at the
application level. These two compressions may be independent. The
Compression Rules can be set up by two independent entities and are out of
the scope of this document. In both cases, the SCHC mechanism remains the
same.*

SCHC compresses and decompresses headers based on shared contexts between
devices. Each context consists of multiple Rules. Each Rule can match
header fields and specific values or ranges of values. If a Rule matches,
the matched header fields are substituted by the RuleID and optionally some
residual bits. Thus, different Rules may correspond to different types of
packets that a device expects to send or receive.

A Rule describes the complete header of the packet with an ordered list of
fields descriptions, see section 7 of {{rfc8724}}, thereby each description
contains the field ID (FID), its length (FL) and its position (FP), a
direction indicator (DI) (upstream, downstream and bidirectional) and some
associated Target Values (TV).

....

Section 2. Applying SCHC to CoAP headers

We have divided the Figure 1, into three different figures, in order to
show the architecture of each use case.

New text:
Applying SCHC to CoAP headers

The SCHC Compression Rules can be applied to CoAP headers. SCHC Compression
of the CoAP header MAY be done in conjunction with the lower layers
(IPv6/UDP) or independently. The SCHC adaptation layers as described in
Section 5 of {{rfc8724}} and may be used as shown in {{Fig-SCHCCOAP1}},
{{Fig-SCHCCOAP2}} and {{Fig-SCHCCOAP3}}.

In the first example {{Fig-SCHCCOAP1}}, a Rule compresses the complete
header stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context
Header Compression Compressor/Decompressor) is performed at the Sender and
at the Receiver. The host communicating with the device does not implement
SCHC C/D.


   (device)            (NGW)        (internet)           (App)

   +--------+                                           +--------+
   |  CoAP  |                                           |  CoAP  |
   +--------+                                           +--------+
   |  UDP   |                                           |  UDP   |
   +--------+     +----------------+                    +--------+
   |  IPv6  |     |      IPv6      |                    |  IPv6  |
   +--------+     +--------+-------+                    +--------+
   |  SCHC  |     |  SCHC  |       |                    |        |
   +--------+     +--------+       +                    +        +
   |  LPWAN |     | LPWAN  |       |                    |        |
   +--------+     +--------+-------+                    +--------+
       ((((((()))))))           -----  ------  ------  -----

{: #Fig-SCHCCOAP1 title='Compression/decompression at the LPWAN bondary'}

In the second example, {{Fig-SCHCCOAP2}}, the SCHC compression is applied
in the CoAP layer, compressing the CoAP header independently of the other
layers. The RuleID and the Compression Residue are encrypted using a
mechanism such as DTLS. Only the other end can decipher the information. If
needed, layers below use SCHC to compress the header as defined in
{{rfc8724}} document. This use case realizes an End-to-End context
initialization between the sender and the receiver and is out-of-scope of
this document.


   (device)            (NGW)        (internet)           (App)

   +--------+                                           +--------+
   |  CoAP  |                                           |  CoAP  |
   +--------+                                           +--------+
   |  SCHC  |                                           |  SCHC  |
   +--------+                                           +--------+
   |  DTLS  |                                           |  DTLS  |
   +--------+                                           +--------+
   .  udp   .                                           .  udp   .
   ..........     ..................                    ..........
   .  ipv6  .     .      ipv6      .                    .  ipv6  .
   ..........     ..................                    ..........
   .  schc  .     .  schc  .       .                    .        .
   ..........     ..........       .                    .        .
   .  lpwan .     . lpwan  .       .                    .        .
   ..........     ..................                    ..........
       ((((((()))))))           -----  ------  ------  -----

{: #Fig-SCHCCOAP2 title='Standalone CoAP ene-to-end
compression/decompression'}

In the third example, {{Fig-SCHCCOAP3}} the Object Security for Constrained
RESTful Environments (OSCORE) {{rfc8613}} is used. In this case, two
rulesets are used to compress the CoAP message. A first ruleset focused on
the inner header and is applied end to end by both ends. A second ruleset
compresses the outer header and the layers below and is done between the
Sender and the Receiver.


   (device)            (NGW)        (internet)           (App)

   +--------+                                           +--------+
   |  CoAP  |                                           |  CoAP  |
   |  inner |                                           |  inner |
   +--------+                                           +--------+
   |  SCHC  |                                           |  SCHC  |
   +--------+                                           +--------+
   |  CoAP  |                                           |  CoAP  |
   |  outer |                                           |  outer |
   +--------+                                           +--------+
   .  udp   .                                           .  udp   .
   ..........     ..................                    ..........
   .  ipv6  .     .      ipv6      .                    .  ipv6  .
   ..........     ..................                    ..........
   .  schc  .     .  schc  .       .                    .        .
   ..........     ..........       .                    .        .
   .  lpwan .     . lpwan  .       .                    .        .
   ..........     ..................                    ..........
       ((((((()))))))           -----  ------  ------  -----

{: #Fig-SCHCCOAP3 title='OSCORE compression/decompression.'}

In case of 2 rule-sets, as shown in {{Fig-SCHCCOAP2}} and
{{Fig-SCHCCOAP3}}, they may come from different provisioning domains, and
that they do not include the cryptography part that is done in between the
two SCHC activities. This document focuses on CoAP compression represented
in the dashed boxes in the previous figures.

.....

We have published the version 14 with these new changes, hoping they cover
all your requests.


Regards

Ana, Laurent, & Ricardo

On Wed, Jun 3, 2020 at 3:19 PM Magnus Westerlund <
[e-mail]> wrote:

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