Re: [lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-ipv6-static-context-hc-21: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hello Benjamin,

Thanks for your responses and for clearing the DISCUSS.
A few comments inlined, as a response to some of yours.
Thanks a lot for your very thorough and insightful discussion.
Best regards

Dominique 

Le 01/11/19 23:39, « Benjamin Kaduk » <[e-mail]> a écrit :

>Hi Dominique,
>
>Thanks for the updates, and sorry for my slow response.  A few places
>required a lot of thought to process, and the last week was pretty busy
>for
>me.
>
>I think that all of the discussion points are adequately resolved, so I
>will update my ballot position in the datatracker shortly; I'll still
>respond inline in several places, though (but only when I have something
>to
>say other than "thanks" or "I agree").
>
>On Fri, Oct 25, 2019 at 05:17:04PM +0000, [e-mail]
>wrote:
>> Hello Benjamin,
>> 
>> Thanks a lot for your time reviewing our draft and providing your
>>comments.
>> Sorry for this long overdue answer.
>> We expect to publish -22 early next week, it should respond to all
>>reviews
>> received since -21 was published.
>> Regarding your review, please find inline our proposed changes or
>> discussion points.
>> Let me know of any observations.
>> You can also find all cumulated changes since -21 at
>> 
>>https://github.com/lp-wan/ip-compression/compare/df85983113ec9bcefe9ba378
>>2a
>> e8a07edd1e6ef6...master
>> The only one change not included is the change in the ACK-Always
>>algorithm
>> text.
>> Best regards
>> 
>> Dominique
>> 
>> 
>> Le 21/08/19 19:21, « Benjamin Kaduk via Datatracker »
>><[e-mail]> a
>> écrit :
>> 
>> >Benjamin Kaduk has entered the following ballot position for
>> >draft-ietf-lpwan-ipv6-static-context-hc-21: Discuss
>> >
>> >The document, along with other ballot positions, can be found here:
>> 
>>>https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc
>>>/
>> >
>> >
>> >
>> >----------------------------------------------------------------------
>> >DISCUSS:
>> >----------------------------------------------------------------------
>> >
>> >I wavered a lot about whether to ballot Discuss or No Objection; there
>> >are a lot of important technical and clarity-of-writing points that
>> >remain in the Comment section, but only a few points seemed to merit
>> >elevating to the Discuss level.  That said, this remains a generally
>> >clear and useful document, so I'm looking forward to seeing it further
>> >improved.
>> >
>> >(1) I'm concerned about Section 8.2.4's recommendation for the use of a
>> >sequential counter:
>> >
>> >      A sequence counter that is incremented for each new fragmented
>> >      SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back
>>to
>> >      0 is RECOMMENDED for maximum traceability and avoidance of
>> >      ambiguity.
>> >
>> >It seems like there may be substantial privacy and security
>> >considerations, here -- draft-gont-numeric-ids-history has some
>> >background about similar cases in the past and links to other documents
>> >with analysis and guidance for future protocols.  Shall we discuss to
>> >what extent those concerns apply here?
>> [DB] the sentence has been removed, so that we don't recommend anything
>> that might result in privacy issues.
>> However, the fragmentation is intended to operate over the LPWAN link
>> which is one router hop, so Dtag is not expected to propagate over the
>> internet.
>> At most, there might be a cloud-based SCHC F/R unit, but it is expected
>>to
>> establish a tunnel with the LPWAN network server, therefore not exposing
>> Dtag to an eavesdropper.
>> Text added in the security considerations section.
>> 
>> >
>> >(2) In Section 8.3.1.2, does the use of the All-1 fragment to signify
>> >the end of the packet, combined with the lack of an explicit "number of
>> >fragments" field, imply that the RCS value is the only thing (at this
>> >protocol level) preventing an attacker from inserting, from off-path,
>> >additional fragments between the penultimate "legitimate" fragment and
>> >the final fragment?  (I understand that the LPWAN radio technologies
>> >generally do have some physical-layer cryptographic mechanisms, though
>> >they sometimes involve shared symmetric keys.)  If the RCS is to play
>> >this pivotal a role, we need to at least document that, and arguably
>> >give stronger guidance about how it should be computed.
>> [DB] your understanding is correct. The RCS allows detecting that an
>>extra
>> fragment was inserted before the last one.
>> However, if the LPWAN network security is weak enough to allow an
>>attacker
>> to insert such a message, then many attacks are possible that are much
>> worse than this one: the attacker can insert a full un-fragmented SCHC
>> Packet, or a full uncompressed IPv6 packet.
>> Therefore, we don't see the RCS role as pivotal in the SCHC/LPWAN
>>network
>> security.
>> Comments?
>
>That's a fair point about the other attacks available to an attacker with
>the capabilities needed to do this.  Sometimes it comes up that an
>attacker
>can do something without detection by the (legitimate) sender whereas the
>other more-damaging attacks would be detected by the sender, but I do not
>think even that is the case here.
>
>My preference would still be to document the behavior/property of RCS, but
>that would just be a Comment-level comment and your opinion outweighs
>mine.
>
>> >
>> >(3) There are several places (noted, for the most part, in the Comment
>> >section) where we say that some field is optional.  I think this means
>> >"optional at the profile level" as opposed to "optional at runtime",
>>but
>> >we should be clear in the document about that.
>> [DB] thanks for this comment, we have revisited all instance of
>> optional/OPTIONAL and may/MAY to make sure the text is clear about
>> optionality at runtime or at the Profile/Rule level.
>> 
>> >
>> >(4) There's an internal inconsistency in Section 8.4.3:
>> >
>> >   In ACK-on-Error mode, windows are used.  All tiles MUST be of equal
>> >   size, except for the last one, which MUST be of the same size or
>> >   smaller than the regular ones.  If allowed in a Profile, the
>> >   penultimate tile MAY be exactly one L2 Word smaller than the regular
>> >   tile size.
>> >
>> >We need to reword this, as the subsequent text contradicts the initial
>> >"MUST".
>> [DB] Indeed, the last sentence in your quoted text creates an exception
>>to
>> the MUST of the sentence before it.
>> Roman Danyliw also commented that this text was confusing.
>> Proposed change
>> OLD_TEXT
>> All tiles MUST be of equal
>>    size, except for the last one, which MUST be of the same size or
>>    smaller than the regular ones.  If allowed in a Profile, the
>>    penultimate tile MAY be exactly one L2 Word smaller than the regular
>>    tile size.
>> 
>> NEW_TEXT
>> All tiles, but the last one and the penultimate one, MUST be of equal
>>    size, hereafter called "regular".  The size of the last tile MUST be
>>    smaller than or equal to the regular tile size.  Regarding the
>>    penultimate tile, a Profile MUST pick one of the following two
>>    options:
>> o  The penultimate tile size MUST be the regular tile size
>> o  or the penultimate tile size MUST be either the regular tile size
>>       or the regular tile size minus one L2 Word.
>> 
>> 
>> >
>> >
>> >----------------------------------------------------------------------
>> >COMMENT:
>> >----------------------------------------------------------------------
>> >
>> >It's perhaps a little interesting/surprising to see this document
>> >describe itself as just "header compression [with some fragmentation
>> >support]".  Is this intended (after profiling) to be the entire IPv6
>> >adaptation layer for the LPWAN technologies in question, or would there
>> >need to be an additional adaptation layer?
>> [DB] yes, this is the entire adaptation layer for the LPWAN technologies
>> in question, after profiling.
>> The Abstract says:
>> "This document defines the Static Context Header Compression (SCHC)
>> framework, which provides both header compression and fragmentation
>> functionalities. SCHC has been designed for Low Power Wide Area Networks
>> (LPWAN)."
>> And also
>> "This document also specifies a fragmentation and reassembly mechanism
>>Š "
>> Can you please elaborate on what text made you think this specification
>> only provided support for fragmentation, not the full real fragmentation
>> protocol?
>> The word "support" is only used in sentences like "the fragmentation
>> functionality supports IPv6 MTU requirement of 1280 bytes".
>> We dont mandate the use of SCHC fragmentation because some layer 2
>> technologies have their own one.
>> This moderation may have make it look like this document does not
>>contain
>> a full real fragmentation protocol. We'll happily correct this
>> misunderstanding.
>
>I don't think there was anything that gave me the impression that this was
>an incomplete protocol.  Rather, I had the sense that "adaption layer" is
>a
>specific keyword that was commonly used for this sort of protocol.  I am
>not entirely sure why I have that impression, though, as it doesn't appear
>in (e.g.) RFC 8200.  It does appear in the discussion of IPv6 over other
>technologies, though (e.g., RFC 4944), and there's even an entire document
>for "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms".  So I
>was just thinking that some readers might be helped by using that specific
>keyword in the description of what this document does, is all.
[DB] Got it, thanks for your detailed explanation. I guess we could have
used the term "adaptation layer".
Or, thinking aloud, maybe it is better to leave to the schc-over-foo
documents to specify "The adaptation layer between IP and foo" and keep
this draft as the description of the tool box that allows building such an
adaptation layer.
We will discuss it in the WG and consider a change for -23.

