Subject: Benjamin Kaduk's Discuss on draft-ietf-6man-rfc4941bis-11: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 19:45:53 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-rfc4941bis-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I am not entirely sure what we mean by saying that temporary addresses
must have a lifetime that is "statistically different" across different
addresses, and accordingly I am not sure that the procedures in Section
3.4+3.5 for rereshing a temporary address achieve that property.  (The
text about "statistically different" does not appear in RFC 4941, and
the relevant parts of Section 3.4/3.5 are unchanged from RFC 4941, so
this may be the result of an incomplete update.)

Specifically, when Section 3.5 says to "[repeat] the actions described
in Section 3.4, starting at step 4" that seems to (for long-lived PIOs)
result in, e.g., the new temporary address having lifetime
TEMP_VALID_LIFETIME starting at exactly the time when the previous one
expired; wouldn't an observer be able to trivially correlate "new
address showed up with TEMP_VALID_LIFETIME" with "address that expired
at that time"?  Note that the attacker does not need to know the value
of TEMP_VALID_LIFETIME in order to perform a DFT on the distribution of
"new address" events.  (Furthermore, we apparently qualify the
"repeating the actions" with some caveats, which doesn't exactly qualify
as "repeating the actions" anymore.  That said, the caveats currently
listed in Section 3.5 don't seem to be enough to provide the
"statistically different property" in what I believe to be the intended
interpretation.)

(2) Please fix the reference for DupAddrDetectTransmits in Section 3.8
-- it is defined in 4862, while RetransTimer is in 4861.

(3) RFC 4941 cannot be a *normative* reference of this document if we are
going to Obsolete it.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

Having followed many of the references from the Introduction, it seems
that there could be an additional aspect to the problem statement,
namely the question of whether an attacker can (statistically) determine
whether or not there is a host at a given address/IID.  When such an
ability is present, techniques (e.g., pen-testing) involving scanning
the entire address space become more feasible.  I do not think this
potential aspect needs to be mentioned, per se, but do not know if it
was considered for inclusion or not.

   The correlation can be performed by

   o  An attacker who is in the path between the node in question and
      the peer(s) to which it is communicating, and who can view the
      IPv6 addresses present in the datagrams.

   o  An attacker who can access the communication logs of the peers
      with which the node has communicated.

