Subject: Solutions to the problem with RFC 4941

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 2 May 2013 21:35:06 +0200

Dear All,

Since Fernando's proposal is not going to solve the current problem with RFC
4941, I have suggested to him, on several occasions, that he resolve this
problem so that the node's privacy will be better protected but he ignored
this suggestion and claiming that his purpose is different. This is the main
reason that today I wrote an RFC draft which I will submit  to the IETF
repository. This draft does not overlap Fernando's proposal  it is related
to the problems with this RFC (RFC 4941) which he doesn't feel the need to
address. The problems that I address here concern the fact that the node
should also change its IID when it receives different router prefixes.

In the experimental results, Windows machine that implemented privacy
extension RFC, generates different IIDs by rebooting .But when it receives a
different prefix without a reboot, then, on the first two occasions that the
new  prefixes received, the node was generated a new IID, but not for other
new prefix generations. Also, as you can see, the temporary addresses have
the same IID. This means that there is a need to change section 8 of this
RFC

   6.  The node is now allowed to generate different interface

      identifiers for different prefixes, if it so desires.

Where a different IID should be generated when a different prefix is
received.  I called it "RA-based privacy extension for SLAAC".

   Physical Address. . . . . . . . . : 00-0C-29-FA-38-32

   IPv6 Address. . . . . . . . . . . :
2000:abc:ab:0:3003:bfe7:125a:5c0(Preferre

d)

   IPv6 Address. . . . . . . . . . . :
2000:abc:bad:bad:3003:bfe7:125a:5c0(Prefe

rred)

   Temporary IPv6 Address. . . . . . :
2000:abc:ab:0:5d60:2136:554:188b(Preferre

d)

   Temporary IPv6 Address. . . . . . :
2000:abc:bad:bad:5d60:2136:554:188b(Prefe

rred)

   Temporary IPv6 Address. . . . . . :
2000:bad:bad:bad:5d60:2136:554:188b(Prefe

rred)

Lifetime of the addresses as long as the computer is on

Addr Type  DAD State   Valid Life Pref. Life Address

---------  ----------- ---------- ---------- ------------------------

Public     Preferred   3314d21m1s 779d18h22m24s
2000:abc:ab:0:3003:bfe7:125a:5c0

Temporary  Preferred   6d23h51m4s 6d23h51m4s
2000:abc:ab:0:5d60:2136:554:188b

Public     Preferred  3314d16m15s 779d18h17m38s
2000:abc:bad:bad:3003:bfe7:125a:

5c0

Temporary  Preferred  6d23h50m22s  23h50m22s
2000:abc:bad:bad:5d60:2136:554:188b

Public     Preferred  3314d21m13s 779d18h22m36s
2000:aed:ab:0:3003:bfe7:125a:5c0

Temporary  Preferred  6d23h55m20s  23h55m20s
2000:aed:ab:0:5d60:2136:554:188b

Public     Preferred  3314d15m26s 779d18h16m49s
2000:bad:bad:bad:3003:bfe7:125a:

5c0

Temporary  Preferred  6d23h49m13s 6d23h49m13s
2000:bad:bad:bad:5d60:2136:554:188

b

A second problem that I found with that RFC is the second approach used to
generate the IID. In section 3.2.2 it describes a more randomized  IID
generation approach by using  CGA, but it does not explain how to use this
algorithm when security is not a consideration. In my extension, I also
explain how to use that algorithm if we do not wish to consider security as
a part of CGA. Of course, I derived that section from my last draft , SSAS,
and will remove that section from SSAS. I would prefer that the SSAS
algorithm  focus more on security and then focus on privacy.

Best,

Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 May 2013 17:17:55 -0300

Hosnieh,

You have been making many misleading claims about things I have said or
stated. Quite a few times I have corrected you, provided pointers, etc.
-- which you have systematically ignored. Your comments below seem to
indicate to you didn't bother reading the Introduction of
draft-ietf-6man-stable-privacy-addresses, or pay attention to the
clarifications I made on-list. I suggest you wait for the next rev of
the document, but meanwhile you may consult
<http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt>
for an alternative explanation of the issues involved.

I believe such behavior is harmful.

All & chairs: I'm currently working a lot with all (off-list, to reduce
the noise) with all those folks that provided feedback during IETC LC
and right after IETF LC on the mailing-list... and we're making a lot of
progress on the I-D. My plan is to submit a rev of
draft-ietf-6man-stable-privacy-addresses fr broader review (i.e., have
the wg review that I have double-checked that addresses IETF LC comments).

