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

From: Jiayihao <[email-masked]>
Date: Fri, 7 Jan 2022 07:29:25 +0000

Hello Abe,

Happy new year!

The postal system analogy is a good story to understand IP, but not equal to the pessimistic conclusion you made. For the conclusion part, I am fully agree with Tom’s arguments.

As you focus on IP(v4/v6) specifically, we more or less follow the logic of How TCP/IP works. Within TCP/IP, privacy can be divided into content encryption (A) and content delivery (B). A and B both belong to user privacy. However, A and B are different things.

For A, Tom’s arguments is good enough. As for B, same as Tom’s but one more thing to point. Since you care more about the LE, I would say the current countermeasures are designed for anyone except the LE because LE can force any part to disclose specific data that should be uncovered under its design philosophy.

In short, in IP ecosystem, both A and B is still worth doing. However, as I mentioned in my last mail, any design philosophy/architecture has somehow implicit *trust party*. But a LE could be All-powerful because the fundament of *trust party* is break and no *trust party* anymore if you put LE into consideration.

As you mentioned in your last email that there are conflicts requirements, it happens all the time. RFC 8890 give the answer and the direction IETF choose.

So back to the questions I am wondering: If we can upgrade the architecture somehow, can we enhance the privacy by ways that more than current countermeasures like RFC7721 can do?

Have an excellent 2022!
Best,
Yihao

From: Abraham Y. Chen <[email-masked]>
Sent: 2022年1月1日 0:58
To: Tom Herbert <[email-masked]>
Cc: Jiayihao <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112301817.AYC
Importance: High

Hi, Tom:

1)    "Your argument seems to be that we shouldn't bother with things like security or encryption at all :-) ...    ":    My apologies for getting you to an unexpected conclusion. Perhaps I failed to make an explicit statement because I thought that I was following a thread about the IPv4 or IPv6 addresses "scrambling" schemes for protecting the privacy of or increasing the security to users. That is, we should look at this subject by the "Divide & Conquer" concept. In other words, I was saying that encrypting the "Content" part as much as the sender / receiver pair agrees to. But, keep the "Address" part mostly clear. This way, the LE parties will not have the excuse of performing "mass surveillance" by scooping up everything, then take time to digest and regurgitate the "Content" for hidden treasures. (Remember the report that the German Chancellor's telephone calls were picked up by spy agencies?) Rumors have been, that high performance computer and large capacity storage device manufacturers are having a field day supplying equipment to LE organizations such as NSA because the current Internet trend.

2)    Since my engineering training started from RF (Radio Frequency or Wireless -- actually all bands from audio all the way to 60+ GHz), then telephony, and cellular phone before getting involved with the Internet, allow me to briefly describe my understanding of the characteristics of each with respect to our current discussion. Hopefully, the below can thread different fields together to clarify my point:

    A.    In the RF field, any signal that is transmitted (sent) into the "ether" is a fair game for everyone. So, there is no "Address" in the basic RF signal transmission. Most RF equipment does not transmit its identification by itself unless the user does so as part of the "Content" on purpose. For example, a commercial (AM, FM, TV) station announces its station ID, or call-sign (Address) as part of the broadcast (Content) according to FCC Rules. So, in RF communication, we concentrate only on encrypting the "Content" (such as scrambled / encode speech) for proprietary applications.

    B.    For traditional land-line telephony services, the caller's phone number (Address) is fixed by wiring (nailed up) upon subscription. Only the called party's phone number (Addressee) is dialed once to tell the switching system who is the destination party, so that the switches can make the connection. Once the called party answers, the actual session consists of only "Content" exchanges, no more "Address" information necessary. Speech scramblers may be used on either end as a pair, for private conversation (Content).

    C.   RF signals from cellular mobile phone do carry the handset (and the cell tower) identifications (Addresses) on both ends without the user's knowledge to facilitate establishing and maintaining a connection, while the user constantly crosses the boundaries between cells. Similarly, speech scramblers may be used on either end as a pair for private conversation (Content). Note that since VoIP is behind the scene these days, cellular mobile service is supported by a mixture of both the traditional telephony and the Internet infrastructures.

    D.   If we look at the Internet environment itself, it is kind like the cellular mobile phone service. It is inherently wide open like RF because packets are forwarded by unstructured mesh routers allowing everyone to listen in. Yet, each IP packet header carries the Addresses of both ends for directing routers to deliver the packet, as well as for the return packet. So, how much can a sender "hide" the identities of either or both ends for privacy while still enables the routers to deliver the packet to its intended destination effectively is a real challenge. Whatever the scheme chosen, it can not be too sophisticated to over-burden the routers which means that it is probably mot much a challenge for a perpetrator intentionally trying to crack the scheme.

3)    My sense from the above analysis is that attempting to make the "Address" part of an IP packet "cryptic" for improving the privacy / security properties of the "Content" is probably futile. The more we attempt doing it, the stronger the LEs' argument for mass surveillance, even though they probably already knew the solution.

4)    On the other hand, if we push too hard on strengthening the encryption of the "Content" without a back door, we essentially are helping the perpetrators. This is because if this part worked, the LEs will not be able to monitor and catch the criminals!

5)    So, we need to review the pros and cons of the end results, before jumping into a scheme.

Happy New Year!

Abe (2021-12-31 11:57 EST)

On 2021-12-30 13:29, Tom Herbert wrote:

On Mon, Dec 27, 2021 at 7:00 PM Abraham Y. Chen <[email-masked]<mailto:[email-masked]>> wrote:
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?

Abe,

Happy New Year!

Your argument seems to be that we shouldn't bother with things like security or encryption at all :-) While it's true that anything sent into the Internet can be intercepted and analyzed offline, it's clearly the intent of security and privacy mechanisms to make offline analysis of data ineffective or at least cost prohibitive. For encryption the calculation is pretty straightforward, the complexity and cost and breaking a cipher is generally correlated to the key size. So for any given key size, it can be determined what sort of resources are required to break the code. This is a continuous escalation as attackers gain access for more computational resources and there are breakthroughs like in quantum computing that require rethinking encryption.  But regardless, the effectiveness of encryption at any given point of time is quantifiable.

For security and privacy in IP addresses I believe we should be similarly taking a quantitative approach. This is where RFC7721 fails. The recommendation of RFC7721 is that for better security, use temporary addresses with shorter lifetimes. But the RFC doesn't attempt to quantify the relationship between address lifetime and the security that's offered or even say what specific lifetime is recommended for optimal security. For instance, if the user changes their interface address twice a day instead of once a day does that halve the chances that some may breach their security by correlating two different flows that they source from the user? Probably not. But, what if they change their address every five minutes? How much better is that than changing the address once a day? It's intuitive that it should be better security, but is it _really_ better? And if it is better, are the benefits worth the aggravation of changing the address. This is quite similar to some companies that have a policy that everyone needs to change their passwords periodically. Studies have shown that there is little quantitative value in doing this and in fact the net effect is likely less security and increased user aggravation-- even so, companies will continue to do this because it's easier to stick with the inertia of intuition.

The fix for the password problem is one time passwords (OTP) and IMO that hints at the fix for the address security problems described in RFC7712, essentially we need single use source addresses per each connection.  The security effects of single use addresses are quantifiable, i.e. given sample packets from independent two flows generated by the same user, without additional information it isn't possible for a third party to correlate that they are sourced by the same user.

Tom

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 <[email-masked]><mailto:[email-masked]>
Sent: 2021年12月23日 10:01
To: Jiayihao <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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>

---

From: Jiayihao <[email-masked]>
Date: Fri, 7 Jan 2022 07:47:57 +0000

Hi Tom,

I love your argument on RFC7721 and agree on that quantitative analysis is needed to prove that periodically source address shift is more secure, and if so, the timing to shift the address should be calculated.

Apparently a simple answer to that is OTP as you detailed. However, the sad thing is that if every Endpoint (most refer to requestor/client in IPv6) shift its source address per each connection, is it *seriously affordable* for the network (provider) that these endpoints attached to? If not, is that the argument you prefer CGNAT than IPv6 Temporary address(RFC7721) for IP layer privacy consideration?

Happy new year!
Thanks,
Yihao

From: Tom Herbert <[email-masked]>
Sent: 2021年12月31日 2:30
To: Abraham Y. Chen <[email-masked]>
Cc: Jiayihao <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Jan 2022 07:38:10 -0800

On Thu, Jan 6, 2022 at 11:48 PM Jiayihao <[email-masked]> wrote:

> Hi Tom,
>
>
>
> I love your argument on RFC7721 and agree on that quantitative analysis is
> needed to prove that periodically source address shift is more secure, and
> if so, the timing to shift the address should be calculated.
>
>
>
> Apparently a simple answer to that is OTP as you detailed. However, the
> sad thing is that if every Endpoint (most refer to requestor/client in
> IPv6) shift its source address per each connection, is it **seriously
> affordable** for the network (provider) that these endpoints attached to?
>

Hi Yihao,

It's unclear to me whether it's affordable without a specific proposal on
how to do it. In order to do this it would require a service provider to
manage and track a very large block of independent hosts addresses, however
given how other databases have been able to scale to very large datasets, I
tend to believe there is a feasible solution. I wrote a draft outlining
problem and general solutions in
https://www.ietf.org/archive/id/draft-herbert-ipv6-prefix-address-privacy-00.txt

> If not, is that the argument you prefer CGNAT than IPv6 Temporary
> address(RFC7721) for IP layer privacy consideration?
>

Objectively, it seems that CGNAT, under the right conditions, does provide
better privacy for users in IP addressing. The strength of CGNAT in terms
of privacy has also been anecdotally demonstrated by law enforcement's
concerns about it. It pains me to say that because the whole point of a 128
bit address space in IPv6 was to eliminate the NAT abomination :-)

Tom

