Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 09 March 2020 17:56 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB35A3A14B5; Mon, 9 Mar 2020 10:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hE2nXiVy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QWXQ3cYs
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq1ZqNdxKFTX; Mon, 9 Mar 2020 10:56:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3ED73A14CA; Mon, 9 Mar 2020 10:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8040; q=dns/txt; s=iport; t=1583776599; x=1584986199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GybbmFlS9z0BD+yOywFfHzJIaz4aqH9EA75BOTMUGg0=; b=hE2nXiVy3hdTjjBXnhNnBMbY1Xc65Z/oLcQoXxnK9Q4dKVRZ4IKxKyGR 7nlUb3su4i9pvERIzzeOkhfLYn3dBd5F/O+EbduikX3pcLRWAb3DjhnCc H6QetQtE25VbsCulocRe5v0tXHzD7jrdAcbFLOwsKUe0S/kXOR7AMWGFa o=;
IronPort-PHdr: 9a23:H8Ec5BZRA6EAxkR425uvrCH/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbBQBNgmZe/4oNJK1mHAEBAQEBBwEBEQEEBAEBgXuBVFAFbFggBAsqhBWDRgOKboJfmBWCUgNUCQEBAQwBASMKAgQBAYRDAheBdyQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECARIREQwBATcBBAsCAQgaAiYCAgIwFQULAgQBDQ0agwWCSgMOIAEOniMCgTmIYnWBMoJ/AQEFgTMCg1QYggwDBoEOKoUhhECCSxqBQT+BEUeCTT6CZAICGoFLgw8ygiyNc4J1kAGPPwqCPI0fiWOCSYghkEuDTIsqm1ECBAIEBQIOAQEFgWkigVhwFYMnUBgNjh0JGhWDO4UUhUF0gSmNZQEB
X-IronPort-AV: E=Sophos;i="5.70,534,1574121600"; d="scan'208";a="737026754"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2020 17:56:38 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 029HucJ1014299 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2020 17:56:38 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Mar 2020 12:56:38 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Mar 2020 12:56:38 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Mar 2020 12:56:38 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gMoNnnP6apJlZquiiwdKf8YXyAvr9G4BqRO0jG8Re5gSxeg/NVnpEPbIb7hLLM/BMcAQgnJ5w4KFI4ioGCie7HH2vONepEjajIkiapYTDLaqU8KA0FUaa09uksnpqOfVPBlkHdERLZ4X1Qouags+nZ3JGpyBGQP6nNQ6NywTLBxdMfQhSJcMXgWl8oCdTYW7CdP2tHAizkXr5FqxHHxco9/m2mNLKAPWt55Lu3wLo86pvyrbDr4EGMYlU6lX/JbHWgHPQeYtZwuGK13I1tMPL+wefgIc7RRGwUwG19rHh+VZIZf6Qs2zsh/MecUNWw2GU8DCjvRLZo0XNZ9gxiOjgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=GybbmFlS9z0BD+yOywFfHzJIaz4aqH9EA75BOTMUGg0=; b=hbzXf5Y1ikaiW7ZtW8yEQeu8BtRzhTSUlpB4mQHiKiRESerjlsQuQfuhO4bdBaHUSOMGnky2OqAg1ZGUQc7AvIdHzhxXX0RAp/7qF/xjrkVU9zDKhxd51vTCVJGSGrbbYH1SAE2mxQim8nGJmYvyKCWYnWLgZC0HNGdeYY6isZkMeyc4TVpJmZz30JxF3e8bcMBCyOkNo7Sy7UZU+Sum/t7AlN+fsLABCq+6WTqpLz2KVFSXvdf5f2g7BeMk60QomGXbVzAx2zevV1YnfvsSrfRYjk3jIe39XBdfiTHFs2KmkA1Ww7cpTxdp6+uWw2cd4MIBejER/rGpkNO//WRGHQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GybbmFlS9z0BD+yOywFfHzJIaz4aqH9EA75BOTMUGg0=; b=QWXQ3cYsU83knxINKsYnL/PcvrBxfwWm6BVD6qUb4+QGIUGyky3in2kxXHIumZzGskqKjz7jv4JR/IpEJT+Ha4SGfu7TY19U/nzqt48x0ngvolwFSgossqGzembiSWIG5SaLWzPBUQXIIQvWu7aRRJG3K9zE5c4t7Wyd1UI/PhA=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3728.namprd11.prod.outlook.com (2603:10b6:208:f4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Mon, 9 Mar 2020 17:56:37 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::edba:2b0f:7341:2c24%6]) with mapi id 15.20.2793.013; Mon, 9 Mar 2020 17:56:37 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Thread-Index: AQHV5yxvQMp3kJRXD0SmWqJXtHBMvqhAn8GQ
Date: Mon, 09 Mar 2020 17:56:28 +0000
Deferred-Delivery: Mon, 9 Mar 2020 17:56:01 +0000
Message-ID: <MN2PR11MB3565608ECFDA09E90402EE30D8FE0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com>
In-Reply-To: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:ddbe:d99b:151e:b253]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2cc0ed86-6896-42d1-b87f-08d7c453368c
x-ms-traffictypediagnostic: MN2PR11MB3728:
x-microsoft-antispam-prvs: <MN2PR11MB3728C1C81E45F9DF0087ED1FD8FE0@MN2PR11MB3728.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0337AFFE9A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(189003)(199004)(66574012)(81156014)(6506007)(6666004)(33656002)(76116006)(966005)(86362001)(478600001)(81166006)(66446008)(224303003)(66556008)(66476007)(5660300002)(9686003)(66946007)(55016002)(64756008)(52536014)(316002)(186003)(71200400001)(2906002)(110136005)(54906003)(4326008)(8936002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3728; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xgvRopU2z3utIezCm/na59v8Iz13oKsXinnYrzQdXc5bbrjMRM63DzEQ8Dpqk6we7sLmzBzaB+fsu+67zo+O98eKF32p4lrvIj4ON0AKou9SFlrRrWvgBMnqWv1PXmqeiEoJQqHLETwL9Tfgo+KaEC7IBvUuMWKYVO0sKc5BeNa9Me4M2YrvklTGw1zu+SHnDzXiL+VNvAf64QNf9fZYWzXUzNUlEZjMifur2IEDo+L5mdDFOxchdYuE56MNNvNRMYQtPBo0gP3V3W93aKU9arh9NwFhd68DYOY9xjJOtTzNcrpcdKfaLPnhU/QDw2pKAPxZQ1zNscVm6+P1yzDsar5qf8z1foAKx9YkA2qOFtZaONjwDcOih9bCv00b6NL6nplqatHt6o+A/ENoVPKGgimWp0kU7bc1V3zp009zv9M7e3eceHVl+gQQbXENPFW6UKxstS61I9EbLgclHIyQRggAQoQGNK6S7YskQdYFxSujApkmsnFilQx+r95TdDnOhGEttZHBVTN6uEcAEaQwUw==
x-ms-exchange-antispam-messagedata: RnUvKnmdYdajy224BrCI+IyV8A8iewBs9BcrGRUn/9BhH/45FW8bP8Zuz7291ttkdXfXVAipTTzUnQdnIfEOvMtsl6NCSVGDMUSeKGVMQo0nqTSGX6Yrfv+URWn4GbiapEsRZJDncP68Mgbgp/xP08ycxA9QrIb4vGJI+PE5RQQOQ4JKhll1O45to27iy4kLxxrQ5ZsPhpnw0bUGY9m+pA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2cc0ed86-6896-42d1-b87f-08d7c453368c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 17:56:37.0507 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XAcbwhiW5i5jY+4Ia4MwB+5QHow4TlpvvSj0imF0FZiHaSbiGtPfgq2MzVCTc2lKaAipJ5zk2oYj86UDHGCoUQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3728
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/oajIwmIbj5NV7VCA26zKta6PSvg>
Subject: Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 09 Mar 2020 17:56:50 -0000

Hello Mirja:

Again many thanks for your very deep review. 

I published -14 to propose some changes that address your DISCUSS comments as well as Benjamin's
Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 . 
Then I published  https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-15 with proposals to fix Benjamin's COMMENTS.
Since it is cut off, I'm publishing https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-16 with proposals to fix your COMMENTS in a row without waiting for the answer.

Please find a first round of discussion on your COMMENTS below:


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1) side comment regarding section 2.2: Note that there is also a working group
> draft defining PMTUD for datagram transports: draft-ietf-tsvwg-datagram-
> plpmtud

