Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

Owen DeLong <> Fri, 31 July 2020 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22A163A05A7; Fri, 31 Jul 2020 08:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GRSu6t69-arY; Fri, 31 Jul 2020 08:30:41 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 801703A09AC; Fri, 31 Jul 2020 08:30:36 -0700 (PDT)
Received: from [IPv6:2620::930:0:210d:d9ed:30e1:81ab] ([IPv6:2620:0:930:0:210d:d9ed:30e1:81ab]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 06VFUTXP2912634 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 08:30:29 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 06VFUTXP2912634
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1596209430; bh=uvpfd7pcdkt29QOzVeXGlUzrkveSzVLz+tMyg/OYph0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ddd0z4wmF15YYVe0LxeNtjLFyTw0OkOhsmn0DA0Qe7CyiPMDoCLRsymiIHuELvuYS 8MjtOQuoeouKvcLa71M5RGRzDnRkC5Ebd2shjD8U70mW4xQiB3GvvN2ZTZ9tEQvbxk 546RZGIRcabASfuyPy8wLdTS7pxTvIpwBuCW2CQ8=
From: Owen DeLong <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E0326AA2-F8DC-411A-B248-0D3993288282"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 31 Jul 2020 08:30:29 -0700
In-Reply-To: <>
Cc: "Pascal Thubert (pthubert)" <>, v6ops list <>, 6man <>
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( [IPv6:2620:0:930:0:0:0:200:2]); Fri, 31 Jul 2020 08:30:30 -0700 (PDT)
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 15:30:44 -0000

> On Jul 31, 2020, at 08:13 , Ted Lemon <> wrote:
> On Jul 30, 2020, at 6:26 PM, Pascal Thubert (pthubert) < <>> wrote:
>> I support GRAND because it is better than nothing and progressing just that at 6MAN seems to be an incredible achievement already. 
> Indeed.  GRAND seems like a thing that one would be tempted to add to a stack even in the absence of a draft describing it. Having a draft that describes how to do it is better, because we can then have a discussion of what the benefits and drawbacks are, and mitigate the drawbacks. This concern about ND security seems like a useless digression: yes, ND is not secure, we know this. We’ve tried to address it with SEND, but that hasn’t gotten any traction in the market. 
> Are we seeing L2 attacks on ND in the wild? What’s the threat model? If this is a real concern, let’s confront it head-on, rather than trying to address it piecemeal.

ND attacks are a concern in a very limited number of scenarios, most of which have not had significant v6 penetration yet…

1.	Public wifi networks (e.g. coffee houses, etc.)
2.	College/University settings (some v6 traction here, but often not on student-device accessible LANs)
3.	Other networks which must admit untrusted clients/devices

In reality, ND is not significantly better or worse than ARP in terms of attack surface. The primary difference with ND
is the ability to overrun {switch, router, host} neighbor tables. This doesn’t stem from the difference between ND
and ARP, but rather from the difference between networks that rarely have more than 256 possible L3 addresses
and networks which routinely have more than 18 quintillion possible addresses. There’s just not enough silicon
on the planet for every switch to support an n x 2^64 bit neighbor table.

Indeed, as an operator, IMHO, if there’s a place we need to focus on improving L2 attack surface in v6, it’s in
finding better ways for {routers, hosts, switches} to mitigate/absorb this type of resource exhaustion attack.
Unfortunately, this is a hard problem to solve, so we focus on moving the deck chairs we can move while
ignoring the elephant-sized hole in the bulkheads that we don’t know how to patch.