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

[Fernando Gont <[e-mail]>]

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)

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)



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



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



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



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


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



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


?


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


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


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



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




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

    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.

    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?


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


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



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

?



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


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

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