Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.txt

From: [email-masked]
Date: Sat, 01 Jul 2017 10:04:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF.

        Title           : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP
        Authors         : Ana Minaburo
                          Laurent Toutain
                          Carles Gomez
	Filename        : draft-ietf-lpwan-ipv6-static-context-hc-05.txt
	Pages           : 37
	Date            : 2017-07-01

Abstract:
   This document describes a header compression scheme and fragmentation
   functionality for very low bandwidth networks.  These techniques are
   especially tailored for LPWAN (Low Power Wide Area Network) networks.

   The Static Context Header Compression (SCHC) offers a great level of
   flexibility when processing the header fields and must be used for
   these kind of networks.  A common context stored in a LPWAN device
   and in the network is used.  This context keeps information that will
   not be transmitted in the constrained network.  Static context means
   that information stored in the context which describes field values,
   does not change during packet transmission, avoiding complex
   resynchronization mechanisms, incompatible with LPWAN
   characteristics.  In most of the cases, IPv6/UDP headers are reduced
   to a small identifier called Rule ID.  But sometimes the SCHC header
   compression mechanisms will not be enough to send the compressed
   packet in one L2 PDU, so the SCHC Fragmentation protocol must be used
   when needed.

   This document describes SCHC compression/decompression mechanism
   framework and applies it to IPv6/UDP headers.  Similar solutions for
   other protocols such as CoAP will be described in separate documents.
   Moreover, this document specifies fragmentation and reassembly
   mechanim for SCHC compressed packets exceeding the L2 PDU size and
   for the case where the SCHC compression is not possible then the
   packet is sent using the fragmentation protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-05
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Wed, 5 Jul 2017 09:11:30 +0000

Hello all,

I have reviewed the "Fragmentation" part (Section 9, Appendices A and B)
of this draft and I have the following comments.

"highest CFN in the window"
  This notion is introduced in 9.5.2, in the subsection that describes the
CFN field.
  At this point in the text, it is not clear who picks the value of
"highest CFN in the window", if it is a constant or how it is conveyed to
the receiver if it is variable.
  Only when reading section 9.7 does one understand that it is a constant
that is known as part of the context and that multiple values may be
supported by ways of different rule Ids.
  However, "highest CFN in the window" is not listed at the bottom of
9.5.2 along with R, N, T and M that are constants to be defined in other
documents.
  I think "highest CFN in the window" deserves a short name and a
notation, and it should be listed along with R, N, T and M at the bottom
of 9.5.2.
  The explanation at the bottom of 9.5.3 as to why one could want a
"highest CFN in the window" value that is not CFN=2^N-2 (56 bits in the
example) is very useful.
  Furthermore, I think that it would be advantageous that, in the
examples, at least one example use a "highest CFN in the window" value
that is not CFN=2^N-2.
  Correction : in Section 9.6, replace
  OLD TEXT
    "Note that, in Window mode, the first fragment of the window is the
one with CFN=2^N-2."
  NEW TEXT
   "Note that, in Window mode, the first fragment of the window is the one
with "highest CFN in the window"".

Section 9.6, Baseline mechanism, description of reassembly buffer
"For example, it may place the data payload of the fragments within a
payload datagram reassembly buffer at the location determined from the CFN
and order of arrival of the fragments, and the fragment payload sizes."
  In order to place fragment at the appropriate location in the reassembly
buffer, how does one know the size of preceding fragments that have been
lost? Are fragments supposed to be all of the same size?
  Does a specific rule Id mandate a fragment size? Is this behaviour to be
specified in "other documents"?
"It uses the CFN and the order of arrival of each fragment to determine
the location"
  Maybe an explanation of why the CFN *and* the order or arrival? I guess
you are referring to the No ACK mode where CFN is constant but for the
last fragment?
  Do we agree that in Window mode, CFN and W unambiguously determine
location in the reassembly buffer?

Section 9.6, Baseline mechanism, description of Window mode - ACK on error
"Upon expiration of the "ACK on Error Timer", if the receiver knows that
at least one fragment of the current window has been lost Š²
  If the "ACK on Error Timer" expires at the receiver, then it knows that
at least the last fragment is assumed to have been lost, correct?
Therefore, the "if the receiver knows that at least one fragment of the
current window has been lost" clause is irrelevant and can be removed from
the text.
The description of ³Window mode - ACK on error² does not mention
MAX_FRAG_RETRIES. My understanding of ³Window mode - Ack on error² is that
it would benefit from the same MAX_FRAG_RETRIES mechanism.
In ³Window mode - ACK on error², the ACK cannot be used for flow control.
The draft does not provide recommendations on when a sender can forget
about a window that it has sent, and reallocate the window number (1 bit)
to a new window. Nor does it provide recommendation about forgetting about
the last window of an IPv6 packet. See for example Figures 17 and 18 in
Appendix A. I¹m assuming that a sender implementation would want to wait
for a reasonable time before forgetting about a window, just in case an
ACK on error would be received shortly. Should this be described here?