Yes, I guess 6LoWPAN could learn and adapt. The problem is below IP for sub 1280 interfaces over a number of mesh hops, but the method could be the same or similar.

> 
> 2) Sec 6:
> "Note that acknowledgments might consume precious resources so the use  of
> unsolicited acknowledgments should be configurable and not enabled
>    by default."
> Maybe SHOULD?

done

> 
> 3) Sec 6: Maybe use normative language here?
> OLD
> "Fragments are sent in a round-robin fashion: the sender sends all the
>    fragments for a first time before it retries any lost fragment; lost
>    fragments are retried in sequence, oldest first.  This mechanism
>    enables the receiver to acknowledge fragments that were delayed in
>    the network before they are retried."
> NEW
> "Fragments MUST be sent in a round-robin fashion: the sender MUST send all
> the
>    fragments for a first time before it retries any lost fragment; lost
>    fragments MUST be retried in sequence, oldest first.  This mechanism
>    enables the receiver to acknowledge fragments that were delayed in
>    the network before they are retried."
> 

Applied


> 4) Sec 6:
> "When a single frequency is used by contiguous hops, the sender should
>    insert a delay between the frames (e.g., carrying fragments) that are
>    sent to the same next hop.
> Maybe SHOULD?
> 

done

> 5) sec 6.3:
> "Until the timer
>    elapses, fragments of that datagram may still be received, e.g. if
>    the RFRAG-ACK was lost on the way back and the source retried the
>    last fragment.  In that case, the router forwards the fragment
>    according to the state in the VRB."
> Why should a router forward the segment, rather than re-sending/re-
> generating the full ACK knowing that all segments have been successfully
> received?

