Subject: ra-privacy : new version accomodated all the comments

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 9 Aug 2013 00:27:04 +0200

Hello and thank you so much for your comments.

I applied your comments and submitted a new version of the ra-privacy draft.
I also removed the text concerning the application layer based lifetime from
this draft. This draft, thus, just focuses on a few updates to RFC 4941 that
address some deficiencies.

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

According to my discussions with some people during the IETF meetings, some
people thought that it would be better to have the discussion about the
application layer based lifetime in a separate document as it seems that it
is a new mechanism and should not be an update to RFC 4941. In my update to
that RFC , I just briefly mentioned that the node "MIGHT" follow the other
external policies for the lifetime and "Might" not follow those of RFC 4941.

If there are any other issues that I should consider for this draft, please
let me know.

Thanks,

Best,

Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 08 Aug 2013 20:00:49 -0300

Hosnieh,

Some comments:

* In Section 1, you should probably remove some of the general
discussion on security and privacy here. For instance, some of your
definitions seem incomplete.

* Section 6 is fine... but I don't think the rest of the stuff is needed.

* Section 7 should probably be removed and just reference
draft-6man-cooper-ipv6-addressing-privacy-considerations.

Meta comment: If an implementation is going through the burden of
implementing this algorithm, it might as well implement a good PRNG, and
be done with it (if I understand correctly, the motivation for
specifying this algorithm is that you don't have a good PRNG, right?).

Thanks,
Fernando

On 08/08/2013 07:27 PM, Hosnieh Rafiee wrote:
> I applied your comments and submitted a new version of the ra-privacy
> draft. I also removed the text concerning the application layer based
> lifetime from this draft. This draft, thus, just focuses on a few
> updates to RFC 4941 that address some deficiencies.
> 
>  
> 
> According to my discussions with some people during the IETF meetings,
> some people thought that it would be better to have the discussion
> /_about the application layer based lifetime in a separate document _/as
> it seems that it is a new mechanism and should not be an update to RFC
> 4941. In my update to that RFC , I just briefly mentioned that the node
> "MIGHT" follow the other external policies for the lifetime and “Might”
> not follow those of RFC 4941.
> 
>  
> 
>  
> 
> If there are any other issues that I should consider for this draft,
> please let me know.
> 
>  
> 
> Thanks,
> 
> Best,
> 
> Hosnieh
> 

-- 
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: Fri, 9 Aug 2013 22:34:55 +0200

Fernando, Thanks  for your comments.

> * In Section 1, you should probably remove some of the general discussion
on
> security and privacy here. For instance, some of your definitions seem
> incomplete.

Ok, I think I just did not want to jump to the topic and have a kind of
introduction. Maybe I just refer to cooper's draft.

> * Section 6 is fine... but I don't think the rest of the stuff is needed.

Ok. I will remove them

> * Section 7 should probably be removed and just reference
draft-6man-cooper-
> ipv6-addressing-privacy-considerations.

Ok, I will do it

> implementing this algorithm, it might as well implement a good PRNG, and
be
> done with it (if I understand correctly, the motivation for specifying
this
> algorithm is that you don't have a good PRNG, right?).

One reason is PRNG and the other reason is in case the node doesn't want to
use stable storage.

Thanks,
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 09 Aug 2013 18:13:50 -0300

> introduction. Maybe I just refer to cooper's draft.

Just focus on the problem you're trying to solve, and provide references
where necessary.

> One reason is PRNG and the other reason is in case the node doesn't want to

IMO, reason "1" is void: If an implementer is going through the effort
of implementing this document, he/she'd rather implement a god PRNG.

Regarding "2", do you realy need stable storage? -- we're talking about
64-bit IIDs here.

Besides, there are IPRs on the CGA algorithm... but RFC4941 itself
doesn't have any. SO this document would essentially IPR-encumber
RFC4941 -- the farther that you can get from that, the better, I'd say. :-)

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 9 Aug 2013 23:25:50 +0200

Hi there,

> Just focus on the problem you're trying to solve, and provide references
where
> necessary.

Ok :-)

> 
> 
> IMO, reason "1" is void: If an implementer is going through the effort of
> implementing this document, he/she'd rather implement a god PRNG.
> 
64-bit
> IIDs here.
> 
> Besides, there are IPRs on the CGA algorithm... but RFC4941 itself doesn't
have
> any. SO this document would essentially IPR-encumber

CGA has IPR but it does not prevent the implementation of it. So, no worry
about that. In addition, this algorithm is pseudo-CGA as I had to change
some inputs so nobody can claim about IPR for this algorithm. :-)

Thanks again,
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 09 Aug 2013 18:47:13 -0300