FWIW, I'd like to express a big "thank you" to all the folks that have
provided timely comments/reviews, and that have been exchanging emails
with me (off-list) to improve the I-D.

P.S.: At this point I will not continue responding on this thread.

Thanks,
Fernando

On 05/02/2013 04:35 PM, Hosnieh Rafiee wrote:
> Dear All,
> 
>  
> 
> Since Fernando’s proposal is not going to solve the current problem with
> RFC 4941, I have suggested to him, on several occasions, that he resolve
> this problem so that the node's privacy will be better protected but he
> ignored this suggestion and claiming that his purpose is different. This
> is the main reason that today I wrote an RFC draft which I will submit 
> to the IETF repository. This draft does not overlap Fernando’s proposal
>  it is related to the problems with this RFC (RFC 4941) which he doesn't
> feel the need to address. The problems that I address here concern the
> fact that the node should also change its IID when it receives different
> router prefixes.
> 
>  
> 
> extension RFC, generates different IIDs by rebooting .But when it
> receives a different prefix without a reboot, then, on the first two
> occasions that the new  prefixes received, the node was generated a new
> IID, but not for other new prefix generations. Also, as you can see, the
> temporary addresses have the same IID. This means that there is a need
> to change section 8 of this RFC
> 
> received.  I called it “RA-based privacy extension for SLAAC”.
> 
> A second problem that I found with that RFC is the second approach used
> to generate the IID. In section 3.2.2 it describes a more randomized 
> IID generation approach by using  CGA, but it does not explain how to
> use this algorithm when security is not a consideration. In my
> extension, I also explain how to use that algorithm if we do not wish to
> consider security as a part of CGA. Of course, I derived that section
> from my last draft , SSAS, and will remove that section from SSAS. I
> would prefer that the SSAS algorithm  focus more on security and then
> focus on privacy.
> 
>  
> 
> Best,
> 
> Hosnieh
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
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: Thu, 2 May 2013 23:35:51 +0200

Fernando,

The purpose of your draft was not to obsolete or update RFC 4941 and you
wanted to have your approach as an optional approach in parallel with that
approach. So what is your problem with improving that document. It has
nothing to do with your proposal. The people can accept or reject yours. I
do not see any harmful behavior here as I also asked you 1000 times to
update that rfc instead of having something new or in between two RFCs.

Hosnieh

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, May 02, 2013 10:18 PM
To: Hosnieh Rafiee
Cc: [email-masked]
Subject: Re: Solutions to the problem with RFC 4941

Hosnieh,

You have been making many misleading claims about things I have said or
stated. Quite a few times I have corrected you, provided pointers, etc.
-- which you have systematically ignored. Your comments below seem to
indicate to you didn't bother reading the Introduction of
draft-ietf-6man-stable-privacy-addresses, or pay attention to the
clarifications I made on-list. I suggest you wait for the next rev of the
document, but meanwhile you may consult
<http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-re
view.txt>
for an alternative explanation of the issues involved.

All & chairs: I'm currently working a lot with all (off-list, to reduce the
noise) with all those folks that provided feedback during IETC LC and right
after IETF LC on the mailing-list... and we're making a lot of progress on
the I-D. My plan is to submit a rev of
draft-ietf-6man-stable-privacy-addresses fr broader review (i.e., have the
wg review that I have double-checked that addresses IETF LC comments).

FWIW, I'd like to express a big "thank you" to all the folks that have
provided timely comments/reviews, and that have been exchanging emails with
me (off-list) to improve the I-D.

Thanks,
Fernando

On 05/02/2013 04:35 PM, Hosnieh Rafiee wrote:
> Dear All,
> 
>  
> 
> Since Fernando's proposal is not going to solve the current problem 
> with RFC 4941, I have suggested to him, on several occasions, that he 
> resolve this problem so that the node's privacy will be better 
> protected but he ignored this suggestion and claiming that his purpose 
> is different. This is the main reason that today I wrote an RFC draft 
> which I will submit to the IETF repository. This draft does not 
> overlap Fernando's proposal  it is related to the problems with this 
> RFC (RFC 4941) which he doesn't feel the need to address. The problems 
> that I address here concern the fact that the node should also change 
> its IID when it receives different router prefixes.
> 
>  
> 
> occasions that the new  prefixes received, the node was generated a 
> new IID, but not for other new prefix generations. Also, as you can 
> see, the temporary addresses have the same IID. This means that there 
> is a need to change section 8 of this RFC
> 
> A second problem that I found with that RFC is the second approach 
> used to generate the IID. In section 3.2.2 it describes a more 
> randomized IID generation approach by using  CGA, but it does not 
> explain how to use this algorithm when security is not a 
> consideration. In my extension, I also explain how to use that 
> algorithm if we do not wish to consider security as a part of CGA. Of 
> course, I derived that section from my last draft , SSAS, and will 
> remove that section from SSAS. I would prefer that the SSAS algorithm  
> focus more on security and then focus on privacy.
> 
>  
> 
> Best,
> 
> Hosnieh
> 
> 
>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 03 May 2013 08:49:24 +0200

