Re: RFC4941bis: consequences of many addresses for the network

[Alexandre Petrescu <[e-mail]>]

Le 23/01/2020 à 14:37, Jared Mauch a écrit :
> 
> 
>> On Jan 23, 2020, at 8:32 AM, Tim Chown <[e-mail]>
>> wrote:
>> 
>> The problem statement section in 4941bis is all about user privacy,
>> no mention of operational / management complexity, or other
>> “general problems” that SLAAC has.  It seems there are unstated
>> problems here :)
> 
> 
> I would +1 this here.
> 
> I would also generally question if rotating IPs is a adequate privacy
> protector considering there are other ways to identify users that are
> being (broadly) employed today.
> 
> The complexity that this introduces into networks for operational
> debugging (provider: what’s your IP address so I can debug? User:
> Well here’s the 20 on the host because I have limited lifetime
> privacy addresses, and I don’t know what outbound one it’s using for
> this connection.  Provider: What’s your IP address so I can debug?
> Actually, can you just turn off v6 so I can debug your problem?
> User: sure, I just want it fixed).


I cheer the good effects of GDPR, and now of California law on privacy, 
in that end users can decide how much data about themselves to share or 
not share.

I admit the shortcomings and the bad side effects of Privacy concepts à 
la GDPR:
- when clicking No on homepages I get much less data than if I said Yes.
   In that direction, I might get isolated because I dont tell my
   address.
- some sites dont even bother to ask, they just stop serving because
   they have out-of-band data about my IP address being under the rule of
   law related to GDPR.  That's not  good.

Something unrelated to GDPR, but witness of lack of consideration of 
full picture of Privacy, is the following: the existence of the /64 
boundary makes the attackers' job on privacy easier.

There are possibilities to address each of these issues, and some of 
them might impact what RFC4941 needs.

For example, the problem of Yes/No giving less information, is a problem 
of layers: of course I am a powerful end user, and that is a weak 
Server.  The human intelligence is with me, the AI is with it.  The 
privacy of the two cant be compared- it's not on the same layer. 
'Privacy' is something between two humans on the same layer, not between 
a Human and a Server.

As such, I use something like Diffie-Helmann between me and a peer, and 
the servers something like pre-agreed keys between two servers.

But I cant talk about me hiding from a Server.  I might talk  about me 
hiding from sniffers on the way to server, but it is still me hiding 
form others like me.

I cant get into a bank and cover my face.  I cant drive the car without 
a license plate.  I cant get data from a server without telling who I 
am.  It's the law.  It's almost as the Nature.  Opposing Nature doesnt work.

This Yes/No homepage problem could be solved by a mechanism inspired 
from Diffie-Helman, as long as I accept the results will not be 100% 
satisfying either.  I could use a protocol to replace the Yes/No 
clicking.  That protocol would work like Diffie-Helman automated 
negotiation: I try see some data by revealing just a bit of me, then the 
server replies 'maybe', then I reveal a bit more, and so on.  A gradual 
escalation-deescalation, which would allow settling somewhere in a 
middle.  And without 1000 clicks.

I am sure http designers already thought about it.  I guess http already 
has a need of IP addresses and privacy.  Is http in line with RFC4941bis?

Still, it would still be me vs a server, and not me vs a me like me.  It 
means that the questions the Server poses would be too generic (how old 
are you, etc.) such as to accommodate a large number of people like me; 
that is where I might get bored first.

Maybe then another human should be in the loop, behind the server.  Then 
the whole Privacy and IP addressing would be different again.

S/he knows my address but I also know hers (his) - so there is no 
danger.  That's how privacy is respected.

You cant try to respect Privacy if you accept from a start that it's not 
on the same layer (human vs Server).

Alex

> 
> - Jared
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>