Subject: Re: [lp-wan] WGLC in effect, ending soon! Re: Second last call for SCHC/IP

From: Charlie Perkins <[email-masked]>
Date: Mon, 16 Jul 2018 15:46:24 -0400

Hello folks,

I have reviewed most of the first part of the draft, not including the 
Appendices or the details for IPv6 and UDP.  I have sent various 
editorial comments to the authors of the draft.

Here are some comments of a more technical nature.

Since the Sender-Abort doesn't have a MIC, does this mean that the Abort 
could be spoofed and all fragmented transmissions disabled?

SCHC is supposed to allow compression over bit-oriented media. In this 
case, I think that Layer-2 Word size should be defined to be 1 (one).  
With that definition, I think there are problems in the specification of 
the All-0 fragments and All-1 fragments.  For instance, the following 
sentence needs work:

>    The size of the All-0 fragment header is generally not a multiple of
>    the L2 Word size.

And there may be some ambiguities at the receiver - I need to map this 
out in more detail.

The MIC is specified to occur only for fragmented packets. However, it 
seems that the MIC might be pretty useful even for unfragmented 
packets.  There is text in the specification to the effect that the MIC 
allows for compression of UDP checksums as well, but I guess currently 
only when the packet is fragmented.

In the following sentence:

>    The MIC MUST be computed on the payload and the padding bits.

shouldn't the Compression Residue be included?

As a larger editorial matter, I think that the reader needs to know the 
contents of section 8.5 (Baseline mechanism) before fully understanding 
the contents of the preceding major sections.  That indicates the need 
for some reorganization of the material.

I am pretty sure that the fragmentation/reassembly mechanism in the 
specification is to be treated as optional, especially for Layer-2 
technologies that already perform fragmentation.  But there are a number 
of instances where the document places mandates on the implementation of 
fragmentation.  And this even extends to mandating that 
technology-specific documents provide parameter definitions for 
fragmentation and reassembly.  It would be clearer if the language were 
reviewed so that implementers of SCHC on some layer-2 technologies are 
not required to implement fragmentation. Authors of technology-specific 
documents should not be required to specify parameters that they do not 
need.

The Target Value (TV) is allowed, quite appropriately, to be supplied 
using any data type.  It is conceivable that some implementers would 
make a mistake so that the compressor and decompressor somehow did not 
agree on the data type used for the TV of the rule.  I wondered if it 
would be better to signify the type of the TV, while still allowing for 
any data type to be used.  For structures, the situation is quite 
complicated.  At minimum, I think some guidance to implementers belongs 
in the document, even if no additional specification is made for how to 
construct the TV as part of the Rule.

It is stated that the CDAs can be applied in different orders on the 
Compressor versus the Decompressor.  Given the terrific flexibility of 
the CDAs, I wonder if this is really safe.  Maybe even the most 
error-prone case is the one used as an example, namely the Compute-*.  
About this, I am not sure, and need to think about it a good bit more.  
Why can't the order of application be maintained?

I would like to review the rest of the document, but this is a helluva 
week and I wanted at least to get these comments in before the 
expiration of Last Call.

Regards,
Charlie P.

---

From: ana minaburo <[email-masked]>
Date: Tue, 17 Jul 2018 10:13:30 -0500

Hello,

Thank you for all your inputs,

Please see answer below

Ana

On Mon, Jul 16, 2018 at 2:46 PM, Charlie Perkins <
[email-masked]> wrote:

> Appendices or the details for IPv6 and UDP.  I have sent various editorial
> comments to the authors of the draft.
>
[Authors] We believe it is protected by layer 2 and no other device can
send this message

> case, I think that Layer-2 Word size should be defined to be 1 (one).  With
> that definition, I think there are problems in the specification of the
> All-0 fragments and All-1 fragments.  For instance, the following sentence
> needs work:
>
> And there may be some ambiguities at the receiver - I need to map this out
> in more detail.
>
[Authors]Good catch! It works with bit alignment but the sentence is not
correctly written

> seems that the MIC might be pretty useful even for unfragmented packets.
> There is text in the specification to the effect that the MIC allows for
> compression of UDP checksums as well, but I guess currently only when the
> packet is fragmented.
>
[Authors] Yes, it is true but if you need a MIC you need at least one
fragment to include it.

> shouldn't the Compression Residue be included?

[Authors] Yes it is computed over the SCHC packet, which inlcudes
Compression Residue.

> contents of section 8.5 (Baseline mechanism) before fully understanding the
> contents of the preceding major sections.  That indicates the need for some
> reorganization of the material.
>
[Authors] Ok, where do you want to put it? upper in the section 8, I mean
instead of 8.2 or with the compression part?

> technologies that already perform fragmentation.  But there are a number of
> instances where the document places mandates on the implementation of
> fragmentation.  And this even extends to mandating that technology-specific
> documents provide parameter definitions for fragmentation and reassembly.
> It would be clearer if the language were reviewed so that implementers of
> SCHC on some layer-2 technologies are not required to implement
> fragmentation. Authors of technology-specific documents should not be
> required to specify parameters that they do not need.
>
> [Authors] The fragmentation is optional but if it is used there are some
mandatory parameters, which needs to be specified in the
technology-specific documents when it is used. I think it is a language
problem could you help us to improve this?

