Re: [v6ops] Are we competitive?

Tom Herbert <tom@herbertland.com> Tue, 16 August 2022 14:40 UTC

Return-Path: <tom@herbertland.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 CAF05C1524AB for <v6ops@ietfa.amsl.com>; Tue, 16 Aug 2022 07:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.com
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 FD0SPLex4RQ7 for <v6ops@ietfa.amsl.com>; Tue, 16 Aug 2022 07:40:13 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 25439C1522D1 for <v6ops@ietf.org>; Tue, 16 Aug 2022 07:40:13 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id w5so15212110lfq.5 for <v6ops@ietf.org>; Tue, 16 Aug 2022 07:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=hIYEZGmrMDH71LCC6gipjxG/aHwqH6TaOT/HoWHj6K8=; b=UUK2V8oyN4IDGzHqVItGy080TvQ0qvMEEFZ5rAChgduJPUxhkjYdlWpe4oProa9wSR u/d7EOl/8KrWjWfn3EdCupKpaWwUKsu9E/cRJ4SZQ4/arcAfuG0oOsBwDsyQdbf05yqX n2GLhAZC7iWz7KD6I+/K1N+kK/eB3QtAhw5W4Q9HLQ4MT0b2F9o03yd0wHX6aWqQ/km3 G4EG9fL1i907ULaAUj5+imlmoWSM/mX2DhQDxLI+A8foQzVVSQhSP5FD8s9MO+VS+gWj bTeBgPxrbiYFur7shLohyQIyFJpWTkWCG2OZFxWEe4N2TBxDCBwIeFotaapqDyW5hPzo HdUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=hIYEZGmrMDH71LCC6gipjxG/aHwqH6TaOT/HoWHj6K8=; b=5a5iCGaVuQGLbtfCZf8rq+BDvRdFgGPcCo9eU1+FrSvdI4q04sq8qv5v2hdN4jqo93 wPsDyLO/GKhset6vvZYRn9+C6Z78/KFwQYN3DqbBRwl64D5vFWyWX+xKMPYis7c9dDIr Mg6iPbVp1VNL5s1DLMevm2PrGBR5r8h1iUJfvA/hENsflsnLmq92cO6/yNFGn1EW89o4 4ykIfuSvWeCxuVwQrjJWMasHuM0jv87fIsmxvuarL1+MS2kgKigVameH9mUBnS9LND0N cZl3gVj1OYUpc17I7vuBiKDgUYQtBjL6bs/yUzyqfzMapWCE4ioVTFrUgVENmC1Vmc8U eBnA==
X-Gm-Message-State: ACgBeo3VgT6R/zIh6pARobYsz7mn8h2abUpqob6dvwtrTLhPT1bj3hgd 4FBLVM42bFIqadU4+qJ+3dGI4F74K5H2khu3DOO38wIwS9dOjh7A
X-Google-Smtp-Source: AA6agR5FMnODzastvmFtRDeOIF3HNtCCF4w6R0lS8whN3Rrv+tS5BE47tYufD+DUutOsn/H+31D2IVw0t2kf4qIh12U=
X-Received: by 2002:a05:6512:159b:b0:492:9fae:2108 with SMTP id bp27-20020a056512159b00b004929fae2108mr795346lfb.233.1660660810969; Tue, 16 Aug 2022 07:40:10 -0700 (PDT)
MIME-Version: 1.0
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> <33249103-b373-03f8-655a-71cb9751e36f@si6networks.com> <CALx6S35S+ZxsuSsC2EhwRXNR0Huis=QcZXhgOWvEcJWYTXSs3A@mail.gmail.com> <e721506d-e15b-2846-de97-7b3b10943a1c@si6networks.com>
In-Reply-To: <e721506d-e15b-2846-de97-7b3b10943a1c@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 16 Aug 2022 07:40:00 -0700
Message-ID: <CALx6S36H42wgj3QPvSHiDKc6=im_E=k4sU5qpxughU8SQEtbcw@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: IPv6 Operations <v6ops@ietf.org>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yDX80b8C1XgrX3CbkZ3Zqh2U2GE>
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: Tue, 16 Aug 2022 14:40:13 -0000

On Mon, Aug 15, 2022 at 4:38 PM Fernando Gont <fgont@si6networks.com> wrote:
>
> Tom,
>
> On 15/8/22 12:27, Tom Herbert wrote:
> [...]
> >
> > The moment someone connects to an external host on the Internet such a
> > number is leaked. For instance, if an attacker has access to an
> > Internet server with a user login, they would have the mapping from
> > address to user PII.
>
> Of course, if/when you authenticate, all bets are of. But for other
> cases, masquerading the the address does help.
>
>
>
> > For real, quantifiable privacy in Internet addressing, we need to give
> > each connection its own unique pseudo random address.
>
> Two things:
>
> 1) You say "quantifiable"... -- what are the metrics/units you are
> considering? How would you measure this quantity?
>

Hi Fernando,

Here are the criteria from draft-herbert-ipv6-prefix-address-privacy
that make good privacy in addressing quantifiable:

* Given two addresses and no other information, the desired properties
of correlating them are:

        *It may be inferred if they belong to the same organization and
          registry. This is true for any two global IP addresses.

       * It may be inferred that they belong to the same broad
          grouping, such as a geographic region, if the information is
          encoded in the organizational bits of the address.

       * No correlation can be made for a user's Personal Identifiable
Information (PII).
         This includes identity of a user as well as location (other
than broad geographic
          location as described above)

      * No topological correlation can be established. It cannot be inferred
          that the IP addresses address the same node, the addressed
          nodes reside in the same subnet, rack, or department, or that
          the nodes for the two addresses have any geographic proximity
          to one another (other than the broad geographic and organizational
          correlations described above)

      * No correlation can be made for a user's Personal Identifiable
Information (PII).
        This includes identity of a user as well as location

 > 2) Other than masquerading, the only part that you can improve in terms
> of privacy is the IID. Because the rest of the address (the prefix) does
> need to leak information about the topology -- that's why the identifier
> is called an address in the first place.

An Internet address encodes both an identifier and location in the
topology. But the problem is probably worse than you think. Some
mobile providers assign a sixty-four bit prefix to each of their
customer devices, so the upper sixty-four bits of such addresses is
sufficient as PII for the user, and RFC8981 offers no benefit for user
privacy. In other cases, a mobile device might be assigned an address
for the local cell they are in thereby encoding the user's location in
the address. If an attacker has access to the user's identity via the
exploit I described, they would also know the user's physical location
as well.

So with respect to privacy in addressing, I believe that IPv6 is
likely worse privacy than IPv4 (with CGNAT). This is bad for users who
are interested in protecting their privacy in communications (and we
should assume that all users need strong privacy in the same way they
need strong security). This is also bad for network providers that
don't want to expose their topology to the world. So IMO, IPv6 is at a
competitive disadvantage to IPv4 in this regard. This liability can be
addressed in IPv6, but we need to use the voluminous IPv6 address to
much better effect than currently done.

Tom

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