> update that rfc instead of having something new or in between two RFCs.

IMHO You are missing how the standards documents relate to each other.

The base problem is that RFC4862 (IPv6 Stateless Address Autoconfiguration) uses an IID defined in RFC4291 (IP Version 6 Addressing Architecture) Appendix A.

The fact that IID's are derived from EUI64 identifiers using a reversible transformation (RFC4291 Appendix A) means that the IID portion of an IPV6 SLAAC address can be used to infer privacy information about living persons carrying a particular device.

RFC4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) attempted to plug that gap.

RFC4941 did NOT directly update RFC4862 nor RFC4291: it was an optional extension to 4862. This update method was chosen so that RFC4941 was backwards compatible with existing implementations (goal #1 of 4941 Section 3). RFC4941 addresses outbound connections. But RFC4941 is an incomplete solution: nodes implementing RFC4941 still respond on the native SLAAC address generated by RFC4862.

draft-ietf-6man-stable-privacy-addresses plugs that vestigial problem with nodes responding on RFC4862 SLAAC generated addresses, whether RFC4941 has been implemented or not.

If draft-ietf-6man-stable-privacy-addresses updated RFC4941, it would miss out all implementations that did not implement (the optional) RFC4941, so those nodes would be left with a problem.

If draft-ietf-6man-stable-privacy-addresses updated RFC4862, it would mean all existing implementations would have to be mandatorily updated. There's no need for this to guarantee interoperability, and it would clearly be undesirable to deprecate existing implementations (which is why RFC4941 included goal #1).

In the future there may even be better alternatives to RFC4941 and draft-ietf-6man-stable-privacy-addresses.

IMHO These proposed solutions are all orthogonal, and are therefore best defined in independent standards (that use each other as normative references).

best regards,
RayH

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 May 2013 08:16:51 +1200

> IMHO These proposed solutions are all orthogonal, and are therefore best defined in independent standards (that use each other as normative references).

Exactly. I think that draft-ietf-6man-ug clarifies this to some extent,
as a side-effect of clarifying the U/G bits. Would it be useful to add
an extra sentence in that draft, simply stating that a number of
independent methods for forming an IID can exist?

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 3 May 2013 14:39:41 -0700

> independent methods for forming an IID can exist?

Perhaps also referencing Appendix A of RFC4291.

Bob

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 4 May 2013 00:15:19 +0200

> >> The purpose of your draft was not to obsolete or update RFC 4941 and
> >> you wanted to have your approach as an optional approach in parallel
> >> with that approach. So what is your problem with improving that
> >> document. It has nothing to do with your proposal. The people can
> >> accept or reject yours. I do not see any harmful behavior here as I
> >> also asked you 1000 times to update that rfc instead of having something
> new or in between two RFCs.
> >>
> >> Hosnieh
> >
> > The base problem is that RFC4862 (IPv6 Stateless Address Autoconfiguration)
> uses an IID defined in RFC4291 (IP Version 6 Addressing Architecture) Appendix
> A.
> >
> > The fact that IID's are derived from EUI64 identifiers using a reversible
> transformation (RFC4291 Appendix A) means that the IID portion of an IPV6
> SLAAC address can be used to infer privacy information about living persons
> carrying a particular device.
> 
> >
> > RFC4941 did NOT directly update RFC4862 nor RFC4291: it was an optional
> extension to 4862. This update method was chosen so that RFC4941 was
> backwards compatible with existing implementations (goal #1 of 4941 Section
> 3). RFC4941 addresses outbound connections. But RFC4941 is an incomplete
> solution: nodes implementing RFC4941 still respond on the native SLAAC
> address generated by RFC4862.
> >
> >
> > draft-ietf-6man-stable-privacy-addresses plugs that vestigial problem with
> nodes responding on RFC4862 SLAAC generated addresses, whether RFC4941
> has been implemented or not.
> >
> >
> > If draft-ietf-6man-stable-privacy-addresses updated RFC4941, it would miss
> out all implementations that did not implement (the optional) RFC4941, so
> those nodes would be left with a problem.
> >
> > If draft-ietf-6man-stable-privacy-addresses updated RFC4862, it would mean
> all existing implementations would have to be mandatorily updated. There's no
> need for this to guarantee interoperability, and it would clearly be undesirable
> to deprecate existing implementations (which is why RFC4941 included goal
> #1).
> >
> > IMHO These proposed solutions are all orthogonal, and are therefore best
> defined in independent standards (that use each other as normative
> references).
> 
> Exactly

I have already responded to Ray about this. FYI: I have included that response here. 

"We are on the same page. Probably you read the following proposal. That email and his defensive reaction was because he thinks I want to have his proposal. 
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-00
I wrote this yesterday after I found out that his purpose is to have a new optional approach. You can read it. The total text is two pages. It has nothing to do with his proposal. It is just an improvement on RFC 4941. If you see any overlap let me know and I will remove it. My plan is not to steal his idea or his proposal but to just improve the current document."

My concern is also about privacy in a same network and I see it as an important issue. I think that by making a small update to RFC 4941, this will take care the problem. However, some people seem to think that this RFC does not maintain privacy very well. Finally, implementations or RFCs have never been as fast as new RFCs. This means nobody expects that vendors will immediately update their implementations with new options.  In the off list messages exchanged between us, I explained this and asked Fernando whether or not he wants to also cover this privacy issue or he does not still see it as a problem and wants to have a stable IID in the same network. If he covers, I have no more need for my proposal and I can withdraw it but if he does not, then I will keep it because many implementations would rather implement RFC 4941. So why not update it?

Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Sat, 04 May 2013 00:16:11 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 3 May 2013 22:16
>
Yes.

I think there's potentially a number of things to consider clarifying  :

1) There may be multiple independent methods for forming an IID.

2) These methods SHOULD NOT assume any exclusivity, either on a per
link, per interface, or per prefix basis.

