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

Jiayihao <jiayihao@huawei.com> Fri, 24 December 2021 03:26 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 1F8513A0EC7 for <int-area@ietfa.amsl.com>; Thu, 23 Dec 2021 19:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_MSPIKE_ZBI=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 mKFKGyfvCUt1 for <int-area@ietfa.amsl.com>; Thu, 23 Dec 2021 19:26:46 -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 1DFA23A0EC6 for <int-area@ietf.org>; Thu, 23 Dec 2021 19:26:46 -0800 (PST)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JKsr1435wz67mBK for <int-area@ietf.org>; Fri, 24 Dec 2021 11:24:49 +0800 (CST)
Received: from kwepemm600003.china.huawei.com (7.193.23.202) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 24 Dec 2021 04:26:42 +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; Fri, 24 Dec 2021 11:26:41 +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; Fri, 24 Dec 2021 11:26:41 +0800
From: Jiayihao <jiayihao@huawei.com>
To: "Abraham Y. Chen" <aychen@avinta.com>
CC: "tom@herbertland.com" <tom@herbertland.com>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] Where/How is the features innovation, happening? Re: 202112221726.AYC
Thread-Index: AQHX96EkMZWPJmyab0utRR1DladRlqxA4JhQ
Date: Fri, 24 Dec 2021 03:26:40 +0000
Message-ID: <ce16122f3387479ca4456325a6fb0a6b@huawei.com>
References: <7c509337-31b5-c0d2-020e-aca6fc9d344e@avinta.com>
In-Reply-To: <7c509337-31b5-c0d2-020e-aca6fc9d344e@avinta.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.167.116]
Content-Type: multipart/related; boundary="_004_ce16122f3387479ca4456325a6fb0a6bhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ZPIR1qDSvOc2Y_Wmy_5EpO01YLE>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112221726.AYC
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: Fri, 24 Dec 2021 03:26:51 -0000

Hello Abe,

Users are unwilling to be watched by any parties(ISP, and ICP also) excepts users themselves. Actually I would like to divide the arguments into 2 case: network layers and below (not completely but mostly controlled by ISP); transport layers and above (not completely but mostly controlled by ICP).

1) For transport layers and above, Encryption Everywhere (like TLS) is a good tool to provide user privacy. However, it is only a tool against ISPs, while ICPs survive and keep gaining revenue (even by selling data like the negative news of Facebook, or Meta, whatever you call it). As discussed, it is not networks faults because IP provides peer-to-peer already. You may blame CGNAT in ISP increasingly contributes to a C/S mode in replacing P2P, like in China where IPv4 addresses are scare and CGNAT is almost everywhere. However, I don’t find the situation any better in U.S. where most of IPv4 address are located. It is a business choice to overwrite the mode to be peer-ICP-peer(C/S mode) at application layer, other than utilize the P2P mode that natively provided by IP.

In this case, there are trust points and they are ICPs.

2) For network layers and below, ISP and IP still provide a pure P2P network, and Encryption in TLS do not blind ISP in IP layer since IP header is still in plaintext and almost controlled by ISP. That is to say, in an access network scenario, the access network provide can see every trace of every user at network layer level (although exclude the encrypted payload). To against this, one can use Proxy(i.e., VPN, Tor) to bypass the trace analysis just like the CGNAT does. The only difference is that detour points (Proxies) belong to a third party, not ISP.

In this case, there are trust points and they are third party proxies.

The bottom line is that trust points are everywhere explicitly or implicitly, and privacy can be leaked from every (trust) point that you trust (or have business with). No matter what network system you have, no matter it is PSTN or ATM, these trust points are just the weak points for your privacy, and the only things users can beg is that *ALL* trust points are 1) well behave/don’t be evil; 2)system is advanced enough that can’t be hacked by any others; 3) protected by law.

I would say pretty challenging and also expecting to reach that.
Network itself just cannot be bypassed in reaching that.

Merry Christmas,
Yihao


From: Abraham Y. Chen <aychen@avinta.com>
Sent: 2021年12月23日 10:01
To: Jiayihao <jiayihao@huawei.com>
Cc: tom@herbertland.com; int-area@ietf.org
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112221726.AYC
Importance: High


Hi, YiHao:

0)    I am glad that you distilled the complex and elusive privacy / security tradeoff issues to a very unique and concise perspective.

1)    Yes, the IPv4 CG-NAT and IPv6 Temporary address may seem to provide some privacy protection. However, with the availability of the computing power, these (and others such as VPN) approaches may be just ostrich mentality.  On the other hand, they provide the perfect excuse for the government (at least US) to justify for "mass surveillance". For example, the following is a recent news report which practically defeats all current "privacy protection" attempts.

    https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/

[jiayihao] there is no doubt.

2)    Rather than contradicting efforts, it is time to review whether any of these schemes such as mapping techniques really is effective for the perceived "protection". As much of the current science fiction type crime scene detective novel / movie / TV program hinted, the government probably has more capability to zero-in on anyone than an ordinary citizen can imagine, anyway. And, businesses have gathered more information about us than they will ever admit. Perhaps we should "think out of the box" by going back to the PSTN days of definitive subscriber identification systems, so that accordingly we will behave appropriately on the Internet, and the government will be allowed to only monitor suspected criminals by filing explicit (although in secret) requests, case by case, to the court for approval?



Happy Holidays!





Abe (2021-12-22 21:00 EST)



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.



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

[Image removed by sender.]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>

Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>