Section 9.6, Baseline mechanism, description of MIC processing at the end
of reassembly
  ³In No ACK mode, if the integrity check indicates that the reassembled
IPv6 datagram does not match the original IPv6 datagram (prior to
fragmentation), the reassembled IPv6 datagram MUST be discarded.²
  The following sentences state that in either Window mode, the ACK
conveys information about fragments of the last window that have been
correctly received or not received. (Incidentally, these sentences are
redundant with the same text in the third and fifth paragraphs of the same
section 9.6. Do we need both?)
  Nothing is said about what to do, in Window mode, when the MIC does not
match. For completeness, I suggest we write that the reassembled IPv6
datagram MUST be discarded, and simply state that an ACK is sent with the
same behaviour than for any other window.

Appendix B, allocation of Rule IDs for fragmentation
  I suggest to modify the section title to ³Allocation of Rule IDs for
fragmentation².
  This section should be rewritten. I suggest:
  ³A set of Rule IDs are allocated to support different aspects of
fragmentation
   functionality as per this document. The allocation of IDs is to be
defined in other documents. The set MAY include:

   o  one ID or a subset of IDs to identify a fragment as well as its
reliability option and its window size, if multiple of these are supported

   o  one ID to identify the ACK message.

   o  one ID to identify the Abort message as per Section 9.8.²
  Do we agree with the ³one ID² in the last two items, or are there use
cases that I don¹t see that would justify for multiple IDs ?

Various nits
* Section 3, Terminology. CFN is not listed. Also add the other acronyms
(DTag, MIC, etc.) used in the fragmentation section.
* Section 9.2: MAX_FRAG_RETRIES is described for the Window mode - ACK
³always². For completeness, the same text should be repeated for the
Window mode - ACK on error.
* Section 9.4: Rule ID description. Add the use of Rule ID for conveying
the window size if multiple sizes are supported.
  OLD TEXT
  ³Rule ID may also be used to signal which reliability option is in use
for the IPv6 packet being carried.²
  NEW TEXT
  ³Rule ID may also be used to signal which reliability option is in use
for the IPv6 packet being carried. Rule ID may also be used to signal the
window size if multiple sizes are supported (see 9.7).²
* Section 9.4: ³Compressed Fragment Number². ³Compressed² refers to the
number, not to the fragment, since uncompressed packet can also be
fragmented with this mechanism.
  To remove this ambiguity, rename CFN to Fragment Compressed Number
(FCN)? 
  CFN/FCN should be listed in the Terminology section.
  The part of the sentence ³, and does not necessarily carry an absolute
fragment number.² should be rewritten as ³, and does not carry an absolute
fragment number.². Indeed, CFN counts down from "highest CFN in the
window" anyway, so the chances that it corresponds to an absolute fragment
number are null.
  See as well my comment on text regarding CFN in 9.5.2
* Section 9.5.2: Remove ³, and thus the CFN does not strictly correspond
to the N least significant bits of the actual absolute fragment number.².
It does not strictly correspond, nor loosely.
* Section 9.5.3: ²Absence of the bitmap in an ACK confirms correct
reception of all fragments to be acknowledged by means of the ACK."
  For the wondering soul, maybe explain that the absence is noticed by
looking at the L2 size, since it doesn't immediately show from Figure 13.
* Section 9.6: "if no ACK has been received since the timer start, the
sender retransmits the last fragment sent Š". Could refer to the last in
time or the last in order.
  I guess the correct answer is the latter, i.e. the last fragment of the
IPv6 packet.
* Section 9.6: ³Similarly, when a node first receives Š ³. ³node² is not
part of the terminology. Do you mean a Device, or either end of the LPWAN
link ?
* Section 9.8, fragm/reassbly abortion
  OLD TEXT
  ³The entity (either the fragment sender or the fragment receiver) that
triggers abortion transmits to the other endpoint a format that only
comprises a Rule ID (of size R bits), which signals abortion of all
on-going fragmented IPv6 packet transmissions.²
  NEW TEXT
  ³The entity (either the fragment sender or the fragment receiver) that
triggers abortion transmits to the other endpoint a packet that only
comprises a unique Rule ID (of size R bits), which signals abortion of all
on-going fragmented IPv6 packet transmissions.²
* Section 10.2, security considerations for fragmentation
  ³If an attacker can overhear a fragment, it can send a spoofed duplicate
(e.g. with random payload) to the destination. A receiver cannot
distinguish legitimate from spoofed fragments.²
  This is true of all LPWAN technologies. For example, LoRaWAN has source
