Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Mar 2020 18:07:31 +0000

Dear Benjamin

Many thanks for your  review this time again!

I answered the track question separately (with you and Mirja), this is a conscious discussion that was debated with Suresh in Singapore, we decided for STD track and made the changes accordingly.

Let's address the DISCUSS first, more tomorrow on the COMMENTs

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I think we need to be more explicit (whether inline or by reference) about
> what "Secure joining and the Link-Layer security that it sets up"
> (Section 7) entails in terms of ensuring that access to the LLN is only available
> to authenticated and authorized entities.  It might be worth doing so as
> explicit assumptions or an applicability statement early in the document
> (e.g., the Introduction).

For one thing, in https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-05.txt text was moved that makes this unreadable.

Changed the first paragraph of the intro to:
"
   The original 6LoWPAN fragmentation is defined in [RFC4944] for use
   over a single Layer 3 hop, though possibly multiple Layer 2 hops in a
   mesh-under network, and was not modified by the [RFC6282] update.
   6LoWPAN operations including fragmentation depend on a Link-Layer
   security that prevents any rogue access to the network.
"
 
> 
> Also, in Section 2.3 we refer to the datagram_tag plus layer-2 sender address
> as being "a globally unique identifier for the datagram", but I think this can
> only hold within some time-bounded window (e.g., the lifetime of the
> packet), since the tag space is finite and reuse somewhat inevitable.

This is certainly correct was better make it explicit. What about:
"
   datagram_tag:  An identifier of a datagram that is locally unique to
      the Layer 2 sender.  Associated with the MAC address of the
      sender, this becomes a globally unique identifier for the datagram
      within the duration of its transmission.

"

Please let me know if that addresses your DISCUSS so I can move on with the COMMENTS

Many thanks again!

Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Mar 2020 07:41:25 -0800

> For one thing, in https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-05.txt text was moved that makes this unreadable.

Oh, yes, that would make a difference.

>    security that prevents any rogue access to the network.

Assuming this is meant to replace the "Secure joining and [...]" text, this
looks good.

> Please let me know if that addresses your DISCUSS so I can move on with the COMMENTS

Yes, that sounds good.

Thanks!

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:00:52 +0000

Dear Benjamin

As usual I compiled the proposed changes in an early publication https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-13 

Let's see below for the other COMMENTs:

> COMMENT:
> My initial reading of this document was that it was saying that we literally
> forwarded fragments from the sending node, changing only the tag and link-
> layer addresses; on the contrary, [LWIG-VRB] is preetty clear that there may
> be a need to slice up fragments along the way and carry a "tail" of a previous
> fragment that gets inserted into the beginning of the next fragment.  I would
> suggest tweaking the Introduction slightly to avoid the misreading that I fell
> into, perhaps by s/whereby an intermediate node forwards a fragment as
> soon as it is received if the next hop is a similar 6LoWPAN link/whereby an
> intermediate node forwards a fragment (or the bulk thereof, MTU
> permitting) as soon as it is received if the next hop is a similar 6LoWPAN
> link/.  It might also be possible to note in the definition of "fragment_offset"
> that it applies only to a given hop/transmission, and that the packet's
> fragmentation could be adjusted at each intermediate node.  I'd also suggest
> expanding on the need for "a buffer for the remainder of a previous
> fragment left to be sent" in Section 5.

You're correct that  the LWIG allows that though the frag recovery does not. So it's not a generic thing but a specific thing to the LWIG draft. Also, it has to do with the 6LoWPAN compression that is not the same at intermediate hops, so it's not really an MTU issue. Note that this may have weird implications like an intermediate node generates a 'final' fragment in addition to the original ones. The win becomes a loss because a whole additional frame is sent.

Anyway I picked your proposed change. Note that the case happens because of the compression of the source and/or the destination IP when the IID matches the MAC address. T hint on that, let me also change the first paragraph of section 3 as:
"
  We use Figure 1 to illustrate 6LoWPAN fragmentation.  We assume node
   A forwards a packet to node B, possibly as part of a multi-hop route
   between IPv6 source and destination nodes which may be neither A nor
   B, though 6LoWPAN may compress the IP header better when they are.