I guess that there was a reason; but I cannot fathom it at this point.
Let me change the text.
"

   Either way, if the RFRAG-ACK indicates that the fragment was entirely
   received (FULL bitmap), it arms a short timer, and upon timeout, the
   VRB and all the associated state are destroyed.  Until the timer
   elapses, fragments of that datagram may still be received, e.g. if
   the RFRAG-ACK was lost on the path back and the source retried the
   last fragment.  In that case, the router generates an RFRAG-ACK with
   a FULL bitmap back to the fragmenting endpoint if an acknowledgement
   was requested, else it silently drops the fragment.

"


> 6) sec 8:
> As currently described an off-path attacker could abort the transmission if the
> datagram_tag is known. I think it should be mention somewhere that a null
> bitmap should only be accepted and forwarded if received on the right
> interface. Further it might make sense to not erase state immediately but wait
> to see if any further fragments are received from the sender. In any case this
> attack should at least be mentioned in section 8.

You are correct, I made a change in 15 that now includes the interface in the lookup for another comment from Benjamin. That caused me to change minimal fragments as well. With that change, the attacker would need to be on the same interface as a hop of the path, which means on-path really, otherwise it cannot cause the MPLS forwarding. 

The text quoted above has the timer that maintains a short-lived state for the retries in flight.

Some new text was added to section 8 in particular:

"

   In addition to the threats detailed therein, an attacker that is on-
   path can prematurely end the transmission of a datagram by sending a
   RFRAG Acknowledgment to the fragmenting endpoint.  It can also cause
   extra transmissions of fragments by resetting bits in the RFRAG
   Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the
   Ack-Request bit in fragments that it forwards.  As indicated in
   [FRAG-FWD], Secure joining and the Link-Layer security are REQUIRED
   to protect against those attacks.

"

Basically the only protection we have for 6LoWPAN compression and fragmentation as a whole is the lower layer security.

> 
> 7) Appendix B:
> "The recovery mechanism must support highly
>       fragmented packets, with a maximum of 32 fragments per packet."
> Where does the 32 come from and shouldn't this be stated normatively in
> body of the document?

It was computed from LoWPAN (IEEE std 802.15.4) to ensure we fit above 2K bytes in a payload that could be in the order or above 70 bytes, with a margin. We used that requirement to dimension the bitmap. I'm not sure about normative, this is the information that we used to design the protocol but the protocol coud live without that text at all.




> 
> Nit: you use both "time out" and "time-out". I recommend to change the two
> occasions of "time out" to "time-out".
> 

Fixed

Again many thanks!

P