[6lo] Magnus Westerlund's No Objection on draft-ietf-6lo-fragment-recovery-12: (with COMMENT)

Magnus Westerlund via Datatracker <noreply@ietf.org> Tue, 18 February 2020 15:20 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 ED829120180; Tue, 18 Feb 2020 07:20:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-fragment-recovery@ietf.org, Carles Gomez <carlesgo@entel.upc.edu>, 6lo-chairs@ietf.org, carlesgo@entel.upc.edu, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <158203922796.14034.11972445891648310968.idtracker@ietfa.amsl.com>
Date: Tue, 18 Feb 2020 07:20:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/wRwIbZdWlPLGVutV28BwvyCs_tY>
Subject: [6lo] Magnus Westerlund's No Objection on draft-ietf-6lo-fragment-recovery-12: (with COMMENT)
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, 18 Feb 2020 15:20:28 -0000

Magnus Westerlund has entered the following ballot position for
draft-ietf-6lo-fragment-recovery-12: No Objection

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-fragment-recovery/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am uncertain if there is security risk that is poorly noted. I don't think it
is significant as an intermediate node will in many other ways be able to
interfere with the transmission of the fragments. However, it appears to me
that the below formulation potentially allow a fragment sender to go into an
interesting state by acknowledging fragments prior to even have received them,
causing the sender to abort the transmission prematurely?

   When all the fragments are received, the receiving endpoint
   reconstructs the packet, passes it to the upper layer, sends an RFRAG
   Acknowledgment on the reverse path with a FULL bitmap, and arms a
   short timer, e.g., in the order of an average round-trip delay in the
   network.  As the timer runs, the receiving endpoint absorbs the
   fragments that were still in flight for that datagram without
   creating a new state.  The receiving endpoint abort the communication
   if it keeps going on beyond the duration of the timer.

Could the author please comment on this aspect of what would occur in the
fragment sender if it receives an RFRAG-ACK will full bitmap prior to having
send all fragments, and also what would happen if this is received very shortly
after having sent the last fragment?