Thanks for sharing.
> 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?
I feel that I'm stuck with this.
If a system do not provide any authentication, then a third party is
needed to help authentication (Like Web PKI). If a system do provide
authentication, like Apple iMessage, then the trust anchor is already
there (Apple Inc.).
In the IP layer, IP packets come to a receiver without any
authentication. IPsec is a (patch-like) solution example with a third
party for helping the authentication.
For this, I am stuck with that how to architecturally improve the
privacy/security of IP layer other than the above methodologies, and I
am keep thinking the lessons we can get from Caller-ID.
Thanks,
Yihao
*From:* Abraham Y. Chen <ayc...@avinta.com>
*Sent:* 2022年1月25日 20:30
*To:* Jiayihao <jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
*Subject:* Re: [Int-area] Where/How is the features innovation,
happening? Re: 202201250721.AYC
*Importance:* High
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
*From:* Abraham Y. Chen <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月25日 3:31
*To:* Jiayihao <jiayi...@huawei.com> <mailto:jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
<mailto: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>