On 08/09/2013 06:25 PM, Hosnieh Rafiee wrote:
> about that. 

I believe your underestimating IPRs, and also think that introduing an
IPR to RFC4941 (as this document is indirectly doing) is an extremely
bad idea.

> In addition, this algorithm is pseudo-CGA as I had to change

I won't fight this one with you, Hosnieh. You have received my input.
It's up to you what you do with it.

Cheers,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 9 Aug 2013 23:57:08 +0200

> 
> I believe your underestimating IPRs, and also think that introduing an IPR
to
> RFC4941 (as this document is indirectly doing) is an extremely bad idea.

There is no IPR for my algorithm. You can name it Pseudo CGA or xxx.  I only
used a hash function, i.e., SHA256 that anyone can use a hash function on
some inputs. 

> It's up to you what you do with it.
Check here please:

http://datatracker.ietf.org/ipr/138/ 
<snip>
b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All
Implementers 

Check here if this licensing declaration is limited solely to
standards-track IETF documents _X_
...

Thanks,
Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 09 Aug 2013 19:23:23 -0300

> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to All

This is a non-starter for many free-software projects.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 10 Aug 2013 00:34:07 +0200

Hi Andrew,
Thanks for your comments.

>Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not really seem to be much of a problem as everyone does privacy addresses today (you saw stats yourself at >ipv6-hackers meeting), the second (not changing the address) is an implementation choice, so the third one remains as an open problem, sort of.

It has problem because there are some deficiencies with that RFC. This is the main reason that I wanted to address those problems.  The statistics about Privacy Addresses was more related to the problem that RFC 4941 makes by generating a public address based on EUI-64. So, it also responds to request to that as well as using temporary addresses. This means there is no privacy.  So, this update is to that section of the RFC to ignore the step in order to use other approach to generate public addresses, i.e.,  stable addresses. 

>Now: what's the comparison between the amount of nonvolatile storage taken by code implementing the algorithm vs code to store IIDs ?

It is wording issue and can be interpreted to store all IIDs in a stable storage. The update might not make any problem to the current implementations if they did it correctly but would be consider for any new implementation of this RFC not to store more than the currently assigned IIDs to the network interfaces. 

>P.s. I agree with what Fernando wrote as well. 

As I explained to Fernando, I just named it like that but it does not mean that I used CGA algorithm as it is different inputs by executing a hash function on them and the purpose is not like CGA to find a binding between the IP address and the public key. This means the IPR of CGA is not considered for this algorithm. 

Thanks,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 10 Aug 2013 00:39:35 +0200

> This is a non-starter for many free-software projects.

As I explained before my algorithm is not CGA anyway. 
But, what I know and had many discussions for my other draft, SSAS, the
problem of using CGA is not IPR otherwise without any reason people accepted
SSAS and I did not need to put effort to convince people :-).

Thanks,
Best,
Hosnieh

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 9 Aug 2013 23:13:54 +0100

Hosjieh,

Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not really seem to be much of a problem as everyone does privacy addresses today (you saw stats yourself at ipv6-hackers meeting), the second (not changing the address) is an implementation choice, so the third one remains as an open problem, sort of.

I.e. I am still unclear what's the real-world problem this solves. 

If it is a particular implementation corner case, maybe makes sense to keep it as such, not updating the core specs.

--a

On 08 Aug 2013, at 23:27, "Hosnieh Rafiee" <[email-masked]> wrote:

> I applied your comments and submitted a new version of the ra-privacy draft. I also removed the text concerning the application layer based lifetime from this draft. This draft, thus, just focuses on a few updates to RFC 4941 that address some deficiencies.
>  
> According to my discussions with some people during the IETF meetings, some people thought that it would be better to have the discussion about the application layer based lifetime in a separate document as it seems that it is a new mechanism and should not be an update to RFC 4941. In my update to that RFC , I just briefly mentioned that the node "MIGHT" follow the other external policies for the lifetime and “Might” not follow those of RFC 4941.
>  
>  
> If there are any other issues that I should consider for this draft, please let me know.
>  
> Thanks,
> Best,
> Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Sat, 10 Aug 2013 00:37:09 -0300

> As I explained before my algorithm is not CGA anyway. 

It looks pretty much like it. And, in any case, it's a complex way of
doing something that can be much simpler.

> SSAS and I did not need to put effort to convince people :-).

The problem of your scheme is that is an extremely complex way of doing
something that can be much simpler.

IPRs *are* a problem. If you think you know better, talk to developers.

Cheers,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 10 Aug 2013 09:43:56 +0200

> >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to
> >>> All Implementers
> >>
doing
> something that can be much simpler.

