Subject: solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt -

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 4 May 2013 21:17:37 +0200

Has anybody had a chance to look at this draft
(http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy )? Any comments?
The aim of this draft is to adapt the current RFC to the latest European law
http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en and to
accommodate the needs of customers with relation to the new law for a long
term period. The purpose is to allow users to choose their means to the
privacy and anonymity within a network as well as across networks. 

There is still an option of merging this draft with other drafts, that
address the issue of allowing users to set the lifetime of the IP address
during the installation or an option to set it by the users, if people on
the mailing list thinks it would be useful. 
Share your technical ideas.

Thanks,
Best,
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 May 2013 07:54:29 +1200

> http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en 

Can you please identify the exact clause in the proposed EU regulation
that would require pseudo-random IIDs that change when the subnet
prefix changes?

All I can see in the EU PR release is a hint that "your computer's IP
address" might be considered to be personal data, and might therefore
be covered by privacy regulations.

Even if you can identify the exact clause, we don't normally take
account of specific national or regional legislation in IETF standards.
I think the scarecrow references to EU regulation should be deleted.

It would be more useful if the draft contained a threat analysis.
As far as I can see, if I set the RFC 4941 timer to a reasonable
value, my IID will change much more often than my subnet prefix.

I don't understand the concern about CGA. A network that uses SEND
is highly unlikely to allow RFC 4941.

   Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 4 May 2013 22:48:23 +0200

> Can you please identify the exact clause in the proposed EU regulation that
> would require pseudo-random IIDs that change when the subnet prefix
> changes?

Randomization of IID is my proposed solution to the privacy issues discussed in EU regulation. 
"Personal data is any information relating to an individual, whether it relates to his or her private, professional or public life. It can be anything from a name, a photo, an email address, bank details, your posts on social networking websites, your medical information, or your computer's IP address. The EU Charter of Fundamental Rights says that everyone has the right to personal data protection in all aspects of life: at home, at work, whilst shopping, when receiving medical treatment, at a police station or on the Internet."
Not changing the IID after a period of time gives attackers the ability to invade an entity's privacy.

> All I can see in the EU PR release is a hint that "your computer's IP address"
> might be considered to be personal data, and might therefore be covered by
> privacy regulations.
> Even if you can identify the exact clause, we don't normally take account of
> specific national or regional legislation in IETF standards.

This law was a reference for me as a meaning of privacy. I did not want to use my personal opinion of the definition of privacy. I will delete that reference if there is no need for it.

> As far as I can see, if I set the RFC 4941 timer to a reasonable value, my IID will
> change much more often than my subnet prefix.

I will add this section, thanks

> I don't understand the concern about CGA. A network that uses SEND is highly
> unlikely to allow RFC 4941.

In that RFC is an explanation stating that there is a possibility for using CGA to generate a higher randomized IID but there is nothing mentioned on how to accomplish this. Here I used a modified version of that algorithm without any public/private key because here we want to address the privacy issues and not security issues.

Thanks, 
Hosnieh

---

From: Mark Smith <[email-masked]>
Date: Sat, 4 May 2013 18:45:23 -0700 (PDT)

Hi,

I've had a very brief look, because there was one specific thing I was looking for, and it doesn't seem to be there.

Addresses/IIDs have to last at least as long as the transport layer/application connections are using them, unless the transport layer/application connection takes ownership of dealing with addresses that might "change underneath them". In general, larger preferred and valid lifetimes (e.g, measured in hours or greater) and fairly stable identifiers are intended to avoid transport layer protocols/applications having to deal with them changing.

Rather than trying to shorten the lifetimes and lowering the stability of addresses to the point where they may disrupt the applications using them, perhaps creating per-application or transport layer connection addresses may be a better idea, as discussed in:

"Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host"
https://www.cs.columbia.edu/~smb/papers/tarp.pdf

Regards,
Mark. 

----- Original Message -----
> From: Hosnieh Rafiee <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Sunday, 5 May 2013 5:17 AM
> Subject: solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt - 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 May 2013 15:23:51 +0200

>  http://europa.eu/rapid/press-release_IP-12-46_en.htm?locale=en

=> I tried to not participate to this... Nethertheless this is *not*
an European law, only a EC directive project. BTW even if (when?) it is
adopted it must be adapted in each country into a national law.
Note this doesn't mean there is no country in the EU with silly
legal position about IPv6 address (cf Germany).

Regards

[email-masked]

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 5 May 2013 17:01:28 +0200

> => I tried to not participate to this... Nethertheless this is *not* an
European
> law, only a EC directive project. BTW even if (when?)

