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

[Andrew Yourtchenko <[e-mail]>]

Hi Hosnieh,

I'll reply on-list so it gets into archives - so as to record my
feedback, which is mostly a retransmit of what I wrote in our offline
communication.

I will go over the "problems" that are now distinctly listed in the
introduction, thanks!

"- 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.

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.

"
   - 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.

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.

"
   - This document is also plan to clarify the interpretation of some
   words used in RFC 4941. One example is a node might nterpret a need
   for the use of a large, stable storage area in which to store each
   newly generated IID. This needs to be done to prevent the generation
   of another currently "in use" value.
"

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.

Making things fool-proof applies a Darwinian pressure to breed better fools...

"
   - 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.

--a

On 10/21/13, Hosnieh Rafiee <[e-mail]> wrote:
> First I would like to thank Andrew for his constructive comments off list.
> I
> tried to address his concerns.
>
>
>
> I wrote a small c++ program that compares ra-privacy with privacy
> extension.
> Before, I submitted a version that only ran on windows OS
> (www.hpi.uni-potsdam.de/fileadmin/hpi/FG_ITS/research/Ipv6/md5_Test.zip ).
> This version works on Linux. I haven't tried it on another OS (FreeBSD ,
> etc). I guess you should try to compile it for other OSs.
>
> You only need to run compare.cpp. It will call the other functions.
>
> http://sourceforge.net/u/hrafiee/raprivacy/ci/master/tree/
>
>
>
> Finally I had a chance to update ra-privacy draft as well. The purpose of
> this draft, if you can still remember :-), is to improve privacy
> deficiencies that exist in Privacy Extension RFC  (RFC 4941) and update it.
> Please share your comments and support the document. I would like to ask
> the
> chair of 6man to assign a timeslot at the upcoming IETF meeting  to discuss
> it further.
>
> http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy
>
>
>
> Thank you,
>
>
>
>
>
> -----------smile----------
>
> Hosnieh
>
> . success is a journey, not a destination..
>
>
>
>