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

[Benjamin Kaduk <[e-mail]>]

Hi Fernando,

Also in-line.

On Wed, Oct 21, 2020 at 11:24:43AM -0300, Fernando Gont wrote:
> Hello, Ben,
> 
> Thanks a lot for your comments! In-line....
> 
> On 19/10/20 23:45, Benjamin Kaduk via Datatracker wrote:
> [...]
> > 
> > (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.)
> 
> 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)

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

> i.e., we need to apply your suggestion such that we comply with Goal #4 
> from Section 3.1.  (more on this below)
> 
> 
> 
> 
> > 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.
> 
> 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.

> 
> 
> > (2) Please fix the reference for DupAddrDetectTransmits in Section 3.8
> > -- 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
> > going to Obsolete it.
> 
> Good grief! Will fix this.
> 
> 
> 
> 
> > ----------------------------------------------------------------------
> > 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.
> 
> 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.

Understood; thanks.

> >     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.
> 
> Agreed.
> 
> 
> >     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/
> 
> Fixed. Thanks!
> 
> 
> 
> > 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"?
> 
> Yep. Thanks!
> 
> 
> 
> 
> >     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.
> 
> 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.

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

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

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.

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

Totally your call.

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

> 
> 
> > 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/ .
> 
> 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)."
> 
> 
> ?

Sounds good to me; thanks.

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

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.

> 
> > (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. 
> 
> 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."
> ?

Thanks!

> 
> > (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!
> 
> How about changing this to:
> "SHOULD produce an output of at least as many bits as required for the 
> Interface Identifier"?

Works for me.

> 
> 
> >         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?
> 
> This is an extension to SLAAC, so it is implied that the prefix has been 
> learned via ICMPv6 RAs -- otherwise, it's not SLAAC. :-)
> 
> 
> > 
> >            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/
> 
> Thanks!
> 
> 
> > 
> > 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?
> 
> Yes.
> 
> 
> 
> > 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.
> 
> Will fix this. Thanks!
> 
> 
> 
> > 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).
> 
> 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"
> ?

Sounds good; thanks.

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

("computed")

>         derived from the corresponding prefix as follows:
> 
>         *  Its Valid Lifetime is the lower of the Valid Lifetime of the
>            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.

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

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.

>     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?

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

> > 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.
> 
> Will fix. Thanks!
> 
> 
> 
> > 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.
> 
> Agreed.
> 
> 
> 
> 
> > 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?)
> 
> 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?

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.

> 
> >     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.
> 
> Should we add "for the part(ies) that receive the authentication 
> information"?

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

> 
> 
> > 
> >     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.
> 
> 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 ..."
> 
> ?

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

> 
> 
> >     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?
> 
> Something different from what we currently have in Section 4? -- If so, 
> 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".

> 
> > 
> > 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).
> 
> Makes sense. Will move it to the "Informational" references unless there 
> are arguments against this.
> 
> 
> 
> > 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.
> 
> 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!

Thank you!

-Ben