IETF Logo Mail Archive

Re: [v6ops] [EXTERNAL] Improving ND security

Fernando Gont <fernando@gont.com.ar> Fri, 31 July 2020 17:56 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A463A0B73; Fri, 31 Jul 2020 10:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 bTnn6L898e97; Fri, 31 Jul 2020 10:56:02 -0700 (PDT)
Received: from tools.si6networks.com (v6toolkit.go6lab.si [91.239.96.57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BB83A0B94; Fri, 31 Jul 2020 10:56:01 -0700 (PDT)
Received: from [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b] (unknown [IPv6:2800:810:464:1f7:7c31:7d03:b423:b91b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id 555A23FFE8; Fri, 31 Jul 2020 19:55:57 +0200 (CEST)
To: Ted Lemon <mellon@fugue.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
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>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <483c9813-4a19-cb0b-b054-ef6b65202d4a@gont.com.ar>
Date: Fri, 31 Jul 2020 13:58:12 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <25FAEE9A-3D14-4428-A573-5EFE863219D2@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8epHeEQNryUD44e6kDtTBZVyZ2s>
Subject: Re: [v6ops] [EXTERNAL] Improving ND security
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 17:56:05 -0000

On 31/7/20 13:12, Ted Lemon wrote:
> On Jul 31, 2020, at 12:10 PM, Templin (US), Fred L 
> <Fred.L.Templin@boeing.com <mailto:Fred.L.Templin@boeing.com>> wrote:
>> */I like SEND, and it is written into my documents – is that enough of 
>> a push, or do I need/*
>> */to do more aggressive marketing? Interested in helping?/*
> 
> The push would have to be from somebody producing software that has 
> broad reach. And it would have to solve a real problem or nobody with 
> that reach would try to do it.
> 
> Does it solve the problem Owen was talking about (overloading neighbor 
> tables as an attack)?  

No, it doesn't.


> 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).

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

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

v2.23.0 | Report a Bug | By Email