Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....)

[Fernando Gont <[e-mail]>]

Hi, Karl,

Thanks so much for your feedback! Please find my comments inline...

["Subject" changed so that this discussion doesn't mix up with the poll]


On 04/13/2012 02:14 AM, Karl Auer wrote:
> That said, I have some comments. My apologies if I have missed some
> discussion where these were covered already:
> 
> 1: I'm unsure about this bit:
> 
>     IPv6 implementations conforming to this specification
>     MUST generate interface identifiers using the algorithm
>     specified in this section.
> 
> While this does not explicitly *say* that other interface identifiers
> MUST NOT be used, that interpretation seems to be possible.

Good point. Maybe we could replace that para with:

"IPv6 implementations conforming to this specification MUST generate
interface identifiers using the algorithm specified in this section in
replacement of Modified EUI-64 format identifiers."
?


> A hint that
> stable addresses may be used alongside privacy addresses, is found in
> the sentence:
> 
>     On the other hand, in scenarios in which "Privacy Extensions"
>     are employed, implementation of the mechanism described in this
>     document would [...]
> 
> Section five does mention replacing IEEE-based interface IDs, but I
> think it needs to be stronger, one way or the other. The document should
> make clear which other mechanisms it excludes, if any - for example,
> that a host using this mechanism SHOULD NOT (MUST NOT?) also generate
> interface IDs based on IEEE identifiers but MAY also use privacy
> extensions. See also point 4 below.

Please let me know if the suggested change (above) is okay, or whether
you think it would be better to include an additional note with
something along the lines of "That is, they MUST NOT employ Modified
EUI-64 format identifiers, but MAY still implement RFC 4941 in addition
to the algorithm specified in this document".



> 2: What exactly is a "serial number"? 

Some number that varies from one machine to another, which is not
expected to be known by an attacker.


> Do all machines, even
> small/embedded etc machines, have a serial number? 

Now that you mention it, I think I should tweak the corresponding text,
making inclusion of such serial number a "MAY".


> Seems to me that the
> algorithm should use a default value, such as zero, for the "serial
> number" if none is available OR should fail to generate a secret key
> (and thus fail to generate interface IDs later). My preference would be
> for the first of these - i.e., a default.

Agreed. Either that, or simply not include the serial number if it's not
available.



> 3: Related to the previous point, if it is possible to fail to generate
> a secret key, 

It shouldn't be possible. The idea is that the secret key is set to a
random number (by default).


> 4: Assuming point 1 above has relevance, and a host using this algorithm
> MUST NOT also use IEEE-based interface IDs, then a host which fails to
> generate a stable address for any reason MUST NOT fall back to the use
> of IEEE-based interface IDs. Why? Because that would expose the host to
> precisely the disadvantages that the stable addresses were supposed to
> prevent.

Agreed. But this would be implied when we say "... MUST use this
algorithm in replacement of Modified EUI-64 format identifiers"?


> 5: Duplicate address detection is not mentioned explicitly, but probably
> should be - what happens if a host does DAD and determines that its
> stable address is already in use?

Address configuration fails.

Note: I didn't discuss DAD because to some extent *what* you do is not
discussed in the traditional-SLAAC specs.

That said, if deemed appropriate, one could include one additional byte,
"DAD" in the hash function, which is initialized to 0, and that is
incremented by 1 if the host wants to try a different address if/when
DAD fails.

If we do that, the implementations should probably cache the resulting
address, such that it is stable. (otherwise the resulting address might
change if the same node was brought up while the node with the
conflicting address is off).


> 6: The interface IDs generated are 64 bits long. I think it should be
> stated explicitly that this algorithm MUST NOT be used where the prefix
> is not 64 bits long.

Actually, this algorithm could still be used with longer prefixes (i.e.,
fewer bits for the IID). So I'm not sure whether we should include this
requirement. e.g., if we were to eventually allow non-/64 autoconfigured
addresses, this algorithm could be use without any changes (while the
traditional MAC-based identifiers couldn't).

(Note: Just me thinking out loud).


> 7: Add "An implementation SHOULD provide the means for the user to
> enable and disable the use of stable addresses."

May be s/stable addresses/this specification/?

That said, I think we should probably note what nodes are supposed to be
done with this specification as a whole. Me, I'd argue that "nodes
SHOULD employ generate IIDs with this algorithm in replacement of
Modified-EUI 64 format identifiers" -- since we clearly want to move
away from MAC-based IIDs.

(Note that this is a different issue from item #1 above: Item #1 above
is about what you should do if you implement this spec, while the point
that I'm making in the previous paragraph is that you SHOULD implement
this spec).

Thoughts?


> 8: This may be a bit out of scope, but it occurs to me that being able
> to specify a static interface identifier and have it used in any
> (64-bit) prefix would also be useful in some contexts. That is, have an
> address which is stable, but explicitly specified.

The problem is that as soon as you use a static identifier, you can be
tracked. -- Yes, you may argue that if your identifiers is "::1", then
it's very likely that many other systems will be using the same
identifier, and hence it would not be of much help to an attacker for
tracking purposes.... but I'd say that's walking a fine line.

Additionally, I'd argue that in order to have such thing, then
1) You'd need to manually configure your address each time you move from
one network to another (as with manual configuration requires you to set
the whole address, rather than just the IID bits), or,

2) You should be using e.g. Windows algorithm for generating the IIDs,
which is sub-optimal, since they mitigate only host-scanning attacks and
not host-stacking attacks.

That said, I wonder what the use might be. e.g., would the user be
expected to remember all the bits from the IID, and then say "ok, the
prefix we're using on this net is [blah..blah], so the resulting IPv6
address of the host with known IID is blah-blah"? -- If that's the
expected use case, then I'd argue that you should be doing mDNS, LLNR,
or DNS dynamic updates....

Thanks!

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