> using any data type.  It is conceivable that some implementers would make a
> mistake so that the compressor and decompressor somehow did not agree on
> the data type used for the TV of the rule.  I wondered if it would be
> better to signify the type of the TV, while still allowing for any data
> type to be used.  For structures, the situation is quite complicated.  At
> minimum, I think some guidance to implementers belongs in the document,
> even if no additional specification is made for how to construct the TV as
> part of the Rule.
>
[Authors] The TV depends on the field ID and the field ID gives the type.
Perhaps we can add this explanation to make it more clear.

> Compressor versus the Decompressor.  Given the terrific flexibility of the
> CDAs, I wonder if this is really safe.  Maybe even the most error-prone
> case is the one used as an example, namely the Compute-*.  About this, I am
> not sure, and need to think about it a good bit more.  Why can't the order
> of application be maintained?
>
> [Authors] Because you can not compute the length or the checksum if the
rest of the header is not decompressed first.

> week and I wanted at least to get these comments in before the expiration
> of Last Call.
>
> [Authors] Thank you very much

> Regards,
> Charlie P.
>
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 17 Jul 2018 13:52:22 -0400

Hello Ana,

I guess it's better to split apart some of the discussion points.

On 7/17/2018 11:13 AM, ana minaburo wrote:
>
> On Mon, Jul 16, 2018 at 2:46 PM, Charlie Perkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>
>     Since the Sender-Abort doesn't have a MIC, does this mean that the
>     Abort could be spoofed and all fragmented transmissions disabled?
>
> [Authors] We believe it is protected by layer 2 and no other device 
> can send this message

I could not find a statement about this requirement on layer 2 within 
the document.  It amounts to restricting the draft to layer-2 
technologies that offer the protection.  If the draft already says this, 
then I just missed it, please excuse -- and perhaps give me a pointer to 
the relevant text.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 17 Jul 2018 13:59:14 -0400

Hello Ana,

Follow-up below.

> [Authors] Yes it is computed over the SCHC packet, which inlcudes 

I actually thought so, but the sentence as shown could easily be 
misinterpreted.  I think that a more exact formulation would be helpful 
to avoid mistakes.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 17 Jul 2018 14:13:12 -0400

Hello Ana,

Follow-up below...

>
>     As a larger editorial matter, I think that the reader needs to
>     know the contents of section 8.5 (Baseline mechanism) before fully
>     understanding the contents of the preceding major sections.  That
>     indicates the need for some reorganization of the material.
>
> [Authors] Ok, where do you want to put it? upper in the section 8, I 
> mean instead of 8.2 or with the compression part?

I'll try to come up with some suggestions about this, but doing so will 
require that I re-read those parts of the draft.

>
>     I am pretty sure that the fragmentation/reassembly mechanism in
>     the specification is to be treated as optional, especially for
>     Layer-2 technologies that already perform fragmentation.  But
>     there are a number of instances where the document places mandates
>     on the implementation of fragmentation.  And this even extends to
>     mandating that technology-specific documents provide parameter
>     definitions for fragmentation and reassembly. It would be clearer
>     if the language were reviewed so that implementers of SCHC on some
>     layer-2 technologies are not required to implement fragmentation.
>     Authors of technology-specific documents should not be required to
>     specify parameters that they do not need.
>
> [Authors] The fragmentation is optional but if it is used there are 
> some mandatory parameters, which needs to be specified in the 
> technology-specific documents when it is used. I think it is a 
> language problem could you help us to improve this?

Yes, I will do so.  I already provided a number of instances in the 
editorial comments sent offline, but there are more.

Regards,
Charlie P.

---

From: ana minaburo <[email-masked]>
Date: Wed, 18 Jul 2018 10:56:50 -0400

Hello,

You are right, thanks for catching all these stuff

Ana

On Tue, Jul 17, 2018 at 1:59 PM, Charlie Perkins <
[email-masked]> wrote:

> misinterpreted.  I think that a more exact formulation would be helpful to
> avoid mistakes.
>
> Regards,
> Charlie P.
>
>

---

From: ana minaburo <[email-masked]>
Date: Wed, 18 Jul 2018 11:28:17 -0400

Hello,

On Tue, Jul 17, 2018 at 1:52 PM, Charlie Perkins <
[email-masked]> wrote:

> I could not find a statement about this requirement on layer 2 within the
> document.  It amounts to restricting the draft to layer-2 technologies that
> offer the protection.  If the draft already says this, then I just missed
> it, please excuse -- and perhaps give me a pointer to the relevant text.
>
> Regards,
> Charlie P.
>
[Ana] There is nothing about this in the document. I'm trying to find a
correct answer because the MIC is only used in the ALL-1 fragment and
covers the complete SCHC packet so the difference is that the Abort is not
included in the MIC check but neither the ALL-0-empty used to request the
ACK.

Either we include this as an L2 request either the SCHC fragments header
need a MIC for these 2 messages, i.e. a fragment MIC?