>
>> >  If yes, would the
>> >fragmentation be a better fit there?
>> [DB] It is definitely in *this* layer, if it not already provided by the
>> LPWAN.
>> 
>> >  If no, perhaps the document should
>> >reframe itself as such?
>> >
>> >Some discussion in the security considerations about detecting
>>malformed
>> >packets by unknown Rule ID prompted me to wonder about whether there is
>> >any possibility of SCHC (i.e., IPv6) traffic coexisting with non-IP
>> >LPWAN traffic on the same (device) interface.  My naive expectation is
>> >that a device would need separate interfaces for IP and non-IP traffic,
>> >but I'm not sure.  Is there any benefit from mentioning such scenarios
>> >in this document?
>> [DB] Some LPWANs, such as LoRaWAN, have standardised a "port number" in
>> their L2 frame to multiplex multiple upper-layer protocols.
>> This allows non-IP (legacy) traffic to co-exist with SCHC traffic,
>> provided Fport value(s) are assigned to SCHC. This is being defined in
>>the
>> schc-over-lorawan draft.
>
>Thanks for educating me!  I assume you'd rather leave that documented in
>the other document and not mention it here, which is fine.
>
>> >
>> >Section 1
>> >
>> >   Header compression is needed for efficient Internet connectivity to
>> >   the node within an LPWAN network.  The following properties of LPWAN
>> >
>> >nit: s/the node/a node/ or s/the node/nodes/ -- there's more than one
>> >node within a given LPWAN network, in the general case.
>> [DB] done, thanks
>> 
>> >
>> >   This document defines generic functionality and offers flexibility
>> >   with regard to parameters settings and mechanism choices.
>> >   Technology-specific settings and product-specific choices are
>> >   expected to be grouped into Profiles specified in other documents.
>> >
>> >Having looked briefly at RFC 8376 and the rest of this document, I
>>worry
>> >a little bit about enabling vendor-locked "walled gardens" there a
>> >specific product defines a custom protcol and does not provide
>> >sufficient information for others to interoperate with networks of the
>> >corresponding devices.  Can we do more to ensure that the resulting
>> >profiles/protocols will be interoperable with independent
>> >implementations?
>> [DB] Profiles define the set of options and the value of parameters used
>> by the device and by its corresponding network-side SCHC entity.
>> The contexts resulting from the profiles are provisioned into the
>>devices
>> at commissioning time or during the lifetime of the product.
>> The LPWAN WG is working at standardising the description of the context,
>> see 
>>https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-yang-data-model/
>> While we understand that a severely constrained end-device may elect not
>> to implement some protocol options if it is targeted to a few specific
>> profiles, we do expect less-constrained implementations of SCHC to be
>>able
>> to operate with any publicly disclosed SCHC profile that uses the
>> forthcoming standard context description.
>> Having said that, and since Abstract and Intro are non-normative, we
>> changed the text
>> OLD_TEXT
>> Technology-specific settings and product-specific choices are
>>    expected to be grouped into Profiles specified in other documents.
>> 
>> NEW_TEXT
>> Technology-specific settings are
>>    expected to be grouped into Profiles specified in other documents.
>> 
>> 
>> 
>> >
>> >Section 4
>> >
>> >   o  Padding (P).  Extra bits that may be appended by SCHC to a data
>> >      unit that it passes to the underlying Layer 2 for transmission.
>> >      SCHC itself operates on bits, not bytes, and does not have any
>> >      alignment prerequisite.  See Section 9.
>> >
>> >Do we mandate the value of the padding bits?  A forward-reference to
>> >Section 9 might be helpful.
>> [DB] This paragraph does reference Section 9. Do you mean we should copy
>> some text/information from Section 9 into here? What information you
>>feel
>> is absolutely needed?
>
>Oops, I must have misread.  (Or, left a note to myself to write more, and
>then written the note about a forward-reference without re-reading the
>actual text in question.)
>
>> >
>> >Section 5
>> >
>> >Should there be an indication in Figure 3 that the SCHC ACK is optional
>> >(as may be made necessary by the radio technology)?
>> [DB] indeed. Done as part of responses to Roman Danyliw's review.
>> 
>> >
>> >Section 5.2
>> >
>> >   The operation in the Downlink direction is similar to that in the
>> >   Uplink direction, only reverting the order in which the architecture
>> >   elements are traversed.
>> >
>> >nit: s/reverting/reversing/
>> [DB] still learning English, thanks! Done
>> 
>> >
>> >Section 6
>> >
>> >   Rule IDs identify the Rules used for Compression/Decompression or
>>for
>> >   Fragmentation/Reassembly.
>> >
>> >Is the Rule ID name(number)space shared between C/D and F/R, or do they
>> >have distinct Rule ID tables?
>> [DB] they do share the same space. A receiver expects either
>>unfragmented
>> compressed packets or fragments, and needs to tell these apart.
>> See next response for proposed text.
>> 
>> >
>> >   The scope of a Rule ID is the link between the SCHC Compressor and
>> >   the SCHC Decompressor, or between the SCHC Fragmenter and the SCHC
>> >   Reassembler.
>> >
>> >It seems that Section 7.2 clarifies that this scope is available
>> >per-device, and the rule IDs are not shared across all devices in the
>> >LPWAN application.  Would it be worth putting "per-device" in here as
>> >well?
>> [DB] "the link" was meant to refer to a specific device. However, it was
>> not clear whether this was a directed or undirected link.
>> NEW_TEXT
>> The scope of a Rule ID is the undirected link instance (i.e. per Dev,
>> regardless of direction) between a SCHC Compressor and its corresponding
>> SCHC Decompressor,
>> or between a SCHC Fragmenter and its corresponding SCHC Reassembler.
>> Within this scope, Rule IDs for Compression and Rule IDs for
>>Fragmentation
>> share the same space.
>
>I think when I read "link" I was inferring the possibility of a
>multi-access link as well as a point-to-point link.
>
>> 
>>   
>> >
>> >   o  In SCHC F/R, to identify the specific mode and settings of F/R
>>for
>> >      one direction of traffic (Up or Dw).
>> >
>> >      *  When F/R is used for both communication directions, at least
>> >         two Rule ID values are needed for F/R, one per direction of
>> >         traffic.
>> >
>> >It might be worth a forward reference here, or a note that this is so
>>we
>> >can tell what header format to use for parsing (e.g., fragment vs.
>>ack).
>> [DB] tough call. More details could overwhelm the reader at this point.
>> OLD_TEXT
>> *  When F/R is used for both communication directions, at least
>>          two Rule ID values are needed for F/R, one per direction of
>> traffic.
>> NEW_TEXT
>> 
>> *  When F/R is used for both communication directions, at least
>>          two Rule ID values are needed for F/R, one per direction of
>> traffic.
>> This is because F/R may entail control messages
>>          flowing in the reverse direction compared to data traffic.
>> 
>> 
>> >
>> >Section 7.2
>> >
>> >   [...]
>> >   On the network side, in order to identify the correct Rule to be
>> >   applied, the SCHC Decompressor needs to associate the Rule ID with
>> >   the Dev identifier.  Similarly, the SCHC Compressor on the network
>> >   side first identifies the destination Dev before looking for the
>> >   appropriate compression Rule (and associated Rule ID) in the Context
>> >   of that Dev.
>> >
>> >Does this imply that the set of Devices is known in advance at
>> >provisioning time, or will part of device onboarding be to synchronize
>> >these Rule IDs+device ID state (or are they expected to be determinable
>> >algorithmically)?
>> [DB] on the network side, device onboarding will entail installing the
>> "context" including the Rules and parameters for that Device.
>> It is expected that a fleet of similar device models will share Rules
>>and
>> parameters.
>> The way Devices are identified is LPWAN-technology-specific. We do not
>> make assumptions on the computability of the Device Ids.
>> 
>> >
>> >Section 7.3
>> >
>> >      *  The first step is to check the Field Identifiers (FID).  If
>>any
>> >         header field of the packet being examined cannot be matched
>> >         with a Field Description with the correct FID, the Rule MUST
>>be
>> >         disregarded.  If any Field Description in the Rule has a FID
>> >         that cannot be matched to one of the header fields of the
>> >         packet being examined, the Rule MUST be disregarded.
>> >
>> >This seems to imply that a given Rule must encompass the entire header
>> >structure considered as input to compression, since any field in the
>> >packet not having a corresponding FID in the Rule means that the Rule
>>is
>> >disregarded.  It would be good to state this requiremnet more plainly.
>> [DB] indeed. Text is already updated as a response to Pete Resnick's
>> review.
>> 
>> >
>> >         example could be uri-queries in CoAP.  Care needs to be
>> >         exercised when writing Rules containing FP=0 values.  Inded,
>>it
>> >         may result in decompressed packets having fields ordered
>> >         differently compared to the original packet.
>> >
>> >There may be security consequences of this if there is a checksum or
>> >other integrity protection on the original packet!
>> [DB] indeed. Care needs to be exercised. We will mention this in the
>> security considerations section.
>> 
>> >
>> >      *  If no eligible compression Rule is found, then the header MUST
>> >         be sent in its entirety using the Rule ID of the "default"
>>Rule
>> >         dedicated to this purpose.  Sending an uncompressed header may
>> >         require SCHC F/R.
>> >
>> >It feels like s/may require/will likely require/ might be justified,
>> >given the description of LPWAN technologies here and in RFC 8376.
>> [DB] indeed. Already changed as a result of Pete Resnick's review.
>> 
>> >
>> >   o  Compression: each field of the header is compressed according to
>> >      the Compression/Decompression Actions (CDAs).  The fields are
>> >      compressed in the order that the Field Descriptions appear in the
>> >      Rule.  [...]
>> >
>> >Compressed in the order of Field Descriptions in the rule, not the
>>order
>> >the fields appear in in the packet, interesting.  This means that the
>> >ordering of fields in the Rule is semantically important (and we should
>> >say so explicitly) but perhaps also provides a bit more flexibility of
>> >compression in the cases where the protocol header being compressed
>> >allows flexibility of representation/field ordering.
>> [DB] Indeed. Sentence added.
>> 
>> >
>> >   o  Decompression: when decompressing, on the network side the SCHC
>>C/
>> >      D needs to find the correct Rule based on the L2 address; in this
>> >
>> >nit: the L2 address of the Dev.
>> [DB] indeed, thanks. Done.
>> 
>> >
>> >      The receiver identifies the sender through its device-id or
>>source
>> >      identifier (e.g.  MAC address, if it exists) and selects the Rule
>> >      using the Rule ID.  This Rule describes the compressed header
>> >      format and associates the received residues to each of the header
>> >      fields.  For each field in the header, the receiver applies the
>> >
>> >We could perhaps stand to say a bit more about "associates the received
>> >residues to each of the header fields", since even the boundaries
>> >between received residues need to be determined based on the Rule ID
>>and
>> >any variable field lengths.
>> [DB] Indeed, thanks!
>> NEW_TEXT
>> The receiver identifies the sender through its device-id or source
>>       identifier (e.g.  MAC address, if it exists) and selects the Rule
>>       using the Rule ID.
>> This Rule describes the compressed header format.  From this, the
>>       decompressor determines the order of the residues, the fixed-sized
>>       or variable-sized nature of each residue (see Section 7.5.2), and
>>       the size of the fixed-sized residues.
>> From the received compressed header, it can therefore retrieve all
>>       the residue values and associate them to the corresponding header
>>       fields.
>> 
>> 
>> 
>> >
>> >Section 7.5.3
>> >
>> >   The not-sent action can be used when the field value is specified in
>> >   a Rule and therefore known by both the Compressor and the
>> >   Decompressor.  This action SHOULD be used with the "equal" MO.  If
>>MO
>> >   is "ignore", there is a risk to have a decompressed field value
>> >   different from the original field that was compressed.
>> >
>> >The security considerations should talk about the consequences of that
>> >risk.
>> [DB] Will do.
>> 
>> 
>> >
>> >Section 7.5.5
>> >
>> >   The mapping-sent action is used to send an index (the index into the
>> >   Target Value list of values) instead of the original value.  This
>> >
>> >Do we need to say this is zero-indexed?
>> [DB] good catch. Indeed.
>> NEW_TEXT
>> The first element in the list MUST be represented by index value 0, and
>> successive elements in the list MUST have indices incremented by 1.
>> 
>> 
>> >
>> >Section  8.1
>> >
>> >   The L2 Word size (see Section 4) determines the encoding of some
>> >   messages.  SCHC F/R usually generates SCHC Fragments and SCHC ACKs
>> >   that are multiples of L2 Words.
>> >
>> >Do we want to say anything about the unusual cases where it does not?
>> [DB] this was meant to imply that SCHC is padding-conscious.
>> I'm afraid the complexity and variety of situations where padding is
>> required is much too involved for this overview section.
>> 
>> >
>> >Section 8.2.2.1
>> >
>> >The figure implies that the tiles need not all be the same length; is
>> >that worth stating explicitly (in contrast to Windows, which do need to
>> >have a consistent cardinality)?
>> [DB] Indeed, at this point in the text, tiles need not be of the same
>>size.
>> However, some modes like ACK-on-Error restricts this and mandate that
>> tiles (but the last and penultimate ones) be of the same size.
>> NEW_TEXT
>> Modes (see Section 8.4) MAY place additional constraints on tile sizes.
>> 
>> 
>> >
>> >Section 8.2.3
>> >
>> >   The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of
>> >   the polynomial used e.g. in the Ethernet standard [RFC3385]) is
>> >
>> >I don't think that RFC 3385 is a good reference for how to interpret
>>the
>> >hex constant as a CRC polynomial.  Given the parenthetical, perhaps
>>it's
>> >not trying to be, but I'd suggest having a CRC32 reference.
>> [DB] Good point, thanks. Reference changed to IEEE 802.3.
>> 
>> >
>> >   Note that the concatenation of the complete SCHC Packet and the
>> >   potential padding bits of the last SCHC Fragment does not generally
>> >
>> >nit(?): I keep trying to read "potential padding bits" as "these bits
>> >exist but are potentially padding bits", as opposed to the intended
>>"any
>> >padding bits [that may potentially be present]".  (Also in the rest of
>> >this paragraph.)
>> [DB] updated.
>> 
>> >
>> >Section 8.2.4
>> >
>> >      The Rule ID allows SCHC F/R interleaving non-fragmented SCHC
>> >      Packets and SCHC Fragments that carry other SCHC Packets, or
>> >      interleaving SCHC Fragments that use different SCHC F/R modes or
>> >
>> >nit(?): I don't see how just the Rule ID allows identifying Fragments
>> >that carry other Packets, in the general case (i.e., including when the
>> >same F/R mode+parameters are used for both packets).  The DTag seems
>> >necessary in this case.
>> [DB] Because it has a different value, the Rule ID will tell apart e.g.
>>a
>> fragmented SCHC Packet and an unfragmented SCHC Packet. Or two
>>fragmented
>> SCHC Packets that use different modes/parameters.
>> You are right that Dtag is needed to tell apart fragments of SCHC
>>Packets
>> that are fragmented under the same F/R mode+parameters.
>> NEW TEXT
>> The Rule ID tells apart a non-fragmented SCHC Packet from SCHC
>>Fragments.
>>   It will also tell part SCHC Fragments of fragmented SCHC Packets that
>> use different SCHC F/R modes or different parameters.
>>   Interleaved transmission of these is therefore possible.
>> 
>> 
>> 
>> >
>> >      A flow of SCHC F/R messages with a given Rule ID and DTag value
>> >      pair MUST NOT interfere with the operation of a SCHC F/R instance
>> >      that uses another Rule ID and DTag value pair.
>> >
>> >What does "interfere with the operation of" mean?  Is this supposed to
>> >be at a spectrum level or in the reassembly process?
>> [DB] the sentence has been removed.
>> 
>> >
>> >   o  C (integrity Check): C is a 1-bit field.  This field is used in
>> >      the SCHC ACK message to report on the reassembled SCHC Packet
>> >      integrity check (see Section 8.2.3).
>> >
>> >      A value of 1 tells that the integrity check was performed and is
>> >      successful.  A value of 0 tells that the integrity check was not
>> >      performed, or that is was a failure.
>> >
>> >What is the recipient of this field expected to do in response to a 1
>>or
>> >0 value?  (E.g., some forward references might help.)
>> [DB] this section is about the fields found in the fragmentation
>>headers.
>> I'd rather leave the description of the algorithm to Section 8.4, which
>> describes the various modes of operations.
>> 
>> 
>> >A perhaps-related question is whether "not performed" is always due to
>> >"not all fragments were present" or could be "my software is configured
>> >to not check the RCS".  Figure 39 suggests that it's the former, but if
>> >so that's probably worth saying explicitly.
>> [DB] again, a short explanation would be inaccurate, therefore is better
>> deferred to the appropriate section.
>> 
>> >
>> >Section 8.3.1.1
>> >
>> >   The Regular SCHC Fragment format is shown in Figure 13.  Regular
>>SCHC
>> >   Fragments are generally used to carry tiles that are not the last
>>one
>> >   of a SCHC Packet.  The DTag field and the W field are optional.
>> >
>> >Optional at a Profile level, or at runtime?
>> [DB] at the Profile level. Text updated, thanks!
>> 
>> >
>> >   The Fragment Payload of a SCHC Fragment with FCN equal to 0 (called
>> >   an All-0 SCHC Fragment) MUST be distinguishable by size from a SCHC
>> >   ACK REQ message (see Section 8.3.3) that has the same T, M and N
>> >   values, even in the presence of padding.  This condition is met if
>> >   the Payload is at least the size of an L2 Word.  This condition is
>> >   also met if the SCHC Fragment Header is a multiple of L2 Words.
>> >
>> >(I think there's an implicit "and the payload is at least one bit long"
>> >in here, which may actually go without saying, but I had to think about
>> >it while verifying the last sentence.)
>> [DB] indeed.
>> 
>> >
>> >Section 8.3.1.2
>> >
>> >   The All-1 SCHC Fragment format is shown in Figure 14.  The sender
>> >   generally uses the All-1 SCHC Fragment format for the message that
>> >   completes the emission of a fragmented SCHC Packet.  The DTag field,
>> >   the W field, the RCS field and the Payload are optional.  At least
>> >
>> >What does "generally" mean?  When would it be used for other things?
>> [DB] the emission could be completed by another message than an All-1
>>SCHC
>> Fragment, for example by a Regular Fragment, following an ACK reporting
>>a
>> missing tile.
>> We can't write "that sends the last tile of the SCHC Packet", because in
>> some Profiles, the All-1 Fragment only has the RCS, and no tile.
>> Removed "generally", at the risk of introducing another confusion.
>> 
>> >
>> >As above, are W/RCS/Payload optional at the Profile level or at
>>runtime?
>> [DB] Profile level. Text updated.
>> 
>> >
>> >Section 8.3.2
>> >
>> >   The SCHC ACK message is shown in Figure 15.  The DTag field, the W
>> >   field and the Compressed Bitmap field are optional.  The Compressed
>> >
>> >As above, optional at the Profile level or runtime?
>> [DB] Profile level. Text updated.
>> 
>> >
>> >Section 8.3.4
>> >
>> >   The SCHC Sender-Abort format is shown in Figure 21.  The DTag field
>> >   and the W field are optional.  The FCN field is all ones.
>> >
>> >[same comment]
>> [DB] Profile level. Text updated.
>> 
>> 
>> >
>> >   If the W field is present,
>> >
>> >   o  the fragment sender MUST set it to all ones.  Other values are
>> >      RESERVED.
>> >
>> >   o  the fragment receiver MUST check its value.  If the value is
>> >      different from all ones, the message MUST be ignored.
>> >
>> >I'm pretty sure there are some other preconditions here, maybe
>>including
>> >"the SCHC Fragment has no payload", as ignoring all fragments that are
>> >not All-1s is unlikely to work very well.
>> [DB] This section is specifically about the Sender-Abort message, so no
>> other 
>> precondition is required: this text does not apply to All-1 SCHC
>>Fragments.
>> 
>> >
>> >Section 8.3.5
>> >
>> >   The SCHC Receiver-Abort format is shown in Figure 22.  The DTag
>>field
>> >   and the W field are optional.
>> >
>> >As above, optional at the Profile level or runtime?
>> [DB] Profile level. Text updated.
>> 
>> 
>> >
>> >   o  if the value is different from all ones, the fragment sender MUST
>> >      ignore the message.
>> >
>> >As above, are there other preconditions here?  I guess the SCHC
>>Receiver
>> >does not send many types of fragment, so the requirements here may
>> >actually be fairly weak.  (Perhaps this requirement goes better
>> >rhetorically after the final paragraph of this section?)
>> [DB] the SCHC F/R receiver does not send Fragments. The purpose is
>>simply
>> to reserve code points for future use.
>> 
>> >
>> >That does raise another question, of whether (when bidirectional
>>traffic
>> >is used) it is needed or recommended to have the traffic direction be
>> >implicit in Rule ID.
>> [BD] Rules are meant to be shared between the two directions (for space
>> saving 
>> in the Rule table), but with slight variations of behaviour (depending
>>on
>> direction) allowed by the DI flag.
>> 
>> >
>> >Section 8.4.1
>> >
>> >   For each active pair of Rule ID and DTag values, the receiver MUST
>> >   maintain an Inactivity Timer.
>> >
>> >What happens if the receiver is under-resourced to do this?
>> [DB] Text added to each of the 3 modes:
>> - No-Ack: drop the offending frames
>> - Ack-Always and Ack-on-Error: respond back with a SCHC Receiver Abort
>> 
>> >
>> >Section 8.4.1.1
>> >
>> >   Each SCHC Fragment MUST contain exactly one tile in its Payload.
>>The
>> >   tile MUST be at least the size of an L2 Word.  The sender MUST
>> >
>> >Including the last tile?
>> [DB] yes indeed. This might entail "saving" a byte from the penultimate
>> tile in order to beef up the last tile.
>> 
>> >
>> >Section 8.4.2
>> >
>> >   o  Data unit out-of-sequence delivery does not occur between the
>> >      entity performing fragmentation and the entity performing
>> >      reassembly
>> >
>> >Is there an implicit "but data units may be lost or otherwise not
>> >delivered" here?
>> [DB] yes indeed.
>> 
>> >
>> >Section 8.4.2.1
>> >
>> >   o  upon receiving a SCHC ACK,
>> >
>> >      *  if the SCHC ACK indicates that some tiles are missing at the
>> >         receiver, then the sender MUST transmit all the tiles that 
>>have
>> >         been reported missing, it MUST increment Attempts, it MUST
>> >         reset the Retransmission Timer and MUST await the next SCHC
>> >         ACK.
>> >
>> >Are there any ACK REQs involved here?  How will the receiver know to
>> >send a second SCHC ACK if only some tiles (potentially not including 
>>the
>> >last tile of the window) are being retransmitted?
>> [DB] no ACK REQ involved here. For the explanation, see the text "on the
>> Bitmap becoming fully populated with 1¹s, Š" in the receiver behavior
>> specification, 8.4.2.2
>> 
>> >
>> >   o  on Retransmission Timer expiration,
>> >
>> >      *  if Attempts is strictly less that MAX_ACK_REQUESTS, the
>> >         fragment sender MUST send a SCHC ACK REQ and MUST increment 
>>the
>> >         Attempts counter.
>> >
>> >E.g., this text would suggest that after sending the last tile of a
>> >window, we wait for the retransmission timer's delay before sending an
>> >ACK REQ and thus inherently stall the transaction for that long.
>> >(Later on we see that the All-0 Fragment has an implicit ACK REQ
>> >semantics, but it's unclear that this works for the last tile of a
>> >retransmitted window when the bitmap remains incomplete at the 
>>receiver.)
>> [DB] indeed, if a Fragment of a retransmitted window is lost, it will 
>>take
>> a retransmission timer delay before an ACK REQ is transmitted, unless 
>>the
>> sender elects to send an ACK REQ right away after the batch of
>> retransmitted Fragments. The latter is not forbidden by this
>> specification. Whether it is a good idea or not depends on the 
>>conditions.
>> Note that the SCHC ACK REQ can get lost, the same way as a Fragment can,
>> so it cannot be the only solution.
>> 
>> >
>> >Section 8.4.2.2
>> >
>> >   On receiving a SCHC Fragment with a Rule ID and DTag pair not being
>> >   processed at that time
>> >[...]
>> >   On reception of any SCHC F/R message, the receiver MUST reset the
>> >   Inactivity Timer.
>> >
>> >I think these statements are inconsistent about the scope of the
>> >Inactivity Timer.  The latter implies that the timer is global to the
>> >recipient, but the former implies it is specific to a Rule ID/DTag 
>>pair.
>> >(Section 8.4.2, of course, is clear that it is per-Rule ID/DTag pair.)
>> [DB] you are totally right, the second statement has an implicit "for 
>>the
>> RuleID and Dtag pair at hand" condition. It was in there in earlier
>> versions, and was removed for legibility later on, because it was deemed
>> obvious. Tough call.
>> Text amended to be more explicit, at the risk of being harder to read.
>> 
>> >
>> >         +  If the Bitmap indicates that all the tiles of the current
>> >            window have been correctly received, the receiver MUST
>> >            increment its window counter and it enters the "acceptance
>> >            phase" for that new window.
>> >
>> >Is this going to leave us in a bad state if our ACK gets dropped?
>> [DB] Thanks for catching this. Indeed, when we rewrote the algorithm
>> description from a clean sheet, we over-simplified it :-(
>> Text will be changed, not yet pushed to GitHub.
>
>Please let me know if you want me to go through the whole algorithm again;
>I think I am out of time to do so proactively today.
[DB] this is now rewritten in -22, that we rolled out on Thursday.
Thanks for volunteering to go through the algorithm again.
Carsten Bormann says he will review the fragmentation specification as 
part of his IoT-Dir review, and I trust him to go through each and every 
detail.
This will also be a good focal point for our Hackahton106 work.

>
>> >
>> >      *  on the Bitmap becoming fully populated with 1's, the receiver
>> >         MUST send a SCHC ACK for this window, it MUST increment its
>> >         window counter and it enters the "acceptance phase" for the 
>>new
>> >         window.
>> >
>> >[same comment]
>> >
>> >   o  if the window is the last window
>> >   [...]
>> >      *  on receiving a SCHC Fragment with a W bit equal to the local W
>> >         bit,
>> >         [...]
>> >         +  otherwise, the receiver MUST update the Bitmap and it MUST
>> >            assemble the tile received.  If the SCHC Fragment received
>> >            is an All-1 SCHC Fragment, the receiver MUST assemble the
>> >            padding bits of the All-1 SCHC Fragment after the received
>> >            tile.  It MUST perform the integrity check.  Then
>> >
>> >            -  if the integrity check indicates that the full SCHC
>> >               Packet has been correctly reassembled, the receiver MUST
>> >               send a SCHC ACK and it enters the "clean-up phase".
>> >
>> >            -  if the integrity check indicates that the full SCHC
>> >               Packet has not been correctly reassembled,
>> >
>> >It seems that there will be some cases where we know that there remain
>> >missing tiles; do we want to say anything about that (and skipping the
>> >integrity check validation) here?
>> [DB] to keep the text simpler, I'd rather assume that an implementer 
>>will
>> short-cut the integrity check computation to yield a false in the
>> cases where we know there remain missing tiles.
>> 
>> >
>> >Section 8.4.3.1
>> >
>> >   On Retransmission Timer expiration
>> >
>> >   o  if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment
>> >      sender MUST send either the All-1 SCHC Fragment or a SCHC ACK REQ
>> >      with the W field corresponding to the last window,
>> >
>> >   o  otherwise the fragment sender MUST send a SCHC Sender-Abort and 
>>it
>> >      MAY exit with an error condition.
>> >
>> >Having a heads-up here that there's special behavior for the receiver
>> >where the window that gets ACK'd in response to an ACK REQ may be a
>> >different window than the one indicated in the ACK REQ would help me
>> >out, as there's a few places in this section where that behavior is
>> >implicitly relied upon but it's not otherwise stated until we get o the
>> >following subsection.
>> [DB] we believe this heads-up is provided in the intro of the 
>>Ack-on-Error 
>> mode (section 8.4.3), where we state
>> "
>> The fragment sender retransmits SCHC Fragments for tiles that are 
>> reported missing.  It can advance to next windows even before it has 
>> ascertained that all tiles belonging to previous windows have been 
>> correctly received, and can still later retransmit SCHC Fragments with 
>> tiles belonging to previous windows.  Therefore, the sender and the 
>> receiver may operate in a decoupled fashion.
>> 
>> "
>> We reckon there is a lot of information to be digested because of the 
>> degrees of freedom allowed by the Ack-on-Error mode, and we plead that 
>>a 
>> two-pass reading is inevitable.
>
>Two-pass or more :)
>
>> >
>> >In a few places in this section we talk about "the All-1 SCHC 
>>Fragment",
>> >but I'm not entirely clear on whether this will always include the last
>> >tile or, in the case where the profile directs that the last tile be
>> >included in a regular fragment, there is some special format for the
>> >All-1 fragment that does not include (much) payload.
>> [DB] indeed, both cases are allowed by this specification. While the 
>> former case is the most obvious one, the latter one is meant to 
>> accommodate 
>> situations where the fragmentation header and the RCS alone would 
>>nearly 
>> fill up the LPWAN payload, not leaving enough room for even a single 
>>tile, 
>> or only room for a ridiculously small tile. 
>> The Sigfox downlink payload of 8 bytes comes to mind.
>> 
>> >
>> >Section 8.4.3.2
>> >
>> >   On receiving any SCHC F/R message, the receiver MUST reset the
>> >   Inactivity Timer.
>> >
>> >As mentioned above, this statement is overly broad (and should be 
>>scoped
>> >to Rule ID/DTag matching).
>> [DB] done.
>> 
>> >
>> >   After receiving an All-1 SCHC Fragment, a receiver MUST check the
>> >   integrity of the reassembled SCHC Packet at least every time it
>> >   prepares for sending a SCHC ACK for the last window.
>> >
>> >As mentioned previously, the receiver may already know it lacks some
>> >tiles, which makes checking the integrity kind of pointless.
>> [DB] indeed. We do agree that, in this case, the receiver already knows 
>> the integrity status, therefore the "check" can be performed at no cost.
>> 
>>  
>> >
>> >Section 10.7.2
>> >
>> >   As described in [RFC8065], it may be undesirable to build the Dev
>> >   IPv6 IID out of the Dev address.  Another static value is used
>> >   instead.  In that case, the TV contains the static value, the MO
>> >
>> >What's the scope/duration of this other static value's usage?
>> [DB] the way an IPv6 address is formed is is out of scope for this 
>>draft, 
>> which deals with header compression and fragmentation.
>> However, for compression to be efficient, we need the static value to 
>>last 
>> for as long as the static context is provisioned into the 
>>device/network.
>> Both are likely to be provisioned into the device through the same 
>> mechanism, anyway.
>
>Hmm, it seems like that provides only a modest privacy benefit over using
>the Dev address, then.  (Not that I have any better alternative to
>propose!)
[DB] Indeed. However, irrespective of whether DevAddr is used for IID or 
not, a few more data points on this privacy issue:
A) Sigfox is a single world-wide "access" network. Recognizing the IDD of 
a Dev in its packets sent over the Internet amounts to saying "this Dev is 
on planet Earth". Not much privacy-revealing.
B) LoRaWAN has a passive roaming mode whereby the radio frames will be 
routed to the "home" network server. As the Dev moves between networks (in 
passive roaming mode), even if the IP Prefix is assigned by the LPWAN 
network operator, the Dev will appear as originating from the home 
network, which is typically a country. Depending on the mobility pattern 
of the Dev, this may or may not be an issue.
C) In the first SCHC commercial offer, the "Infrastructure side" SCHC C/D 
and F/R are located in the cloud and the IPv6 prefix belongs to the SCHC 
platform vendor, which does the routing to the network operators over 
tunnels. Therefore, whatever the network a Dev is on, it always appears on 
the Internet as being on the "SCHC platform vendor's network", not 
revealing any geographical location nor a physical network attachement.

