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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-minimal-fragment-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/



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

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.


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

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

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

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.

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

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.

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

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

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

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

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?

   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.

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?

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

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

   *  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.
Also, nit: s/but recompose/but instead should recompose/.

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

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