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

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 21 Oct 2013 20:20:02 +0200

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

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 24 Oct 2013 22:00:16 +0200

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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 00:11:37 +0200

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

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

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

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

> We had tons of the discussions about the algorithm. I maintain that it
boils
> down to:

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

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sat, 26 Oct 2013 00:39:40 +0200

Hi Hosnieh,

On 10/26/13, Hosnieh Rafiee <[email-masked]> wrote:
>> public

http://www.ietf.org/id/draft-gont-6man-deprecate-eui64-based-addresses-00.txt
: short and to the point.

>> scan-

Please re-read the
https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/?include_text=1.
It solves this problem imho as well.

I like the privacy, but I severely dislike the pain and additional
cost that the frivolous usage of it inflicts on the real-world network
administrators of the large networks.

Read e.g. the http://www.gossamer-threads.com/lists/nsp/ipv6/47882 for
more info.

> I am open to suggestions and improve it.

I am saying the node maintaining IID on link change is the only valid
point in this draft in my opinion, no need to argue it :-)

Also I am saying that picking the IID is a node-local decision which
does not affect the communication, and it's not as dramatic as
portrayed above.

IETF is about rough consensus and running code - so if you have
running code and you get rough consensus on this draft being a
positive thing - my opinion does not really count, nor should it - I
was simply stating my reasons for thinking the way I am thinking.

We do not have to agree on everything. I am glad that you found some
of my comments useful.

--a