Review of draft-ietf-6man-stable-privacy-addresses-16.txt

[Thomas Narten <[e-mail]>]

Note: I haven't been following this work and haven't read the document
since its initial version.  

Overall, I think this document is a good thing and should move
forward.  I have a number of general comments.

First, I'm surprised this document doesn't reference any of the DNA
work (RFC 4436 & 6059). That work is all about determining whether
you've attached to the same network as one you've attached to before
and reusing the same network parameters if you do. Given that this
document is about using the same IID when connecting to the same
network... This seems like an oversight. I.e., shouldn't some of the
same approaches for determining what network you are on be leveraged?

Two things come to mind. If you have stable storage (and many devices
do), it makes sense to just cache the addresses instead of
regenerating them. DNA does this. Seems like that option should be
allowed. (the current document suggests saving the number of DAD
iterations in stable storage... why do that if you can just save the
address itself?)

Second, DNA also has recommendations for detecting when you
(re)connect to a network you visited before. That is pretty much the
same thing this spec needs to do in order to generate the same
addresses when connecting to a previously visited network (i.e., the
Network_ID paramater). For the wired case (i.e, no SSID), DNA suggests
using the linklayer/linklocal address pair of routers to identify a
link. This document might suggest doing the same thing.

Seems this spec might benefit from a clearer applicability
statement. There seem to be two motivations for the document: 1)
mitigate off-site scanning attacks and 2) making it harder to track
devices that move.

The second item seems of interest (only) to personally owned devices,
those that are typically owned by a single user and are (at least
somewhat) mobile. For other types of devices (e.g., those typically
found in data centers), I suspect this motivation is not compelling.
I think it would be good to make this more clear.

On mitigating address scanning attacks, that will be of interest to
some folk. But I suspect there are others that won't care all that
much.

What I think this spec should be clear about is that it is optional,
and give guidance for those scenarios where it is potentially useful.

Finally, I want to raise a generic issue that applies to this
document, but really is a general problem. The document adds a random
delay between 0 and IDGEN_DELAY in order to avoid lock-step
behavior. While that is a good thing, Using IDGEN_DELAY of 1 second is
pretty long for some network technologies (think data center with 10G
or higher interfaces). I wonder if we should stop using constants that
are fixed and make them more dependent on actual network
technology. E.g., 1 second seems OK for WiFi, but not for 10G.

Likewise, should you ever stop trying to configure an address if you
keep getting DAD failures? I'm of two minds. Going forward, it becomes
increasingly painful to require operator intervention to "fix"
something that isn't working. That argues for never giving up. But
what should happen then is some sort of exponential backoff should be
used to ensure that retries happen infrequently, so as not to cause
network problems. The current text says:

>    We also
>    note that hosts MUST limit the number of tentative addresses that are
>    tried (rather than indefinitely try a new tentative address until the
>    conflict is resolved).

But that is pretty vague advice.

That all said, if you have a device with a (broken) implementation,
having it try over and over again makes no sense either.

Editorial comments:

>   However, implementations conforming to
>    this specification MAY employ the algorithm specified in [RFC4941] to
>    generate temporary addresses in addition to the addresses generated
>    with the algorithm specified in this document.

reword to say something like "MAY employ other alogorithms for
generating additional temporary addresses (e.g., RFC4941])."

The MAY should make it clear that other approaches are allowed, with
4941 being one example. Rather than suggesting only that RFC4941 MAY
be implemented.

       Network_ID:
          Some network specific data that identifies the subnet to which
          this interface is attached.  For example the IEEE 802.11
          Service Set Identifier (SSID) corresponding to the network to
          which this interface is associated.  This parameter is
          OPTIONAL.

RFC6059 (DNAv6) may be useful here. It has the notion of identifying a
link by a combination of the routers Link-local + Link Layer
address.

   Local Addresses (ULAs).  In those scenarios where the Network_ID is
   unknown to the attacker, including this parameter might help mitigate
   attacks where a victim node connects to the same subnet as the
   attacker, and the attacker tries to learn the Interface Identifier
   used by the victim node for a remote network (see Section 9 for
   further details).

add reference to ULAs on first use of term.

   Finally, we note that all of the bits in the resulting Interface IDs
   are treated as "opaque" bits [I-D.ietf-6man-ug].  For example, the
   universal/local bit of Modified EUI-64 format identifiers is treated
   as any other bit of such identifier.  In theory, this might result in
   Duplicate Address Detection (DAD) failures that would otherwise not
   be encountered.  However, this is not deemed as a real issue, because
   of the following considerations:

Wording is awkward about DAD failures...wording suggests the problem
is DAD. Actually, the problem is that failures lead to duplicate
addresses -- that is the real issue. That DAD catches them is a good
thing.

NEW TEXT:

   In theory, this might result in address formation collisions and
   Duplicate Address Detection (DAD) failures that would otherwise not
   be encountered.  However, this is not deemed as a real issue, because
   of the following considerations:

also, s/real issue/likely issue/

It will be a very "real" issue when it happens, e.g., as it likely
will when implementations mess up!

   o  Since some popular and widely-deployed operating systems (such as
      Microsoft Windows) do not employ unique hardware addresses for the
      Interface IDs of their stable addresses, reliance on such unique
      identifiers is more reduced in the deployed world (fewer deployed
      systems rely on them for the avoidance of address collisions).

wording is awkward. what are "unique hardware addresses"? Do you mean
standard SLAAC?

Also, what are you trying to say above? that because windows doesn't
do SLAAC, and things didn't break, something isn't an issue? That's not
much of a justification, and should maybe just be deleted.

   This procedure may be repeated a number of times until the address
   conflict is resolved.  Hosts SHOULD try at least IDGEN_RETRIES (see
   Section 7) tentative addresses if DAD fails for successive generated
   addresses, in the hopes of resolving the address conflict.  We also
   note that hosts MUST limit the number of tentative addresses that are
   tried (rather than indefinitely try a new tentative address until the
   conflict is resolved).

wonder if it would be better to specify some rate limiting that makes
sense.


   In those unlikely scenarios in which duplicate addresses are detected
   and in which the order in which the conflicting nodes configure their
   addresses may vary (e.g., because they may be bootstrapped in
   different order), the algorithm specified in this section for
   resolving DAD conflicts could lead to addresses that are not stable
   within the same subnet.  In order to mitigate this potential problem,
   nodes MAY record the DAD_Counter value employed for a specific
   {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such
   that the same DAD_Counter value is employed when configuring an
   address for the same Prefix and subnet at any other point in time.

if you have non-volatle memory, wouldn't it just make more sense to
save the address you generated before? I.e., that is what DNA does...

   In the event that a DAD conflict cannot be solved (possibly after
   trying a number of different addresses), address configuration would
   fail.  In those scenarios, nodes MUST NOT automatically fall back to
   employing other algorithms for generating Interface Identifiers.

why not?

   Hosts SHOULD introduce a random delay between 0 and IDGEN_DELAY
   seconds (see Section 7) before trying a new tentative address, to
   avoid lock-step behavior of multiple hosts.

IDGEN_DELAY of 1 sec is too long for some network technologies.

Need to put in a  reference to ULA spec.