"

> 
> The shepherd writeup indicates that, after Dave Thaler's review, there was a
> perceived need to provide normative protocol specification in this document
> for "how to do fragment forwarding"; Section 6 seems to be the closest
> thing to that, but is not really such a specification.  Some further clarity on

It is a generic specification that needs to be completed for a real solution, but it's still a specification. In particular there's a need to indicate that any FF solution MUST swap the datagram_tag at each hop ans interleave space between fragments on radios. That was not obvious and there may be early tentative implementations around that made the mistake.

> subsequent evolution of the WG's goals and whether/why such protocol
> specification is no longer needed in this document would be appreciated.  In
> particular, it's not clear (anymore?) why VRB is so privileged to get its own
> section, when there are alternative approaches.

Initially there was a single doc for a very long time https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-01 (yes that IS old) and the blocking debate on whether one needs to change RFC 4944 (or a new RFC at all) to do FF. So we ended up with the decision to have 2 specs, one that changes RFC 4944 and one that does not and we figured that the one that does not was pure implementation so it went to LWIG. And we figured that there was an over arching spec that any draft, LWIG or new std track , has in common so we extracted that, and then there were 3. Initially the over-arching (this) was informational but we concluded with Suresh in Singapore that 1) the additions from Dave's review made it an Standard Track and 2) that the fragment recovery needed a normative reference to include the normative text in this.

> 
> Abstract
> 
>    This document introduces the capability to forward 6LoWPAN fragments.
>    This method reduces the latency and increases end-to-end reliability
>    in route-over forwarding.  It is the companion to using virtual
>    reassembly buffers which is a pure implementation technique.
> 
> nit: I don't really see what sense of "companion" is supposed to apply, here;
> perhaps a different word would work better?  (In my head, VRB is an
> "incarnation" of the generic "fragment forwarding technique", which would
> be a bit more churn than just swapping out one word here.)

Very right. What about:

"
   This document provides generic rules to enable the forwarding of
   6LoWPAN fragment over a route-over network.  Forwarding fragments can
   improve both the end-to-end latency and reliability, and reduce the
   buffer requirements in intermediate nodes; it may be implemented
   using RFC 4944 and virtual reassembly buffers.
"

> Section 1
> 
>    This specification provides a generic overview of FF, discusses
>    advantages and caveats, and introduces a particular 6LoWPAN Fragment
>    Forwarding technique called Virtual Reassembly Buffer that can be
>    used while conserving the message formats defined in [RFC4944].
> 
> nit: I'd double-check that "conserving" is the intended meaning; to my
> ignorant eye "retaining" or "preserving" would be more appropriate.

Used "retaining".

> 
> Section 2.2
> 
>    "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
>    threats that are linked to using IP fragmentation.  The 6LoWPAN
>    fragmentation takes place underneath, but some issues described there
>    may still apply to 6LoWPAN fragments (as discussed in further details
>    in Section 7).
> 
> nit: I think "underneath the IP layer"?
> 

Done

> Section 2.3
> 
>    6LoWPAN endpoints:  The 6LoWPAN endpoints are the first and last
>       nodes in an unbroken string of 6LoWPAN nodes.  They are in charge
>       of generating or expanding a 6LoWPAN header from/to a full IPv6
>       packet.  They are also the points where the fragmentation and
>       reassembly operations take place.
> 
> nit: I think they are only "the [only] points" where fragmentation/reassembly
> happen if the entire newtork is using fragment forwarding; in other cases
> some intermediate nodes will also reassemble and (re)fragment.

Correct. What about
"
   6LoWPAN endpoints:  The 6LoWPAN endpoints are the first and last
      nodes in an unbroken string of 6LoWPAN fragment forwarding nodes.
      They are in charge of generating or expanding a 6LoWPAN header
      from/to a full IPv6 packet.  They are also the only points where
      the fragmentation and reassembly operations take place.
