Re: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

[Alexandre Petrescu <[e-mail]>]

Le 10/09/2020 à 13:26, Lorenzo Colitti a écrit :
> Having read this document again, I have the following concerns.
> 
> 1. I think it should not include section 3.3.2. The reason is that it
>  needlessly suggests an algorithm that is much more complex than
> simply using an existing random number generator which all nodes
> likely already have.

I object to that I-D paragraph at least because it says this "SHOULD
produce an output of at least 64 bits."  It should be of a more variable
length.  It is not 'at least 64bit'.

I do not oppose to the existence of that section 3.3.2.  But how would
it cope with other generated Interface Identifiers, like HIT (Host
Identity Tag) or ORCHIDs.  These are too RFCs on the Standards Track.
They too are generated by a crypto function, they too are 64bit length.
  Still they are different than this F().

As for implementation of it, think that there are already
implementations of generating Interface IDs out there, and I think none
respects what either of these documents says.

(we do have a couple of Internet Drafts under preparation, and code,
about this variable length 64bit, but for some reason it takes more
private interest and review than expected...)

Alex


> 2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2)
> is not useful to implementers, because all it says is that it is
> possible to implement a behaviour that for in all practical cases is
> forbidden by RFC 4291. 3. This normative text:
> 
> 1.  Process the Prefix Information Option as defined in [RFC4862], 
> adjusting the lifetimes of existing temporary addresses.  If a 
> received option may extend the lifetimes of temporary addresses, with
> the overall constraint that no temporary addresses should ever remain
> "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME)
> or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR) respectively.
> 
> does not seem to mean anything because the second sentence lacks a
> verb. If a received option may extend the lifetime of temporary
> addressess... then what should the implementation do? The text
> doesn't say.
> 
> 4. This text:
> 
> Note that, except for the transient period when a temporary address
> is being regenerated, in normal operation at most one temporary
> address per prefix should be in a non-deprecated state at any given
> time on a given interface.
> 
> seems excessive because it immediately makes all current
> implementations non-compliant. It also does not seem like a good
> thing to limit the number of temporary addresses in general. If an
> implementation wants to create more than one for extra privacy (e.g.,
> to use different IPv6 addresses for different applications), it
> should be free to do so. This text is also not true if a user changes
> TEMP_VALID_LIFETIME to a value that is not exactly 2x
> TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change
> these values in section 3.8.
> 
> 5. Should this text:
> 
> The TEMP_PREFERRED_LIFETIME value MUST be less than the 
> TEMP_VALID_LIFETIME value.
> 
> really say "less than"? Shouldn't it say "less than or equal to"?
> 
> On Thu, Sep 10, 2020 at 7:55 AM The IESG <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man)
> to consider the following document: - 'Temporary Address Extensions
> for Stateless Address Autoconfiguration in IPv6' 
> <draft-ietf-6man-rfc4941bis-10.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to
> the [e-mail] <mailto:[e-mail]> mailing lists by 
> 2020-09-23. Exceptionally, comments may be sent to [e-mail]
> <mailto:[e-mail]> instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> This document describes an extension that causes nodes to generate 
> global scope addresses with randomized interface identifiers that 
> change over time.  Changing global scope addresses over time limits 
> the window of time during which eavesdroppers and other information 
> collectors may trivially perform address-based network activity 
> correlation when the same address is employed for multiple 
> transactions by the same node.  Additionally, it reduces the window 
> of exposure of a node via an address that becomes revealed as a 
> result of active communication.  This document obsoletes RFC4941.
> 
> 
> 
> 
> The file can be obtained via 
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail]
> <mailto:[e-mail]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>