I like & support the idea, but it's not clear to me the
randomness/stableness of the created identifiers.
Is there a guarantee, that after rebooting or powering-off/on the host,
the produced RID will remain the same if Prefix remains the same?
Is there a way to change the secret key in case someone discovers it or
for whatever reason?
I would like more examples (and probably a better definition) of the
network_id. i.e. the SSID is something that is not exactly local to the
host. Are all the usage cases like this? i.e. in case of fixed network,
would it be the directly attached router's mac?
Extra question/idea..
If this address creation functionality can be transferred to a dhcp
server too (which i don't see why not, since the critical input fields
are already there), maybe the text regarding SLAAC should be replaced
with something more appropriate. Or just add a note regarding this extra
option (someone mentioned about a dhcp server creating temporary
addresses).
Finally, I would prefer to keep the prefix as mandatory to the algorithm
for the exact reason that you wrote.
PS: should there be any paragraph about the source address selection
(rfc3484/bis) RFCs and these stable privacy addresses and how they
should be handled, especially in comparison to the temporary ones?
--
Tassos
On 28/3/2012 5:53 μμ, Fernando Gont wrote:
Folks,
Probably the only objection that I got for
draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be
included in F() (the hash function).
I'd like to clarify the motivation for that, and also trigger some
discussion on the topic such that I can produce a revision of this
docuement that addresses any remaining concerns.
* Motivation for including the SLAAC Prefix in F() (the hash function)
The essential rationale for including the prefix in the hash function is
that, if we don't, then we'd be leaking more information than we should.
If we don't include the prefix as part of the data to be hashed, then
the Interface-ID will be exactly the same no matter whether the devices
moves from one network to another, and hence the node could be tracked,
even if it implements RFC 4941.
For example, think about the following scenario:
Attack scenario #1
A host configures the stable addresses without including the Prefix in
the hash function. Let's say the host employs any application that needs
to perform a server-like function (P2P, or whatever). As a result of
that, an attacker attacker participating in that application (e.g., P2P)
would learn the Interface-ID used for the stable address.
Now the same host moves to a completely different network, and uses the
same P2P application, probably even with a different user. The attacker
now interacts with the same node again, and hence can learn the "new"
stable address. Since the interface ID is the same as the one above, he
can infer that it is communicating with the same device as before.
Had the host included the Prefix when computing the Interface-ID (with
the hash function F()), the Interface-ID would have been different, and
this wouldn't have been made possible.
This is just *one* possible attack scenario, which should remind us that
one shouldn't disclose more than it is really needed (and a static
Interface-ID across many different networks does exactly that).
* Use of draft-gont-6man-stable-privacy-addresses without RFC 4941
Temporary addresses are painful to manage. They make painful to
correlate the activities of your own nodes. FOr example, one host gets
infeceted will malware, you logged the IPv6 address, but then you don't
know which node was using that address at that point in time.
This is the reason for which in many deployments temporary addresses
(RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma).
When you disable temporary addresses, all you're left with is whatever
stable addresses your host uses. If you don't include the Prefix in F()
(the hash function) then, while you may be resistant to host scanning
attacks (your addresses is not predictable anymore), you're still
trackable, since your interface ID doesn't change as you move from one
network to another.
So yes, there are cases in which you may want privacy, without
necessarily be willing to deal with the burden of temporary addresses.
And if you're just going to have stable addresses, you do not really
want the Interface ID to be constant across networks.
* Concerns about CPU impact
Other folks have expressed concerns (in corridor meetings) that if the
Prefix is included in the hash function, they may need to recompute the
hash every time they attach to a network (assuming the SLAAC prefix
changes), and that would be expensive. I personally think this shouldn't
be an issue for most implementations (for instance, we do MD5 for every
single new TCP connection! -- see RFC 6528). And, in any case, we do not
really specify which hash function to use. -- If you're concerned about
CPU, you may want to use a (CPU-wise) cheaper function.
That said, I'd have no problem with making the inclusion of the Prefix a
SHOULD (i.e., do it, unless you have very good reasons not to do so
(such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in
the hash function turns out to be the show-stopper here).
If you have any feedback/comments, I'd be glad to hear. I'm planning to
rev the document asap, clarifying and incorporating many of the things
explained throughout this e-mail. So if you send your feedback shortly,
the next rev could reflect your comments.
Thanks,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
