Re: Issues Raised in Chair Review of <draft-ietf-6man-rfc4941bis-05 >

[Fernando Gont <[e-mail]>]

Hello, Bob,

On 27/1/20 14:17, Bob Hinden wrote:
> Ole and I did a chairs review of <draft-ietf-6man-rfc4941bis-05>.   Our comments are below.
> 
> We sent editorial issues to the authors separately.

Thanks for the review!

I see that some comments have to do with "why this text is here?". FWIW, 
some of the text, or titles, or even ordering for the sections simply 
come from rfc4941 -- when we started the rfc4941bis approach rather than 
pursuing draft-gont-6man-non-stable-iids.



>> 1.  Introduction
> 
> This section needs needs to repeat that this obsoletes RFC4941, and good to have a short summary of what changed.

Will add a note. For the summary, why not simply move the current 
Section 8 ("Significant Changes from RFC4941"), and reference the 
appendix from here?





>> 2.1.  Extended Use of the Same Identifier
> 
> This section is missing a description about tracking stable IIDs when the node connects to different networks.

Not sure what you mean. Tracking as in checking whether the node is 
connected to any of a given set of networks, by e.g. pinging the stable 
address?


> 
> 
>> 2.2.  Possible Approaches
> 
> Better to have this a new section, it’s not part of “Background”.

I see it as "background" since it sets the stage for what we're doing in 
the spec. -- and it even discusses things like DHCPv6, which doesn't 
have much to do with this aprticular spec.  Note: this section was also 
grouped within "Background" in RFC4941 (see: 
https://tools.ietf.org/html/rfc4941#section-2.4)


> 
>>
>>    One way to avoid having a stable non-changing address is to use
>>    DHCPv6 [RFC8415] for obtaining addresses.  Section 12 of [RFC8415]
>>    discusses the use of DHCPv6 for the assignment and management of
>>    "temporary addresses", which are never renewed and provide the same
>>    property of temporary addresses described in this document with
>>    regards to the privacy concern.
> 
> We don’t think this should be the first paragraph.   Start with the next paragraph.  Then the DHCPv6 paragraph can be at the end of this section, starting with “Another way…”.

It would seem to me that since this spec is all about slaac, it would be 
best to remove the paragraph on dhcpv6. Thoughts?





> 3.1.  Assumptions
> 
> 
>>    ….
>>            This document also
>>    assumes that an API will exist that allows individual applications to
>>    indicate whether they prefer to use temporary or stable addresses and
>>    override the system defaults.
> 
> Is this the best approach?   Or should the user be able to configure this on a per node basis?

I'd say much of this is largely unspecified, as noted in: 
draft-gont-6man-address-usage-recommendations

That said, I do think the approach described is the best: you have a 
default setting, and a way to override it.




> 
>> 3.2.  Generation of Randomized Interface Identifiers
>>
>>    The following subsections specify   example algorithms for
>>    generating temporary interface identifiers that follow the guidelines
>>    in Section 3 of this document.
> 
> s/Section 3/Section 3.1/

Thanks! WIll fix.



> 
>> 3.2.1.  Simple Randomized Interface Identifiers
>>
>>    One approach is  to select a pseudorandom number of the
>>    appropriate length.  A node employing this algorithm should generate
>>    IIDs as follows:
>>
>>    1.  Obtain a random number (see [RFC4086] for randomness requirements
>>        for security).
>>
>>    2.  The Interface Identifier is obtained by taking as many bits from
>>        the random number obtained in the previous step
>>        as necessary.  Note: there are no special bits in an Interface
>>        Identifier [RFC7136].
>>
>>           We note that [RFC4291] requires that the Interface IDs of all
>>           unicast addresses (except those that start with the binary
>>           value 000) be 64 bits long.  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).
> 
> It get’s a lot worse if the IID is much smaller, for example, an 8 bit IID is not very useful.   Suggest removing this paragraph or expand it.   The current text doesn’t add very much value.

This text was pretty much borrowed from RFC7217. The motivation for it 
is to keep the hardcoded value of "64" where it belongs (RFC4291
), rather than explicitly repeat "64" here which wuold be a suboptimal 
spec approach. So the text essentially means "You are going to pick 64 
bits because that's what rfc4291 requires for unicast addresses that 
start with binary 000, but you could actually use this algorithm for any 
IID length).