(side note) I suppose if some other node in the path kept logs and the
attacker got access to those logs, that would also allow the
correlation, but that's rather an edge case and we don't claim to have
an exhaustive list, so I don't see a need to add complications to this
text.

   Use of temporary addresses will not prevent such payload-based
   correlation, which can only be addressed by widespread deployment of
   encryption as discussed in [RFC7624].  Nor will it prevent an on-link
   observer (e.g. the node's default router) to track all the node's
   addresses.

nit: s/to track/from tracking/

Section 2.1

   Many nodes also have DNS names associated with their addresses, in
   which case the DNS name serves as a similar identifier.  Although the
   DNS name associated with an address is more work to obtain (it may
   require a DNS query), the information is often readily available.  In
   such cases, changing the address on a machine over time would do
   little to address the concerns raised in this document, unless the
   DNS name is changed as well (see Section 4).

nit: perhaps say "at the same time"?

   The use of a constant identifier within an address is of special
   concern because addresses are a fundamental requirement of
   communication and cannot easily be hidden from eavesdroppers and
   other parties.  Even when higher layers encrypt their payloads,

(editorial) the two paragraphs before this one seem to be examples (DNS
names, HTTP cookies) of "identifier[s] that [are] recognizable over time
within different contexts" as discussed in the paragraph prior to them.
This paragraph is getting back to why we care about constant identifiers
in IP addresses; I wonder if some kind of (list?) formatting for the
previous two paragraphs might help indicate the structure of the
discussion.

   Changing global scope addresses over time limits the time window over
   which eavesdroppers and other information collectors may trivially
   correlate network activity 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 gets revealed as a
   result of active communication.

I'm not 100% sure that I understand what is being exposed by this
"window of exposure" -- is it just "there is a node at this address and
it is responsible for all activities using that address"?  Thus, perhaps
"window of exposure for such correlation"?  (Similar text also appears
in the Abstract.)

   The security and privacy implications of IPv6 addresses are discussed
   in detail in [RFC7721], [RFC7707], and [RFC7217].

A sentence essentially identical to this one already appeared in the
Introduction; I'm not sure if we should de-duplicate.

Section 3.1

   4.  Temporary addresses must have a limited lifetime (limited "valid
       lifetime" and "preferred lifetime" from [RFC4862]), that should
       be statistically different for different addresses.  The lifetime

We should probably be more specific about what "statistically different" is
supposed to mean.  For example, is it intended to relate to the initial
value associated with a freshly generated address (i.e., "should not be
exactly 24 hour lifetime at time of generation") or the offset between
different addresses ("should not be exactly 24 hours more than the
previous one")?

   5.  By default, one address is generated for each prefix advertised
       by stateless address autoconfiguration.  The resulting Interface
       Identifiers must be statistically different when addresses are
       configured for different prefixes.  That is, when temporary

[In contrast, this use of "statistically different" is both (1)
clarified further and (2) for a time-independent quantity, so the
interpretation is pretty clear as-is.]

Section 3.3.1

I think we need to say something about the random number being long
enough or getting more random bits in step 2 if there aren't enough
bits, or similar.  Just "obtain a random number" doesn't say what the
number is sampled from, and could cover, e.g., https://xkcd.com/221/ .

Section 3.3.2

   1.  Compute a random identifier with the expression:

       RID = F(Prefix, Net_Iface, Network_ID, Time, DAD_Counter,
       secret_key)
   [...]
       F():
          A pseudorandom function (PRF) that MUST NOT be computable from
          the outside (without knowledge of the secret key).  F() MUST
          also be difficult to reverse, such that it resists attempts to
          obtain the secret_key, even when given samples of the output
          of F() and knowledge or control of the other input parameters.
          F() SHOULD produce an output of at least 64 bits.  F() could
          be implemented as a cryptographic hash of the concatenation of
          each of the function parameters.  SHA-256 [FIPS-SHS] is one
          possible option for F().  Note: MD5 [RFC1321] is considered
          unacceptable for F() [RFC6151].

I recognize that this is just the RFC 7217 construction with the 'Time'
parameter added, but it's not entirely clear that we want to be
recommending the plain "hash of concatenation" option without additional
caveats.  While having the secret key be the last element in the
bitstring seems to close off the length-extension class of attacks, we
don't say anything about performing the concatenation with fixed-width
types (or a length prefix), as is needed for non-malleability of the
hash inputs.  (This is particularly of note for the IPv6 prefix, that
one might naturally encode as just the prefix parts, not necessarily
fixed length, but also applies to other parameters, including some of
the "Net_Iface" examples given in RFC 7217.)  There is also no
discussion about the potential for hash collisions (or, more generally,
attacks) across this construction and the RFC 7217 construction.
Guidance to not reuse a secret_key for both constructions would be in
order.  (I will note that it may be tempting to upgrade to an HMAC
construction, and while that will certainly work, modulo the need for
length prefixes/fixed-length input, it is overkill for this case.)
Finally, the guidance for "SHOULD produce an output of at least 64 bits"
could perhaps be revisited; any useful cryptographic hash these days is
going to have at least 128 bits of output, which is certainly enough for
generating an IID!

       Prefix:
          The prefix to be used for SLAAC, as learned from an ICMPv6
          Router Advertisement message.

(side note) is the "as learned from an ICMPv6 RA" an important
prerequisite, or could a prefix learned in some other fashion still be
usable?

          which this interface is associated.  Additionally, Simple DNA
          [RFC6059] describes ideas that could be leveraged to generate
          a Network_ID parameter.  This parameter is SHOULD be employed
          if some form of "Network_ID" is available.

nit: s/is SHOULD/SHOULD/

Section 3.4

   7.  The node MUST perform duplicate address detection (DAD) on the
       generated temporary address.  If DAD indicates the address is
       already in use, the node MUST generate a new randomized interface
       identifier, and repeat the previous steps as appropriate up to
       TEMP_IDGEN_RETRIES times.  If after TEMP_IDGEN_RETRIES
       consecutive attempts no non-unique address was generated, the
       node MUST log a system error and SHOULD NOT attempt to generate a
       temporary address for the given prefix for the duration of the
       node's attachment to the network via this interface.  [...]

Just to confirm my understanding: "for the duration of the node's
attachment to the network" means that even if a new RA+PIO is received,
the node still ignores that prefix?

Section 3.6

   determine that the link change has occurred.  One such process is
   described by "Simple Procedures for Detecting Network Attachment in
   IPv6" [RFC6059].  Detecting link changes would prevent link down/up

nit: we have already referred to the abbreviated name "Simple DNA"
earlier in this document, so the expanded title does not seem necessary
here.

Section 3.8

   REGEN_ADVANCE -- 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits *
   RetransTimer / 1000)

Please indicate the units of this value (the division by 1000 indicates
it is likely measured in seconds).

   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).

Computing only at startup and not changing it could perhaps run into
issues with maintaining the invariant, when TEMP_PREFERRED_LIFETIME and
REGEN_ADVANCE are configurable after startup.  (Changing DESYNC_FACTOR
more often, and having the range be more like half of the overall
lifetime, would be one approach for achieving the "statistically
different" property mentioned in my Discuss point.)

Section 4.

   The desires of protecting individual privacy versus the desire to
   effectively maintain and debug a network can conflict with each
   other.  [...]

(editorial) this sentence lacks parallelism of structure.  Perhaps:

% The desire to protect individual privacy can conflict with the desire
% to effectively maintain and debug a network.

Section 5

   o  Addresses all errata submitted for [RFC4941].

There are errata reports against RFC 4941 that are still in the state
"reported"; the responsible AD should probably process those before this
document gets published.

Section 9

Overall these security considerations seem pretty comprehensive and
well-described -- thank you!

   If a very small number of nodes (say, only one) use a given prefix
   for extended periods of time, just changing the interface identifier
   part of the address may not be sufficient to mitigate address-based
   network activity correlation, since the prefix acts as a constant
   identifier.  [...]

It might be worth noting some scenarios where this commonly occurs,
e.g., residential households that only have a single computer.  (Is it
also the case for mobile phones?)

   fairly large number of nodes.  Additionally, if a temporary address
   is used in a session where the user authenticates, any notion of
   "privacy" for that address is compromised.

Compromised for the part(ies) that receive the authentication information,
at least.  That does not necessarily include a passive observer in the
network.

   While this document discusses ways of obscuring a user's IP address,
   the method described is believed to be ineffective against

I don't think "obscuring" is the right word -- the IP address is still
visible; we're just trying to remove some of the information content
from it over long periods of time.  I understand the desire to remove
the word "permanent" from the RFC 4941 version, but this still doesn't
seem right.  Perhaps the goal could be rephrased as something about
making the IP address less useful as a persistent (numerical) identifier.

   Ingress filtering has been and is being deployed as a means of
   preventing the use of spoofed source addresses in Distributed Denial
   of Service (DDoS) attacks.  In a network with a large number of
   nodes, new temporary addresses are created at a fairly high rate.
   This might make it difficult for ingress filtering mechanisms to
   distinguish between legitimately changing temporary addresses and
   spoofed source addresses, which are "in-prefix" (using a
   topologically correct prefix and non-existent interface ID).  This
   can be addressed by using access control mechanisms on a per-address
   basis on the network egress point.

Should we say something about the corresponding resource consumption
increase at the egress point?

Section 11.1

One might argue that RFC 7217 is merely informative, since we duplicate
in full the IID-generation algorithm from it (with modifications).

RFC 8190 is only referenced to note that we specifically do *not* use
terminology from it; that seems like it does not really meet the
threshold for being a normative reference.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 11:24:43 -0300

Hello, Ben,

Thanks a lot for your comments! In-line....

On 19/10/20 23:45, Benjamin Kaduk via Datatracker wrote:
[...]
> this may be the result of an incomplete update.)

FWIW, what we *meant* is that we try for them to have different 
lifetimes, but we don't enforce that.

But the issue regarding "statistically-different lifetimes" warrants 
some "background":
When we started with this effort to address issues in RFC4941,  we 
started with a fresh document (more of a replacement than a -bis 
document) that, among other things, included the "Design Guidelines" 
from Section.  And while coming up with the goals, it became 
natural/obvious that anything that would result in patterns should be 
fixed (since such patterns allow for correlation). The regeneration 
period is one of such examples. As you correctly note, in order to avoid 
synchronization of address regeneration we would need to expand the 
DESYNC_FACTOR range (and make it variable) -- which we seem to have 
missed. (but as you correctly noted, can be easily addressed)

i.e., we need to apply your suggestion such that we comply with Goal #4 
from Section 3.1.  (more on this below)

> "new address" events.  
[....]
> (Furthermore, we apparently qualify the
> as "repeating the actions" anymore.

Not sure what you mean. Could you please elaborate? (on this last sentence)

> -- it is defined in 4862, while RetransTimer is in 4861.

Good grief! Will fix this.

> (3) RFC 4941 cannot be a *normative* reference of this document if we are

Good grief! Will fix this.

Since temporary addresses have been traditionally employed *in addition* 
to stable addresses, the issue of address-scanning has been orthogonal 
to RFC4941. Specifically, the feasibility of address scanning has always 
depended on whether the *stable* addresses follow patterns. This has 
been one of the motivations for RFC7217/RFC8064.

> an exhaustive list, so I don't see a need to add complications to this

Agreed.

> nit: s/to track/from tracking/

Fixed. Thanks!

> nit: perhaps say "at the same time"?

Yep. Thanks!

> previous two paragraphs might help indicate the structure of the

How about
"...but there are more. For example,"

And then include each of the next to paragraphs as a bullet item each. 
Will not necessarily look great (long bullets), but the structure will 
be evident.

> "window of exposure for such correlation"?  (Similar text also appears

What we meant is that once the address is exposed, your host will be 
reachable via that address via a limited period of time. -- Compare that 
with stable addresses, where once you have learned the stable address of 
a host, you can use that address to contact the host at any time.

> Introduction; I'm not sure if we should de-duplicate.

In Section 1, the references are used to explain that this document 
tries to address some of such issues. Where the ref in this section is 
to indicate where the discussion of addresses as identifiers that are 
used for an extended period of time are identified.

Id requested to de-duplicate, I'd probably remove the last line from 
Section 2.1.

Thoughts?

> different addresses ("should not be exactly 24 hours more than the

Aren't' the two equivalent?

> number is sampled from, and could cover, e.g., https://xkcd.com/221/ .

Maybe:

"   1.  Obtain a random number from pseudo-random number generator 
(PRNG) that can produce random numbers of at least as many bits as 
required for the Interface Identifier (please see the next step). 
[RFC4086] specifies randomness requirements for security)."

?

> hash inputs. 

I'm wondering if this should be specified (and if so, in which way), 
such that the document discusses the concept behind the algorithm rather 
than what might be seen as implementation details.

Thoughts?

> (This is particularly of note for the IPv6 prefix, that
> order. 

How about adding this to the definition of "secret_key":

The secret_key MUST NOT be employed for any other purpose than the one 
discussed in this section. For example, implementations MUST NOT employ 
the same secret_key for the generation of stable addresses [RFC7217] and 
temporary addresses via this algorithm."
?

> (I will note that it may be tempting to upgrade to an HMAC

How about changing this to:
"SHOULD produce an output of at least as many bits as required for the 
Interface Identifier"?

> prerequisite, or could a prefix learned in some other fashion still be

This is an extension to SLAAC, so it is implied that the prefix has been 
learned via ICMPv6 RAs -- otherwise, it's not SLAAC. :-)

>            if some form of "Network_ID" is available.

Thanks!

> the node still ignores that prefix?

Yes.

> earlier in this document, so the expanded title does not seem necessary

Will fix this. Thanks!

> it is likely measured in seconds).

Indeed. I had omitted the units as they are specified in the 
specification of each of these parameters.

How about adding a last item in the ""Note:" that says:

"RetransTimer is specified by [RFC4861] in units of milliseconds, and 
therefore this expression employs the constant "1000" such that 
REGEN_ADVANCE is expressed in seconds"
?

> different" property mentioned in my Discuss point.)

Agreed.

This would mean that the text should be tweaked as follows:

* Item #1 of Section 3.4 should be changed as:

OLD:
        The configuration variables
        TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
        approximate target lifetimes for temporary addresses.

NEW:
        The configuration variables
        TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
        maximum target lifetimes for temporary addresses.

Item #4 of Section 3.4 should be tweaked as:

OLD:
    4.  When creating a temporary address, the lifetime values MUST be
        derived from the corresponding prefix as follows:

        *  Its Valid Lifetime is the lower of the Valid Lifetime of the
           prefix and TEMP_VALID_LIFETIME

        *  Its Preferred Lifetime is the lower of the Preferred Lifetime
           of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.

NEW:
    4.  When creating a temporary address, the DESYNC_FACTOR MUST be
        computer for the new address, and the lifetime values MUST be
        derived from the corresponding prefix as follows:

        *  Its Valid Lifetime is the lower of the Valid Lifetime of the
           prefix and TEMP_VALID_LIFETIME

        *  Its Preferred Lifetime is the lower of the Preferred Lifetime
           of the prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.

* And the definitions should be tweaked as:

OLD:
    MAX_DESYNC_FACTOR -- 10 minutes.  Upper bound on DESYNC_FACTOR.

NEW:
    MAX_DESYNC_FACTOR -- 0.4 * TEMP_PREFERRED_LIFETIME.  Upper bound on
                         DESYNC_FACTOR.

        Note: Setting MAX_DESYNC_FACTOR to 0.4 TEMP_PREFERRED_LIFETIME
              results in addresses that have statistically different
              lifetimes, and a maximum of 3 concurrent temporary
              addresses when the default parameters specified in this
              section are employed.

    DESYNC_FACTOR -- A random value within the range 0 -
    MAX_DESYNC_FACTOR.  It is computed each time a temporary address is
     generated, and must smaller than
    (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE).

* This paragraph from SEction 3.6, should be tweaked as:

OLD:
    Nodes following this specification SHOULD generate new temporary
    addresses on a periodic basis.  This can be achieved by generating a
    new temporary address at least once every (TEMP_PREFERRED_LIFETIME -
    REGEN_ADVANCE - DESYNC_FACTOR) time units.  As described above,
    generating a new temporary address REGEN_ADVANCE time units before a
    temporary address becomes deprecated produces addresses with a
    preferred lifetime no larger than TEMP_PREFERRED_LIFETIME.  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.  When the preferred lifetime
    expires, a new temporary address MUST be generated using the new
    randomized interface identifier.

NEW:
    Nodes following this specification SHOULD generate new temporary
    addresses on a periodic basis.  This can be achieved by generating a
    new temporary address at least once every (TEMP_PREFERRED_LIFETIME -
    REGEN_ADVANCE - DESYNC_FACTOR) time units.  As described above,
    generating a new temporary address REGEN_ADVANCE time units before a
    temporary address becomes deprecated produces addresses with a
    preferred lifetime no larger than TEMP_PREFERRED_LIFETIME.  The value
    DESYNC_FACTOR is a random value computed when a temporary address is
    generated that ensures that clients don't generate new addresses with
    a fixed frequency, and that clients don't synchronize with each other
    and generate new addresses at exactly the same time.  When the
    preferred lifetime expires, a new temporary address MUST be generated
    using the new randomized interface identifier.

* The following text from Section 5 should be tweaked as:

OLD:
    o  Reduces the default Valid Lifetime for temporary addresses:
       The default Valid Lifetime for temporary addresses has been
       reduced from 1 week to 2 days, decreasing the typical number of
       concurrent temporary addresses from 7 to 2.  This reduces the
       possible stress on network elements (see Section 4 for further
       details).

NEW:
    o  Reduces the default Valid Lifetime for temporary addresses:
       The default Valid Lifetime for temporary addresses has been
       reduced from 1 week to 2 days, decreasing the typical number of
       concurrent temporary addresses from 7 to 3.  This reduces the
       possible stress on network elements (see Section 4 for further
       details).

Thoughts?

> % to effectively maintain and debug a network.

Will fix. Thanks!

> "reported"; the responsible AD should probably process those before this

Agreed.

> also the case for mobile phones?)

For home, one might expect that this is less of the case, since homes 
connect more and more stuff to the Internet (computer, phone, smart tv, 
blue ray...). OTOH, I would expect this to be the case for phones, 
although at the same time I'm not sure how often the prefix might change 
(if ever).

Both since this will depend on many factors (dynamic vs static prefixes, 
number of employed devices, etc.) I'd probably refrain from speculating, 
since that'd be more guesswork than anything else.

Thoughts?

> at least.  That does not necessarily include a passive observer in the

Should we add "for the part(ies) that receive the authentication 
information"?

> making the IP address less useful as a persistent (numerical) identifier.

Maybe

"While this document discusses ways limit the lifetime of Interface 
Identifiers to reduce the ability of attackers from performing 
address-based network activity correlation, the method described is 
believed to ..."

?

> increase at the egress point?

Something different from what we currently have in Section 4? -- If so, 
what?   Or were you suggesting to reference Section 4 from here?

> in full the IID-generation algorithm from it (with modifications).

Makes sense. Will move it to the "Informational" references unless there 
are arguments against this.

> threshold for being a normative reference.

I don't mind changing it. That said, I must say that at times the 
difference seems to be subtle. e.g., normative references are those that 
you need to read to understand the document. So, in a way, you're right. 
OTOH, I'm not sure one could understand the difference between "global 
scope" and globally reachable" without looking at the referenced documents.

Thanks!

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Oct 2020 22:26:42 -0700

Hi Fernando,

Also in-line.

> missed. (but as you correctly noted, can be easily addressed)

Ah, thanks for the extra background.  The diff only says so much...

> Not sure what you mean. Could you please elaborate? (on this last sentence)

This was just me whining that we say "repeat the actions" but we actually
mean "mostly repeat the actions, with some variations that we describe
below"...though I'm no longer sure which parts I thought we the "variations
that we describe below", which might explain your confusion.  (Perhaps the
zero-Preferred-Lifetime case?)  I think I may have just been misreading
Section 3.5; sorry for causing confusion.

> been one of the motivations for RFC7217/RFC8064.

Understood; thanks.

> Will not necessarily look great (long bullets), but the structure will 

I think that's basically what I had in mind; thanks.

> a host, you can use that address to contact the host at any time.

Ah, so it's like "exposure to external attack" (can you tell I'm a security
person?).  Brainstorming potential clarifications, neither "window of
accessibility/exposure" and "window of exposure of a node as being
accessible via an address" are clear winners.  It wouldn't be a problem to
leave this alone, if we can't come up with an alternative that we like.

> Id requested to de-duplicate, I'd probably remove the last line from 

Totally your call.

> Aren't' the two equivalent?

I can see why what I wrote would make it sound like they were.  I think
there can be a difference, but it requires generating a new address before
the old one expires -- you have one problem if you always set the time of
the new one to be 24 hours, and a different problem if you always set the
time of the new one to be (time left on the old one + 24 hours).

> [RFC4086] specifies randomness requirements for security)."

Sounds good to me; thanks.

> than what might be seen as implementation details.

That would emphasize the bits we care about while avoiding the fiddly
details that are just distractions at this level of abstraction ... so, yes
sounds like a good approach :)

