Re: [v6ops] [EXTERNAL] Improving ND security

"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Fri, 31 July 2020 19:03 UTC

Return-Path: <bzeeb-lists@lists.zabbadoz.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86D3A044E; Fri, 31 Jul 2020 12:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DrfQSMI0oIKQ; Fri, 31 Jul 2020 12:03:55 -0700 (PDT)
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A783A0476; Fri, 31 Jul 2020 12:03:10 -0700 (PDT)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EFC7D8D4A161; Fri, 31 Jul 2020 19:03:08 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 3D9E4E707B7; Fri, 31 Jul 2020 19:03:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id S6f1v5dinMGa; Fri, 31 Jul 2020 19:03:06 +0000 (UTC)
Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:582a:9aa7:5038:eec3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4E0E0E707AD; Fri, 31 Jul 2020 19:03:06 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To: v6ops list <v6ops@ietf.org>
Cc: 6man <ipv6@ietf.org>
Subject: Re: [v6ops] [EXTERNAL] Improving ND security
Date: Fri, 31 Jul 2020 19:03:05 +0000
X-Mailer: MailMate (2.0BETAr6146)
Message-ID: <88AD0E70-071A-4E51-AB4B-19F7F4571769@lists.zabbadoz.net>
In-Reply-To: <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar>
References: <96fa6d80137241dd9b57fcd871c8a897@huawei.com> <CAFU7BARePzdeU5DFgoOWyrF0xZCj67_xkC2t8vMN2nH0d8aUig@mail.gmail.com> <37e2a7110f6b423eba0303811913f533@huawei.com> <CAFU7BATiD8RkiWXjrxGuAJU-BUwRQCErYZivUPZ-Mc_up_qGxQ@mail.gmail.com> <aebc46c9b813477b9ae0db0ef33e7bd9@huawei.com> <CAO42Z2yL7+GbO6QRaNzFYoBXLF-JZ2NfwgTTt2zerKhJLwt2Lw@mail.gmail.com> <3C1ECB6F-E667-4200-964F-AB233A0A56E9@cisco.com> <91D98D51-4045-4331-A711-8387ECE73400@fugue.com> <a43ffd94d6364a0f869cd4c694ab7432@boeing.com> <5FB3E98B-6CEE-458C-90B7-E6FD73C7AFDE@fugue.com> <caa62d8d93594f7ea445a403fac8c140@boeing.com> <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com> <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/woXBuZ8-9M8Pz5Oq_jMUCienlwc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 19:03:58 -0000

On 31 Jul 2020, at 16:58, Fernando Gont wrote:

>> Is there agreement that this is a serious problem in any case?
>
> It is a problem... which seems to be more cost-effective solved with 
> smaller prefixes for P2P links and/or better management of the 
> neighbor cache (e.g. be more aggressive flushing/policing NC entries 
> in the incomplete state).

I agree that there are quite a few intelligent things which can be done 
on neighbour tables under attack to a certain level. People had this 
discussions [felt] like a decade ago as well and they should be in the 
archives.


> SEND seems to me like a nice idea, but overly complex for the problem 
> it's trying to address.

It is these unbacked statements which people will use to reason against 
it.
“complex” is not a cause unless it is backed by proper arguments.
“trust distribution” is a thing, which doesn’t really work in a 
coffee shop around the corner.

I do agree that SeND does not solve all the problems either but having 
had it running since Ana Kukec (some might remember her from IETF) did 
this in 2009/2010 for FreeBSD [1] we’ve been shipping a mixed 
kernel/user space solution based on the DoCoMo NTT works which alos run 
on Linux and others.  People later produced WinSeND for Windows [2] and 
their paper read a lot like Ana’s.

I have no idea how the support for major OSes and router vendors is a 
decade later, but I’d be curious if someone would do a proper survey 
and post the results.  I think that would be super helpful (not as an 
RFC, but as a “state snapshot”);  could be a blog post or a cloud 
based spreadsheet somewhere.

/bz


[1] https://wiki.freebsd.org/SOC2009AnaKukec
[2] 
https://hpi.de/meinel/security-tech/next-generation-security-engineering/ipv6-security/winsend.html 
  (I hope the link is good, I cannot currently reach their site)