Re: [v6ops] [EXTERNAL] Re: Improving ND security

Vasilenko Eduard <> Mon, 03 August 2020 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A539D3A0C29; Mon, 3 Aug 2020 08:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BST1LY7WB8VO; Mon, 3 Aug 2020 08:37:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70C6D3A0C22; Mon, 3 Aug 2020 08:37:57 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 868E18DC2DCA0915B375; Mon, 3 Aug 2020 16:37:55 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 16:37:55 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 3 Aug 2020 18:37:54 +0300
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Mon, 3 Aug 2020 18:37:54 +0300
From: Vasilenko Eduard <>
To: "Templin (US), Fred L" <>, "Pascal Thubert (pthubert)" <>
CC: v6ops list <>, 6man <>
Thread-Topic: [EXTERNAL] Re: Improving ND security
Thread-Index: AQHWZ2MUnNPDF6+dz0W13zbI2SbhcKkiBzuAgAAHOoCABDOFgIAAQtMA
Date: Mon, 3 Aug 2020 15:37:54 +0000
Message-ID: <>
References: <> <>, <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_e743130cc74548e0b01a9b9fe27a601fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
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: Mon, 03 Aug 2020 15:38:00 -0000

IMHO: Forget about Authentication – it would not fly.
Any Authentication would need to possess a key against every neighbor.

The same RFC that you mentioned: “The receiver deems the authentication successful if the two values match.”
PKI is the best place for key materials (and much more). But only strict security requirements could push people to PKI complexity.

Compromise is needed between:

1.      Distributed database of SLAAC (6lo and SAVI are centralized)

2.      No complexity of key management (Authentication is out)

3.      Security that is possible in such circumstances (no “man-in-the-middle”, low pressure from DoS)
Full fix of all security problems are not possible.
If one would change (1) or (2) then it would be not SLAAC anymore.

From: v6ops [] On Behalf Of Templin (US), Fred L
Sent: 3 августа 2020 г. 17:23
To: Pascal Thubert (pthubert) <>
Cc: v6ops list <>rg>; 6man <>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security

Here’s another think about SEND. RFC3971 SEND says that it works in conjunction with
Cryptographically Generated addresses (CGA) per RFC3972. But, CGAs are cumbersome
to work with as the source and destination addresses of IPv6 packets, and SEND hints
that it can be used without CGA but does not tell how to do so.

But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It places a message
authentication code in the encapsulation headers of IPv6 ND messages so that the
messages can pass a rudimentary authentication check. So someone with security
experience please help me out here – is RFC4380 authentication an acceptably
secure  replacement for SEND/CGA that might be easier to work with and less

Thanks - Fred

From: ipv6 [] On Behalf Of Templin (US), Fred L
Sent: Friday, July 31, 2020 3:13 PM
To: Pascal Thubert (pthubert) <<>>
Cc: 6man <<>>; v6ops list <<>>
Subject: RE: [EXTERNAL] Re: Improving ND security

Hi Pascal, see below:

A major attack vector is an external attacker sending packets to the 2^64 or so possible addresses in the subnet.
[>] Subnet?? As in, an on-link IPv6 prefix? The large NBMA link that I want to use SEND
on will not have any of those – link-local only.

The attack causes a denial of service at the router that MUST store one packet for one second and multicast a NS lookup, which multiplies the effect.
[>] Again, we are talking about different kinds of links; there will not be any sort of
multicast explosion on the NBMA link based on a router receiving a SEND-protected
IPv6 ND message.

The attack is easy to perform from the outside and send offers no protection.
[>] For the OMNI NBMA link, the process is based on a Client sending a SEND-protected
RS message to exactly one router. The router authenticates the RS before processing it
further, which may include returning a unicasted RA. No NCEs are created until the RS
has been authenticated, and no multicast storms are initiated.

The only clear protection is to know in advance all the addresses present in the network and drop the rest. GRAND offers a way to preset the ND cache which is better than nothing but it offers no guarantee that the router has the full set of addresses I. Cache. In fact the concept of a cache is dated from the days memory was scarce and expensive. This concept is not needed And rather harmful in modern networks.
[>] The OMNI routers are not going to require any kind of ND cache presets; they
simply establish NCEs upon receipt *and* authentication of good RS messages.

Thanks - Fred



Le 31 juil. 2020 à 19:49, Templin (US), Fred L <<>> a écrit :

Hi Ted,

By “NM” I think you mean “Mobile Node?” That’s not really one of the use cases we’re talking about here. Or am I missing something?
Or, just call it a (mobile) “Stub-Network” – I think we are talking about the same
thing here.

In any case, you’re presuming some kind of trust establishment for non-router nodes, right? SEND only talks about trust establishment for routers. And, let’s be frank, doesn’t actually give us enough operational guidance that we would expect what _is_ said to be generally practicable.
OK, the specs I have been working dip their toes into the SEND pool but maybe they
should be updated to dive in completely? With an adoption call in progress, I don’t
know if it would be a good idea to make changes right now but be assured that it
will be added to the TODO list – would that be acceptable for now?

Thanks - Fred