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 <ayc...@avinta.com>
*Sent:* 2022年1月25日 3:31
*To:* Jiayihao <jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
*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,
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 <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月17日 1:21
*To:* Jiayihao <jiayi...@huawei.com> <mailto:jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
<mailto:t...@herbertland.com>
*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 <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月12日 0:22
*To:* Jiayihao <jiayi...@huawei.com> <mailto:jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
<mailto:t...@herbertland.com>
*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 <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月1日 0:58
*To:* Tom Herbert <t...@herbertland.com>
<mailto:t...@herbertland.com>
*Cc:* Jiayihao <jiayi...@huawei.com>
<mailto:jiayi...@huawei.com>; int-area@ietf.org
*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
<ayc...@avinta.com> 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 <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2021年12月23日10:01
*To:* Jiayihao <jiayi...@huawei.com>
<mailto:jiayi...@huawei.com>
*Cc:* t...@herbertland.com; int-area@ietf.org
*Subject:* Re: [Int-area] Where/How is the
features innovation, happening? Re:
202112221726.AYC
*Importance:* High
Hi, YiHao:
0) I am glad that you distilled the complex
and elusive privacy / security tradeoff issues
to a very unique and concise perspective.
1) Yes, the IPv4 CG-NAT and IPv6 Temporary
address may seem to provide some privacy
protection. However, with the availability of
the computing power, these (and others such as
VPN) approaches may be just ostrich
mentality. On the other hand, they provide
the perfect excuse for the government (at
least US) to justify for "mass surveillance".
For example, the following is a recent news
report which practically defeats all current
"privacy protection" attempts.
https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/
<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>