"

> 
>    fragment_offset:  The offset of a fragment of a datagram in its
>       Compressed Form.  The fragment_offset is expressed in a unit that
>       depends on the MAC layer technology and is by default a byte.
> 
> (The same unit as the datagram_size, I trust.)

Who knows? But I realize that this is not the right level for this spec that never provides a format.
Removing that sentence.

> 
> Section 3
> 
>    Node A starts by compacting the IPv6 packet using the header
>    compression mechanism defined in [RFC6282].  If the resulting 6LoWPAN
> 
> The previous discussion implies that A at least sometimes is starting from an
> existing 6LoWPAN compressed-form packet (as opposed to a fully expanded
> IPv6 packet); would "(if needed)" be appropriate?  (Perhaps I'm misreading
> this implication into things.)

That would mean forwarding a full packet in its compressed form over a hop and then fragmenting it over the next hop?
Arguably the compressed form and the uncompressed forms are equivalent, so one could do that. Though it is encouraged implicitly with RFC 8138 for the routing headers, I do not believe that implementations of RFC 4944 ever did that.

So I suggest 'typically' instead of "if needed":
"
   Typically, Node A starts with an uncompressed packet and compacts the
   IPv6 packet using the header compression mechanism defined in
   [RFC6282].  
"

> 
> Section 5
> 
>    the destination.  Upon a first fragment, a forwarding node (e.g. node
>    B in a A->B->C sequence) that does fragment forwarding MUST attempt
>    to create a state and forward the fragment.  This is an atomic
> 
> There seems to be a verb missing here ("Upon receiving"?).

Oups, fixed

> 
>    Consecutive fragments of a same datagram must be separated with an
>    inter-frame gap that allows one fragment to progress before the next
>    shows up.  This can be achieved by interleaving packets or fragments
>    sent via different next-hop routers.
> 
> What's the tradeoff on making this "must be separated" vs. "MUST be
> separated"?  (Do we want exactly a one-frame gap or a gap of at least one
> frame?)
 
We never know when the next hop will send, it may be busy with a queue of other packets. So there's always a risk unless you schedule like you could with 6TiSCH. Also a TSCH technology will protect against the hidden terminal but a single channel mesh must let the fragment go farther away. So it's like the proverbial time it takes for the canon to cool down.:"Enough time".

So I cannot be more precise that: for TSCH, allow the next hop to forward; for single channel mesh, several times that because the frame must progress out of interference range.

"Enough time" can be expressed as what's needed for a packet to  " progress beyond the next hop and beyond the interference domain before the next shows up.  "
 Is that OK?

> Section 6
> 
> Would it be appropriate to transition from the previous sentence by saying
> that "VRB is a particular incarnation of a 6LoWPAN Fragment Forwarding
> technique" as the second sentence of the first paragraph?

I changed the first sentence as 
"

   The Virtual Reassembly Buffer (VRB) [LWIG-VRB] is a particular
   incarnation of a 6LoWPAN Fragment Forwarding that can be implemented
   without a change to [RFC4944].

"
> 
>    The severity and occurrence of these caveats depends on the Link-
>    Layer used.  Whether they are acceptable depends entirely on the
>    requirements the application places on the network.
> 
> I wish we could give more guidance on how to make these decisions, but I
> can't think of anything specific to say.

Yes, there's a uge variety of MAC PHYs and then even more types of applications...

> 
> Section 7
> 
> I guess the [FRAG-ILE] discussion of reassembly errors at high data rates are
> not applicable here, because "high data rate" and "low-power and lossy
> network" do not go together?