THoughts?




>> 3.2.2.  Hash-based Generation of Randomized Interface Identifiers
>>
>>    The algorithm in [RFC7217] can be augmented for the generation of
>>    temporary addresses.  The benefit of this would be that a node could
>>    employ a single algorithm for generating stable and temporary
>>    addresses, by employing appropriate parameters.
>>
>>    Nodes would employ the following algorithm for generating the
>>    temporary IID:
>>
> 
> What are the differences from the RFC7217 algorithm and why is it changed?  It appears to be different.  This makes the statement in the first paragraph incorrect.

The algorithm is the same, with the exception of the new "Time" argument 
that guarantees that IIDs change over time.

The parameter "MAC_Address" is Net_Iface from RFC7217. We changed the 
*name* of the parameter to make it more explicit about what it contains.

Let me know if this clarifies your comment, or whether I should add 
similar text to the I-D to incorporate the clarification into the I-D.



> 
>> 3.3.  Generating Temporary Addresses
>>
>> …..
>>
>>    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.  The configuration variables
>>        TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
>>        approximate target lifetimes for temporary addresses.
>>
> 
> Why would not each address have an expiration time instead, then DESYNC_FACTOR factor doesn't need to be factored in here?

How would you check the lifetimes have not been expanded past: 
(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), 
respectively?

(see bullet 2. bellow this one, that suggests one approach)



> 
>> 5.  A temporary address is created only if this calculated Preferred
>>        Lifetime is greater than REGEN_ADVANCE time units.  In
>>        particular, an implementation MUST NOT create a temporary address
>>        with a zero Preferred Lifetime.
> 
> REGEN_ADVANCE   Please define or explain this variable before use.

FWIW, we kept the structure of RFC4941, that employs these constants and 
define them later in the text (see: 
https://tools.ietf.org/html/rfc4941#section-5).

We can move the "Defined constants" up in the document, if deemed necessary.


> 
>>
>> 7.  The node MUST perform duplicate address detection (DAD) on the
>>
> …..
> 
>> If after TEMP_IDGEN_RETRIES
>>        consecutive attempts no non-unique address was generated, the
>>        node MUST log a system error and MUST NOT attempt to generate
>>        temporary addresses for that interface.
> 
> Is that the correct behavior, if so explain why?

This is text borrowed from RFC4941.

Essentially you have two options:
1) Keep trying forever
2) Try a few times, after which you should have succeeded unless 
something weird is going on.


RFC4941 does "2)". It recovers from the problem, and logs the problem if 
something weird were going on.




>> 3.5.  Regeneration of Temporary Addresses
> ….
>> Implementations SHOULD provide end users with the
>>    ability to override both of these default values.
> 
> Seems doubtful that most users would understand what to do with this.

Agreed. But I guess still valid. e.g., As a Linux user I have tons of 
knbs to control network configuration (e.g., SLAAC vs DHCPv6 vs manual, 
etc.). MOst users won't care. But those who care, have knobs to play with.



>> 3.6.  Implementation  Considerations
>>
>> ….
> 
>>    other global prefixes.  Another site might wish to enable temporary
>>    address generation only for the prefixes 2001::/16 and 2002::/16
> 
> Poor choice of example prefixes.  Use documentation prefixes?

This text was borrowed from RFC4941. While I think they meant the 
prefixes they picked, I think they could be replaced with documentation 
prefixes. Will do.




>>    while disabling it for all other prefixes.  To support this behavior,
>>    implementations SHOULD provide a way to enable and disable generation
>>    of temporary addresses for specific prefix subranges.  This per-
>>    prefix setting SHOULD override the global settings on the node with
>>    respect to the specified prefix subranges.  Note that the per-prefix
>>    setting can be applied at any granularity, and not necessarily on a
>>    per subnet basis.
>>
>>    The use of temporary addresses may cause unexpected difficulties with
>>    some applications.  As described below, some servers refuse to accept
>>    communications from clients for which they cannot map the IP address
>>    into a DNS name.  In addition, some applications may not behave
>>    robustly if temporary addresses are used and an address expires
>>    before the application has terminated, or if it opens multiple
>>    sessions, but expects them to all use the same addresses.
> 
> This is not an implementation consideration.   It is also redundant with next section.

