Subject: ra-privacy : addressed the deficiencies of RFC 4941- applied recent comments

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 13 Aug 2013 00:58:46 +0200

Hi,
I applied Fernando's recent comments. I also clarified the usage of the new
algorithm to make it clear that is not CGA (for those who interpreted it
incorrectly). Now this draft addresses all the deficiencies contained in RFC
4941 so as to prevent node tracking or location tracking attacks that could
result from the use of a bad randomization choice for IID generation or
because of using EUI-64 in generating public addresses or because there is
the possibility that the IIDs will not be changed when the node joins a new
network.

 http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy

Please review and share your concerns if there are any.

Thank you,
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Aug 2013 00:25:39 -0300

On 08/12/2013 07:58 PM, Hosnieh Rafiee wrote:
> Hi,
> I applied Fernando's recent comments. 

For the record, this document doesn't address my feedback.

Most of the I-D is about how to generate a random number.

If you need a PRNG, just require implementations to implement one. Your
workaround is to get into the same level of complexity to produce a PRNG
that wil be employed just by the stack -- if you're ging to implement
one, make it available to all apps/functions (rather than reinvent the
wheel at every module that needs a PRNG).

There's still lots of text that could/should be removed throughout the
document -- for instance, you need to get deep into the Abstract to see
what the document is trying to solve (I bet you might even get a id-nits
warning as a result of the large Abstract?).

I won't comment further, but just wanted to note that my comments have
not been addressed, since you've stated that they have.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 13 Aug 2013 09:14:23 +0200

> workaround is to get into the same level of complexity to produce a PRNG
that
> wil be employed just by the stack -- if you're ging to implement one, make
it
> available to all apps/functions (rather than reinvent the wheel at every
module
> that needs a PRNG).

JFYI: if you check the algorithm, when stable storage is in use, they also
need to implement a PRNG in addition to use a stack.
I have already discussed about the complexity in my last email. obtaining
timestamp from the system, generating a random number using timestamp as a
seed and call it modifier or whatever and then applying SHA256 on
(timestamp, prefix, modifier)  is not complex. For using a default value in
history, the system need to generate random number anyway. While after that
it needs stack in RFC 4941, but with my update it only needs that PRNG.
Second, I did not say that the implementation cannot use the stable storage.
This way is only "RECOMMENDED" but no force to implement this and the
implementers can keep their first approach. But, what is clear here is the
probability of an attacker to find the history value in order to guess the
next IID of the node is more than using my approach which is completely
random. This is because I do not need to keep any value anywhere in the node
and modifier every time can be new value.

> There's still lots of text that could/should be removed throughout the
document
> -- for instance, you need to get deep into the Abstract to see what the
> document is trying to solve (I bet you might even get a id-nits warning as
a
> result of the large Abstract?).

No, I didn't. It passed without any problem! My abstract is explaining what
I plan to address in the whole document. There is no problem to shorten it
as well.

> I won't comment further, but just wanted to note that my comments have not
> been addressed, since you've stated that they have.

You usually do not apply the comments that you are not convinced about and
have already explained your reason as to why you are not agree. This is the
same case for your comments on PRNG.

To be more clear, here is your comments which I applied:
http://www.ietf.org/mail-archive/web/ipv6/current/msg18732.html

Thanks,
Hosnieh

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 13 Aug 2013 08:15:29 +0000

"One of the
   issues with this RFC concerns the wording that is used that allows
   the implementation to make the choice as to what approach to use, and
   in so doing, in some cases, the choice made is not the most prudent
   or best approach, and this thus is not ideal and can lead to some
   problems."

"prudent" and "best" are things that will change overtime. I can see
the value in publishing some algorithm to generate IID, and maybe the
more of these we have - the better.

I see it harmful in marking the core IPv6 specs updated with this
algorithm - even
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/
does not do that.

Now, beyond the philosophical-political comments, a couple of things
on the "meat":

1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC.
This seems to me that step 6 of algorithm needs to go.

2) the algorithm components

   R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix)

it looks to me that it is functionally equivalent of just taking a
hash of 16 random bytes and using that as an interface ID ? Why the
additional components ? They're trivially guessable (even remotely)
and are the same for the nodes on the segment, so they do not add much
in terms of entropy.

3) DAD

If, after 3 tries, it receives the same
   result, it will consider this an attack and will start using that IP
   address.

Uh. So if I have a mass of devices on the segment from the same vendor
who made a poor implementation of this algorithm there is a plausible
race condition where they might start using the same address ?

(if the RNG is of bad quality).

4) stable storage.

If I read it right, I think the node still must have at least enough
storage to keep a single IID. If we are talking this a replacement of
EUI64, then, again, why not take a random 64bit value, store that, and
just use either that value alone for the IID ?

