Harald Alvestrand wrote :
Rémi Després wrote:
My desire to have privacy is, in itself, something I may want to keep
private.
I am not sure I see the practical consequences.
If my source address says "I am someone but you will not know who I
am", isn't this sufficient?
You're not thinking this through.
Think of the case where there are 1000 users on a LAN, and one of them
desires to use the address privacy option for all the normal reasons.
Then think about the policeman / bad guy / secret agent / mafioso with a
trace of all traffic from that LAN - he can immediately say that the 999
were using non-privacy-enhanced addresses, and the resulting trace will
show him immediately what the 1000th was up to, no matter how many times
he changed his address.
Right if the user keeps the same address for a series of outgoing
connections.
However things are different in the context in which I proposed, in
earlier mails of the same thread, that the resolver would query the DNS
for site prefixes.
The concern was client hosts for which one desires both: (1) a privacy
similar to that offered by NATs; (2) undisturbed E2E significance of
addresses and ports.
For this, the idea at hand is that these clients would use a fresh
privacy address for each outgoing connection (with some more
specification work left to avoid unreasonable Duplicate Address Detection).
If this is done, the poor mafioso will believe that consecutive
connections of a single host are connections initiated by various hosts
(or at least will be unable to decide which connections come from the
same host) :-).
If what you want to know is indeed "which site is at the other end",
wildcards at the /64 level will achieve that with no changes to
existing code.
I am not familiar enough with wildcard operation in the DNS.
If it provides for queries that concern only site prefixes, then you
are right: no need for an agreed "wildcard IID".
The result is the same with existing mechanisms, which is clearly better.
Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a
while (although their behaviour still surprises many).
Thanks.
I will have a look.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf