Added key pair to the CGA as well :-)
> On 08/09/2013 07:39 PM, Hosnieh Rafiee wrote: > >>> Check here please: > >>> > >>> http://datatracker.ietf.org/ipr/138/ > >>> <snip> > >>> b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to > >>> All Implementers > >> > >> This is a non-starter for many free-software projects. > > > > 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. 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=64_leftmost_bits(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_ECC(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 : pubkey,prikey = Generate_RSA(keypair) =>Hash1=Sha1(modifier, subnet prefix, collision count, pubkey) => R=16_LeftMost_byte_By_secval(R) => CompareToZero(R) ?= true (false: Increment(modifier); repeat algorithm) => Hash2= Sha1(modifier, subnet prefix, collision count, pubkey) => 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 :-). > > The problem of your scheme is that is an extremely complex way of > doing 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