>
>> >
>> >Section 12
>> >
>> >Do we want/expect the network gateway to be running a firewall that 
>>only
>> >allows traffic from the Application to be relayed down to the radio
>> >network?  If so, what kind of authentication mechanism could it use?
>> >In a similar vein, I note that some of the examples show the use of
>> >link-local IPv6 addressing; if the device is one end of that "link",
>> >what node is the other end, and to what extent does the link-local
>> >nature of the addressing prevent off-path traffic injection?
>> >
>> >   Wireless networks are subjects to various sorts of attacks, which 
>>are
>> >   not specific to SCHC.  In this section, we'll assume that an 
>>attacker
>> >   was able to break into the network despite the latter's security
>> >   measures and that it can now send packets to a target node.  What is
>> >
>> >Since this is radio, is it implicit that the send-packets ability is
>> >"from off-path"?
>> [DB] Offending sentence removed. We are extensively revisiting Section 
>>12 
>> anyway.
>> 
>> >
>> >Section 12.1
>> >
>> >It feels like we should say something about what the endpoint will do
>> >with the bogus packet after SCHC Decompression -- does it just get
>> >passed to the application with the application left to do any
>> >sanity/authenticity checking?
>> >
>> >I sympathize with the secdir reviewer's point about mixing secret
>> >information with attacker-controlled information as compression input.
>> >That said, my sense from reading the document is that compression is
>> >applied on a per-protocol-header-field basis, which makes it unlikely
>> >that there will be secret data combined with attacker-controlled data,
>> >but I would appreciate a confirmation of that.
>> [DB] you're totally right about the analysis. The question will be 
>> discussed in the coming version of the draft.
>> 
>> >
>> >Section 12.2
>> >
>> >This is a really great discussion of the risks affecting the
>> >fragmentation/reassembly mechanism; thank you!
>> >I suppose we could also mention the possibility of a spoofed ACK that
>> >claims all data is received when it was not successfully received,
>> >though in practice it does not seem like that would be particularly
>> >valuable to the attacker (not least since they would probably also need
>> >to suppress the legitimate ACK that indicates some fragment loss).
>> >
>> >I also note the secdir reviewer's remark about fragmentation and packet
>> >inspection devices.  I mostly expect any such devices to not be at the
>> >radio layer for these application traffic flows, but please confirm.
>> [DB] We do agree with your analysis, and will state this in the coming 
>> version of the draft.
>> 
>> >
>> >Appendix A
>> >
>> >What is the Rule ID for "no compression applied"?
>> [DB] will add one in the example
>
>Did this make it into the -22?  I might just be looking in the wrong
>place...
[DB] oops, this slipped through my final check. Sorry about this!
We'll definitely do it for -23.