authentication that allows a receiver distinguishing a random-payload
spoofed fragment from a legitimate one. Il also has a frame counter
mechanism that allows a receiver to discard later replay by an attacker of
a strictly identical message as send earlier by a legitimate node.
  Therefore, the attack described here and its mitigation only applies to
certain LPWAN technologies.
* Appendix A: ³Note: in Window mode, an additional bit will be needed to
number windows.². This comment is correct, but it is oddly placed in the
middle of the description of Figure 19 as if it didn¹t apply to the ³ACK
on error² mode as well.

Best regards,

Dominique

Le 01/07/17 19:04, « lp-wan on behalf of [email-masked] »
<[email-masked] on behalf of [email-masked]> a écrit :

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

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Wed, 5 Jul 2017 09:24:59 +0000

Sorry about a typo in my comments

<<<snip>>
> This is true of all LPWAN technologies.
I meant : This is *not* true of all LPWAN technologies.

Dominique

Le 05/07/17 11:11, « lp-wan on behalf of [email-masked] »
<[email-masked] on behalf of [email-masked]> a
écrit :

>>https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-contex
>>t
>>-hc-05
>>
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc
>>-
>>05
>>
>>
>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 11 Jul 2017 17:36:07 +0200

Hello Dominique,

First of all, thank you very much for such a thorough, comprehensive, and
constructive review!

All comments (except two) have led to respective updates in the working
version of the document:
https://github.com/lp-wan/ip-compression

Some of the updates have been included in this email as well. Below,
"Agreed" can be understood as "Agreed and update done".

Please find inline responses below.

> notation, and it should be listed along with R, N, T and M at the bottom

Agreed. Proposed notation: MAX_WIND_FCN. The setting for MAX_WIND_FCN has
been added as well in the examples in Appendix A.

> "highest CFN in the window" value that is not CFN=2^N-2 (56 bits in the

Thanks.  Added a pointer in 9.5.2 so that the explanation in 9.5.3 can be
found more easily by a reader.

> examples, at least one example use a "highest CFN in the window" value

Agreed. An example has been added at the end of Appendix A.

> with "highest CFN in the window"".

Agreed, applied this change as:

“Note that, in Window mode, the first fragment of the window is the
   one with FCN set to MAX_WIND_FCN”

> specified in "other documents"?

Fragments are not required/supposed to be of the same size. Maybe the
following text should suffice?

NEW:
  For example, it may place the data payload of the fragments within a
  payload datagram reassembly buffer, based on the CFN and order of arrival
  of the fragments. However, implementers need to be aware that fragments
  are not supposed to be all of the same size.

> location in the reassembly buffer?

The No ACK mode is indeed one reason for why the FCN *and* the order of
arrival are mentioned. I understand you mean that in Window mode, the
receiver will suffer no ambiguity to determine the location of a fragment
in a reassembly buffer, and I agree. However, strictly speaking, maybe at
an abstract level, the FCN and W alone do not unambiguously determine the
location of a fragment, since e.g. an IPv6 packet comprising three or more
windows may transmit two or more different fragments with the same CFN and
W values.

> current window has been lost" clause is irrelevant and can be removed from

Agreed, although an addition is needed to state that:

   When the last fragment of the IPv6 datagram is received, if all fragments
   of that last window of the packet have been received, the “ACK on Error
   Timer” is stopped.

> ACK on error would be received shortly. Should this be described here?

Proposed new text follows.

NEW:
   In Window mode – ACK on error, when a fragment sender has transmitted
   the last fragment of a window, or it has retransmitted the last fragment
   within the set of lost fragments reported in an ACK, it is assumed that
   the time the fragment sender will wait to receive an ACK is smaller than
   the transmission time of MAX_WIND_FCN + 1 fragments (i.e. the time
   required to transmit a complete window of fragments). This aspect must be
   carefully considered if Window mode – ACK on error is used, in particular
   taking into account the latency characteristics of the underlying L2
   technology.

With regard to MAX_FRAG_RETRIES, please see another response below.

> section 9.6. Do we need both?)

Agreed that these are redundant and not needed.

> same behaviour than for any other window.

Agreed that we need to refer explicitly to Window mode.

A problem is that if at the first MIC check the IPv6 datagram is
discarded, then we miss the opportunity to hopefully recover the IPv6
datagram by retransmitting the missing fragment(s) from the last window.
Therefore, the following new text is proposed:

