Subject: Re: Re: Last Call: <draft-ietf-6man-stable-privacy-addresses-06.txt> (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

From: "Sujing Zhou"<[email-masked]>
Date: Thu, 2 May 2013 15:54:00 +0800

> 
> 
> > However, in the case of
> > roaming the feature is highly debatable. If a host visits the same
> > network multiple times, should it always reuse the same ID, or should
> > it get a new identifier each time? It is very easy to argue that
> > "different each time" has better privacy properties.
> 
> Agreed. For instance, draft-ietf-6man-stable-privacy-addresses-06.txt is
> not a replacement for RFC4941. If you're a roaming node, you probably
> want RFC4941 enabled (in addition to having
> draft-ietf-6man-stable-privacy-addresses-06.txt enabled).

Have you considered adding a date/time parameter in generating the new 
RID?
e.g. RID ’= F(Prefix, Interface_Index, Network_ID, DAD_Counter,Date/time,
       secret_key)
That will result in different IIDs from time to time, and the time could 
be chosen 
a wide range, e.g., the year, the month, so that when a node move within a 
certain time, 
the running sessions will not break because of time change. 
For conveniency, the time parameter could be decided optional.

Of course, changing secret key will also have a similar effect, at the 
owner's will,
but adding a optional time parameter will add more flexibility.

> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 2 May 2013 19:25:25 +0200

>Privacy is handled in the same way as security. Perfect privacy (as with
perfect security) doesn't exist... and you usually must decide when putting
even more effort on it doesn't make any more sense.

My point is that this is not true. Let's use a real life example. Suppose
that someone knows the address of some place. Would it behoove him to do
something bad against that place not really knowing what it is used for?
No, it wouldn't, not really. But what if this unsigned building was actually
a bank and the person in question is a bank robber? Then the plot thickens
and the bank robber's interest is piqued. YES. The borders of privacy are
different that those of security. If I only know the IP address of a node
and nothing more, there is no real incentive to harm the privacy of this
node. But when is this different? The answer would be when I could associate
information obtained about this node with its IP address. This information
could be obtained from the upper layers during the time this node has the
same IP address. Now it makes sense.

Your definition for privacy is just bound to layer 3. I refer to this
definition as pertaining partly to security but not privacy because you do
not want to leak patterns about this IP address. So what can happen if there
is a leak? What will I be able to obtain solely from the pattern of this IP
address? Will I be able to inflict damage to either privacy or security or
both? My definition of privacy has to do with how IP layer  is involved in
allowing for the gathering of information about the node in order to do harm
to its privacy. That is why, in my case, I feel that it is important to
change the IID within the same network if I make the assumption  that  by
staying in that network for a time period longer that x, without the router
prefix changing, I will be vulnerable to compromise.

>THis approach mitigate a number of privacy issues that arise from using
traditional slaac addresses. In many cases, mitigating those is "good
enough".

 I am not talking about the native SLAAC that generates the IID based on the
MAC. I am talking about the so called solution for privacy, RFC 4941. The
problem I can see with this RFC is that the lifetime of the IP address plays
the key role. I tested a windows machine with different prefixes and I did
not see any association of the IID with the MAC. Please explain where this
association is? I will give you a real example from my test
The MAC address is : 00:0c:29:fa:38:32
The IID generated in this windows machine is : 3007:efb7:125a:5c0

Several times I have suggested  that you show this in your draft  in order
to solve the problem of RFC 4941. But if you say this is just a new approach
for IID generation and my purpose is not privacy, then why you are talking
about privacy in your document while you cannot really provide the users
with the privacy they need?

>It does the following:
>* prevents leaking address patterns
>* prevents trivial host-tracking across networks.

 They can still follow you via the information they obtained when you joined
the first network and spent a long time there. So, it does not  prove to be
of much help.

>If your concern is the name, let's call this "Fernando's addresses" :-) or
whatever -- the meat is in the mechanism, rather than the title.

 First, it is not just the title. It is also your repeated reference to
privacy in several places in your document. Second, the title  should show
the purpose of the draft and not mislead readers.

 >Not sure what "conditions" you're referring to. Could you please
elaborate?

 The condition is related to the time you will remain using the same IID. If
it is longer than x, where x depends on many factors such as how important
the information of the users in this network is, how long it could  take an
attacker gather information about each individual users in this network, and
so on.

>This scheme results in addresses that have IIDs that **change across
networks**. --That's a big different, isn't it?

 What if my node is to move to and from  x different networks? If I generate
the same IID as well, then I will be a good victim for the attacker.
 
>Why would you expect a *prefix* to change, if your node does not move, when
an *address* is supposed to be topologically-dependent??

 Because privacy has to do with my information and not my IP address. I am
not talking about security where the attacker knows my IP  address which
enables him to do certain attacks against me or my network. I am talking
about the information that might leak during the time I am using the same IP
address.

>No matter how short-lived you make addresses, this will still be the case.
FOr instance, with current tools and bandwidths, you do not need a node to
be connected for more than a few seconds to have a >penetration testing tool
attempt what you refer to as "dirty deeds".
 
I think that you are confusing privacy with security.

>How many times do I need to repeat that RFC4941 addresses are generated
**in addition** to traditional slaac addresses?

 What it uses as a global address is a temporary one which is not based on
traditional SLAAC or it tries to randomize the IID. 

>Because while you're still in that network, some of the protocols you
employ may need a stable address... and because you may not want your e.g.
ssh sessions to break every X minutes.

What I know is that you cannot start a new session with your old or expired
IP address. But you can keep your current session with your old IP address
(see section 3 RFC 4941). Did you really try to see if the current session
is cut when using the current services? I have never experienced this. If
you or others have ever experienced this, then this is a bad interpretation
of RFC 4941 or a bad implementation.
 Now, when you move from one network to another, where the prefix changes
completely and you have a new IP address, do you still keep the same session
with your node? I do not think so, otherwise you should use Mobile IPv6
which is the solution here for mobility in IPv6. If your concern is this,
then why don't you use mobile ipv6? In this protocol, when a completely new
IP address is generated, it still maintains my session along with my old
nodes. So now, what is the reason for having stable addresses when there is
another solution for mobility in IPv6?

 >FWIW, I'm writing this email on a laptop, which is my mobile node. It
tends to stay cnnected for a few hours at home, then for a few hours at my
office, then for a few hours at some relative's home I'm >visiting, etc.

 I have already answered this. The solution is  the use mobile IPv6 and not
stable addresses.

 >Certainly not obvious/possible by just looking at the IPv6 address. -- and
if you don't think so, please explain your attack vector.

 This is what I am trying to tell you. The association of IP addresses to
the information obtained from other layers is important and might put
privacy at risk and not just hiding the "pattern" of your network. It has
more to do with partial security than privacy.

Thanks,
Hosnieh