--a

On 8/13/13, Hosnieh Rafiee <[email-masked]> wrote:
>> not

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 13 Aug 2013 11:53:20 +0200

Hi Andrew,

Thanks for your comments. See my response as follow:

> "prudent" and "best" are things that will change overtime. I can see the
value in
> publishing some algorithm to generate IID, and maybe the more of these we
> have - the better.
>

That section is related to the use of word "might" for the use of RFC 4086
in order to pick up a random number.

> I see it harmful in marking the core IPv6 specs updated with this
algorithm -
> even
> does not do that.

The old version of draft was not like that but I changed it to apply
Fernando's comment. How about change it like before : The node must not
generate its public address based on any algorithm that uses MAC address. It
"MIGHT" generate it based on [stableaddresses] document. 
Does it address your concern?

> Now, beyond the philosophical-political comments, a couple of things on
the
> "meat":

I did not mention it because that draft relaxed the usage of those bits. So,
I thought it would be useful to use all those bits for IID. I can add a
reference to that document .

> it looks to me that it is functionally equivalent of just taking a hash of
16
> random bytes and using that as an interface ID ? 

If I added router prefix , It is only for more randomization and decrease
the chance of pick up the same value for other network. It is true that
prefix is well known, but timestamp and modifier is not known.  

Why the additional
> components ? They're trivially guessable (even remotely) and are the same
for
> the nodes on the segment, so they do not add much in terms of entropy.

Timestamp : you have to consider clock skew and the CPU cycles so not easily
guessable.
Modifier: this value is added in case we have the same vendors as you also
mentioned. The seed can be any value. One can pick up timestamp. But then
based on seed you pick up another number. It is not guessable as well. 

You have to consider that the attacker is not in the same local link as the
node. If he is, he can harm user's privacy based on layer 2 and no need to
look for the IP address of this node. Otherwise we have another mechanism to
also change the MAC address! Which is out of the scope of this document
which talks on layer 3 privacy.

However, I think it is currently have a good randomization (because of my
reasons) but I also can apply a simple step to increase the randomization,
i.e., use any permutation of the s. where  s=(modifier||timestamp||prefix)
and || is the sign for concatenation. As a result, the node will pick up any
different orders of s array of bytes and so the attacker needs to guess on
32 bits and not 16 or 24 bits.

Any thoughts?

> Uh. So if I have a mass of devices on the segment from the same vendor who
> made a poor implementation of this algorithm there is a plausible race
> condition where they might start using the same address ?
> 
No, the probability of two nodes pick up the same modifier is really low.
Especially if we give a chance for 3 tries. Although they starts at the same
time and we say their clock is completely synchronize but the modifier
change this value.

Any thoughts?

> If I read it right, I think the node still must have at least enough
storage to keep
> a single IID. If we are talking this a replacement of EUI64, then, again,
why not
> take a random 64bit value, store that, and just use either that value
alone for
> the IID ?

That is almost the same as my algorithm with a small different step, i.e.,
you also use stable storage to keep a value while I think there is no need
to do so. (they use also a hash function on the concatenation of "history"
and EUI-64.). My reason is, as I explained off list, this will increase the
chance for the attacker to guess next value generated by the node in case
the node is compromised and the attacker access the history once (virus or
...). But using my algorithm, the attacker needs to try different values and
he might not have enough time it is because based on that RFC, the node will
keep its IID maximum for a week and in most cases for a day. This means an
attacker need to try different guessed values in a week (2^24) for the
inputs of SHA256 hash function.

Thanks,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 13 Aug 2013 11:58:38 +0200

Follow up:
Just a mistake... not 32 bits... 32 bytes! Everything in my last email is
bytes and not bits... :-) I just got confused...

> > publishing some algorithm to generate IID, and maybe the more of these
> > we have - the better.
> >
> 
in
> order to pick up a random number.
> 
Fernando's
> comment. How about change it like before : The node must not generate its
> public address based on any algorithm that uses MAC address. It "MIGHT"
> generate it based on [stableaddresses] document.
> > on
> I did not mention it because that draft relaxed the usage of those bits.
So, I
> thought it would be useful to use all those bits for IID. I can add a
reference to
> that document .
> > hash of
the
> chance of pick up the same value for other network. It is true that prefix
is well
> known, but timestamp and modifier is not known.
> 
> 
> Why the additional
> You have to consider that the attacker is not in the same local link as
the node.
> If he is, he can harm user's privacy based on layer 2 and no need to look
for the
> IP address of this node. Otherwise we have another mechanism to also
change
> the MAC address! Which is out of the scope of this document which talks on
> layer 3 privacy.
> 
i.e.,
> use any permutation of the s. where  s=(modifier||timestamp||prefix) and
|| is
> the sign for concatenation. As a result, the node will pick up any
different
> orders of s array of bytes and so the attacker needs to guess on
> Especially if we give a chance for 3 tries. Although they starts at the
same time
> and we say their clock is completely synchronize but the modifier change
this
> value.
you
> also use stable storage to keep a value while I think there is no need to
do so.
> (they use also a hash function on the concatenation of "history"
> and EUI-64.). My reason is, as I explained off list, this will increase
the chance
> for the attacker to guess next value generated by the node in case the
node is
> compromised and the attacker access the history once (virus or ...). But
using
> my algorithm, the attacker needs to try different values and he might not
have
> enough time it is because based on that RFC, the node will keep its IID
> maximum for a week and in most cases for a day. This means an attacker
need
> to try different guessed values in a week (2^24) for the inputs of SHA256
hash
> function.
> 
> Thanks,
> Best,
> Hosnieh
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 13 Aug 2013 11:00:12 +0000