NEW:
   In Window mode, a MIC check is also performed by the fragment receiver
   after reception of a round of retransmitted fragments. If the MIC check
   still fails after the last round of fragments retransmitted by the
   fragment sender (which may have been received or not by the fragment
   receiver), the reassembled IPv6 packet is discarded. Note that the
   fragment receiver will need to determine when it is safe to assume that
   no more fragments will be received. Further guidance on this is expected
   to be provided in future (possibly technology-specific) documents. Note
   also that, in Window mode, the rules that apply for constructing and
   transmitting an ACK for the last window are the same rules that apply for
   any other window.

>   I suggest to modify the section title to ³Allocation of Rule IDs for

Agreed.

>    o  one ID to identify the Abort message as per Section 9.8.²

Agreed.

> cases that I don¹t see that would justify for multiple IDs ?

For ACKs, my understanding is that one ID is sufficient.

For Abort, we discussed in one of the past interims that there might be
reasons to support different options (e.g. abort all on-going, possibly
interleaved, transmissions vs some more fine-grained behavior). We decided
at the time that we would go for the most simple approach to just use one
ID to abort all on-going transmissions.

> (DTag, MIC, etc.) used in the fragmentation section.

Agreed.

> Window mode - ACK on error.

I think your proposal is one possible approach.

Another approach, which is the current one in the draft (and may need to
be discussed) is that in “ACK on error”, the maximum number of
retransmission rounds will be controlled by the receiver by means of
MAX_ACKS_PER_WINDOW, while the sender will retransmit any fragments
reported to be lost in an ACK. Otherwise, in some situations, the receiver
may unnecessarily send ACKs while the sender will not reply (with fragment
retries) to those if it has reached its maximum number of retries. The
receiver does not necessarily know the MAX_FRAG_RETRIES value of the
sender.

Thoughts?

> window size if multiple sizes are supported (see 9.7).²

Agreed.

>   CFN/FCN should be listed in the Terminology section.

Agreed.

> window" anyway, so the chances that it corresponds to an absolute fragment

Agreed.

> It does not strictly correspond, nor loosely.

Agreed.

> looking at the L2 size, since it doesn't immediately show from Figure 13.

Agreed.

>   I guess the correct answer is the latter, i.e. the last fragment of the

The sentence refers to the last fragment that has been sent at the moment
of timer expiration, which could be: i) the last fragment of a window
(i.e. FCN=0 or FCN=2^N-1), e.g. in the first round of fragment
transmission attempts; or ii) the last fragment sent within a a round of
retransmissions (which can be a fragment with any valid FCN for the
current window).

Proposed new text follows.

NEW
   Upon expiration of the timer, if no ACK has been received since the timer
   start, the sender retransmits the last fragment sent at the moment of
   timer expiration, and it reinitializes and restarts the timer. Note that
   the last fragment sent at the moment of timer expiration may be the last
   fragment of a window (i.e. FCN=0 or FCN=2^N-1) or the last fragment sent
   within a round of fragment retransmissions.

> part of the terminology. Do you mean a Device, or either end of the LPWAN

Either end of the LPWAN link.

> on-going fragmented IPv6 packet transmissions.²

Yes, “format” is not so suitable here... What about “data unit with an L2
payload” instead of “packet”?

I’d like to avoid terminology confusion with an IPv6 packet...

> certain LPWAN technologies.

Agreed.

OLD:
   A receiver cannot distinguish legitimate from spoofed fragments

NEW:
   If the LPWAN technology does not support suitable protection (e.g. source
   authentication and frame counters to prevent replay attacks), a receiver
   cannot distinguish legitimate from spoofed fragments.

> middle of the description of Figure 19 as if it didn¹t apply to the ³ACK

I think it is better to just remove the sentence. The “W” bit is now
clearly defined in the document (the sentence pointed out made sense in an
older version of the document, before the “W” bit was defined).

Cheers,

Carles

---

From: <[email-masked]>
Date: Tue, 11 Jul 2017 16:45:00 +0000

Hello Carles,

Thanks to you for all your detailed answers.
A few reactions inline. They are all yes'es, but one that I think warrants
further discussion.
Cheers,

Dominique

Le 11/07/17 17:36, « Carles Gomez Montenegro » <[email-masked]> a
écrit :

>>one
Yes, this sounds good.

>   of that last window of the packet have been received, the “ACK on Error

Agreed

>receiver does not necessarily know the MAX_FRAG_RETRIES value of the

I understand how it works if every node is nice and plays by the rule.
But I picture myself implementing the sender code and writing the "repeat
… until" loop where the exit condition is totally under the control of the
other node.
That makes me shiver.
Isn't this an avenue for a DOS attack, with a node handing its energy and
radio bandwidth over to another node?
I'm sure implementers will want to add a local stop condition to this loop
anyway.
But maybe it does not belong to the protocol specification.
What do others think?

>payload” instead of “packet”?

Yes, sounds good.

>older version of the document, before the “W” bit was defined).

Good