Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 21 June 2019 16:01 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 2F566120399 for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 09:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=R/nxx48X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d/XOBwEQ
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 dUNEH4WtvBKv for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 09:01:31 -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 279CF120390 for <6lo@ietf.org>; Fri, 21 Jun 2019 09:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2358; q=dns/txt; s=iport; t=1561132891; x=1562342491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WDGZZgXfC2t2+SJV8yLaLSl4KF5Exj/KQaRk8qhYWFA=; b=R/nxx48XcQ3DeZd3BUB7VlAMsJJ1rNQY2aAFPcJM1nVt7iIYfIlSlpUk w/MEzLHSdyOxV/QlISjLvY9LC+uqGf6iuWQnLfcPFswC17rCk4M6R4g2V OfYHgO3HLEjR8iAsjPtvLCCmJCE2upyt259E+DMbBmqw5LUT/QypW5UY1 w=;
IronPort-PHdr: 9a23:dnAx3xe025yX/nVwXq9KvX2llGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAADj/gxd/5tdJa1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBUwQBAQEBAQsBgUMkLANqVSAECygKhAyDRwOEUooPgluXOIEugSQDVAkBAQEMAQEYCwoCAQGEQAIXgkcjNAkOAQMBAQQBAQIBBW2KNwyFSgEBAQEDAQEQEREMAQEsCwELBAIBBgIOAwQBAQECAiYCAgIlCxUICAIEAQ0FCBqDAYFqAx0BAgyMLZBgAoE4iF9xgTGCeQEBBYEyAYNJGIIRAwaBDCgBhHCEJIJJF4FAP4FXgkw+gmEBAYFjgwgygiaOSps6CQKCEpN8l0aNJZZ/AgQCBAUCDgEBBYFQOIFYcBU7gmyCQYNwhRSFP3KBKY1MAYEgAQE
X-IronPort-AV: E=Sophos;i="5.63,400,1557187200"; d="scan'208";a="577382778"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2019 16:01:08 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x5LG18rT020211 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Jun 2019 16:01:08 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 11:01:07 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 12:01:03 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Jun 2019 11:01:02 -0500
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=WDGZZgXfC2t2+SJV8yLaLSl4KF5Exj/KQaRk8qhYWFA=; b=d/XOBwEQfVTi8cEr+E9AbAfCpSnmzlyxtRR3v8IJOSrMk4pV4w1bp5SoKMzichD3yAAxPUpWShcqctLYJLQE1mcsOTzpNL19BdyHhAKxjc8O8eHT5R58YYL6b+F22a0wckNPwzrNzlRhQde8W/Lo7YXReZrdOkRmFH4Obqxk9lg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3791.namprd11.prod.outlook.com (20.178.254.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 21 Jun 2019 16:01:02 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1987.014; Fri, 21 Jun 2019 16:01:02 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?
Thread-Index: AQHUvtP/l/WCJnJQfkSfvBG+Jtz0TaXUMWWAgAADp4CAAAFwAIDS0bBw
Date: Fri, 21 Jun 2019 16:00:47 +0000
Deferred-Delivery: Fri, 21 Jun 2019 15:08:46 +0000
Message-ID: <MN2PR11MB35651AF9ADEAD3BD5AAD3979D8E70@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CALHmdRwqF972Y4DG8x9QW_fg+AkwnQtzUVSgyE77FBYYO0SLpQ@mail.gmail.com> <cc58e1c1-9084-e1dd-91ab-db485a242767@inria.fr> <A448295E-D3AF-45CD-A14A-48FA82A8ABF2@tzi.org> <499847d6-337a-4484-972f-18647f8c75be@inria.fr> <4F69EDC9-AAAC-4BCD-8493-52BA0D129130@tzi.org>
In-Reply-To: <4F69EDC9-AAAC-4BCD-8493-52BA0D129130@tzi.org>
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: [173.38.220.51]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 14e59087-3489-4c12-c285-08d6f661a89a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3791;
x-ms-traffictypediagnostic: MN2PR11MB3791:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB379100630F151CB6277214ACD8E70@MN2PR11MB3791.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0075CB064E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(396003)(346002)(39860400002)(13464003)(189003)(199004)(81166006)(33656002)(81156014)(478600001)(8676002)(53936002)(66066001)(71200400001)(71190400001)(102836004)(966005)(5660300002)(6666004)(305945005)(6436002)(25786009)(66446008)(64756008)(316002)(86362001)(14454004)(9686003)(66556008)(66476007)(7736002)(55016002)(6306002)(66946007)(229853002)(76176011)(73956011)(26005)(186003)(2906002)(11346002)(110136005)(74316002)(486006)(76116006)(52536014)(256004)(14444005)(53546011)(446003)(6116002)(3846002)(66574012)(99286004)(6246003)(6506007)(476003)(68736007)(8936002)(4326008)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3791; 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-message-info: WMJjoiKLaP98U8EysOjiFt6fA3bYpq4pwO22YKq7Oku5WuPng+nTk767KugHIjM78AsxTGs6Op7EjtV3/avTinY2evW5OmqEXQ/AY5NQRmb7atxDXt2I6/MouMcSH0bpsIDrw7lNHvgBQ4hzdk2x6plhum6wig6/YA1G5MGNz8Be3VqldI3vTgoO806EOOWrsuT8SAe4NXKNDC50i5zB5sbg70Ik/AHZeQrWqqf1Yt/YwwAoaMEjbhfh2dDsmm50kGrJC07fjnI6B4QlM+mDtWUpvpZWIpcxyvVpHFmsopBk2CSnwiRKZKyhV8y25/8qnQFp/W4X84t2OcGbfYDLkSujihhous/74MoYDbOU6jbSzE07izjNs+S34NKQa++xiWgdCvMazuiNGeYJCk2PI5k0cb/9p8K5Xe9eoue3yJA=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 14e59087-3489-4c12-c285-08d6f661a89a
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 16:01:01.7880 (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: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3791
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/1LPyxDrQz09hF4ctThR1WWBo0Jk>
Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?
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: Fri, 21 Jun 2019 16:01:34 -0000

Hello Yatch;

In the security section is changed the text to:

"

An attacker can perform a Denial-of-Service (DoS) attack on a node implementing VRB by generating a large number of bogus "fragment 1" fragments without sending subsequent fragments.
This causes the VRB table to fill up. Note that 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.
It is expected that an implementation protects itself to keep the number of VRBs within capacity, and that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.
"

Works?

Pascal

> -----Original Message-----
> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Carsten Bormann
> Sent: jeudi 7 février 2019 12:42
> To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
> Cc: 6lo@ietf.org
> Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB
> entries?
> 
> On Feb 7, 2019, at 12:36, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> wrote:
> >
> > Since datagram_tag is expected to be incremented (by one) as RFC4944
> specifies, holding the last datagram_tag per peer may be enough, although this
> kind of thing could be "implementation-specific":
> 
> Right.  We don’t want to blackhole datagrams after a reboot, and we want to
> allow the sending implementation to forget their neighbor state (which might
> include that counter, if it is not global) after a while.  So I think some form of
> timeout may be needed.
> 
> Grüße, Carsten
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo