Subject: Re: problems with privacy draft

From: Richard Draves <[email-masked]>
Date: Wed, 7 Jun 2000 15:14:24 -0700

Ignatios asked me to forward his comments to the list.
I'll reply separately.

-----Original Message-----
From: Ignatios Souvatzis [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 3:26 AM
To: Richard Draves
Subject: Re: problems with privacy draft

On Tue, Jun 06, 2000 at 05:20:19PM -0700, Richard Draves wrote:

[This is from the proposal part]
> 8. You don't create a new random interface-identifier each time you
generate
> an anonymous address. Instead you keep a current random
interface-identifier
> associated with an interface, and use it when generating an anonymous
> address.

This is to limit the number of multicast groups that the interface must
join?
While this does not affect long time correlation of the nodes communication,
it
allows for easier short time correlation (that is, two communicating outside
observers will be able to notice, that in (prefix X) there is a machine
accessing resource A close to the time where  in prefix Y the same user is
accessing resource B. 

Without this rule (if instead using a new Interface Identifier each time you
create an anonymous address) accesses to resources that are at different 
destination addresses, which have some likelihood to use different source
prefixes, will not be trackable to the same machine. I can imagine
situations
where this correlation should be hidden.

> An implementation consequence of all this is that you do need to find the
> corresponding public addresses from an anonymous address.

Why?
	-is
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Thu, 8 Jun 2000 00:21:46 -0700

> Without addressing most of your points, I think you're (plural if
> necessary) overlooking a mode in which many would wish to operate:
> generating a new anonymous address for almost every active TCP open
> (I say almost because the data connection for an FTP transfer is an
> obvious exception) and some class of new UDP sockets.

The draft should allow implementations to generate anonymous addresses very
frequently. I did some testing generating a new anonymous address every five
seconds. Generating a new source address for every socket probably
introduces unacceptable latency for DAD, but it should be allowed. Another
problem with generating so many addresses is knowing when they can be
removed. The draft allows implementations to remove unused deprecated
anonymous addresses, but it may be difficult to tell that an address is not
in use. For example an application might use getsockname, save the address
in a variable, and try to bind to it later.

Rich