3) DAD is the recognised mechanism for testing whether a unicast address
is unique.

4) I have a question regarding existing RFC4862 implementations, and a
very unlikely chain of events.

Quote: draft-ietf-6man-ug  states "Specifications of other forms of
64-bit IID MUST specify how all 64 bits are set, but need not treat the
"u" and "g" bits in any special way." OK current text of
draft-ietf-6man-stable-privacy-addresses is compliant with that.

What happens in the unlikely event that these new mechanisms for
creating an IID (such as draft-ietf-6man-stable-privacy-addresses) and
which ignore setting u/g bits, cause a DAD clash with existing
link-local addresses created compliant to RFC 4862 (IPv6 Stateless
Address Autoconfiguration) especially regarding Section 5.4.5 (When
Duplicate Address Detection Fails), which DOES rely on the u bit?

4862 states: "On the other hand, if the duplicate link-local address is
not formed from an interface identifier based on the hardware address,
which is supposed to be uniquely assigned, IP operation on the interface
MAY be continued."

How would the node using 4862+4291 know the difference whether the
duplicate was caused by another node running 4862+4291 with a duplicate
MAC/EUI-64 hardware address, or because of
draft-ietf-6man-stable-privacy-addresses or some other mechanism?

Presumably by checking the incoming DAD probe NS packet to check if the
transform of the EUI-64 / link-layer hardware source address matches the
interface identifier stripped from the Target Address?

Do all existing 4862 implementations perform this check before disabling
IPv6 processing on the interface?

I think that this additional check is a candidate for a SHOULD, rather
than a MAY, and also needs highlighting in draft-ietf-6man-ug .

regards,
RayH

---

From: Mark Smith <[email-masked]>
Date: Fri, 3 May 2013 16:43:50 -0700 (PDT)

----- Original Message -----
> From: Ray Hunter <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Cc: 'Fernando Gont' <[email-masked]>; [email-masked]
> Sent: Saturday, 4 May 2013 8:16 AM

I think there are rather than may be, as static manually configured addresses would be a method of forming an IID, and I understand they were the motivation for inverting the U bit.

> is unique.

It may also be worth pointing out that more generally, the prefix length doesn't assure the presence of the other addresses within the prefix, and that the only way to test for their presence is to probe for them them. For example, an address with a /127 prefix length on one end of a link doesn't ensure that the other address within the subnet either has been configured at the other end of the link, or isn't a duplicate of the local address. So neighbor presence discovery and DAD really need to take place for all addresses, regardless of the prefix length.