>
>Thanks again,
[DB] Thanks to you, we value the time you spent working on our draft!

>
>Ben
>
>> >
>> >Appendix C
>> >
>> >Some of these are so hard to follow that I couldn't really verify them
>> >completely.  I don't really have suggestions for improving them that
>> >don't involve using substantially more vertical space, though.
>> [DB] Thanks for your comment. We needed these at some point in the 
>>design 
>> to make sure we agreed between ourselves about what was the behaviour.
>> We added them as an Appendix in hope it could help some readers.
>> While No-Ack and Ack-Always have a detailed and truthful representation 
>>of 
>> the state machines, the drawings for Ack-on-Error are just one example 
>>of 
>> diverse behaviours made available by this specification.
>> We have made every effort to ensure that the text in 8.4 is accurate.
>> The drawings in Appendix C are only meant to be illustrative.
>> 
>> >
>> >Appendix D
>> >
>> >What about MAX_ACK_RETRIES?
>> [DB] this was a typo, thanks for catching it. Should have read 
>> MAX_AK_REQUESTS.
>> Fixed.
>> 
>> >
>> >Appendix E
>> >
>> >   tiles.  If multiple window sizes are supported, the Rule ID may
>> >   signal the window size in use for a specific packet transmission.
>> >
>> >Is this really a "may" or a "must"?  I don't see what else would be 
>>used
>> >to determine what width to use when parsing the fragment.
>> [DB] indeed.
>> NEW_TEXT
>> If multiple window sizes are supported, the Rule ID signals the window 
>> size in use for a specific packet transmission.
>> 
>> >
>> >Appendix F
>> >
>> >   When the SCHC Fragment sender transmits the All-1 SCHC Fragment, it
>> >   starts its Retransmission Timer with a large timeout value (e.g.
>> >   several times that of the initial Inactivity Timer).  If a SCHC ACK
>> >   is received before expiration of this timer, the SCHC Fragment 
>>sender
>> >   retransmits any lost SCHC Fragments reported by the SCHC ACK, or if
>> >   the SCHC ACK confirms successful reception of all SCHC Fragments of
>> >   the last window, the transmission of the fragmented SCHC Packet is
>> >   considered complete.  If the timer expires, and no SCHC ACK has been
>> >   received since the start of the timer, the SCHC Fragment sender
>> >   assumes that the All-1 SCHC Fragment has been successfully received
>> >   (and possibly, the last SCHC ACK has been lost: this mechanism
>> >   [...]
>> >
>> >This seems like it's no longer a *retransmission* timer for the All-1
>> >fragment, since we don't retransmit when it expires; we just assume
>> >success and stop.
>> {DB] Indeed. Actually, we have rewritten Appendix F to basically state 
>> that ACK-Always and ACK-on-Error modes require a bidirectional channel. 
>>On 
>> LPWANs that are only quasi-bidirectional, extra measures need to be 
>> applied so that the channel is made bidirectional, but this is out of 
>> scope of the specification of the generic SCHC algorithm.
>> The possible solutions vary widely. A simple keep-alive message from 
>> application layer may suffice.
>> A SCHC-over-foo specification may amend this specification to nicely 
>>blend 
>> said extra measures into the SCHC mechanism for that particular LPWAN 
>> technology.
>> 
>> 
>> 
>> 
>>_________________________________________________________________________
>>________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations 
>>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
>>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
>>messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme 
>>ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged 
>>information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>>delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have 
>>been modified, changed or falsified.
>> Thank you.
>> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.