>
>
> Happy new year!
>
> Thanks,
>
> Yihao
>
>
>
> *From:* Tom Herbert <[email-masked]>
> *Sent:* 2021年12月31日 2:30
> *To:* Abraham Y. Chen <[email-masked]>
> *Cc:* Jiayihao <[email-masked]>; [email-masked]
> *Subject:* Re: [Int-area] Where/How is the features innovation,
> happening? Re: 202112271737.AYC
>
>
>
>
>
>
>
> On Mon, Dec 27, 2021 at 7:00 PM Abraham Y. Chen <[email-masked]> wrote:
>
> Hi, YiHao:
>
>
>
> 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:
>
>
>
>     C.    ISP (Internet Service Provider):    This will be used as the
> general expression that covers both ICP and IAP above.
>
>
>
> 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?
>
>
>
> Abe,
>
>
>
> Happy New Year!
>
>
>
> Your argument seems to be that we shouldn't bother with things like
> security or encryption at all :-) While it's true that anything sent into
> the Internet can be intercepted and analyzed offline, it's clearly the
> intent of security and privacy mechanisms to make offline analysis of data
> ineffective or at least cost prohibitive. For encryption the calculation is
> pretty straightforward, the complexity and cost and breaking a cipher is
> generally correlated to the key size. So for any given key size, it can be
> determined what sort of resources are required to break the code. This is a
> continuous escalation as attackers gain access for more computational
> resources and there are breakthroughs like in quantum computing that
> require rethinking encryption.  But regardless, the effectiveness of
> encryption at any given point of time is quantifiable.
>
>
>
> For security and privacy in IP addresses I believe we should be similarly
> taking a quantitative approach. This is where RFC7721 fails. The
> recommendation of RFC7721 is that for better security, use temporary
> addresses with shorter lifetimes. But the RFC doesn't attempt to quantify
> the relationship between address lifetime and the security that's offered
> or even say what specific lifetime is recommended for optimal security. For
> instance, if the user changes their interface address twice a day instead
> of once a day does that halve the chances that some may breach their
> security by correlating two different flows that they source from the user?
> Probably not. But, what if they change their address every five minutes?
> How much better is that than changing the address once a day? It's
> intuitive that it should be better security, but is it _really_ better? And
> if it is better, are the benefits worth the aggravation of changing the
> address. This is quite similar to some companies that have a policy that
> everyone needs to change their passwords periodically. Studies have shown
> that there is little quantitative value in doing this and in fact the net
> effect is likely less security and increased user aggravation-- even so,
> companies will continue to do this because it's easier to stick with the
> inertia of intuition.
>
>
>
> The fix for the password problem is one time passwords (OTP) and IMO that
> hints at the fix for the address security problems described in RFC7712,
> essentially we need single use source addresses per each connection.  The
> security effects of single use addresses are quantifiable, i.e. given
> sample packets from independent two flows generated by the same user,
> without additional information it isn't possible for a third party to
> correlate that they are sourced by the same user.
>
>
>
> Tom
>
>
>
>
>
>
>
> Happy New Year!
>
>
>
>
>
> Abe (2021-12-27 21:59)
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> *From:* Abraham Y. Chen <[email-masked]> <[email-masked]>
> *Sent:* 2021年12月23日 10:01
> *To:* Jiayihao <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *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.
>
>
> *[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!
>
>
>
>
>
> <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>
>
>
>
>
>
>

---

From: Jiayihao <[email-masked]>
Date: Tue, 11 Jan 2022 10:02:16 +0000

Hello Tom,

Thanks for sharing draft-herbert-ipv6-prefix-address-privacy, and I am concerning the following points after I go through the draft and related references.

- Both IPv6 Temporary Address (TA6 for short) and NAT only enhance privacy against third parties except the Law Enforcement party (a party with super power).

If so, let’s focus on the privacy for those third parties:

- If a prefix is assigned to a certain entity (like a house, or a certain laboratory), privacy is still hard to reach because such entity can be correlated to just a few users, and such mapping can be easily figured out in reality.

In general, if X(X>=1) endpoints are assigned with Y(Y>=1) shared prefixes in TA6 scenarios, I feel the only ways that the privacy can be enhanced are that:
1. X >> Y, so the case is pretty similar to NAT
2. Y >> X, so the case is like any endpoint have infinite prefixes, so I just assume that each endpoint can use different prefix for each flow connect. (However in reality we would really worry about prefix consumption attack, just looks like another kind of DDoS)

Any cases else cannot improve good privacy.
HOWEVER, the suffix/IID in TA6 is out of business NO MATTER it is case 1 or case 2!

For this, I am pretty pessimistic that TA6 seems never provide practical privacy enhancement compared to IPv4, nor provide any proof in the referenced drafts.

---

Besides, as you mention ID/locator split, I am doubt that it just don’t works because although ID provide explicit identity, locators are still and always provide IMPLICIT identity just like what IPv4 did. IMO ID/locator split cannot remove the Implicit nature that locator would always be a shadow of identity.

Best Regards,
Yihao

From: Tom Herbert <[email-masked]>
Sent: 2022年1月7日 23:38
To: Jiayihao <[email-masked]>
Cc: Abraham Y. Chen <[email-masked]>; [email-masked]
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC

On Thu, Jan 6, 2022 at 11:48 PM Jiayihao <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Apparently a simple answer to that is OTP as you detailed. However, the sad thing is that if every Endpoint (most refer to requestor/client in IPv6) shift its source address per each connection, is it *seriously affordable* for the network (provider) that these endpoints attached to?

Hi Yihao,

It's unclear to me whether it's affordable without a specific proposal on how to do it. In order to do this it would require a service provider to manage and track a very large block of independent hosts addresses, however given how other databases have been able to scale to very large datasets, I tend to believe there is a feasible solution. I wrote a draft outlining problem and general solutions in https://www.ietf.org/archive/id/draft-herbert-ipv6-prefix-address-privacy-00.txt

If not, is that the argument you prefer CGNAT than IPv6 Temporary address(RFC7721) for IP layer privacy consideration?

Objectively, it seems that CGNAT, under the right conditions, does provide better privacy for users in IP addressing. The strength of CGNAT in terms of privacy has also been anecdotally demonstrated by law enforcement's concerns about it. It pains me to say that because the whole point of a 128 bit address space in IPv6 was to eliminate the NAT abomination :-)

Tom

Happy new year!
Thanks,
Yihao

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Sent: 2021年12月31日 2:30
To: Abraham Y. Chen <[email-masked]<mailto:[email-masked]>>
Cc: Jiayihao <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: "Abraham Y. Chen" <[email-masked]>
Date: Tue, 11 Jan 2022 11:22:20 -0500

Hi, YiHao:

0)    It appears to me that you are still applying your own technical 
considerations around the subject. Doing so will perpetuate the current 
stalemate. What I suggested was to step back a bit, in order to 
visualize an overall picture of the logic and interactions among the 
parties involved.

1)    " ...  I would say the current countermeasures are designed for 
anyone except the LE because LE can force any part to disclose specific 
data ... ":    Then, make this an explicit statement as the design 
criterion for the privacy measures, so that the LEs will not have the 
excuses to do mass surveillance. Bragging there is no back-door, or even 
refusing to support LE when requested, such as Apple's position on a 
criminal case sometime ago as I heard, LEs will get it done anyway by 
looking for "volunteers" from third-party encryption crackers when their 
internal resources could not. Then, the solution to the secret is out in 
the hacker community.

2)    I learned a long time ago that a sophisticated lock is out there 
for challenging a hacker to figure out a way to break into it. Way back 
when, a chemist told me that even Epoxies had solvents. So, we should 
not stretch our energy to cover too much aspects that some tend to be 
counterproductive for the society as a whole, in the long run.

Regards,

Abe (2022-01-11 11:22)

