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

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2014 13:36:05 -0500

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.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 05:27:53 -0300

Hi, Thomas,

Thanks so much for your detailed feedback! -- Please find my responses
in-line...

> same approaches for determining what network you are on be leveraged?

I'm not sure whether you're arguing:

1) That one might employ DNA to obtain a Network_ID for the expression
in this document, or,

2) That one might do DNA before actually trying to compute the IID with
this document.

I'm fine with 2), but think that 1) is rather orthogonal to this I-D.

(please see below regarding one proposal to achive "2)")

> regenerating them. 

This seems to be out of the scope of this document. Additionally, this
might make sense for some device that you move among a limited set of
networks. But I bet that in most of our cases, we travel from one place
to another, and not infrequently use networks only once in our devices'
lifetime.

> DNA does this. Seems like that option should be

I don't expect nodes to implement the "save the DAD counter" part. --
For instance, that's why it's a "MAY", rather than a SHOULD or MUST.
That said, the reason for saving the DAD counter (as opposed to the
whole address) is that the address that you've saved might collide when
you reuse it.

If you save the DAD counter, eventually you'll have a DAD counter that
results in an address that never collides with anything... and hence you
always use such address.

> For the wired case (i.e, no SSID), DNA suggests

I don't think tying network identification to the router's link-layer or
link-local address is a good idea.

For instance, there's no reason why a NIC replacement at the router or a
backup router coming to life should result in a different address.

Note that the different goals in DNA and this allows this approach to be
more lightweight, so to speak.

> mitigate off-site scanning attacks and 2) making it harder to track

This document:
<http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-00>
(referenced in this I-D) provides a more thorough explanation. (at the
time the wg decided that a thorough discussion deserved it's own document).

> some folk. But I suspect there are others that won't care all that

There are other issues, such as device-specific vulnerability
exploitation, etc.

Bottom-line is that you want to fail on the safe side. And if you some
some specific reason for using IIDs that embed hardware addresses,
override the more sane default in your specific case.

> technology. E.g., 1 second seems OK for WiFi, but not for 10G.

As noted in a separate email, we're talking about collisions of 64-bit
random numbers. The odds of that are pretty low. And if that happens,
let's say that an average delay of 0.5 sec would not be a big deal.

Put another way: I understand your concern, and mostly agree with your
view. But for this specific case, even something like an IDGEN_DELAY of
5 would be fine, since the odds of having to actually use such delay are
almost nil.

> But that is pretty vague advice.

It's kind of intended. Again, in this case /64-bit subnetworks)
collisions are so unlikely that you're probably already good enough
without even retrying after a collision. The odds of the same node
finding, say, 2 or 3 collisions in a row are extremely low.

> 4941 being one example. Rather than suggesting only that RFC4941 MAY

The goal here was to be clear what we were referring to. So far the only
algorithm specified for generating temp addresses is RFC4941. And we
though it would be more clear to refer to it explicitly (particularly
when we have found that terminology on the subject is not that
clear/well-defined).

> link by a combination of the routers Link-local + Link Layer

How about adding something along the lines of:

"DNAv6 [RFC6059] could be employed to obtain a Network_ID to be employed
for this parameter"

?

> add reference to ULAs on first use of term.

Oops, you're right.

> will when implementations mess up!

Thanks for the help with improving the text. I will incorporate your
suggested text.

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

I should remove "unique". The point is that Windows does not employ
hardware addresses for the IIDs (i., they do not employ standard SLAAC).

> much of a justification, and should maybe just be deleted.

What I'm saying is:

1) Of the installed base, not all systems are potentially affected by
this -- not the Microsoft ones, at least.

2) OTOH, uniqueness based on the hardware addresses cannot relied upon
anyway, since research indicates that they are largely duplicated.

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

Isn't that somewhat implicitly specified in the random delay that nodes
need to wait before retrying?

> save the address you generated before? I.e., that is what DNA does...

If you just store the address, and there are address collisions, there
might be oscillations wrt which address each node uses (depending on the
order in which each node is bootstrapped).

OTOH, if you store the DAD counter, eventually each node will converge
to a stable address.

>    employing other algorithms for generating Interface Identifiers.

Because if you are employing this scheme, you don't want your address to
leak your device identity.

I'd note that the only scenario in which I could envision multiple
collisions in a row from random numbers is that in which an attacker is
actively messing up with DAD.

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

Yes, but the average is 0.5, and the odds of actually having to use it
is *extremely* small (we're talking about collisions within a 64-bit
space). Even then, you can go against the SHOULD if you have a good
reason to.

> Need to put in a  reference to ULA spec.

Will do.

Thanks so much!

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