[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?
- [6lo] Magnus Westerlund's No Objection on draft-i… Magnus Westerlund via Datatracker
- Re: [6lo] Magnus Westerlund's No Objection on dra… Pascal Thubert (pthubert)