Disagree! Please check RFC 4086. Most of the approaches uses a hash function
on some inputs. How you look at the algorithms is pretty like a kind of
generalization. So, one might interpret from what you said as follow: 
"any algorithm in any RFC that uses any hash function is CGA!"
However, this interpretation is not true.  If you use the same inputs with
the same orders, the same hash function and with the same purpose, i.e.,
your purpose is also binding between the IP address and the public key, then
you can call it CGA. But any modifications to this algorithm by using any
different inputs and different purpose is not CGA anymore or not included in
the IPR of CGA. Probably you know how to apply for a patent. You should be
so specific and explain your algorithm in so detail. 
 
Just a quick response to show you my algorithms are not complex. Let's
compare most IID algorithms in a simple scheme, we also skip how they want
to pick up a function for your case like F() or modifier or secret_key, etc:

Ra-privacy : R=Sha256(modifier,subnetprefix,timestamp)    => IID=64bits(R) 
                        
RFC4941 : Is_null(history) = true => history= Generate(random_Val)=> R=
MD5(history,EUI-64)  =>  Is_Match{Compare_to_reserved_stablestorage(R)}=
false (true: repeat_algorithm()) => IID= 64_leftmost_bits(R)  and
history=64_rightmost_bits(R)  

SSAS :  pubkey,prikey = Generate(keypair) => p1,p2=Split(pubkey) => IID=
concatenation(p1,p2);

Stable-addresses : RID= F(Prefix, Net_Iface, Network_ID, DAD_Counter,
secret_key) => IID=64_leftmost_bits(RID)

CGA : Hash1=Sha1(modifier, subnet prefix, collision count,  public key) =>
R=16_LeftMost_byte_By_secval(R) => CompareToZero(R) ?= true (false:
Increment(modifier); repeat algorithm) => Hash2= Sha1(modifier, subnet
prefix, collision count,  public key) => IID= 64leftmostbits(Hash2) 

Now, as you know, MD5 and SHA256 both are hash functions, often RFC 4086
(randomization) also, as I explained earlier, uses a hash function on
inputs. This means that F() also can be a hash function in some implementers
as they can pick up any function. So, Are all of these functions (except the
last one) complex and CGA? 

In your own draft (stable addresses) section 3:
<snip>
" F():
          A pseudorandom function (PRF) that is not computable from the
          outside (without knowledge of the secret key), which should
          produce an output of at least 64 bits. The PRF could be
          implemented as a cryptographic hash of the concatenation of
          each of the function parameters."
<snip>

Compare the complexity (you can compare the algorithm yourself):

Most complex   to least complex
CGA>>>SSAS   ~= RFC 4941 > stable-addresses ~= ra-privacy

So, I don't understand your concerns here.

> > But, what I know and had many discussions for my other draft, SSAS,
> > the problem of using CGA is not IPR otherwise without any reason
> > people accepted SSAS and I did not need to put effort to convince people
:-).
> something that can be much simpler.

Complex!?? :-O  please read ssas draft. You cannot find simpler than that
:-). It might be more straight forward than even your draft.

> IPRs *are* a problem. If you think you know better, talk to developers.

I talked with Pascal and others In cisco who developed SeND. Cisco supports
SeND modules in some of their routers. It appears that IPR wasn't a problem
for them. :-) if so, Pascal can explain this better.

@Pascal : Was IPR a problem for you when you developed SeND for cisco
routers?

Best,
Hosnieh

---

From: Fernando Gont <[email-masked]>
Date: Sat, 10 Aug 2013 07:48:34 -0300

Hosnieh,

We have already been down this road where I feel you don't seem to
listen/read what I say. I won't comment any further, except for one
small comment.

>>>> This is a non-starter for many free-software projects.
[...]
> for them. :-) if so, Pascal can explain this better.

Unless IOS has became free software, it looks like you're not reading
what I'm writing.

Thanks,

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 10 Aug 2013 13:27:00 +0200

My explanation was clear and covered all concerns about my algorithm (as it
is not the CGA at all and so no IPR), so I also don't think there is any
need to explain more. Otherwise somebody else still has a problem and not
convinced.

> > I talked with Pascal and others In cisco who developed SeND. Cisco
> > supports SeND modules in some of their routers. It appears that IPR
> > wasn't a problem for them. :-) if so, Pascal can explain this better.
> 
> Unless IOS has became free software, it looks like you're not reading what
I'm
> writing.

When we bought a cisco router with SeND capabilities, it didn't seem to be
free of charge and we had to pay for the module to support SeND (it was
extra cost on the router to add a module which supports SeND and other
features). I also tried to download the latest IOS of cisco. It appears that
it is only possible by a valid contract in my profile.
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/pro
duct_bulletin_c25-409474.html 

Thanks,
Hosnieh