"F() could be the result of applying a cryptographic hash over an encoded
version of the function parameters.  While this document does not recommend
a specific mechanism for encoding the function parameters (or a specific
cryptographic hash function), a cryptographically robust construction will
ensure that the mapping from parameters to the hash function input is an
injective map, as might be attained by using fixed-width encodings and/or
length-prefixing variable-length parameters" could be something to start
with.

Thanks!

> "SHOULD produce an output of at least as many bits as required for the 

Works for me.

> REGEN_ADVANCE is expressed in seconds"

Sounds good; thanks.

>         computer for the new address, and the lifetime values MUST be

("computed")

>            prefix and TEMP_VALID_LIFETIME

Talking through this: the valid lifetime "always" being TEMP_VALID_LIFETIME
is not a correlation risk, because nothing happens when that lifetime
expires -- we care about the preferred lifetime more because we may have to
make a new address when the preferred lifetime expires.

>               addresses when the default parameters specified in this

The factor of 0.4 seems like it should provide enough noise.  I will trust
you about the "maximum of 3 concurrent" -- I didn't walk through the
scenarios myself, but it seems right.

>        possible stress on network elements (see Section 4 for further

I think that should do the trick; thanks for putting it together so
quickly.

> since that'd be more guesswork than anything else.

I don't insist on any changes here.  My own sentiment is that the
"single-computer home" use case will remain understandable for some time,
but I agree that people will have a wide range of prior experience in terms
of how many connected devices there are in a household.  Even in a
multi-device, single-human household, though, there is still some
correlation to be had.  If you don't think you can write something useful
here, I won't lose any sleep over it, though.

> Should we add "for the part(ies) that receive the authentication 

I think it's worth it (or a variant like "that have access to the
authentication information").  We have to deal with many different notions
of "privacy" at times, so sweeping statements can make me uncomfortable...

> address-based network activity correlation, the method described is 

Looks good modulo nits ("ways to limit", "to perform").

> what?   Or were you suggesting to reference Section 4 from here?

Referencing would be good, e.g., "can be addressed [...] on the network
egress point, though as noted in Section 4 there are corresponding costs
for doing so".

> scope" and globally reachable" without looking at the referenced documents.

Thank you!

-Ben