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

[Fernando Gont <[e-mail]>]

Hi, Thomas,

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

On 01/22/2014 03:36 PM, Thomas Narten wrote:
> 
> 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?

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



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

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

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
> using the linklayer/linklocal address pair of routers to identify a
> link. This document might suggest doing the same thing.

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.


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

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



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

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.



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

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.



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

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.



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

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



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

How about adding something along the lines of:

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

?


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

Oops, you're right.



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

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



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

I should remove "unique". The point is that Windows does not employ
hardware addresses for the IIDs (i., they do not employ 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.

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.



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

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



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

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.



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

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.



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

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492