Re: [Int-area] Where/How is the features innovation happening?

Jiayihao <jiayihao@huawei.com> Tue, 21 December 2021 10:52 UTC

Return-Path: <jiayihao@huawei.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F583A077E for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 02:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 SL-7s5Ggy2wd for <int-area@ietfa.amsl.com>; Tue, 21 Dec 2021 02:52:00 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8D73A079B for <int-area@ietf.org>; Tue, 21 Dec 2021 02:52:00 -0800 (PST)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JJCrV03pkz67NNP for <int-area@ietf.org>; Tue, 21 Dec 2021 18:49:30 +0800 (CST)
Received: from kwepemm600003.china.huawei.com (7.193.23.202) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 21 Dec 2021 11:51:56 +0100
Received: from kwepemm600004.china.huawei.com (7.193.23.242) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 21 Dec 2021 18:51:54 +0800
Received: from kwepemm600004.china.huawei.com ([7.193.23.242]) by kwepemm600004.china.huawei.com ([7.193.23.242]) with mapi id 15.01.2308.020; Tue, 21 Dec 2021 18:51:54 +0800
From: Jiayihao <jiayihao@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: Where/How is the features innovation happening?
Thread-Index: AQHX9c8ck5AIu4p+/U+7/XE+cvul06w8w0UA
Date: Tue, 21 Dec 2021 10:51:54 +0000
Message-ID: <63a9be71b30e445196d4fa264d8a7454@huawei.com>
References: <0f21806312f2427dba47fab3b8259f1d@huawei.com> <CALx6S37+7ff9npk+V45_tUUWXYggD6-SdN2xumZ+QnHc+Y4qAg@mail.gmail.com>
In-Reply-To: <CALx6S37+7ff9npk+V45_tUUWXYggD6-SdN2xumZ+QnHc+Y4qAg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.167.116]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/GxQ1VPgAQWhe0jk4gZgI3KB4HkE>
Subject: Re: [Int-area] Where/How is the features innovation happening?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Dec 2021 10:52:06 -0000

Hello Tom,

Agree on that CGNAT is better on this scenario compared to IPv6 temporary address. (although draft https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-addressing-considerations/ is asking for IPv6 improvement)

However it is hard to say CGNAT is better than IPv6 temporary address because IPv6 can deploy CGNAT as well if you like(of course if one decide to embrace IPv6 reflects an preference of P2P other than a C/S mode that NAT contribute to)

Then the final concern goes to - How can we improve privacy under End-to-End Principle?

Thanks,
Yihao

-----Original Message-----
From: Tom Herbert <tom@herbertland.com> 
To: Jiayihao <jiayihao@huawei.com>
Cc: int-area@ietf.org
Subject: Re: Where/How is the features innovation happening?

On Mon, Dec 20, 2021 at 1:27 AM Jiayihao <jiayihao@huawei.com> wrote:
>
> Hello Tom,
>
>
>
> The privacy countermeasure for IPv4/IPv6 is interestingly different.
>
> IPv4 usually utilize CGNAT, i.e., M(hosts)-to-N(IPs), where M >> N so 
> that the host could remain anonymous
>
> IPv6 usually utilize Temporary address, i.e., 1(host)-to-M(IPs[at least suffix level]), where M >> 1 so that the host could remain anonymous.
>
>
>
> HOWEVER, I don’t feel any approach reaches privacy perfectly, because access network have a global perspective on M-to-N or 1-to-M mapping.
>
> For this, it is hard to be convinced that IPv4/6 itself can reach a perfect privacy.
>
Jiayihao,

Yes, the access network might out of necessity maintain the mappings that could correlate users to IP addresses. I would expect that the provider has a contractual agreement with users on how that information is protected. The concern is the rest of the Internet for which users aren't in contract with. For that perfect privacy in flow addressing is achieved if given any two packets for two different flows, no third party passively snooping the Internet would be able to correlate whether they are sourced by the same user. Perfect privacy for addressing in general then would be that a third party couldn't correlate that any two packets were sourced by the same user regardless if they are in the same flow.

As I mentioned, under the right conditions, CGNAT is sufficient to meet the perfect privacy in flow addressing. Temporary addresses can't do it if they are used for more than one connection. This is also why I believe RFC8981 is flawed. It describes the mechanisms for getting temporary addresses nicely, but offers no specific guidance as to how long the quantum for the temporary address should be used for any quantifiable level of privacy for the user.

Tom

>
>
> Thanks,
>
> Yihao Jia
>
>
>
> -----------
>
>
>
> I believe CGNAT is better than IPv6 in terms of privacy in addressing.
>
> In fact one might argue that IPv4 provides better privacy and security
>
> than IPv6 in this regard. Temporary addresses are not single use which
>
> means the attacker can correlate addresses from a user between
>
> unrelated flows during the quantum the temporary address is used. When
>
> a user changes their address, the attacker can continue monitoring if
>
> it is signaled that the address changed. Here is a fairly simple
>
> exploit I derived to do that (from
>
> draft-herbert-ipv6-prefix-address-privacy-00).
>
>
>
> The exploit is:
>
>       o An attacker creates an "always connected" app that provides 
> some
>
>         seemingly benign service and users download the app.
>
>       o The app includes some sort of persistent identity. For 
> instance,
>
>         this could be an account login.
>
>       o The backend server for the app logs the identity and IP 
> address
>
>         of a user each time they connect
>
>       o When an address change happens, existing connections on the 
> user
>
>         device are disconnected. The app will receive a notification 
> and
>
>         immediately attempt to reconnect using the new source address.
>
>       o The backend server will see the new connection and log the new
>
>         IP address as being associated with the specific user. Thus,
>
> the server has
>
>         a real-time record of users and the IP address they are using.
>
>       o The attacker intercepts packets at some point in the Internet.
>
>         The addresses in the captured packets can be time correlated
>
>         with the server database to deduce identities of parties in
>
>         communications that are unrelated to the app.
>
>
>
> The only way I see to mitigate this sort of surveillance is single use
>
> addresses. That is effectively what  CGNAT can provide.
>
>
>
> Tom