Yes, first as I explained to Brian, that was a reference for the meaning of
privacy and a possible way for protecting privacy. Second, it is better to
be prepared. Third, how long does it take a proposal to become a RFC and how
long does it take implementers to start the implementation. The answer is
the same as "when" for your question. 

regards,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 5 May 2013 17:32:47 +0200

As I  wrote in the draft, the time frame for the lifetime of the IP address
should be left up to the use choose based on network policy, but with the
caveat that it should not be so long as to let it be tracked by an attacker.
I explained that as long as the session is valid (layer 5), the node can use
its old IP address but cannot start any new session with the old, expired IP
address.  One might want  to change that sentence to read - the old IP
address can continue being used as long as the transport layer connection is
valid, but a new connection cannot be started using its old IP address.
Does this alleviate your concerns?
Thanks for your comments,
Hosnieh

> 
> I've had a very brief look, because there was one specific thing I was
looking
> for, and it doesn't seem to be there.
> 
> Addresses/IIDs have to last at least as long as the transport
layer/application
> connections are using them, unless the transport layer/application
connection
> takes ownership of dealing with addresses that might "change underneath
> them". In general, larger preferred and valid lifetimes (e.g, measured in
hours
> or greater) and fairly stable identifiers are intended to avoid transport
layer
> protocols/applications having to deal with them changing.
> 
> Rather than trying to shorten the lifetimes and lowering the stability of
> addresses to the point where they may disrupt the applications using them,
> perhaps creating per-application or transport layer connection addresses
may
> be a better idea, as discussed in:
> 
> > accommodate the needs of customers with relation to the new law for a
> > long term period. The purpose is to allow users to choose their means to
the
> > address the issue of allowing users to set the lifetime of the IP
> > address during the installation or an option to set it by the users,
> > if people on the mailing list thinks it would be useful.

---

From: "Sujing Zhou"<[email-masked]>
Date: Mon, 6 May 2013 17:42:24 +0800

To my understanding, rfc4941  meant to use CGA exactky as defined in rfc 
3972.
The modified CGA algorithm in draft-rafiee-6man-ra-privacy has nothing to 
do with CGA.
How are u going to do with the CGA parameter?
There is no meaning in send modifier in CGA parameter then.
If modifier is meant to be kept to the IP address owner, modifer could be 
viewed as secret,
as defined in draft-ietf-6man-stable-privacy-addresses.

IMHO, use CGA just for a random IP address is a waste.

> accommodate the needs of customers with relation to the new law for a 
long
> address the issue of allowing users to set the lifetime of the IP 
address

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 6 May 2013 12:10:52 +0200

3972. 

do with CGA. 

>How are u going to do with the CGA parameter? 

There is no CGA option to add to the ICMP messages. Using a part of CGA
algorithm for IID generation (that I called it modified CGA is because I do
not use public private key and removed the condition checking for security
level. My purpose is not security here as I explained in the draft) is just
for the purpose of randomization in the absence of stable storage. It
provides better randomization than trying to use some random numbers as
explained in section 3.2.2 RFC 4941.

>If modifier is meant to be kept to the IP address owner, modifier could be
viewed as secret, 

>as defined in draft-ietf-6man-stable-privacy-addresses. 

Not exactly. I am not planning to have any correlation between my modifier
and IID as "stable address draft" wants to have. It is because, in my
opinion, there is no reason for it so that others can guess my next IID
values by having my secret or re-generate it. It is because that approach
cannot either help to increase my security like what real CGA does to some
extent nor can help to increase my privacy.

The purpose of ra-privacy draft is first having more control on IID
lifetime. Second, to increase the randomization of IID. 

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 6 May 2013 16:49:55 +0200

3972.

To clarify what my purpose is, I want to address the situation where the
node is not using stable storage but still needs to generate a random IID.
This document is only an update to that section  to provide a better
approach when there is no need to rely on stable storage for randomization.

do with CGA. 

The steps are the same except for removing the steps associated with
security verification. I did not see any need for that.

Finally, the modifier depicted in RA-privacy is just a random number. You
can call it whatever you like, but it is not something secret that would
compromise privacy if somebody knew it. The node picks up whatever number it
likes. By combining this number with the timestamp and the subnet prefix a
unique IID is generated. If another node would happen to choose the same
number (that the probability of that is very low), then the timestamp
enables the generation of a different value than that for the other node in
this network.

Thanks again,
Hosnieh

---

From: Bob Hinden <[email-masked]>
Date: Mon, 6 May 2013 09:13:57 -0700