On 2022-01-07 02:29, Jiayihao wrote:
>
> Hello Abe,
>
> Happy new year!
>
> The postal system analogy is a good story to understand IP, but not 
> equal to the pessimistic conclusion you made. For the conclusion part, 
> I am fully agree with Tom’s arguments.
>
> As you focus on IP(v4/v6) specifically, we more or less follow the 
> logic of How TCP/IP works. Within TCP/IP, privacy can be divided into 
> content encryption (A) and content delivery (B). A and B both belong 
> to user privacy. However, A and B are different things.
>
> For A, Tom’s arguments is good enough. As for B, same as Tom’s but one 
> more thing to point. Since you care more about the LE, I would say the 
> current countermeasures are designed for anyone except the LE because 
> LE can force any part to disclose specific data that should be 
> uncovered under its design philosophy.
>
> In short, in IP ecosystem, both A and B is still worth doing. However, 
> as I mentioned in my last mail, any design philosophy/architecture has 
> somehow implicit **trust party**. But a LE could be All-powerful 
> because the fundament of **trust party** is break and no **trust 
> party** anymore if you put LE into consideration.
>
> As you mentioned in your last email that there are conflicts 
> requirements, it happens all the time. RFC 8890 give the answer and 
> the direction IETF choose.
>
> So back to the questions I am wondering: If we can upgrade the 
> architecture somehow, can we enhance the privacy by ways that more 
> than current countermeasures like RFC7721 can do?
>
> Have an excellent 2022!
>
> Best,
>
> Yihao
>
> *From:* Abraham Y. Chen <[email-masked]>
> *Sent:* 2022年1月1日 0:58
> *To:* Tom Herbert <[email-masked]>
> happening? Re: 202112301817.AYC
> *Importance:* High
>
> Hi, Tom:
>
> 1) "Your argument seems to be that we shouldn't bother with things 
> like security or encryption at all :-) ...    ": My apologies for 
> getting you to an unexpected conclusion. Perhaps I failed to make an 
> explicit statement because I thought that I was following a thread 
> about the IPv4 or IPv6 addresses "scrambling" schemes for protecting 
> the privacy of or increasing the security to users. That is, we should 
> look at this subject by the "Divide & Conquer" concept. In other 
> words, I was saying that encrypting the "Content" part as much as the 
> sender / receiver pair agrees to. But, keep the "Address" part mostly 
> clear. This way, the LE parties will not have the excuse of performing 
> "mass surveillance" by scooping up everything, then take time to 
> digest and regurgitate the "Content" for hidden treasures. (Remember 
> the report that the German Chancellor's telephone calls were picked up 
> by spy agencies?) Rumors have been, that high performance computer and 
> large capacity storage device manufacturers are having a field day 
> supplying equipment to LE organizations such as NSA because the 
> current Internet trend.
>
> 2) Since my engineering training started from RF (Radio Frequency or 
> Wireless -- actually all bands from audio all the way to 60+ GHz), 
> then telephony, and cellular phone before getting involved with the 
> Internet, allow me to briefly describe my understanding of the 
> characteristics of each with respect to our current discussion. 
> Hopefully, the below can thread different fields together to clarify 
> my point:
>
>     A. In the RF field, any signal that is transmitted (sent) into the 
> "ether" is a fair game for everyone. So, there is no "Address" in the 
> basic RF signal transmission. Most RF equipment does not transmit its 
> identification by itself unless the user does so as part of the 
> "Content" on purpose. For example, a commercial (AM, FM, TV) station 
> announces its station ID, or call-sign (Address) as part of the 
> broadcast (Content) according to FCC Rules. So, in RF communication, 
> we concentrate only on encrypting the "Content" (such as scrambled / 
> encode speech) for proprietary applications.
>
>     B. For traditional land-line telephony services, the caller's 
> phone number (Address) is fixed by wiring (nailed up) upon 
> subscription. Only the called party's phone number (Addressee) is 
> dialed once to tell the switching system who is the destination party, 
> so that the switches can make the connection. Once the called party 
> answers, the actual session consists of only "Content" exchanges, no 
> more "Address" information necessary. Speech scramblers may be used on 
> either end as a pair, for private conversation (Content).
>
>     C. RF signals from cellular mobile phone do carry the handset (and 
> the cell tower) identifications (Addresses) on both ends without the 
> user's knowledge to facilitate establishing and maintaining a 
> connection, while the user constantly crosses the boundaries between 
> cells. Similarly, speech scramblers may be used on either end as a 
> pair for private conversation (Content). Note that since VoIP is 
> behind the scene these days, cellular mobile service is supported by a 
> mixture of both the traditional telephony and the Internet 
> infrastructures.
>
>     D. If we look at the Internet environment itself, it is kind like 
> the cellular mobile phone service. It is inherently wide open like RF 
> because packets are forwarded by unstructured mesh routers allowing 
> everyone to listen in. Yet, each IP packet header carries the 
> Addresses of both ends for directing routers to deliver the packet, as 
> well as for the return packet. So, how much can a sender "hide" the 
> identities of either or both ends for privacy while still enables the 
> routers to deliver the packet to its intended destination effectively 
> is a real challenge. Whatever the scheme chosen, it can not be too 
> sophisticated to over-burden the routers which means that it is 
> probably mot much a challenge for a perpetrator intentionally trying 
> to crack the scheme.
>
> 3)    My sense from the above analysis is that attempting to make the 
> "Address" part of an IP packet "cryptic" for improving the privacy / 
> security properties of the "Content" is probably futile. The more we 
> attempt doing it, the stronger the LEs' argument for mass 
> surveillance, even though they probably already knew the solution.
>
> 4)    On the other hand, if we push too hard on strengthening the 
> encryption of the "Content" without a back door, we essentially are 
> helping the perpetrators. This is because if this part worked, the LEs 
> will not be able to monitor and catch the criminals!
>
>         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:
>
>         C.    ISP (Internet Service Provider):    This will be used as
>         the general expression that covers both ICP and IAP above.
>
>         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.
>
>         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?
>
>     Abe,
>
>     Happy New Year!
>
>     Your argument seems to be that we shouldn't bother with things
>     like security or encryption at all :-) While it's true that
>     anything sent into the Internet can be intercepted and analyzed
>     offline, it's clearly the intent of security and
>     privacy mechanisms to make offline analysis of data ineffective or
>     at least cost prohibitive. For encryption the calculation is
>     pretty straightforward, the complexity and cost and breaking a
>     cipher is generally correlated to the key size. So for any given
>     key size, it can be determined what sort of resources are required
>     to break the code. This is a continuous escalation as attackers
>     gain access for more computational resources and there are
>     breakthroughs like in quantum computing that require rethinking
>     encryption.  But regardless, the effectiveness of encryption at
>     any given point of time is quantifiable.
>
>     For security and privacy in IP addresses I believe we should be
>     similarly taking a quantitative approach. This is where RFC7721
>     fails. The recommendation of RFC7721 is that for better security,
>     use temporary addresses with shorter lifetimes. But the RFC
>     doesn't attempt to quantify the relationship between address
>     lifetime and the security that's offered or even say what specific
>     lifetime is recommended for optimal security. For instance, if the
>     user changes their interface address twice a day instead of once a
>     day does that halve the chances that some may breach their
>     security by correlating two different flows that they source from
>     the user? Probably not. But, what if they change their address
>     every five minutes? How much better is that than changing the
>     address once a day? It's intuitive that it should be better
>     security, but is it _really_ better? And if it is better, are
>     the benefits worth the aggravation of changing the address. This
>     is quite similar to some companies that have a policy that
>     everyone needs to change their passwords periodically. Studies
>     have shown that there is little quantitative value in doing this
>     and in fact the net effect is likely less security and increased
>     user aggravation-- even so, companies will continue to do this
>     because it's easier to stick with the inertia of intuition.
>
>     The fix for the password problem is one time passwords (OTP) and
>     IMO that hints at the fix for the address security problems
>     described in RFC7712, essentially we need single use source
>     addresses per each connection.  The security effects of single use
>     addresses are quantifiable, i.e. given sample packets from
>     independent two flows generated by the same user, without
>     additional information it isn't possible for a third party to
>             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.
>
>             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.
>
>             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.
>
>             *From:* Abraham Y. Chen <[email-masked]>
>             <mailto:[email-masked]>
>             *To:* Jiayihao <[email-masked]>
>             <mailto:[email-masked]>
>             *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.
>
>             */[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!
>
>             Image removed by sender.

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 11 Jan 2022 09:36:37 -0800

On Tue, Jan 11, 2022 at 2:02 AM Jiayihao <[email-masked]> wrote:

> Hello Tom,
>
>
>
> Thanks for sharing draft-herbert-ipv6-prefix-address-privacy, and I am
> concerning the following points after I go through the draft and related
> references.
>
>
>
> - Both IPv6 Temporary Address (TA6 for short) and NAT only enhance privacy
> against third parties except the Law Enforcement party (a party with super
> power).
>
>
>
> - If a prefix is assigned to a certain entity (like a house, or a certain
> laboratory), privacy is still hard to reach because such entity can be
> correlated to just a few users, and such mapping can be easily figured out
> in reality.
>
>
>
> In general, if X(X>=1) endpoints are assigned with Y(Y>=1) shared prefixes
> in TA6 scenarios, I feel the only ways that the privacy can be enhanced are
> that:
>
> 2. Y >> X, so the case is like any endpoint have infinite prefixes, so I
> just assume that each endpoint can use different prefix for each flow
> connect. (However in reality we would really worry about prefix consumption
> attack, just looks like another kind of DDoS)
>
>
>
Hi Yihao,

Thanks for the question. We need to consider the vastness of the IPv6
address space, and it's not prefixes that are assigned to end hosts, but
rather blocks of individual addresses that are pseudo randomly assigned out
of a provider's address prefix. Suppose that some provider only has a 64
bit prefix for assigning these addresses, and let's say they need to serve
1B users and each user has a generous 1M temporary addresses at any given
time. The number of addresses in the prefix is 1.8*10^19 addresses and the
number of addresses used at any time is 10^15 or just 0.006% of the
provider's address space.

If we compare this to NATv4, temporary IPv6 addresses have much better
scaling. Even in the base case scenario where a provider had an 8 bit IPv4
prefix so they could assign 2^24 addresses to NAT and combine it with 16
bits of port numbers that is only 40 bits of source address space. If the
mappings include destination address and port then that could provide a few
more bits but still well short of the usable address space in the example
above.

For prefix assignment, like the practice of some mobile providers to give
each end device its own 64 bit prefix seems wasteful to me and would lead
to prefix exhaustion as you mentioned. I suppose one of the ostensible
reasons to do this is for privacy, each end device could create its own
unique addresses from their prefix. But as already discussed, if all these
addresses share the same network prefix that correlates to the user's
device then there's really no privacy benefit.

> For this, I am pretty pessimistic that TA6 seems never provide practical
> privacy enhancement compared to IPv4, nor provide any proof in the
> referenced drafts.
>
>
>
> ---
>
>
>
> Besides, as you mention ID/locator split, I am doubt that it just don’t
> works because although ID provide explicit identity, locators are still and
> always provide IMPLICIT identity just like what IPv4 did. IMO ID/locator
> split cannot remove the Implicit nature that locator would always be a
> shadow of identity.
>

I would confine the ID/locator split to only internal provider use.
Externally, the only specific information that should be exposed in an IP
address is the provider's network prefix that routes a packet to the
provider's network. The externally visible address should not reveal any of
the internal structure of the provider's network and definitely no
information that could be used to deduce sensitive privacy information
about the user like location or human identity. When a packet enters the
provider's network it needs to be mapped to the real location of the
address. This already happens today in mobile networks and virtual networks
where the real location of the host is not set in the address. Once the
real location is determined, the packet is tunneled using an encapsulation
to the location and at the tunnel endpoint it's decapsulated and the
originally sent packet is delivered to the user. ID/locator split in IPv6
addresses is just an alternative for doing this compared to using a more
expensive encapsulation like GRE or VXLAN and similarly would not be
exposed to the Internet.

Tom

> *Sent:* 2022年1月7日 23:38
> *Cc:* Abraham Y. Chen <[email-masked]>; [email-masked]

---

From: Jiayihao <[email-masked]>
Date: Thu, 13 Jan 2022 06:33:07 +0000

Hello Abe,

I think we agree on that it is hard for sender to "hide" the identities in terms of IP.
And I am curious how we can step back a bit as you said. My concerns focus on that if we want improve the privacy (even if one step further), what direction could we head? I embrace any insight that can enlighten me.

As for the event you mentioned about Apple, Apple is just another trust point a lot of us trust. So back to the case that current privacy are ultimately rely on trust point. Whether we could remove the trust point is indeed a question for me.

Maybe Tor network provide an good example for the volunteer mode rather than trust point.

Thanks,
Yihao

From: Abraham Y. Chen <[email-masked]>
Sent: 2022年1月12日 0:22
To: Jiayihao <[email-masked]>
Cc: [email-masked]; Tom Herbert <[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202201111037.AYC
Importance: High

Hi, YiHao:

0)    It appears to me that you are still applying your own technical considerations around the subject. Doing so will perpetuate the current stalemate. What I suggested was to step back a bit, in order to visualize an overall picture of the logic and interactions among the parties involved.

1)    " ...  I would say the current countermeasures are designed for anyone except the LE because LE can force any part to disclose specific data ...    ":    Then, make this an explicit statement as the design criterion for the privacy measures, so that the LEs will not have the excuses to do mass surveillance. Bragging there is no back-door, or even refusing to support LE when requested, such as Apple's position on a criminal case sometime ago as I heard, LEs will get it done anyway by looking for "volunteers" from third-party encryption crackers when their internal resources could not. Then, the solution to the secret is out in the hacker community.

2)    I learned a long time ago that a sophisticated lock is out there for challenging a hacker to figure out a way to break into it. Way back when, a chemist told me that even Epoxies had solvents. So, we should not stretch our energy to cover too much aspects that some tend to be counterproductive for the society as a whole, in the long run.

Regards,

Abe (2022-01-11 11:22)

Happy new year!

Have an excellent 2022!
Best,
Yihao

From: Abraham Y. Chen <[email-masked]><mailto:[email-masked]>
Sent: 2022年1月1日 0:58
To: Tom Herbert <[email-masked]><mailto:[email-masked]>
Cc: Jiayihao <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112301817.AYC
Importance: High

Hi, Tom:

Happy New Year!

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: Jiayihao <[email-masked]>
Date: Thu, 13 Jan 2022 07:58:27 +0000

Thanks for sharing. Hope you don’t mind I rephrase it as follow:

TA6 (IPv6 Temporary address) can be classified into 3 types:
A. X devices to 1 prefix (X >> 1): good for privacy, and looks like a upgraded version of NAT in IPv6 scenarios.
B. 1 devices to 1 prefix: no use for privacy
C. 1 device to Y prefixes (Y >> 1): good for privacy, but waste of address, and we may soon back to days of IPv4 where we lack address space

Then Type A might be the only outlet for TA6 and maintain the end-to-end principle as well. However, to make TA6-TypeA really work, network provider and device still should make a deal for the following points:

1. the device get a lot of sub address slots(like you guess, 1m), and such slots should be scattered enough to avoid the consequence like TA6-TypeB. (No matter addresses come from DHCP or SLACC, but I worry the cost for SLACC because there may be too many duplicate address detection packets.)
2. the device should keep each address disposable for each connections
3. the device should regularly update these time slots (return the used slots and require new slots)