This might also make it clearer that IPv6 addresses, when derived from link layer addresses, aren't tightly bound to them, and that deriving them from the link-layer address has been for operational convenience i.e., autoconfiguration, rather than a requirement (something I struggled with for a while after having experienced Novell IPX, where link-layer addresses were also used as node addresses, and there was no neighbor discovery/address resolution protocol, as the layer 3 node portion of address was directly copied into the link-layer destination address at the last hop).

<snip>

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 03 May 2013 21:33:48 -0300

On 05/03/2013 07:15 PM, Hosnieh Rafiee wrote:
> 
> "We are on the same page. Probably you read the following proposal.
> That email and his defensive reaction was because he thinks I want to
> have his proposal.

My reaction (frustration) is because you make assertions such as this.
e.g. how can you possibly know what I *think*?

In other emails you have not only systematically ignored my responses,
but also made statements like "you said X", when I never said such a thing.

That's where my response came from.

Besides, many times, others and myself have tried to explain that as
with most thinks in the engineering field, there are trade-offs. You
argue that draft-ietf-6man-stable-privacy-addresses doesn't have any
impact on privacy. But me and others have explained otherwise. And I
have even provided a reference to a document posted by the IAB which
essentially argues in favor of producing stable IIDs based on a hash (in
replacement of the embedded MAC address), and also explains why RFC4941
addresses are employed in addition to stable addresses (otherwise,
applications that rely on stable addresses would break).

Eventually, I guess that we need to agree to disagree on these technical
matters (but even then I'd still appreciate that you do not statements
on my behalf based on things I've not said or thought).

Cheers,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 4 May 2013 09:18:35 +0200

> In other emails 
>"you said X", when I never said such a thing.

First, I did not talk on behalf of you. Probably there is misunderstanding in the meaning of the following sentence in my last email (not emails).

>Since Fernando’s proposal is not going to solve the current problem with RFC 4941, I have suggested to him, on several occasions, that he resolve this problem so that the node's privacy will be better >protected but he ignored this suggestion and claiming that his purpose is different.

The meaning of this sentence, if there was misunderstanding: (Based on your responses in the list to me) You are not planning to update this document for whatever reason that you have or explained AND you want to have your draft as one of " several optional standards" as others mentioned. 

http://www.ietf.org/mail-archive/web/ipv6/current/msg16862.html 
http://www.ietf.org/mail-archive/web/ipv6/current/msg16859.html
 
http://www.ietf.org/mail-archive/web/ipv6/current/msg17710.html

Privacy as I defined it before :
" The information in my bank account is my private information and as such should be known to no one. This is privacy., i.e., the information that I do not want to be shared with anyone without my permission: it is so private for me. But by having the same IP address for a long period of time can lead to the leakage of private information. This is why I said that changing the IID from the same network would help. I did not say that the RFC Privacy Extension is perfect. (Nothing in life is perfect. We just strive for perfection but never really attain it.)"

"Why I think that privacy is more an application layer (and in other posts I said, upper layer than IP) issue than an issue with the other layers an why the IP layer might  cause problem in this vain. As an example suppose a criminal follows someone with the name A, Using his IP address to follow A he can then find his location and decide on a location for committing his misdeed, like killing him. Then the IP address proved harmful to his privacy because it exposed information about him to the this criminal. In another example A travels a lot. If a robber follows his IP and knows that he is not at home, he can easily ransack his house. This is again the IP layer causing harm to privacy."

-My concern that I repeated in my posts: If I stay in an x network for more than certain period of time I might be a victim of privacy attacks. The risk of attack depends on the X time. 
-Having stable address helps: Depends on X. if it is short, Yes, but if I am permanently in that network and router prefix does not change, NO. 
-Possible solution: Change my IP address within the same network too.
-How: set a lifetime to my IP address.  

My second concern: moving from and to network a to x. Question: Do I have the same IP in each of these networks?
If yes, I might be a victim.  
- Having stable address helps: If I have the same IP every time I enter to these networks and/or I stay in each networks more than x time, It might not help as the attacker have a chance to still correlate my information to my IP. 

Is RFC 4941 can be of any help?
It might be but needs some improvements. 

@ list: If you think RFC 4941 not really helps for privacy, why do you concern about implementations that use this RFC and talking about backward compatibility? 
In my opinion, If I am a vendor and I see there is no update on a RFC, I assume that it is not a serious concern so when the new optional RFCs do not address my concerns, I still try to implement it for any new OS (using the same old code from my old OS).

@Fernando: If you are so frustrated (for misunderstanding or whatever reasons) Why don't you bring your boxing gloves to Frankfurt main? :-)  as I noticed you are speaker there as well as I. We can enjoy fighting there :-)