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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you Ana and authors for this revised I-D addressing all the remaining concerns.

Thank you Magnus for a quick review of the changes.

I will put this I-D back on the telechat

-éric

-----Original Message-----
From: Magnus Westerlund <[e-mail]>
Date: Friday, 3 July 2020 at 09:33
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "pthubert=[e-mail]" <pthubert=[e-mail]>, "[e-mail]" <[e-mail]>, Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-lpwan-coap-static-context-hc-14.txt and Magnus Westerlund Discuss


    Hi,

    I think this new text looks good and would resolve my discuss. I assume these
    changes will be available in -15 when submitted. I am happy to clear my discuss 
    then. 

    Cheers

    Magnus


    On Fri, 2020-07-03 at 09:18 +0200, Ana Minaburo wrote:
    > 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]
    ----------------------------------------------------------------------