I guess this is just the (only) direction that TA6 can improve privacy. (an upgraded NAT)

Thanks for sharing insight on the ID/Loc split. Here I am wondering is that a variant of TA6-TypeA? Or I feel that it help privacy because it likes another variant of tunneling.
Similarly in draft(Table 1): https://www.ietf.org/archive/id/draft-jia-flex-ip-address-structure-00.html#tab1
A hierarchical address was proposed and it is just good for the scenario you described: The address segment 1 (outer address) is used for routing outside the network provider, and segment 2 (inner address) is used for routing inside the network provider.

I may need more time to think about it, but really good to learn and explore!

Many thanks,
Yihao

Sent: 2022年1月12日 1:37

On Tue, Jan 11, 2022 at 2:02 AM Jiayihao <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tom,

Hi Yihao,

Thanks for the question. We need to consider the vastness of the IPv6 address space, and it's not prefixes that are assigned to end hosts, but rather blocks of individual addresses that are pseudo randomly assigned out of a provider's address prefix. Suppose that some provider only has a 64 bit prefix for assigning these addresses, and let's say they need to serve 1B users and each user has a generous 1M temporary addresses at any given time. The number of addresses in the prefix is 1.8*10^19 addresses and the number of addresses used at any time is 10^15 or just 0.006% of the provider's address space.

If we compare this to NATv4, temporary IPv6 addresses have much better scaling. Even in the base case scenario where a provider had an 8 bit IPv4 prefix so they could assign 2^24 addresses to NAT and combine it with 16 bits of port numbers that is only 40 bits of source address space. If the mappings include destination address and port then that could provide a few more bits but still well short of the usable address space in the example above.

For prefix assignment, like the practice of some mobile providers to give each end device its own 64 bit prefix seems wasteful to me and would lead to prefix exhaustion as you mentioned. I suppose one of the ostensible reasons to do this is for privacy, each end device could create its own unique addresses from their prefix. But as already discussed, if all these addresses share the same network prefix that correlates to the user's device then there's really no privacy benefit.

---

I would confine the ID/locator split to only internal provider use. Externally, the only specific information that should be exposed in an IP address is the provider's network prefix that routes a packet to the provider's network. The externally visible address should not reveal any of the internal structure of the provider's network and definitely no information that could be used to deduce sensitive privacy information about the user like location or human identity. When a packet enters the provider's network it needs to be mapped to the real location of the address. This already happens today in mobile networks and virtual networks where the real location of the host is not set in the address. Once the real location is determined, the packet is tunneled using an encapsulation to the location and at the tunnel endpoint it's decapsulated and the originally sent packet is delivered to the user. ID/locator split in IPv6 addresses is just an alternative for doing this compared to using a more expensive encapsulation like GRE or VXLAN and similarly would not be exposed to the Internet.

Tom

Best Regards,
Yihao

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Sent: 2022年1月7日 23:38
To: Jiayihao <[email-masked]<mailto:[email-masked]>>
Cc: Abraham Y. Chen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202112271737.AYC

Hi Yihao,

Tom

Happy new year!
Thanks,
Yihao

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: "Abraham Y. Chen" <[email-masked]>
Date: Sun, 16 Jan 2022 12:20:34 -0500

Hi, YiHao:

1)    "...  I am curious how we can step back a bit as you said. ... 
current privacy are ultimately rely on trust point. ...":    I have 
already outlined (perhaps hinted) what is needed to deal with this 
issue. That is, we have to look at the overall environment, not just 
keep digging deeper into the technology itself. No matter how great the 
technology is, there are always ways to get around or to defeat it. Some 
are not based on technology, but business practices or just mentality. 
In the case of the APPLE refusing to support LE, it was the combination 
of business decision (The LE decided to do it by themselves and to look 
for help from "volunteers") and the technical challenge (viewed by 
"hackers" as fun with reward) that bypassed the "trust point".

2)    To demonstrate my point, I would like to share a brief history of 
a related topic, although based on an opposite initial intention, for 
you to compare and to figure out how to deal with the incident privacy / 
security goal. It was a service started with great results, but 
deteriorated by various business considerations and other influences to 
a point of nearly useless. The service was called Caller-ID. When it was 
first introduced to identify the caller for the convenience of the 
called party, it also put a big dent on telemarketers. That was because 
the capability was based on a facility inherent in the telephone system 
that no outsiders could touch. With the breakup of the Bell System, the 
Baby-Bells (There were seven to start with. They have gone through the 
M&A processes to become one AT&T again!) started to compete against one 
another. Some marketing genius invented the idea of offering (of course 
with compensation in return) big subscribers to customize their 
Caller-ID messages for various purposes, such as announcing sales. -- 
Note: Thanks to digital technology, the telephone switching equipment 
used by big business (called PABX) had become just as powerful as those 
used by local telcos (COs - Central Offices) where Caller-ID information 
originated. This allowed telemarketers (pretty big operations) to 
masquerade behind any phone number desired, such as using the same local 
exchange prefix number as that of the target subscribers to pretend 
being a neighbor. Still, a called could pick out welcomed callers by 
paying some attention to the message displayed. After VoIP became widely 
used, rather than mimicking the practice employed by cellular phone 
industry, making sense out of the VoIP based phone numbers became 
mind-boggling for practically everyone. No wonder that Robocalls became 
much prevalent than the past telemarketer calls.

https://en.wikipedia.org/wiki/Caller_ID#History

3)    With the FCC's Authentication program, the Robocalls may be 
tempered for awhile. But, the caller name has been dropped out of the 
Caller-ID message, because the carriers now treat such as their own 
valuable merchandise that the called party has to pay to receive it (Try 
figuring out how to identify such relationships and then to establish 
agreements?) An incoming call now may have a "[V]" prefix indicating it 
has passed the "Stir/Shaken" Verification process, followed by only a 
caller phone number without name which becomes pretty much the same 
challenge for most people to begin with. So, the Caller-ID service has 
pretty much lost its original intended main purpose.

https://www.fcc.gov/call-authentication

4)    In brief, Caller-ID was designed under an environment of uniformly 
structured system (the PSTN). Even so, it quickly degraded to a service 
with minimal residual value when system fragmentation, diverse marketing 
incentives, narrow-mindedness (individual's "freedom"?), etc. came into 
play. With distributed network architecture and operation philosophy as 
the foundation, I will venture to say that the Internet would have a 
hard time to just mimic the identification of the "well-behaved" 
subscribers like the original Caller-ID service, let alone hiding their 
identity and providing security. What I am saying is that we must have a 
"system view" of all parameters involved in an issue, before we could 
define what we can do and which we want to do. Then, the chosen 
technology may have a chance to deliver the expected goal. Otherwise, we 
will be just spinning the wheels on partial solutions from the diverse 
individualized perspectives.

Regards,

Abe (2022-01-16 12:20 EST)

On 2022-01-13 01:33, Jiayihao wrote:
> And I am curious how we can step back a bit as you said. My concerns 
> focus on that if we want improve the privacy (even if one step 
> further), what direction could we head? I embrace any insight that can 
> enlighten me.
>
> As for the event you mentioned about Apple, Apple is just another 
> trust point a lot of us trust. So back to the case that current 
> privacy are ultimately rely on trust point. Whether we could remove 
> the trust point is indeed a question for me.
>
> *Sent:* 2022年1月12日 0:22
> *Cc:* [email-masked]; Tom Herbert <[email-masked]>
> happening? Re: 202201111037.AYC
> *Importance:* High
>
> Hi, YiHao:
>
> considerations around the subject. Doing so will perpetuate the 
> current stalemate. What I suggested was to step back a bit, in order 
> to visualize an overall picture of the logic and interactions among 
> the parties involved.
>
> anyone except the LE because LE can force any part to disclose 
> specific data ...    ":    Then, make this an explicit statement as 
> the design criterion for the privacy measures, so that the LEs will 
> not have the excuses to do mass surveillance. Bragging there is no 
> back-door, or even refusing to support LE when requested, such as 
> Apple's position on a criminal case sometime ago as I heard, LEs will 
> get it done anyway by looking for "volunteers" from third-party 
> encryption crackers when their internal resources could not. Then, the 
> solution to the secret is out in the hacker community.
>
> for challenging a hacker to figure out a way to break into it. Way 
> back when, a chemist told me that even Epoxies had solvents. So, we 
> should not stretch our energy to cover too much aspects that some tend 
> to be counterproductive for the society as a whole, in the long run.
>
> Regards,
>
> Abe (2022-01-11 11:22)
>
>     The postal system analogy is a good story to understand IP, but
>     not equal to the pessimistic conclusion you made. For the
>     conclusion part, I am fully agree with Tom’s arguments.
>
>     logic of How TCP/IP works. Within TCP/IP, privacy can be divided
>     into content encryption (A) and content delivery (B). A and B both
>     belong to user privacy. However, A and B are different things.
>
>     For A, Tom’s arguments is good enough. As for B, same as Tom’s but
>     one more thing to point. Since you care more about the LE, I would
>     say the current countermeasures are designed for anyone except the
>     LE because LE can force any part to disclose specific data that
>     should be uncovered under its design philosophy.
>
>     In short, in IP ecosystem, both A and B is still worth doing.
>     However, as I mentioned in my last mail, any design
>     philosophy/architecture has somehow implicit **trust party**. But
>     a LE could be All-powerful because the fundament of **trust
>     party** is break and no **trust party** anymore if you put LE into
>     consideration.
>
>     requirements, it happens all the time. RFC 8890 give the answer
>     and the direction IETF choose.
>
>     *To:* Tom Herbert <[email-masked]> <mailto:[email-masked]>
>     *Cc:* Jiayihao <[email-masked]> <mailto:[email-masked]>;
>     [email-masked]
>     getting you to an unexpected conclusion. Perhaps I failed to make
>     an explicit statement because I thought that I was following a
>     thread about the IPv4 or IPv6 addresses "scrambling" schemes for
>     protecting the privacy of or increasing the security to users.
>     That is, we should look at this subject by the "Divide & Conquer"
>     concept. In other words, I was saying that encrypting the
>     "Content" part as much as the sender / receiver pair agrees to.
>     But, keep the "Address" part mostly clear. This way, the LE
>     parties will not have the excuse of performing "mass surveillance"
>     by scooping up everything, then take time to digest and
>     regurgitate the "Content" for hidden treasures. (Remember the
>     report that the German Chancellor's telephone calls were picked up
>     by spy agencies?) Rumors have been, that high performance computer
>     and large capacity storage device manufacturers are having a field
>     day supplying equipment to LE organizations such as NSA because
>     the current Internet trend.
>
>     2) Since my engineering training started from RF (Radio Frequency
>     or Wireless -- actually all bands from audio all the way to 60+
>     GHz), then telephony, and cellular phone before getting involved
>     with the Internet, allow me to briefly describe my understanding
>     of the characteristics of each with respect to our current
>     discussion. Hopefully, the below can thread different fields
>     together to clarify my point:
>
>     A.    In the RF field, any signal that is transmitted (sent) into
>     the "ether" is a fair game for everyone. So, there is no "Address"
>     in the basic RF signal transmission. Most RF equipment does not
>     transmit its identification by itself unless the user does so as
>     part of the "Content" on purpose. For example, a commercial (AM,
>     FM, TV) station announces its station ID, or call-sign (Address)
>     as part of the broadcast (Content) according to FCC Rules. So, in
>     RF communication, we concentrate only on encrypting the "Content"
>     (such as scrambled / encode speech) for proprietary applications.
>
>     dialed once to tell the switching system who is the destination
>     party, so that the switches can make the connection. Once the
>     called party answers, the actual session consists of only
>     "Content" exchanges, no more "Address" information necessary.
>     Speech scramblers may be used on either end as a pair, for private
>     conversation (Content).
>
>         C. RF signals from cellular mobile phone do carry the handset
>     (and the cell tower) identifications (Addresses) on both ends
>     without the user's knowledge to facilitate establishing and
>     maintaining a connection, while the user constantly crosses the
>     boundaries between cells. Similarly, speech scramblers may be used
>     on either end as a pair for private conversation (Content). Note
>     that since VoIP is behind the scene these days, cellular mobile
>     service is supported by a mixture of both the traditional
>     telephony and the Internet infrastructures.
>
>         D. If we look at the Internet environment itself, it is kind
>     like the cellular mobile phone service. It is inherently wide open
>     like RF because packets are forwarded by unstructured mesh routers
>     allowing everyone to listen in. Yet, each IP packet header carries
>     the Addresses of both ends for directing routers to deliver the
>     packet, as well as for the return packet. So, how much can a
>     sender "hide" the identities of either or both ends for privacy
>     while still enables the routers to deliver the packet to its
>     intended destination effectively is a real challenge. Whatever the
>     scheme chosen, it can not be too sophisticated to over-burden the
>     routers which means that it is probably mot much a challenge for a
>     perpetrator intentionally trying to crack the scheme.
>
>     3)    My sense from the above analysis is that attempting to make
>     the "Address" part of an IP packet "cryptic" for improving the
>     privacy / security properties of the "Content" is probably futile.
>     The more we attempt doing it, the stronger the LEs' argument for
>     mass surveillance, even though they probably already knew the
>     solution.
>
>     encryption of the "Content" without a back door, we essentially
>     are helping the perpetrators. This is because if this part worked,
>     the LEs will not be able to monitor and catch the criminals!
>
>             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:
>
>                 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.
>
>             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.
>
>             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?
>
>         Abe,
>
>         Happy New Year!
>
>         anything sent into the Internet can be intercepted and
>         analyzed offline, it's clearly the intent of security and
>         privacy mechanisms to make offline analysis of data
>         ineffective or at least cost prohibitive. For encryption the
>         calculation is pretty straightforward, the complexity and cost
>         and breaking a cipher is generally correlated to the key size.
>         So for any given key size, it can be determined what sort of
>         resources are required to break the code. This is a continuous
>         escalation as attackers gain access for more computational
>         resources and there are breakthroughs like in quantum
>         computing that require rethinking encryption.  But regardless,
>         the effectiveness of encryption at any given point of time is
>         quantifiable.
>
>         For security and privacy in IP addresses I believe we should
>         be similarly taking a quantitative approach. This is where
>         RFC7721 fails. The recommendation of RFC7721 is that for
>         better security, use temporary addresses with shorter
>         lifetimes. But the RFC doesn't attempt to quantify the
>         relationship between address lifetime and the security that's
>         offered or even say what specific lifetime is recommended for
>         optimal security. For instance, if the user changes their
>         interface address twice a day instead of once a day does that
>         halve the chances that some may breach their security by
>         correlating two different flows that they source from the
>         user? Probably not. But, what if they change their address
>         the benefits worth the aggravation of changing the address.
>         This is quite similar to some companies that have a policy
>         that everyone needs to change their passwords periodically.
>         Studies have shown that there is little quantitative value in
>         doing this and in fact the net effect is likely less security
>         and increased user aggravation-- even so, companies will
>         continue to do this because it's easier to stick with the
>         inertia of intuition.
>
>         The fix for the password problem is one time passwords (OTP)
>         and IMO that hints at the fix for the address security
>         problems described in RFC7712, essentially we need single use
>         source addresses per each connection.  The security effects of
>         single use addresses are quantifiable, i.e. given sample
>         packets from independent two flows generated by the same user,
>         without additional information it isn't possible for a third
>         party to correlate that they are sourced by the same user.
>
>         Tom
>
>             Happy New Year!
>
>             Abe (2021-12-27 21:59)
>
>                 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.
>
>                 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.
>
>                 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.
>
>                 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/>
>
>                 "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