You(re correct that section 3.6 is about high rates - and IPv4 for that matter.
 That's a relative term. In this case, relative to the datagram_tag. 
Which hopefully we made large enough for the foreseeable LLN speeds.
But other sections apply, e.g., 3.1 on Virtual Reassembly is spot on.

> 
>    "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
>    threats that are linked to using IP fragmentation.  The 6LoWPAN
>    fragmentation takes place underneath, but some issues described there
>    may still apply to 6LoWPAN fragments.
> 
> Are we considering only Section 3.7 of [FRAG-ILE] for this discussion?
> If so, a section-specific reference might help (but there are other parts of
> [FRAG-ILE] that may be interesting/relevant, too.

Exactly. Most of the draft is if high interest for us. I could add "threats and other caveats"

> 
>    "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
>    threats that are linked to using IP fragmentation.  The 6LoWPAN
>    fragmentation takes place underneath, but some issues described there
>    may still apply to 6LoWPAN fragments.
> 
> [same comment as above regarding "underneath"]

Applied

"

   "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
   threats and other caveats that are linked to using IP fragmentation.
   The 6LoWPAN fragmentation takes place underneath the IP Layer, but
   some issues described there may still apply to 6LoWPAN fragments.

"

> 
>    *  Overlapping fragment attacks are possible with 6LoWPAN fragments
>       but there is no known firewall operation that would work on
>       6LoWPAN fragments at the time of this writing, so the exposure is
>       limited.  An implementation of a firewall SHOULD NOT forward
>       fragments but recompose the IP packet, check it in the
>       uncompressed form, and then forward it again as fragments if
>       necessary.
> 
> This is implicit about how the checked version of the packet is the one that
> gets refragmented and forwarded, but also does not say what the firewall
> should do when it receives overlapping fragments, particularly ones that
> disagree about the payload.  It seems worth remedying that.

Yep!
"
  * 
     Overlapping fragment attacks are possible with 6LoWPAN fragments
      but there is no known firewall operation that would work on
      6LoWPAN fragments at the time of this writing, so the exposure is
      limited.  An implementation of a firewall SHOULD NOT forward
      fragments but instead should recompose the IP packet, check it in
      the uncompressed form, and then forward it again as fragments if
      necessary.  Overlapping fragments are acceptable as long as they
      contain the same payload.  The firewall MUST drop the whole packet
      if overlapping fragments are encountered that result in different
      data at the same offset.

"
> Also, nit: s/but recompose/but instead should recompose/.

Applied

> 
>    *  Resource exhaustion attacks are certainly possible and a sensitive
>       issue in a constrained network.  An attacker can perform a Denial-
>       of-Service (DoS) attack on a node implementing VRB by generating a
>       large number of bogus first fragments without sending subsequent
>       fragments.  This causes the VRB table to fill up.  When hop-by-hop
>       reassembly is used, the same attack can be more damaging if the
>       node allocates a full datagram_size for each bogus first fragment.
>       With the VRB, the attack can be performed remotely on all nodes
>       along a path, but each node suffers a lesser hit.  This is because
>       the VRB does not need to remember the full datagram as received so
>       far but only possibly a few octets from the last fragment that
>       could not fit in it.  An implementation MUST protect itself to
>       keep the number of VRBs within capacity, and ensure that old VRBs
>       are protected by a timer of a reasonable duration for the
>       technology and destroyed upon timeout.
> 
> I think it would definitely be appropriate to mention that participants in a
> 6LoWPAN network have authenticated to the network, and potentially also
> the ability to blacklist misbehaving nodes.
> 
>    *  Attacks based on predictable fragment identification values are
>       also possible but can be avoided.  The datagram_tag SHOULD be
>       assigned pseudo-randomly in order to defeat such attacks.
> 
> I think it would be worth mentioning the size of the datagram_tag field and
> the corresponding impact on the attacker's ability to succeed at guessing it.

I would have appreciated a suggestion here : ) does this work?
"
   *  Attacks based on predictable fragment identification values are
      also possible but can be avoided.  The datagram_tag SHOULD be
      assigned pseudo-randomly in order to defeat such attacks.  A
      larger size of the datagram_tag makes the guessing more difficult
      and reduces the chances of an accidental reuse while the original
      packet is still in flight, at the expense of more space in each
      frame.
"

> 
>    *  Evasion of Network Intrusion Detection Systems (NIDS) leverages
>       ambiguity in the reassembly of the fragment.  This is difficult
>       and mostly useless in a 6LoWPAN network since the fragmentation is
>       not end-to-end.
> 
> Perhaps add something about "and an NIDS is assumed to have sufficient
> resources to be able to store and reassemble fragmented packets" and/or
> "and NIDS are not often deployed within LLNs (as opposed to on an adjacent
> backbone)" (though I have no hard data to support the latter claim).