FWIW, Ole had suggested to rename the section to "IMplementation 
considerations".

I will move the non-repeating text to Section 4 ·IMplications of 
CHanging Interface Identifiers"...



> 
>> 4.  Implications of Changing Interface Identifiers
>> ...
>>
>>    Some servers refuse to grant access to clients for which no DNS name
>>    exists.  That is, they perform a DNS PTR query to determine the DNS
>>    name, and may then also perform an AAAA query on the returned name to
>>    verify that the returned DNS name maps back into the address being
>>    used.  Consequently, clients not properly registered in the DNS may
>>    be unable to access some services.  As noted earlier, however, a
>>    node's DNS name (if non-changing) serves as a constant identifier.
>>    The wide deployment of the extension described in this document could
>>    challenge the practice of inverse-DNS-based "authentication," which
>>    has little validity, though it is widely implemented.  In order to
>>    meet server challenges, nodes could register temporary addresses in
>>    the DNS using random names (for example, a string version of the
>>    random address itself).
> 
> Is this even used for IPv6?    Relevance for this document?

Yes, it is relevant. My mail server suffered from that when the server 
address changed, and I forgot to update the referse mappings.



>> 5.  Defined Constants
> 
> This needs to be move earlier in the document, before they are used.

Any suggestion where to?

Maybe unfold Section 3.3 into "Defined Constants" and "Algorithm"? -- 
but wouldn't look good.


FWIW, the current order is what's in RFC4941 (they first use the 
constants, and define them at the end). RFC4861 does the same (see: 
https://tools.ietf.org/html/rfc4861#section-10)


> 
>>
>>    Constants defined in this document include:
>>
>>    TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
>>    to override the default value.
>>
>>    TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
>>    able to override the default value.
>>
>>    REGEN_ADVANCE -- 5 seconds
>>
>>    MAX_DESYNC_FACTOR -- 10 minutes.  Upper bound on DESYNC_FACTOR.
>>
>>    DESYNC_FACTOR -- A random value within the range 0 -
>>    MAX_DESYNC_FACTOR.  It is computed once at system start (rather than
>>    each time it is used) and must never be greater than
>>    (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).
> 
> We don't think the purpose of DESYNC_FACTOR has ever been described?

It is described in SEction 3.5:
    The value
    DESYNC_FACTOR is a random value (different for each client) that
    ensures that clients don't synchronize with each other and generate
    new addresses at exactly the same time.

(this text, and order, also borrowed from RFC4941)


(that said, I wonder if this should be more dynamic, as "selected each 
time a temporary address is generated, and also if it shoudl be 
specified more as a % of te TEMP_PREFERRED_LIFETIME).


> 
>> 6.  Future Work
>>
>>    An implementation might want to keep track of which addresses are
>>    being used by upper layers so as to be able to remove a deprecated
>>    temporary address from internal data structures once no upper layer
>>    protocols are using it (but not before).  This is in contrast to
>>    current approaches where addresses are removed from an interface when
>>    they become invalid [RFC4862], independent of whether or not upper
>>    layer protocols are still using them.  For TCP connections, such
>>    information is available in control blocks.  For UDP-based
>>    applications, it may be the case that only the applications have
>>    knowledge about what addresses are actually in use.  Consequently, an
>>    implementation generally will need to use heuristics in deciding when
>>    an address is no longer in use.
>>
>>    Recommendations on DNS practices to avoid the problem described in
>>    Section 4 when reverse DNS lookups fail may be needed.  [RFC4472]
>>    contains a more detailed discussion of the DNS-related issues.
>>
>>    While this document discusses ways of obscuring a user's IP address,
>>    the method described is believed to be ineffective against
>>    sophisticated forms of traffic analysis.  To increase effectiveness,
>>    one may need to consider the use of more advanced techniques, such as
>>    Onion Routing [ONION].
> 
> Is this section needed?   Suggest removing it.

This section was borrowed from RFC4941. I wouldn't mind myself removing 
it, although the first paragraph seems useful.

OTOH, the last para could be moved to the "Security Considerations" Section.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492