RE: ra privacy: an improvement to privacy extension plus source code

["Hosnieh Rafiee" <[e-mail]>]

Hi Andrew,
Thanks a lot for taking time to review this
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy . 

> "- RFC 4941 specifies the use of EUI-64 to generate the public address
>    of node
> "
> 
> I would not agree with this. 4941 refers to 4862 for generating the public
> address, which in turn suggests to use "interface identifier"
> when creating a global address, and does not mandate EUI-64 as the only
> mechanism (as evidenced in some implementations, namely, Windows). The
> 4291, on the other hand, does talk about EUI-64 *format* but it also
> specifically mentions the MAC addresses are not necessary to be used. So,
> IMHO this is not a problem.

I call this the problem because when you have both temporary addresses and
public/permanent addresses that is generated based on EUI-64 or EUI-48(MAC),
your public address will allow the attackers to track your node. 

> 
> Anyway if the nodes want to use the stable public addresses that are scan-
> resistant, there is a draft by Fernando Gont which solves this problem.
I'd
> rather see you contribute to that one if that solution is not good enough
you
> think, rather than having yet another fork.

I guess you missed the point again. That draft generates a stable IID which
means that the node will have the same IID whenever it is fixed in a same
network. IPv6 addresses are the public addresses so the node use this
address to access websites or other data through the internet and this
address soon will be known to all websites or resources on that this user
use it. If as a mistake this user also check a resources which belongs to an
attacker. The attacker will have his IP address and this IP never changes
until the router prefix changes. This actually will not happen at least in
the short time or it can be permanent. 
So, this allows the attacker to access the information of this user. 
This is why I like privacy extension approach more. Because it also changes
the IID within the same subnet but in ra-privacy, I explained that if the
node wants to have this public addresses it should not generate it based on
EUI-64 or MAC and might change it based on Stable addresses that, at least,
we can decrease the chance of exposing hardware information.  
The new draft recently sent  "deprecated addresses" actually contains most
part of information which this draft was addressed and addressing.



>    - If the node is changing the physical link, it may keep the IID
>    already used on the link it is leaving, to form an IPv6 address on
>    the new link using SLAAC.
> "
> 
> This is a problem I agree is a problem, which has been fixed in some
> implementations; and arguably in the other implementations a bug should be
> filed "If the prefix changes, the node MUST NOT reuse the already used
> temporary IID". But, maybe to fix this bug, an update to
> 4941 could be useful.

You say this fixed in implementation. My question is why we have standards?
If implementers wants to implement something in whatever way they like, then
I guess we cannot communicate via internet anymore as it would be ruled by
incompatible systems and we will back to 19 century. 
I am open to suggestions and improve it.


> Fernando's draft also specifies that IID of the "stable addresses"
> needs to be different on different prefixes, so this problem only applies
to
> temporary addresses.

That is true. Ra-privacy has no recommendation about public addresses except
not to use the hardware information or EUI-64 RFC. The recommendation in
this draft is about temporary addresses and a few explanation of the current
problem with Privacy Extension.


> 
> I read the 4941 and I think it is flexible enough allow oneself to both
shoot
> oneself in the foot and to make a sane implementation. So I am not sure
this
> is a valid problem to solve.

I just noticed some ambiguous words in this RFC. It does not effect on the
proper implementation but will effect on new implementation of this RFC or
any bad implementation of this RFC.

> "
>    - This document also clarifies the use of other algorithm and compare
>    it with CGA and DHCPv6 when there is no stable storage available. So
>    that the node may be able to make use of a greatly randomized IID
>    because, according to section 3.2.2 of RFC 4941, there is nothing to
>    force the use of RFC 4086.
> "
> 
> We had tons of the discussions about the algorithm. I maintain that it
boils
> down to:

> "On each link change, take 64 bits of random data and put it into IID.
> Ensure the random data is good quality".
> 
> There is a significant body of work on generating good random numbers and
I
> do not see this draft contributing anything new to it, in this regard.
> 
> So, as I support only 1 portion of the draft out of 4, in general I am
still
> opposed to it.
> 

Spending time on implementation was only for showing how ra-privacy works in
compare with Privacy extension and how good it can generates random number
with this suggested algorithm. Test it please and then say it wasn't any
contribution for generating a good random number.  
Again I am open to good suggestions if you have any.

Thank you,
-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey