Re: Status of Privacy Extensions for Stateless Address Autoconfiguration in IPv6

[Alexandre Petrescu <[e-mail]>]

Le 02/04/2020 à 15:47, Fernando Gont a écrit :
> On 2/4/20 10:32, Alexandre Petrescu wrote:
>>
>> Le 02/04/2020 à 15:16, Fernando Gont a écrit :
>>> Alexandre,
>>>
>>> On 2/4/20 09:54, Alexandre Petrescu wrote:
>>>> Le 02/04/2020 à 14:39, Fernando Gont a écrit :
>>>>> On 2/4/20 09:25, Alexandre Petrescu wrote:
>>>>>> would it it be possible to specify this:
>>>>>>> However, the method discussed in
>>>>>>>           this document could be employed for generating 
>>>>>>> Interface IDs
>>>>>>>           of any arbitrary length, albeit at the expense of reduced
>>>>>>>           entropy (when employing Interface IDs smaller than 64 
>>>>>>> bits) or enhanced entropy (when IID len longer than 64)
>>>>>>
>>>>>> (note 'IID longer than 64')
>>>>>
>>>>> Not sure what you mean.
>>>>> 1) That's of course implied
>>>>> 2) 2**64 is enough entropy for this kind of thing. Why would anyone 
>>>>> do that??
>>>>>
>>>>> I miss the point you are trying to make...
>>>>
>>>> At some point you say less than 64 entropy might not be enough, and 
>>>> that a limit is not clear.
>>>
>>> Nope neither me nor the document says that. The document says the 
>>> obvious: the algorithm does not have any inherent requirement 
>>> regarding the IID length. Of course, if you change the IID length, 
>>> you change the entropy (the search space). (e.g., if you reduced the 
>>> IID length, the entropy would be reduced).
>>>
>>>
>>>> But similarly, more than 64 entropy might be more than enough - you 
>>>> just dont say it.
>>>
>>> Let me put it bluntly: even 32 bits would be more than enough for this.
>>
>> Yes, write that down.  I agree with you.  I do not know why not 
>> writing it down.
> 
> Because this is not a document to discuss IID lengths. The current specs 
> mandate /64. If that's changed, such document should do the appropriate 
> analysis. There's no reason for this document to do that.

True.

It might be this is not a right time to advance this document to IESG.

Maybe address first that IID length in the IPv6 Addr Arch document.

Until then, any privacy work might be irrelevant.

Security is a chain: weakest link breaks it all.

Alex, LF/HF 1

> 
> 
> 
> 
>>>> You say 'it is implied', but there is silence, actually.
>>>>
>>>> There is nothing in I-D RFC4941bis, nor in RFC7421, that talks about 
>>>> IID length longer than 64.
>>>
>>> 1) The current architecture doesn't have such a thing
>>
>> All IPv6-over-foo docs request it, and the IPv6 Addr Arch requests it.
> 
> Exactly. There's no point in getting into a discussion about something 
> that's not even allowed in the current specs.
> 
> 
> 
> [...]
>>> 2) I personally don't think anybody would even think about IIDs 
>>> longer than 64 bits. 64-bit IIDs already waste a big part of the 
>>> address space.
>>
>> ??  No, I dont think so.
>>
>> I personally think IIDs longer than 64bit are absolutely necessary in 
>> some contexts.  A SLAAC where a router that advertises a /56 in an RA, 
>> might need the Host  to form a 72bit IID.
> 
> Write a draft, and propose that change. Until that, this document need 
> to stick to existing specs.
> 
> Thanks,