Hi,

On May 4, 2013, at 12:54 PM, Brian E Carpenter <[email-masked]> wrote:

. . . .

> value, my IID will change much more often than my subnet prefix.

I would like to see the answer to Brian's comment, I didn't see a response to it in the thread.

Bob

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 6 May 2013 21:31:48 +0200

Hi Bob,
> I would like to see the answer to Brian's comment, I didn't see a response
to it
> in the thread.

That is true. But the problem that I address is not why my IID does not
change within the same subnet prefix. The problem is, based on this RFC,
that it is not mandatory to change the IID when my node receives a new
prefix. This is because it depends on the lifetime it receives from the RA.
If the RA message says that my node might extend its lifetime, then the node
does it while the IID is still valid (max lifetime). This means that when
the lifetime is still valid and the new prefix uses this option, my IID will
not change to a different prefix. What I added to my draft is that I set a
mandatory priority on the IID lifetime. When it receives a new prefix,
regardless of its own lifetime or on the lifetime that it received from the
prefix, it MUST generate a new IID and change the status of the current IID
to deprecated. This means that the node, after that, is not allowed to open
any new sessions (will change it to new connections) using the old IID, but
it can maintain its connection with the old IID.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 May 2013 04:48:14 +0000

There is a part of me that wishes that we just deploy what we have. There is another part that notices that between IEEE802, privacy addresses, CGA, stable privacy addresses and probably a few more, we have built a nice mess and maybe we should clean it up. For example, we could decree that composing and IID from a MAC address is obsolete, and we could unify CGA and other privacy addresses. Add some salt can make the CGA addresses as randomized as the privacy addresses; change the lifetime of the key and you get whatever address lifetime is deemed appropriate. But then, the best part of me observes that with the current level of IPv6 deployment, maybe we don't have an urgent need for more specs...

-- Christian Huitema

---

From: "Sujing Zhou"<[email-masked]>
Date: Tue, 7 May 2013 13:07:43 +0800

Considering the current level of IPv6 deployment, we have got so many 
specs...
BTW,how to add some salt to make CGA randomized as provacy address? Since 
public key has 
to be kown to receiver.

> There is a part of me that wishes that we just deploy what we have. 
> There is another part that notices that between IEEE802, privacy 
> addresses, CGA, stable privacy addresses and probably a few more, we
> have built a nice mess and maybe we should clean it up. For example,
> we could decree that composing and IID from a MAC address is 
> obsolete, and we could unify CGA and other privacy addresses. Add 
> some salt can make the CGA addresses as randomized as the privacy 
> addresses; change the lifetime of the key and you get whatever 
> address lifetime is deemed appropriate. But then, the best part of 
> me observes that with the current level of IPv6 deployment, maybe we
> don't have an urgent need for more specs...
> 
> -- Christian Huitema
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 May 2013 05:28:19 +0000

> Considering the current level of IPv6 deployment, we have got so many specs... 
> BTW,how to add some salt to make CGA randomized as privacy address? Since public key has 
> to be kown to receiver. 

The CGA identifiers result from the hash of a modifier, a subnet prefix, a collision count and certificate. A simple way to get privacy properties is to pick a new key. Failing that, the 128 bit modifier can be set to any random value, as long as the hash properties are respected. Granted, the number of valid values depends on the sec field, but for low values of sec, one can just pick a modifier seed at random, then search for the value that provides the right hash. 

CGA nodes only have to disclose their public key if they want to prove their identity.

But as I observed previously, we have more than enough specs around already...

-- Christian Huitema

---

From: "Sujing Zhou"<[email-masked]>
Date: Tue, 7 May 2013 13:50:49 +0800

Christian Huitema <[email-masked]> 写于 2013-05-07 13:28:19:

> The CGA identifiers result from the hash of a modifier, a subnet 
> prefix, a collision count and certificate. A simple way to get 
> privacy properties is to pick a new key. Failing that, the 128 bit 
> modifier can be set to any random value, as long as the hash 
> properties are respected. Granted, the number of valid values 
> depends on the sec field, but for low values of sec, one can just 
> pick a modifier seed at random, then search for the value that 
> provides the right hash. 
Failed to catch what you exactly mean.
IMHO, a method for CGA to be privacy address could be :
keep public key unchanged, and choose different modifier each time so as 
to obtain different IP, and 
only when address ownership is required, send CGA parameter including 
modiefer, public key,etc.

---

From: SM <[email-masked]>
Date: Tue, 07 May 2013 00:07:30 -0700