---

From: Jiayihao <[email-masked]>
Date: Mon, 24 Jan 2022 03:11:36 +0000

Hello Abe,

0) Really appreciate sharing the story of Call-ID. It is really a fresh term and tech to me, and seems I haven’t got a chance to experience the Call-ID time. Really good to learn.

1) Based on my rough understanding of Call-ID, it is a classical example of how we choice to name an object. Assuming we want to visit the Apple Campus (the Headquarters of Apple Inc.) with our Google map, we can type a) Apple Campus (Name); b) 1 Infinite Loop, Cupertino, CA 95014 (Locator 1); c) 37.33182°N 122.03118°W(Locator 2). The only difference is which one people would like to use, or which one is more friendly to human in their practice. My understanding is that people prefer Name while computer prefer Locator, so usually a system would like to provide the Name to users and build a subordinate Mapping system as while to corelate the name and the locator. DNS is just a good example we use every day.

2) Agree on your insight that authentication to just Call-ID(phone number) do not make much sense because it only provide the authentication of Locator, while leave the Name, which users are more willing to perceive, unauthenticated. I find that IETF STIR wg is working on this topic. Although I am not familiar right now, I feel a PKI/Certificate should be involved in order to gain practical value.

3) In a peer to peer context, IMHO, the Name based interface is more practically valuable compared to Locator based one, just like the name instead of phone number in the Call-ID case because the numbers do not offer any meaning even it is authenticated.

4) Agree on “….that we must have a "system view"….” and “…Some are not based on technology, but business practices or just mentality….”. But I feel there is no Silver Bullet and I don’t have an answer yet. It is really enjoyable to discuss and I will keep thinking on this.

Many thanks, Abe,
Yihao

From: Abraham Y. Chen <[email-masked]>
Sent: 2022年1月17日 1:21
To: Jiayihao <[email-masked]>
Cc: [email-masked]; Tom Herbert <[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202201152233.AYC
Importance: High

Hi, YiHao:

1)    "...  I am curious how we can step back a bit as you said. ... current privacy are ultimately rely on trust point. ...":    I have already outlined (perhaps hinted) what is needed to deal with this issue. That is, we have to look at the overall environment, not just keep digging deeper into the technology itself. No matter how great the technology is, there are always ways to get around or to defeat it. Some are not based on technology, but business practices or just mentality. In the case of the APPLE refusing to support LE, it was the combination of business decision (The LE decided to do it by themselves and to look for help from "volunteers") and the technical challenge (viewed by "hackers" as fun with reward) that bypassed the "trust point".

2)    To demonstrate my point, I would like to share a brief history of a related topic, although based on an opposite initial intention, for you to compare and to figure out how to deal with the incident privacy / security goal. It was a service started with great results, but deteriorated by various business considerations and other influences to a point of nearly useless. The service was called Caller-ID. When it was first introduced to identify the caller for the convenience of the called party, it also put a big dent on telemarketers. That was because the capability was based on a facility inherent in the telephone system that no outsiders could touch. With the breakup of the Bell System, the Baby-Bells (There were seven to start with. They have gone through the M&A processes to become one AT&T again!) started to compete against one another. Some marketing genius invented the idea of offering (of course with compensation in return) big subscribers to customize their Caller-ID messages for various purposes, such as announcing sales. -- Note: Thanks to digital technology, the telephone switching equipment used by big business (called PABX) had become just as powerful as those used by local telcos (COs - Central Offices) where Caller-ID information originated. This allowed telemarketers (pretty big operations) to masquerade behind any phone number desired, such as using the same local exchange prefix number as that of the target subscribers to pretend being a neighbor. Still, a called could pick out welcomed callers by paying some attention to the message displayed. After VoIP became widely used, rather than mimicking the practice employed by cellular phone industry, making sense out of the VoIP based phone numbers became mind-boggling for practically everyone. No wonder that Robocalls became much prevalent than the past telemarketer calls.

3)    With the FCC's Authentication program, the Robocalls may be tempered for awhile. But, the caller name has been dropped out of the Caller-ID message, because the carriers now treat such as their own valuable merchandise that the called party has to pay to receive it (Try figuring out how to identify such relationships and then to establish agreements?) An incoming call now may have a "[V]" prefix indicating it has passed the "Stir/Shaken" Verification process, followed by only a caller phone number without name which becomes pretty much the same challenge for most people to begin with. So, the Caller-ID service has pretty much lost its original intended main purpose.

4)    In brief, Caller-ID was designed under an environment of uniformly structured system (the PSTN). Even so, it quickly degraded to a service with minimal residual value when system fragmentation, diverse marketing incentives, narrow-mindedness (individual's "freedom"?), etc. came into play. With distributed network architecture and operation philosophy as the foundation, I will venture to say that the Internet would have a hard time to just mimic the identification of the "well-behaved" subscribers like the original Caller-ID service, let alone hiding their identity and providing security. What I am saying is that we must have a "system view" of all parameters involved in an issue, before we could define what we can do and which we want to do. Then, the chosen technology may have a chance to deliver the expected goal. Otherwise, we will be just spinning the wheels on partial solutions from the diverse individualized perspectives.

Regards,

Thanks,
Yihao

From: Abraham Y. Chen <[email-masked]><mailto:[email-masked]>
Sent: 2022年1月12日 0:22
To: Jiayihao <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Tom Herbert <[email-masked]><mailto:[email-masked]>
Subject: Re: [Int-area] Where/How is the features innovation, happening? Re: 202201111037.AYC
Importance: High

Hi, YiHao:

Regards,

Abe (2022-01-11 11:22)

Happy new year!

Have an excellent 2022!
Best,
Yihao

Hi, Tom:

Happy New Year!

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: "Abraham Y. Chen" <[email-masked]>
Date: Mon, 24 Jan 2022 14:30:54 -0500

Hi, YiHao:

1)    Re: Ur. Pt. 0): I am getting curious. May I ask where are you and 
how old are you? May be not landline. But, cellular mobile phone 
services always have at least the numerical part of the Caller-ID 
function, due to concerns such as who is going to pay for the air-time.

2)    Re: Ur. Pts. 1) & 3):    Good analysis. As to DNS, it is an 
unnecessary "reverse" effort relative to the white-book practice in the 
PSTN field.