Hi Hosnieh,

> in order to pick up a random number.

Yes, I think "might" is correct.  I assert that not all stacks need
the privacy and sometimes there is a tradeoff. My temperature
measurement node at home with 2K of code space and 0.5Kb of RAM
running IPv6 does not have the requirement for privacy. Servers
running HTTP services do not have the requirement for privacy.  The
application of a standard is very wide, and such a broad stroke that
is in the text is simply wrong.

> Does it address your concern?

Not it does not. As I said - this may not be applicable for all of the
hosts on the internet.

> So,

Your step 6 from
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-06 reads:

   6. Take the 64 leftmost bits from the resulting output of step 5
   (SHA2 digest) and set bits u and g (bits 7 and 8) to one and call
   this the IID.

So it looks like it's the opposite of what you just said, or there is
a hidden revision that I haven't seen :-)

> prefix is well known, but timestamp and modifier is not known.

If you have A and B taken from random generators, either they are
random enough to not collide, or they aren't. The need to "make them
more random" means you have a poor RNG assumption ?  How poor ? What
is the math that dictates the necessity to even mix something in ?

> Timestamp : you have to consider clock skew and the CPU cycles so not

Clock skew? CPU cycles ? Your definition of timestamp, from the text:

"3. Obtain the nodes' current time and convert it to a timestamp. The
   timestamp field consists of a 64-bit, unsigned integer field
   containing a timestamp whose value is computed from the number of
   seconds since January 1, 1970, 00:00 UTC, by using a fixed point"

the timestamp is in *seconds*. Today's hosts are synced with NTP or
similar, so this will be *trivially* predictable in my opinion.

> based on seed you pick up another number. It is not guessable as well.

two times timestamp ?

Then maybe the algorithm should be more generic and shorter: "take as
many of random-looking elements that you can find on your host and a
counter,  feed them to a crypto hash function, take 64 bits of that
and use as IID, increment the counter up to 3 until DAD stops failing
and use that as an address till the next reboot" ?

> which talks on layer 3 privacy.

I think we need to roll back and see again which problem we're
solving. As I wrote you in my first reply - the problem of privacy for
the clients is a *solved* problem, *today*.

You then said it was to prevent scanning ? In case the node has no
stable memory ?

Putting it into a *short* (about 1/5th of the current size) abstract
would help make the discussion better.

> 32 bits and not 16 or 24 bits.

Your first step is:

1. Generate a 16 byte random number called modifier. To generate this
   modifier, implementations SHOULD use a random seed to aid in the
   randomization of this number.

If your RNG is good enough, the buck stops there. guessing 16 random
bytes is hard.

>> who

Based on what ?

It seems the entirety of the algorithm is trying to cater to the
situation from here:
http://xkcd.com/221/
If it is the case, what's the guarantee that the modifier is "really
random" ? And if it is really random - why adding complexity by making
it more random ?

> same

I see magic manipulations all over, I am not enough qualified to
comment on that :-)

I could reason more if I saw math that the assertions/logic are based on.

> the node is compromised and the attacker access the history once (virus or

If the node is compromised, this is *GAME OVER*. No, honestly. Your
credit card and CVV are gone and attacker is buying the luxury goods
with that, your email does not work anymore because the attacker has
changed the passwords on there, your iDevices have been wiped clean.
Do you give a beep about the address anymore ? ;-)

> inputs of SHA256 hash function.

Based on the *real-world* implementations, they change the IID every
time they reconnect to the network. Which is, let me repeat, the
*real-world* "large scale privacy problem" is solved today with
*existing* code. If you like, you can even see the demo for that -
just ask someone with an iPhone on an IPv6 network to flip the
airplane mode and back.

Seriously, I think the best way forward is to rewrite the problem
statement in a more conscise way so we can better argue about what
problem is being solved.

--a