Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)

On 08/10/2014 20:50, Pierre Pfister wrote:
> Hello Brian
> 
> Please find my answer inline.
> 
> Le 8 oct. 2014 à 02:32, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
> 
>> On 08/10/2014 12:14, James Woodyatt wrote:
>>
>> (quoting draft-ietf-homenet-prefix-assignment-00)
>>
>>>   prefix.  If no ULA prefix can be found in stable storage, it MUST be
>>>   randomly generated, or generated from hardware specific values.
>> That sentence is not OK. It should be:
>>
>> If no ULA prefix can be found in stable storage, it MUST be generated
>> as specified in [RFC4193].
> 
> The point was to have a pseudo-random algorithm that always generates the same ULA.
> Stable storage can be used, but on most crappy home routers, writing on the SSD too much will kill it in a few thousands writes.

There is nothing in RFC 4193 that prevents saving the generated ULA in
stable storage for future use; so I think you need to be clearer that
when a ULA is generated, it SHOULD be stored for future use (until the
next factory reset). I don't see why that generates more than a very few
writes to SSD.

> [RFC4193] states:
> 3.2.1.  Locally Assigned Global IDs
> 
>    Locally assigned Global IDs MUST be generated with a pseudo-random
>    algorithm consistent with [RANDOM].
> 
> If remembering the ULA prefix and using it again and again (using stable storage) is OK, I don’t see why we would need cryptographic pseudo-randomness here.
> And actually that’s even worse. Why would a cryptographic pseudo-random function would be used with a *known* seed. 
> The ULA doesn’t need to be secret. It just needs to be random enough to avoid collisions.

Well, yes, but randomness is randomness, i.e. all values are equally likely.
It's really the same thing. I think the assumption was that any box capable
of generating a ULA would already have something better than rand() built in
for other reasons.

> My point here is that if we conform to RFC4193, we lose the stability of the generated ULA, and IMHO we win nothing.

But if you deviate from the standard you need to say so explicitly.
"This procedure deviates from [RFC4193] because...".

> Correct me if I’m wrong, but I think using hardware specific values as seed is perfectly fine with the collision-avoidance requirement.

I would expect so, and I'm not against what you propose, it just needs
to be clearly documented.

    Brian

> Cheers,
> 
> Pierre
> 
>>> The requirements keywords in this section make for a pretty serious interop
>>> clash with Thread networks <http://threadgroup.org/>, which generate their
>>> own ULA prefix based on a method defined by its current conventions.
>> I sincerely hope that method conforms to RFC4193.
>>
>>    Brian
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 