3)    Re: Ur. Pts. 2) & 4):    " ...  PKI/Certificate ...   ":    I do 
not believe this is necessary if we review the subject from the ground up.

Regards,

Abe (2022-01-24 14:30 EST)

On 2022-01-23 22:11, Jiayihao wrote:
>
> Hello Abe,
>
> 0) Really appreciate sharing the story of Call-ID. It is really a 
> fresh term and tech to me, and seems I haven’t got a chance to 
> experience the Call-ID time. Really good to learn.
>
> 1) Based on my rough understanding of Call-ID, it is a classical 
> example of how we choice to name an object. Assuming we want to visit 
> the Apple Campus (the Headquarters of Apple Inc.) with our Google map, 
> we can type a) Apple Campus (Name); b) 1 Infinite Loop, Cupertino, CA 
> 95014 (Locator 1); c) 37.33182°N 122.03118°W(Locator 2). The only 
> difference is which one people would like to use, or which one is more 
> friendly to human in their practice. My understanding is that people 
> prefer Name while computer prefer Locator, so usually a system would 
> like to provide the Name to users and build a subordinate Mapping 
> system as while to corelate the name and the locator. DNS is just a 
> good example we use every day.
>
> 2) Agree on your insight that authentication to just Call-ID(phone 
> number) do not make much sense because it only provide the 
> authentication of Locator, while leave the Name, which users are more 
> willing to perceive, unauthenticated. I find that IETF STIR wg is 
> working on this topic. Although I am not familiar right now, I feel a 
> PKI/Certificate should be involved in order to gain practical value.
>
> 3) In a peer to peer context, IMHO, the Name based interface is more 
> practically valuable compared to Locator based one, just like the name 
> instead of phone number in the Call-ID case because the numbers do not 
> offer any meaning even it is authenticated.
>
> 4) Agree on “….that we must have a "system view"….” and “…Some are not 
> based on technology, but business practices or just mentality….”. But 
> I feel there is no Silver Bullet and I don’t have an answer yet. It is 
> really enjoyable to discuss and I will keep thinking on this.
>
> Many thanks, Abe,
>
> Yihao
>
> *Sent:* 2022年1月17日 1:21
> happening? Re: 202201152233.AYC
> *Importance:* High
>
> Hi, YiHao:
>
> keep digging deeper into the technology itself. No matter how great 
> the technology is, there are always ways to get around or to defeat 
> it. Some are not based on technology, but business practices or just 
> mentality. In the case of the APPLE refusing to support LE, it was the 
> combination of business decision (The LE decided to do it by 
> themselves and to look for help from "volunteers") and the technical 
> challenge (viewed by "hackers" as fun with reward) that bypassed the 
> "trust point".
>
> 2)    To demonstrate my point, I would like to share a brief history 
> of a related topic, although based on an opposite initial intention, 
> for you to compare and to figure out how to deal with the incident 
> privacy / security goal. It was a service started with great results, 
> but deteriorated by various business considerations and other 
> influences to a point of nearly useless. The service was called 
> Caller-ID. When it was first introduced to identify the caller for the 
> convenience of the called party, it also put a big dent on 
> telemarketers. That was because the capability was based on a facility 
> inherent in the telephone system that no outsiders could touch. With 
> the breakup of the Bell System, the Baby-Bells (There were seven to 
> start with. They have gone through the M&A processes to become one 
> AT&T again!) started to compete against one another. Some marketing 
> genius invented the idea of offering (of course with compensation in 
> return) big subscribers to customize their Caller-ID messages for 
> various purposes, such as announcing sales. -- Note: Thanks to digital 
> technology, the telephone switching equipment used by big business 
> (called PABX) had become just as powerful as those used by local 
> telcos (COs - Central Offices) where Caller-ID information originated. 
> This allowed telemarketers (pretty big operations) to masquerade 
> behind any phone number desired, such as using the same local exchange 
> prefix number as that of the target subscribers to pretend being a 
> neighbor. Still, a called could pick out welcomed callers by paying 
> some attention to the message displayed. After VoIP became widely 
> mind-boggling for practically everyone. No wonder that Robocalls 
> became much prevalent than the past telemarketer calls.
>
>
> valuable merchandise that the called party has to pay to receive it 
> (Try figuring out how to identify such relationships and then to 
> establish agreements?) An incoming call now may have a "[V]" prefix 
> indicating it has passed the "Stir/Shaken" Verification process, 
> followed by only a caller phone number without name which becomes 
> pretty much the same challenge for most people to begin with. So, the 
> Caller-ID service has pretty much lost its original intended main 
> purpose.
>
> 4)    In brief, Caller-ID was designed under an environment of 
> uniformly structured system (the PSTN). Even so, it quickly degraded 
> to a service with minimal residual value when system fragmentation, 
> diverse marketing incentives, narrow-mindedness (individual's 
> "freedom"?), etc. came into play. With distributed network 
> architecture and operation philosophy as the foundation, I will 
> venture to say that the Internet would have a hard time to just mimic 
> the identification of the "well-behaved" subscribers like the original 
> Caller-ID service, let alone hiding their identity and providing 
> security. What I am saying is that we must have a "system view" of all 
> parameters involved in an issue, before we could define what we can do 
> and which we want to do. Then, the chosen technology may have a chance 
> to deliver the expected goal. Otherwise, we will be just spinning the 
> wheels on partial solutions from the diverse individualized perspectives.
>
> Regards,
>
>     And I am curious how we can step back a bit as you said. My
>     concerns focus on that if we want improve the privacy (even if one
>     step further), what direction could we head? I embrace any insight
>     that can enlighten me.
>
>     privacy are ultimately rely on trust point. Whether we could
>     remove the trust point is indeed a question for me.
>
>     *To:* Jiayihao <[email-masked]> <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     0)    It appears to me that you are still applying your own
>     technical considerations around the subject. Doing so will
>     perpetuate the current stalemate. What I suggested was to step
>     back a bit, in order to visualize an overall picture of the logic
>     and interactions among the parties involved.
>
>     1)    " ...  I would say the current countermeasures are designed
>     for anyone except the LE because LE can force any part to disclose
>     specific data ...    ":    Then, make this an explicit statement
>     as the design criterion for the privacy measures, so that the LEs
>     will not have the excuses to do mass surveillance. Bragging there
>     is no back-door, or even refusing to support LE when requested,
>     such as Apple's position on a criminal case sometime ago as I
>     heard, LEs will get it done anyway by looking for "volunteers"
>     from third-party encryption crackers when their internal resources
>     could not. Then, the solution to the secret is out in the hacker
>     community.
>
>     2)    I learned a long time ago that a sophisticated lock is out
>     there for challenging a hacker to figure out a way to break into
>     it. Way back when, a chemist told me that even Epoxies had
>     solvents. So, we should not stretch our energy to cover too much
>     aspects that some tend to be counterproductive for the society as
>     a whole, in the long run.
>
>     Regards,
>
>     Abe (2022-01-11 11:22)
>
>         The postal system analogy is a good story to understand IP,
>         but not equal to the pessimistic conclusion you made. For the
>         As you focus on IP(v4/v6) specifically, we more or less follow
>         the logic of How TCP/IP works. Within TCP/IP, privacy can be
>         divided into content encryption (A) and content delivery (B).
>         A and B both belong to user privacy. However, A and B are
>         different things.
>
>         For A, Tom’s arguments is good enough. As for B, same as Tom’s
>         but one more thing to point. Since you care more about the LE,
>         I would say the current countermeasures are designed for
>         specific data that should be uncovered under its design
>         philosophy.
>
>         philosophy/architecture has somehow implicit **trust party**.
>         But a LE could be All-powerful because the fundament of
>         **trust party** is break and no **trust party** anymore if you
>         put LE into consideration.
>
>         requirements, it happens all the time. RFC 8890 give the
>         answer and the direction IETF choose.
>
>         architecture somehow, can we enhance the privacy by ways that
>         more than current countermeasures like RFC7721 can do?
>
>         Have an excellent 2022!
>
>         Best,
>
>         Yihao
>
>         <mailto:[email-masked]>
>         *Cc:* Jiayihao <[email-masked]>
>         <mailto:[email-masked]>; [email-masked]
>         innovation, happening? Re: 202112301817.AYC
>         *Importance:* High
>
>         Hi, Tom:
>
>         1) "Your argument seems to be that we shouldn't bother with
>         things like security or encryption at all :-) ...    ":    My
>         apologies for getting you to an unexpected conclusion. Perhaps
>         I failed to make an explicit statement because I thought that
>         I was following a thread about the IPv4 or IPv6 addresses
>         "scrambling" schemes for protecting the privacy of or
>         increasing the security to users. That is, we should look at
>         this subject by the "Divide & Conquer" concept. In other
>         words, I was saying that encrypting the "Content" part as much
>         as the sender / receiver pair agrees to. But, keep the
>         "Address" part mostly clear. This way, the LE parties will not
>         have the excuse of performing "mass surveillance" by scooping
>         up everything, then take time to digest and regurgitate the
>         "Content" for hidden treasures. (Remember the report that the
>         German Chancellor's telephone calls were picked up by spy
>         agencies?) Rumors have been, that high performance computer
>         and large capacity storage device manufacturers are having a
>         field day supplying equipment to LE organizations such as NSA
>         because the current Internet trend.
>
>         2) Since my engineering training started from RF (Radio
>         Frequency or Wireless -- actually all bands from audio all the
>         way to 60+ GHz), then telephony, and cellular phone before
>         getting involved with the Internet, allow me to briefly
>         describe my understanding of the characteristics of each with
>         respect to our current discussion. Hopefully, the below can
>         thread different fields together to clarify my point:
>
>         A.    In the RF field, any signal that is transmitted (sent)
>         into the "ether" is a fair game for everyone. So, there is no
>         "Address" in the basic RF signal transmission. Most RF
>         equipment does not transmit its identification by itself
>         unless the user does so as part of the "Content" on purpose.
>         For example, a commercial (AM, FM, TV) station announces its
>         station ID, or call-sign (Address) as part of the broadcast
>         (Content) according to FCC Rules. So, in RF communication, we
>         concentrate only on encrypting the "Content" (such as
>         scrambled / encode speech) for proprietary applications.
>
>         B.    For traditional land-line telephony services, the
>         caller's phone number (Address) is fixed by wiring (nailed up)
>         upon subscription. Only the called party's phone number
>         (Addressee) is dialed once to tell the switching system who is
>         the destination party, so that the switches can make the
>         connection. Once the called party answers, the actual session
>         consists of only "Content" exchanges, no more "Address"
>         information necessary. Speech scramblers may be used on either
>         end as a pair, for private conversation (Content).
>
>         C.   RF signals from cellular mobile phone do carry the
>         handset (and the cell tower) identifications (Addresses) on
>         both ends without the user's knowledge to facilitate
>         establishing and maintaining a connection, while the user
>         constantly crosses the boundaries between cells. Similarly,
>         speech scramblers may be used on either end as a pair for
>         private conversation (Content). Note that since VoIP is behind
>         the scene these days, cellular mobile service is supported by
>         a mixture of both the traditional telephony and the Internet
>         infrastructures.
>
>         like the cellular mobile phone service. It is inherently wide
>         open like RF because packets are forwarded by unstructured
>         mesh routers allowing everyone to listen in. Yet, each IP
>         packet header carries the Addresses of both ends for directing
>         routers to deliver the packet, as well as for the return
>         packet. So, how much can a sender "hide" the identities of
>         either or both ends for privacy while still enables the
>         routers to deliver the packet to its intended destination
>         effectively is a real challenge. Whatever the scheme chosen,
>         it can not be too sophisticated to over-burden the routers
>         which means that it is probably mot much a challenge for a
>         privacy / security properties of the "Content" is probably
>         futile. The more we attempt doing it, the stronger the LEs'
>         argument for mass surveillance, even though they probably
>         already knew the solution.
>
>         encryption of the "Content" without a back door, we
>         essentially are helping the perpetrators. This is because if
>         this part worked, the LEs will not be able to monitor and
>         catch the criminals!
>
>                 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:
>
>                     C.    ISP (Internet Service Provider):    This
>                 will be used as the general expression that covers
>                 both ICP and IAP above.
>
>                 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
>                 "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
>                 surveillance is only authorized by court, case by
>                 case. While no one can prevent LE bypassing this
>                 procedure, cases built by violating this requirement
>                 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
>             Your argument seems to be that we shouldn't bother with
>             things like security or encryption at all :-) While it's
>             true that anything sent into the Internet can be
>             intercepted and analyzed offline, it's clearly the intent
>             of security and privacy mechanisms to make offline
>             analysis of data ineffective or at least cost prohibitive.
>             For encryption the calculation is pretty straightforward,
>             the complexity and cost and breaking a cipher is generally
>             correlated to the key size. So for any given key size, it
>             can be determined what sort of resources are required to
>             break the code. This is a continuous escalation as
>             attackers gain access for more computational resources and
>             there are breakthroughs like in quantum computing that
>             require rethinking encryption.  But regardless, the
>             effectiveness of encryption at any given point of time is
>             quantifiable.
>
>             For security and privacy in IP addresses I believe we
>             should be similarly taking a quantitative approach. This
>             is where RFC7721 fails. The recommendation of RFC7721 is
>             that for better security, use temporary addresses with
>             shorter lifetimes. But the RFC doesn't attempt to quantify
>             the relationship between address lifetime and the security
>             that's offered or even say what specific lifetime is
>             recommended for optimal security. For instance, if the
>             user changes their interface address twice a day instead
>             of once a day does that halve the chances that some may
>             breach their security by correlating two different flows
>             that they source from the user? Probably not. But, what if
>             they change their address every five minutes? How much
>             better is that than changing the address once a day? It's
>             intuitive that it should be better security, but is it
>             _really_ better? And if it is better, are the benefits
>             worth the aggravation of changing the address. This is
>             quite similar to some companies that have a policy that
>             everyone needs to change their passwords periodically.
>             Studies have shown that there is little quantitative value
>             in doing this and in fact the net effect is likely less
>             security and increased user aggravation-- even so,
>             companies will continue to do this because it's easier to
>             stick with the inertia of intuition.
>
>             The fix for the password problem is one time passwords
>             (OTP) and IMO that hints at the fix for the address
>             security problems described in RFC7712, essentially we
>             need single use source addresses per each connection.  The
>             security effects of single use addresses are quantifiable,
>             i.e. given sample packets from independent two flows
>             generated by the same user, without additional information
>             it isn't possible for a third party to correlate that they
>             are sourced by the same user.
>
>             Tom
>
>                 Happy New Year!
>
>                 Abe (2021-12-27 21:59)
>
>                     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).
>
>                     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.
>
>                     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.
>
>                     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.
>
>                     *Subject:* Re: [Int-area] Where/How is the
>                     features innovation, happening? Re: 202112221726.AYC
>                     *Importance:* High
>
>                     Hi, YiHao:
>
>                     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.
>
>                     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

