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

["Abraham Y. Chen" <[e-mail]>]

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
>
> *From:* Abraham Y. Chen <[e-mail]>
> *Sent:* 2022年1月17日 1:21
> *To:* Jiayihao <[e-mail]>
> *Cc:* [e-mail]; Tom Herbert <[e-mail]>
> *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.
>
>
> 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:
>
>     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 <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* 2022年1月12日 0:22
>     *To:* Jiayihao <[e-mail]> <mailto:[e-mail]>
>     *Cc:* [e-mail]; Tom Herbert <[e-mail]>
>     <mailto:[e-mail]>
>     *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)
>
>     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 <[e-mail]>
>         <mailto:[e-mail]>
>         *Sent:* 2022年1月1日 0:58
>         *To:* Tom Herbert <[e-mail]>
>         <mailto:[e-mail]>
>         *Cc:* Jiayihao <[e-mail]>
>         <mailto:[e-mail]>; [e-mail]
>         *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
>             <[e-mail]> 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 <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Sent:* 2021年12月23日 10:01
>                     *To:* Jiayihao <[e-mail]>
>                     <mailto:[e-mail]>
>                     *Cc:* [e-mail]; [e-mail]
>                     *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/
>                     <https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/>
>
>                     */[jiayihao] there is no doubt./*
>
>                     2)    Rather than contradicting efforts, it is
>                     time to review whether any of these schemes such
>                     as mapping techniques really is effective for the
>                     perceived "protection". As much of the current
>                     science fiction type crime scene detective novel /
>                     movie / TV program hinted, the government probably
>                     has more capability to zero-in on anyone than an
>                     ordinary citizen can imagine, anyway. And,
>                     businesses have gathered more information about us
>                     than they will ever admit. Perhaps we should
>                     "think out of the box" by going back to the PSTN
>                     days of definitive subscriber identification
>                     systems, so that accordingly we will behave
>                     appropriately on the Internet, and the government
>                     will be allowed to only monitor suspected
>                     criminals by filing explicit (although in secret)
>                     requests, case by case, to the court for approval?
>
>                     Happy Holidays!
>
>                     Abe (2021-12-22 21:00 EST)
>
>                     Hello Tom,
>
>                       
>
>                     The privacy countermeasure for IPv4/IPv6 is interestingly different.
>
>                     IPv4 usually utilize CGNAT, i.e., M(hosts)-to-N(IPs), where M >> N so that the host could remain anonymous
>
>                     IPv6 usually utilize Temporary address, i.e., 1(host)-to-M(IPs[at least suffix level]), where M >> 1 so that the host could remain anonymous.
>
>                       
>
>                     HOWEVER, I don't feel any approach reaches privacy perfectly, because access network have a global perspective on M-to-N or 1-to-M mapping.
>
>                     For this, it is hard to be convinced that IPv4/6 itself can reach a perfect privacy.
>
>                       
>
>                     Thanks,
>
>                     Yihao Jia
>
>                       
>
>                     -----------
>
>                       
>
>                     I believe CGNAT is better than IPv6 in terms of privacy in addressing.
>
>                     In fact one might argue that IPv4 provides better privacy and security
>
>                     than IPv6 in this regard. Temporary addresses are not single use which
>
>                     means the attacker can correlate addresses from a user between
>
>                     unrelated flows during the quantum the temporary address is used. When
>
>                     a user changes their address, the attacker can continue monitoring if
>
>                     it is signaled that the address changed. Here is a fairly simple
>
>                     exploit I derived to do that (from
>
>                     draft-herbert-ipv6-prefix-address-privacy-00).
>
>                       
>
>                     The exploit is:
>
>                            o An attacker creates an "always connected" app that provides some
>
>                              seemingly benign service and users download the app.
>
>                            o The app includes some sort of persistent identity. For instance,
>
>                              this could be an account login.
>
>                            o The backend server for the app logs the identity and IP address
>
>                              of a user each time they connect
>
>                            o When an address change happens, existing connections on the user
>
>                              device are disconnected. The app will receive a notification and
>
>                              immediately attempt to reconnect using the new source address.
>
>                            o The backend server will see the new connection and log the new
>
>                              IP address as being associated with the specific user. Thus,
>
>                     the server has
>
>                              a real-time record of users and the IP address they are using.
>
>                            o The attacker intercepts packets at some point in the Internet.
>
>                              The addresses in the captured packets can be time correlated
>
>                              with the server database to deduce identities of parties in
>
>                              communications that are unrelated to the app.
>
>                       
>
>                     The only way I see to mitigate this sort of surveillance is single use
>
>                     addresses. That is effectively what  CGNAT can provide.
>
>                       
>
>                     Tom
>
>                     Image removed by sender.
>                     <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>
>                     	
>
>                     Virus-free. www.avast.com
>                     <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>


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