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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,

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

On Thu, Mar 05, 2020 at 04:00:52PM +0000, Pascal Thubert (pthubert) wrote:
> Dear Benjamin
> 
> Many thanks for your  review this time again!
> 
> 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.

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

> > 
> > 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.
> "

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...

> 
> 
> > 
> >    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].  
> "

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.

> > 
> > 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?

It seems like the best we can do, so it had better be 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.
> "

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.


> 
> > 
> >    *  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..

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