---

From: Jiayihao <[email-masked]>
Date: Tue, 25 Jan 2022 03:42:53 +0000

Hello Abe,

0) Sorry I get it confused and assume that the a) Caller-ID and b) “incoming caller number” are different things. If b) is part of a), I get it wrong. I currently living in China, and my carrier always bring the b) “incoming caller number” each time I get a call, so probably still a modern life style : )

1) "... PKI/Certificate ..." is a patch-style tech and it works quite well, ant it is true things are different if we built a system from scratch. But is there anything you mean behind it that preform equally or better compare to " ...  PKI/Certificate ...   " (in the context of Caller-ID or others)?

Thanks,
Yihao

From: Abraham Y. Chen <[email-masked]>
Sent: 2022年1月25日 3:31
To: Jiayihao <[email-masked]>
Cc: [email-masked]; Tom Herbert <[email-masked]>
Subject: 202201241417.AYC Re: [Int-area] Where/How is the features innovation, happening? Re: 202201152233.AYC
Importance: High

Hi, YiHao:

1)    Re: Ur. Pt. 0):    I am getting curious. May I ask where are you and how old are you? May be not landline. But, cellular mobile phone services always have at least the numerical part of the Caller-ID function, due to concerns such as who is going to pay for the air-time.

2)    Re: Ur. Pts. 1) & 3):    Good analysis. As to DNS, it is an unnecessary "reverse" effort relative to the white-book practice in the PSTN field.

3)    Re: Ur. Pts. 2) & 4):    " ...  PKI/Certificate ...   ":    I do not believe this is necessary if we review the subject from the ground up.

Regards,

Many thanks, Abe,
Yihao

Hi, YiHao:

Regards,

Thanks,
Yihao

Hi, YiHao:

Regards,

Abe (2022-01-11 11:22)

Happy new year!

Have an excellent 2022!
Best,
Yihao

Hi, Tom:

Happy New Year!

Abe,

Happy New Year!

Tom

Happy New Year!

Abe (2021-12-27 21:59)

Merry Christmas,
Yihao

Hi, YiHao:

Happy Holidays!

Hello Tom,

Thanks,

Yihao Jia

-----------

The exploit is:

the server has

Tom

---

From: "Abraham Y. Chen" <[email-masked]>
Date: Tue, 25 Jan 2022 07:29:33 -0500

Hi, YiHao:

0)    Re: Ur. Pt. 0): Correct. However, the Caller-ID terminology was 
introduced when the caller's name was displayed on Called's phone. So, 
when only b) is shown, it is at best a subset, or the minor part, of the 
Caller-ID service.

1)    Re: Ur. Pt. 1): Why do you need a way to certify / authenticate a 
caller if a system is set up with explicit originator identification in 
the first place?

Regards,

Abe (2022-01-25 07:29)