That's not really what I meant. I tried to put it all together below:
"

   *  Evasion of Network Intrusion Detection Systems (NIDS) leverages
      ambiguity in the reassembly of the fragment.  This attack makes
      little sense in the context of this specification since the
      fragmentation happens within the LLN, meaning that the intruder
      should already be inside to perform the attack.  NDIS systems
      would probably not be installed within the LLN either, but rather
      at a bottleneck at the exterior edge of the network..

"

Many things again and again!!!

Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 21 Mar 2020 16:08:51 -0700

Hi Pascal,

Not too much more to say, here, fortunately :)
Though it perhaps makes me more sorry that I was slow in responding...

> Initially there was a single doc for a very long time https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-01 (yes that IS old) and the blocking debate on whether one needs to…

Thanks for the extra background; it helps me understand how we got to where
we are now.

>       the fragmentation and reassembly operations take place.

This helps, though one might be slightly confused that the "endpoints" are
not the packet source and destination.  But I don't have an easy solution
for that...

>    IPv6 packet using the header compression mechanism defined in

That seems reasonable.  IIRC, my understanding at the time was that this
scenario would only arise when fragmentation was performed at a different
node than the original sender of the IP packet, which I expect to be rare
in homogeneous LPWANs.

> "Enough time" can be expressed as what's needed for a packet to  " progress beyond the next hop and beyond the interference domain before the next shows up.  "

It seems like the best we can do, so it had better be OK :)

>       packet is still in flight, at the expense of more space in each

Hmm, talking about a "larger size of the datagram_tag" (or wait, did we end
up at "Datagram_Tag"?) feels odd since this document has fixed it at 16
bits.  Maybe:

   *  Attacks based on predictable fragment identification values are
      also possible but can be avoided.  The datagram_tag SHOULD be
      assigned pseudo-randomly in order to reduce the risk of such attacks.
      Nonetheless, some level of risk remains that an attacker able to
      authenticate to and send traffic on the network can guess a valid
      Datagram_Tag value, since there are only 2^16 possible values.

>       at a bottleneck at the exterior edge of the network..

Maybe s/should already be inside/needs to participate in (i.e.,
authenticate to) the LLN in order/, but this does help clarify.

Thanks!

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Mar 2020 07:48:48 +0000

Hello Benjamin:

Let's go then!

> node than the original sender of the IP packet, which I expect to be rare in
> homogeneous LPWANs.

Sorry I confused you. For a packet sourced in the Internet, the border router does the compression at the ingress of the 6LoWPAN network. So it is not the original sender. But it is both the 6LoWPAN endpoint and the fragmenting endpoint.

> Hmm, talking about a "larger size of the datagram_tag" (or wait, did we end up
> at "Datagram_Tag"?) feels odd since this document has fixed it at 16 bits.

Hum, not this doc but RFC 4944 which is described page 6. 
"
Section 5.3 of
   [RFC4944] defines the format of the header for the first and
   subsequent fragments.  All fragments are tagged with a 16-bit
   "Datagram_Tag", used to identify which packet each fragment belongs
"
This doc does not impose anything per se, e.g. fragment recovery inherits from this but uses a smaller tag.

> Maybe:

Nice, I'd just change " only 2^16" with " a limited number of" to keep it generic

I'm continuing with your other mails based on -14.

Keep safe;

Pascal