[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: Status of Privacy Extensions for Stateless Address Autoconfiguration in IPv6
From:       Alexandre Petrescu <alexandre.petrescu () gmail ! com>
Date:       2020-04-02 13:57:32
Message-ID: 909882b4-4dc3-a2b2-31a8-950f1f1d6109 () gmail ! com
[Download RAW message or body]



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,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]