On 2022-01-24 22:42, Jiayihao wrote:
>
> Hello Abe,
>
> 0) Sorry I get it confused and assume that the a) Caller-ID and b) 
> “incoming caller number” are different things. If b) is part of a), I 
> get it wrong. I currently living in China, and my carrier always bring 
> the b) “incoming caller number” each time I get a call, so probably 
> still a modern life style : )
>
> 1) "... PKI/Certificate ..." is a patch-style tech and it works quite 
> well, ant it is true things are different if we built a system from 
> scratch. But is there anything you mean behind it that preform equally 
> or better compare to " ...  PKI/Certificate ...   " (in the context of 
> Caller-ID or others)?
>
> Thanks,
>
> Yihao
>
> *Sent:* 2022年1月25日 3:31
> *Subject:* 202201241417.AYC Re: [Int-area] Where/How is the features 
> innovation, happening? Re: 202201152233.AYC
> *Importance:* High
>
> Hi, YiHao:
>
> 1)    Re: Ur. Pt. 0):    I am getting curious. May I ask where are you 
> and how old are you? May be not landline. But, cellular mobile phone 
> unnecessary "reverse" effort relative to the white-book practice in 
> the PSTN field.
>
>     example of how we choice to name an object. Assuming we want to
>     visit the Apple Campus (the Headquarters of Apple Inc.) with our
>     Google map, we can type a) Apple Campus (Name); b) 1 Infinite
>     Loop, Cupertino, CA 95014 (Locator 1); c) 37.33182°N
>     122.03118°W(Locator 2). The only difference is which one people
>     would like to use, or which one is more friendly to human in their
>     practice. My understanding is that people prefer Name while
>     computer prefer Locator, so usually a system would like to provide
>     the Name to users and build a subordinate Mapping system as while
>     to corelate the name and the locator. DNS is just a good example
>     we use every day.
>
>     authentication of Locator, while leave the Name, which users are
>     more willing to perceive, unauthenticated. I find that IETF STIR
>     wg is working on this topic. Although I am not familiar right now,
>     I feel a PKI/Certificate should be involved in order to gain
>     practical value.
>
>     3) In a peer to peer context, IMHO, the Name based interface is
>     more practically valuable compared to Locator based one, just like
>     the name instead of phone number in the Call-ID case because the
>     numbers do not offer any meaning even it is authenticated.
>
>     4) Agree on “….that we must have a "system view"….” and “…Some are
>     not based on technology, but business practices or just
>     mentality….”. But I feel there is no Silver Bullet and I don’t
>     have an answer yet. It is really enjoyable to discuss and I will
>     keep thinking on this.
>
>     Many thanks, Abe,
>
>     Yihao
>
>     current privacy are ultimately rely on trust point. ...":    I
>     have already outlined (perhaps hinted) what is needed to deal with
>     this issue. That is, we have to look at the overall environment,
>     not just keep digging deeper into the technology itself. No matter
>     how great the technology is, there are always ways to get around
>     or to defeat it. Some are not based on technology, but business
>     practices or just mentality. In the case of the APPLE refusing to
>     support LE, it was the combination of business decision (The LE
>     decided to do it by themselves and to look for help from
>     "volunteers") and the technical challenge (viewed by "hackers" as
>     fun with reward) that bypassed the "trust point".
>
>     2)    To demonstrate my point, I would like to share a brief
>     history of a related topic, although based on an opposite initial
>     intention, for you to compare and to figure out how to deal with
>     the incident privacy / security goal. It was a service started
>     with great results, but deteriorated by various business
>     considerations and other influences to a point of nearly useless.
>     The service was called Caller-ID. When it was first introduced to
>     identify the caller for the convenience of the called party, it
>     also put a big dent on telemarketers. That was because the
>     capability was based on a facility inherent in the telephone
>     system that no outsiders could touch. With the breakup of the Bell
>     System, the Baby-Bells (There were seven to start with. They have
>     gone through the M&A processes to become one AT&T again!) started
>     to compete against one another. Some marketing genius invented the
>     idea of offering (of course with compensation in return) big
>     subscribers to customize their Caller-ID messages for various
>     purposes, such as announcing sales. -- Note: Thanks to digital
>     telcos (COs - Central Offices) where Caller-ID information
>     masquerade behind any phone number desired, such as using the same
>     local exchange prefix number as that of the target subscribers to
>     pretend being a neighbor. Still, a called could pick out welcomed
>     callers by paying some attention to the message displayed. After
>     VoIP became widely used, rather than mimicking the practice
>     employed by cellular phone industry, making sense out of the VoIP
>     based phone numbers became mind-boggling for practically everyone.
>     No wonder that Robocalls became much prevalent than the past
>     telemarketer calls.
>
>
>     tempered for awhile. But, the caller name has been dropped out of
>     the Caller-ID message, because the carriers now treat such as
>     their own valuable merchandise that the called party has to pay to
>     receive it (Try figuring out how to identify such relationships
>     and then to establish agreements?) An incoming call now may have a
>     "[V]" prefix indicating it has passed the "Stir/Shaken"
>     Verification process, followed by only a caller phone number
>     without name which becomes pretty much the same challenge for most
>     people to begin with. So, the Caller-ID service has pretty much
>     lost its original intended main purpose.
>
>     uniformly structured system (the PSTN). Even so, it quickly
>     degraded to a service with minimal residual value when system
>     fragmentation, diverse marketing incentives, narrow-mindedness
>     (individual's "freedom"?), etc. came into play. With distributed
>     network architecture and operation philosophy as the foundation, I
>     will venture to say that the Internet would have a hard time to
>     just mimic the identification of the "well-behaved" subscribers
>     like the original Caller-ID service, let alone hiding their
>     identity and providing security. What I am saying is that we must
>     have a "system view" of all parameters involved in an issue,
>     before we could define what we can do and which we want to do.
>     Then, the chosen technology may have a chance to deliver the
>     expected goal. Otherwise, we will be just spinning the wheels on
>     partial solutions from the diverse individualized perspectives.
>
>     Regards,
>
>         concerns focus on that if we want improve the privacy (even if
>         one step further), what direction could we head? I embrace any
>         insight that can enlighten me.
>
>         As for the event you mentioned about Apple, Apple is just
>         another trust point a lot of us trust. So back to the case
>         that current privacy are ultimately rely on trust point.
>         Whether we could remove the trust point is indeed a question
>         for me.
>
>         innovation, happening? Re: 202201111037.AYC
>         *Importance:* High
>
>         Hi, YiHao:
>
>         back a bit, in order to visualize an overall picture of the
>         logic and interactions among the parties involved.
>
>         for anyone except the LE because LE can force any part to
>         disclose specific data ...    ":    Then, make this an
>         explicit statement as the design criterion for the privacy
>         measures, so that the LEs will not have the excuses to do mass
>         surveillance. Bragging there is no back-door, or even refusing
>         to support LE when requested, such as Apple's position on a
>         criminal case sometime ago as I heard, LEs will get it done
>         anyway by looking for "volunteers" from third-party encryption
>         crackers when their internal resources could not. Then, the
>         there for challenging a hacker to figure out a way to break
>         into it. Way back when, a chemist told me that even Epoxies
>         had solvents. So, we should not stretch our energy to cover
>         too much aspects that some tend to be counterproductive for
>         the society as a whole, in the long run.
>
>         Regards,
>
>         Abe (2022-01-11 11:22)
>
>             The postal system analogy is a good story to understand
>             IP, but not equal to the pessimistic conclusion you made.
>             For the conclusion part, I am fully agree with Tom’s
>             arguments.
>
>             As you focus on IP(v4/v6) specifically, we more or less
>             follow the logic of How TCP/IP works. Within TCP/IP,
>             privacy can be divided into content encryption (A) and
>             content delivery (B). A and B both belong to user privacy.
>             However, A and B are different things.
>
>             For A, Tom’s arguments is good enough. As for B, same as
>             Tom’s but one more thing to point. Since you care more
>             about the LE, I would say the current countermeasures are
>             designed for anyone except the LE because LE can force any
>             part to disclose specific data that should be uncovered
>             under its design philosophy.
>
>             In short, in IP ecosystem, both A and B is still worth
>             doing. However, as I mentioned in my last mail, any design
>             philosophy/architecture has somehow implicit **trust
>             party**. But a LE could be All-powerful because the
>             fundament of **trust party** is break and no **trust
>             As you mentioned in your last email that there are
>             conflicts requirements, it happens all the time. RFC 8890
>             give the answer and the direction IETF choose.
>
>             So back to the questions I am wondering: If we can upgrade
>             the architecture somehow, can we enhance the privacy by
>             ways that more than current countermeasures like RFC7721
>             can do?
>
>             Have an excellent 2022!
>
>             Best,
>
>             Yihao
>
>             1) "Your argument seems to be that we shouldn't bother
>             with things like security or encryption at all :-) ...   
>             ":    My apologies for getting you to an unexpected
>             conclusion. Perhaps I failed to make an explicit statement
>             because I thought that I was following a thread about the
>             IPv4 or IPv6 addresses "scrambling" schemes for protecting
>             the privacy of or increasing the security to users. That
>             is, we should look at this subject by the "Divide &
>             Conquer" concept. In other words, I was saying that
>             encrypting the "Content" part as much as the sender /
>             receiver pair agrees to. But, keep the "Address" part
>             mostly clear. This way, the LE parties will not have the
>             excuse of performing "mass surveillance" by scooping up
>             everything, then take time to digest and regurgitate the
>             "Content" for hidden treasures. (Remember the report that
>             the German Chancellor's telephone calls were picked up by
>             spy agencies?) Rumors have been, that high performance
>             computer and large capacity storage device manufacturers
>             are having a field day supplying equipment to LE
>             organizations such as NSA because the current Internet trend.
>
>             Frequency or Wireless -- actually all bands from audio all
>             the way to 60+ GHz), then telephony, and cellular phone
>             before getting involved with the Internet, allow me to
>             briefly describe my understanding of the characteristics
>             of each with respect to our current discussion. Hopefully,
>             the below can thread different fields together to clarify
>             my point:
>
>             A.    In the RF field, any signal that is transmitted
>             (sent) into the "ether" is a fair game for everyone. So,
>             there is no "Address" in the basic RF signal transmission.
>             Most RF equipment does not transmit its identification by
>             itself unless the user does so as part of the "Content" on
>             purpose. For example, a commercial (AM, FM, TV) station
>             announces its station ID, or call-sign (Address) as part
>             of the broadcast (Content) according to FCC Rules. So, in
>             RF communication, we concentrate only on encrypting the
>             "Content" (such as scrambled / encode speech) for
>             proprietary applications.
>
>             caller's phone number (Address) is fixed by wiring (nailed
>             up) upon subscription. Only the called party's phone
>             number (Addressee) is dialed once to tell the switching
>             system who is the destination party, so that the switches
>             can make the connection. Once the called party answers,
>             the actual session consists of only "Content" exchanges,
>             no more "Address" information necessary. Speech scramblers
>             may be used on either end as a pair, for private
>             conversation (Content).
>
>             handset (and the cell tower) identifications (Addresses)
>             on both ends without the user's knowledge to facilitate
>             constantly crosses the boundaries between cells.
>             Similarly, speech scramblers may be used on either end as
>             a pair for private conversation (Content). Note that since
>             VoIP is behind the scene these days, cellular mobile
>             D.   If we look at the Internet environment itself, it is
>             kind like the cellular mobile phone service. It is
>             inherently wide open like RF because packets are forwarded
>             by unstructured mesh routers allowing everyone to listen
>             in. Yet, each IP packet header carries the Addresses of
>             both ends for directing routers to deliver the packet, as
>             well as for the return packet. So, how much can a sender
>             "hide" the identities of either or both ends for privacy
>             while still enables the routers to deliver the packet to
>             its intended destination effectively is a real challenge.
>             Whatever the scheme chosen, it can not be too
>             sophisticated to over-burden the routers which means that
>             it is probably mot much a challenge for a perpetrator
>             intentionally trying to crack the scheme.
>
>             3) My sense from the above analysis is that attempting to
>             make the "Address" part of an IP packet "cryptic" for
>             improving the privacy / security properties of the
>             "Content" is probably futile. The more we attempt doing
>             it, the stronger the LEs' argument for mass surveillance,
>             even though they probably already knew the solution.
>
>             4) On the other hand, if we push too hard on strengthening
>             the encryption of the "Content" without a back door, we
>             essentially are helping the perpetrators. This is because
>             if this part worked, the LEs will not be able to monitor
>             and catch the criminals!
>
>                     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:
>
>                         B.    IAP (Internet Access Provider):    This
>                     will represent the ISP that you are referring to.
>
>                     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
>                     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
>                 Your argument seems to be that we shouldn't bother
>                 with things like security or encryption at all :-)
>                 While it's true that anything sent into the Internet
>                 can be intercepted and analyzed offline, it's clearly
>                 the intent of security and privacy mechanisms to make
>                 offline analysis of data ineffective or at least cost
>                 prohibitive. For encryption the calculation is pretty
>                 straightforward, the complexity and cost and breaking
>                 a cipher is generally correlated to the key size. So
>                 for any given key size, it can be determined what sort
>                 of resources are required to break the code. This is a
>                 continuous escalation as attackers gain access for
>                 more computational resources and there are
>                 breakthroughs like in quantum computing that require
>                 rethinking encryption. But regardless, the
>                 effectiveness of encryption at any given point of time
>                 is quantifiable.
>
>                 should be similarly taking a quantitative approach.
>                 This is where RFC7721 fails. The recommendation of
>                 RFC7721 is that for better security, use temporary
>                 addresses with shorter lifetimes. But the RFC doesn't
>                 attempt to quantify the relationship between address
>                 lifetime and the security that's offered or even say
>                 what specific lifetime is recommended for optimal
>                 security. For instance, if the user changes their
>                 interface address twice a day instead of once a day
>                 does that halve the chances that some may breach their
>                 security by correlating two different flows that they
>                 source from the user? Probably not. But, what if they
>                 change their address every five minutes? How much
>                 better is that than changing the address once a day?
>                 It's intuitive that it should be better security, but
>                 is it _really_ better? And if it is better, are
>                 the benefits worth the aggravation of changing the
>                 address. This is quite similar to some companies that
>                 have a policy that everyone needs to change their
>                 passwords periodically. Studies have shown that there
>                 is little quantitative value in doing this and in fact
>                 the net effect is likely less security and increased
>                 user aggravation-- even so, companies will continue to
>                 do this because it's easier to stick with the inertia
>                 of intuition.
>
>                 need single use source addresses per each connection. 
>                 The security effects of single use addresses are
>                 quantifiable, i.e. given sample packets from
>                 independent two flows generated by the same user,
>                 without additional information it isn't possible for a
>                 third party to correlate that they are sourced by the
>                 same user.
>
>                 Tom
>
>                     Happy New Year!
>
>                     Abe (2021-12-27 21:59)
>
>                         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
>                         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
>                         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)
>                         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.
>
>                         *Sent:* 2021年12月23日10:01
>                         0)    I am glad that you distilled the complex
>                         and elusive privacy / security tradeoff issues
>                         to a very unique and concise perspective.
>
>                         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
>                         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
>                         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!
>