[6lo] Iotdir last call review of draft-ietf-6lo-minimal-fragment-04

Ines Robles via Datatracker <noreply@ietf.org> Tue, 26 November 2019 12:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D35341208BA; Tue, 26 Nov 2019 04:28:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ines Robles via Datatracker <noreply@ietf.org>
To: Iot-dir@ietf.org
Cc: draft-ietf-6lo-minimal-fragment.all@ietf.org, last-call@ietf.org, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Ines Robles <mariainesrobles@googlemail.com>
Message-ID: <157477128880.13735.1639586563134012090@ietfa.amsl.com>
Date: Tue, 26 Nov 2019 04:28:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/X2G-2IxQE2VQ1uwqyeGNvZCQyBg>
Subject: [6lo] Iotdir last call review of draft-ietf-6lo-minimal-fragment-04
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 12:28:09 -0000

Reviewer: Ines Robles
Review result: Ready

Document: draft-ietf-6lo-minimal-fragment-04
Review result: Ready
Review type: iotdir - Last Call review
Requested version for review: Current
Review Date: 2019-11-26
Reviewer: Ines Robles

Summary:

I believe the draft is technically good. This document is well written.

The document proposes a method to forwarding 6LoWPAN fragments in which a
forwarder do not to have to reassemble each packet in its entirety before
forwarding it, using the virtual Reassembly Buffer (VRB) implementation
technique. VRB overcomes the limits of doing per-hop fragmentation and
reassembly, such as Latency and Memory Management and Reliability. However, VRB
presents limits such as Non-zero Packet Drop Probability, No Fragment Recovery
and No Per-Fragment Routing.

I have few questions formulated at the end.

Major issues:Not Issues found

Minor issues: Not Issues found

Nits/editorial comments: Not Issues found

Questions:

1- In Section 1 that list the components of the reassembly buffer in node B,
should it contains the datagram_offset as well?

2-  In Section 1, where states: "...the actual packet data from the fragments
received so far, in a form that makes it possible to detect...", I think it
might be nice to add an example referring in which form, I mean: "...in a form
(e.g. ....) that makes it possible....", what do you think?

3- draft-ietf-intarea-frag-fragile-17, section 3.7 states some security
vulnerabilities for IP fragmentation (The mentioned document as well defines
virtual reassembly). Do you think that some of these vulnerabilities can be
applied to 6LOWPAN fragments? For example, attacks based on predictable 6LOWPAN
fragment identification values.

Thank you for this document,

Ines.