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

[Andrew Yourtchenko <[e-mail]>]

Hi Hosnieh,

On 10/26/13, Hosnieh Rafiee <[e-mail]> wrote:
> 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.

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

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

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.

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

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

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