Re: [v6ops] Are we competitive?

Fernando Gont <fgont@si6networks.com> Mon, 15 August 2022 14:30 UTC

Return-Path: <fgont@si6networks.com>
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 ACBC5C1524B7 for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2022 07:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fp2qEMAqslK for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2022 07:30:39 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42399C14F739 for <v6ops@ietf.org>; Mon, 15 Aug 2022 07:30:39 -0700 (PDT)
Received: from [IPV6:2800:810:464:f13:6623:ffb1:f7bf:cc40] (unknown [IPv6:2800:810:464:f13:6623:ffb1:f7bf:cc40]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8FF4C28027F; Mon, 15 Aug 2022 14:30:32 +0000 (UTC)
Message-ID: <33249103-b373-03f8-655a-71cb9751e36f@si6networks.com>
Date: Mon, 15 Aug 2022 11:30:29 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: Clark Gaylord <cgaylord@vt.edu>, Gert Doering <gert@space.net>
Cc: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
References: <CAM5+tA9tOGuy8scXStxOTzWOwG_zvDHx4Hi5CwkGiYmzNLOvqw@mail.gmail.com> <9687af1f59a6492f8353ade4d920fa95@huawei.com> <CAM5+tA8UF-3ZHkE0npZ0r5sDQ+FudTSPhpWns1BsPCk=NecX+Q@mail.gmail.com> <7e4606c4534c49a593863bda870b6e63@huawei.com> <3f138b03-940a-e83a-6c6e-6039506b6e4b@gont.com.ar> <10f89b7cbe784881bd22b4af81577aa6@huawei.com> <CAN-Dau0nz0TouDnz5pei0MCmTzSbP8q+gHLx1m0sxX0hsuPX3w@mail.gmail.com> <b9f33aa499b043bb90ff926731db9739@huawei.com> <b885bdd4-d837-1eda-9614-36c76190d920@gont.com.ar> <a6975472445f49018abab153fa61b399@huawei.com> <YvoaJ+IJdl/VXYLj@Space.Net> <CADzU5g5gGOOPD8MRtwhOFF_je9p+J0sGhetcAnMoFsWVeB4KBA@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <CADzU5g5gGOOPD8MRtwhOFF_je9p+J0sGhetcAnMoFsWVeB4KBA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/N9OJOdjLboB0JZZIdMZOnnRTbgc>
Subject: Re: [v6ops] Are we competitive?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 15 Aug 2022 14:30:40 -0000

On 15/8/22 07:35, Clark Gaylord wrote:
> Hiding a random 64 bit number??

Please note:

1) The traditional SLAAC IID wasn't random, bur rather the underlying
    MAC address.

2) Windows picks a randomied but otherwwise *constant* IID -- so, for
    most practical purposes, it doesn't matter much whether it's random
    or not -- because it's constant.

3) With RFC7217, the IIDs are random (but stable) -- by design. RFC8981
    makes IIDs that vary over time -- but a) they may be stable for "long
    enough", and b) enterprises generally disable temporary addresses

4) With DHCPv6, whether the number is random or not depends on the
    DHCPv6 server implementation. And there is no formal requirement
    (IIRC) for the IIDs to be randomized.. and even less for the address
    pool to be a /64.

5) It doesn't matter how the number was selected. If the attacker can
    learn the number, and use it for the necessary period of time (which,
    with automated tools can be a really short period of time), you're
    probably better off not leaking this number.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494