Hi Sujing,
>Considering the current level of IPv6 deployment, we have got so many specs...

Yes.

Here's what is read: "IPv6 is a well-defined set of completed standards."

Here's what is seen: "Lots of RFCs, both 'standard track' and 
informational, and IETF drafts floating around." [1][2]

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg79157.html
2. http://ripe58.ripe.net/content/presentations/ietf-update.pdf

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 09:31:20 +0200

> 
> There is a part of me that wishes that we just deploy what we have. There
is
> another part that notices that between IEEE802, privacy addresses, CGA,
stable
> privacy addresses and probably a few more, we have built a nice mess and
> maybe we should clean it up. For example, we could decree that composing
> and IID from a MAC address is obsolete, and we could unify CGA and other
> privacy addresses. Add some salt can make the CGA addresses as randomized
> as the privacy addresses; change the lifetime of the key and you get
whatever
> address lifetime is deemed appropriate. But then, the best part of me
observes
> that with the current level of IPv6 deployment, maybe we don't have an
urgent
> need for more specs...

This has been already stated in CGA RFC
http://tools.ietf.org/html/rfc3972#section-7.3 . The problem with CGA
deployment is not privacy, but the computational costs and the RPKI. It does
not need to merge to any other draft to fulfill the privacy. This is why I
am trying to address that problem in my other draft and find the simplest
way. I think the use of ECC is a good option but I will publish my results
soon.

Regards,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 09:36:29 +0200

public key has 
>to be kown to receiver.

CGA provides local link security. So the public key is only exposed within
the same network and it is not published on the internet. The privacy is not
important if you are in the same network as other nodes. It is because if
you try to have privacy by your IP, your MAC address can expose your real
identity (if we skip talking about MAC address spoofing).

Regards,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 09:50:41 +0200

> Here's what is seen: "Lots of RFCs, both 'standard track' and
informational, and
> IETF drafts floating around." [1][2]
> 

In my opinion, it is better to update the current RFCs or obsolete them
instead of adding more specifications which will result on confusing
vendors. Of course, it is my point of view and some people are disagree with
that. They would like to have several optional standards and let the
implementers to choose. 

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 10:09:40 +0200

>keep public key unchanged, and choose different modifier each time so as to
obtain different IP, and 

Different modifier will result in doing the whole CGA computation again
otherwise you use sec value 0. So it does not matter whether you use the
same public/private key or you regenerate the new one as mentioned in the
following links:
http://link.springer.com/chapter/10.1007%2F978-3-642-37119-6_10#page-1
http://tools.ietf.org/html/rfc3972#section-7.3

The problem with CGA is different and not privacy. 

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 7 May 2013 10:41:57 +0200

Hi,

> >In my opinion, it is better to update the current RFCs or obsolete 
> >them instead of adding more specifications which will result on 
> >confusing vendors. Of course, it is my point of view and some people 
> >are disagree with that. They would like to have several optional 
> >standards and let the implementers to choose.
> 
> Proposed Standards were supposed to be "optional".  Implementers 
> choosing to implement them was a good test for running code (code 
> which is actually used on the Internet).  The specifications can then 
> be published as Standard.  If you don't have time to track all the 
> Proposed Standard you could implement the Standard and achieve at 
> least minimum interoperability.  It does not work in practice.  There 
> isn't any Standard for IPv6.  The Standard for SMTP (email) is old and it
is not worth basing an implementation on that.
> 
> I am curious about what you find difficult about IETF specifications.  
> Note that I am not going to disagree with your opinion or argue that 
> what you said is wrong. :-)
> 

As you stated here, there are some old RFCs that, in my opinion, we do not
know whether or not they still address today's minimum requirements. There
are also some vendors that still using them because they did not see any
update on them. This means we are adding more and more standards while we do
a few efforts to check the old standards and obsolete them or update them. I
do not have any problem with having several options. But I do think that
addressing the current RFCs has more priority on adding new specifications.
In other word, to say whether or not the current RFCs can still address our
needs or they need a few modifications to address our needs, has higher
priority than trying to come up with something that might have the same
impact as we resolve the problem with the current RFCs.  

I heard from some people that their problem of not addressing the old RFC is
backward compatibilities. In my opinion, It is the choice of vendors to
improve their old implementations or just leave it as it is. But by
addressing those RFCs at least the customers know that they did not choose
the best option. This means that the customers will force vendors to improve
their current implementations. Then instead of having thousands of RFCs we
will have some that we can rely on and we are sure that they are not
something not useful. When something does not have our today's requirement
why we need to think about that?! 

Regards,
Hosnieh