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

"Abraham Y. Chen" <aychen@avinta.com> Tue, 28 December 2021 03:00 UTC

Return-Path: <aychen@avinta.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 AFA063A09A3 for <int-area@ietfa.amsl.com>; Mon, 27 Dec 2021 19:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=avinta.com
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 f8W5BCoHXMjV for <int-area@ietfa.amsl.com>; Mon, 27 Dec 2021 19:00:05 -0800 (PST)
Received: from mx22-1.lowesthosting.com (cp22.lowesthosting.com [23.111.133.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9F33A099E for <int-area@ietf.org>; Mon, 27 Dec 2021 19:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avinta.com; s=default; h=In-Reply-To:References:Cc:To:Subject:From:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+mXoZHp4nY1ZHUcYLr2ecNXeUFRU17d+W0kaVBFiov8=; b=x2WXgz00ynn9p0el7K+hT0z9XS RDe4TVYG2tkqIR6ViQqlGXLInXOkCR0dQuPEp0a7Gs5vHskgqFZevkH9KGetOfIR93M6pgaJuRGCa HtLpqDCnE3pD27GSWrwE/YDYB/JD2xG7B1jBkhcxrkLmXgShvKoLODAl9wiGSiJglA4graNWgsIIe Chj3gwaXzTGIkaBw5neaspOyuS6JjgMIZ6on2c66MdkSrH3UTF4PfILlNTqm6uGBguJ7ezOQ8ffME kSxpTJldKyTjK+LZIQtts8tkoRKwj0H56qI2czliEygtHQo/6F6L+X+UmXZ8R0gI442mOPyIKD4EJ 0Mbc6qTw==;
Received: from cpe-24-193-166-56.nyc.res.rr.com ([24.193.166.56]:58061 helo=[192.168.1.142]) by mx22-1.lowesthosting.com with esmtpa (Exim 4.94.2) (envelope-from <aychen@avinta.com>) id 1n22iP-0003f6-Hb; Mon, 27 Dec 2021 21:59:59 -0500
Content-Type: multipart/alternative; boundary="------------zqWy03U2pYAit9mi0Q0mVSQr"
Message-ID: <0a3711b9-0969-2eb1-15e6-3aa8354901d0@avinta.com>
Date: Mon, 27 Dec 2021 21:59:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
From: "Abraham Y. Chen" <aychen@avinta.com>
To: Jiayihao <jiayihao@huawei.com>
Cc: "tom@herbertland.com" <tom@herbertland.com>, "int-area@ietf.org" <int-area@ietf.org>
References: <7c509337-31b5-c0d2-020e-aca6fc9d344e@avinta.com> <ce16122f3387479ca4456325a6fb0a6b@huawei.com>
Content-Language: en-US
X-Priority: 1 (Highest)
In-Reply-To: <ce16122f3387479ca4456325a6fb0a6b@huawei.com>
X-Antivirus: Avast (VPS 211227-4, 12/27/2021), Outbound message
X-Antivirus-Status: Clean
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mx22-1.lowesthosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - avinta.com
X-Get-Message-Sender-Via: mx22-1.lowesthosting.com: authenticated_id: aychen@avinta.com
X-Authenticated-Sender: mx22-1.lowesthosting.com: aychen@avinta.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/V90okjakQyi1b-Q1F3gXq9DiuZw>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.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: Tue, 28 Dec 2021 03:00:11 -0000

Hi, YiHao:

0)    Hope you had a Merry Christmas as well!

1)    Re: Ur. Pts 1) & 2):    Allow me to modify and expand your 
definitions of the abbreviations, ICP & ISP, a bit to streamline our 
discussion, then focusing on related meanings of the two keyword 
prefixes, "C" and "A" in the middle of them:

     A.    ICP (Internet Content Provider):    This is the same as you 
are using.

     B.    IAP (Internet Access Provider):    This will represent the 
ISP that you are referring to.

     C.    ISP (Internet Service Provider):    This will be used as the 
general expression that covers both ICP and IAP above.

     With these, I agree in general with your analysis.

2)    From the above, there is a simpler (layman's instead of 
engineer's) way to look at this riddle. Let's consider the old fashioned 
postal service. A letter itself is the "Content". The envelop has the 
"Address". The postal service cares only what is on the envelop. In 
fact, it is commonly practiced without explicitly identified that one 
letter may have multiple layers of envelops that each is opened by the 
"Addressee" who then forward the next "Addressee" according to the 
"Address" on the inside envelop, accordingly. To a larger scale, postal 
services put envelops destined to the same city in one bag. Then, bags 
destined to the same country in one container, etc. This process is 
refined to multiple levels depending on the volume of the mail and the 
facility (routes) available for delivery. Then, the containers are 
opened progressively along the destination route. No wonder that the US 
Postal Service claimed (during the early days of the Internet) that the 
mail system was the fist "packet switching" system.

3)    So, in this analogy, the "Address" on each and every envelop has 
to be in the clear (not coded or encrypted in any sense) for the mail 
handlers to work with. It is only the most inner "Content", the letter 
itself, can have Confidential information (or encrypted if the sender 
wishes). Under this scenario, the LE (Law Enforcement) is allowed only 
to track suspected mail by the "Addresses". And, any specific 
surveillance is only authorized by court, case by case. While no one can 
prevent LE bypassing this procedure, cases built by violating this 
requirement would be the ground for being thrown out of the court.

4)    However, in the Internet environment, largely, if not most, 
Addresses are dynamic. There is no way to specify an IP Address for 
surveillance of a suspect. This gives the LE the perfect excuse to scoop 
up everything and then analyze offline. This gives them plenty of time 
to try various ways to decrypt the encoded messages and the opportunity 
to sift through everything for incidental "surprise bonus finds". The 
result is that practically no privacy is left for anyone. is means that 
all of the schemes of scrambling IP Addresses are useless at the end. 
So, why do we bother with doing so, at all?


Happy New Year!


Abe (2021-12-27 21:59)





On 2021-12-23 22:26, Jiayihao wrote:
>
> 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> 
>
>


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus