Ole and Bob: I don't think that the extension to the Privacy Extension RFC is
applicable here.
Fernando:
I think some of these comments were also made by Ole and Bob but, as I was so
busy, I could not finish them and send them.
Now the question is whether or not you are using the "lifetime" for this IID or
IP. If you are, then it is the same procedure as that for the RFC privacy
extension.
>Nobody has even suggested this. For instance, if these addresses had a
>lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the first
>place.
I understand that you did not use a lifetime for the address where the privacy,
within the network, is questionable! I said that, if you are really concerned
about privacy, then you would need to set the lifetime for your address, even
within the same subnet.
When you use the same, so called stable addresses, in the same subnet, it
means that you generate the same address and use the same address forever
within that subnet. Now the question is, if your address ,according to your
draft, does not change, what privacy protection is afforded within the network
here? Especially for those fixed nodes, within that network, that never move to
another network.
The second question: usually when, for privacy reasons, ISPs change their
addresses they also change the prefixes. So as you say you generate new address
for the new prefix, what is the stability of the address?
For the Second concern, let's go back to the privacy extension RFC. As I
mentioned in a prior email, the second approach is to use CGA or DHCPv6. But
they did not explain how to do this. They mentioned CGA as a way for generating
a random IID but did not mention it as a security option. So one might
consider extending that section to include an explanation as to how to use the
second approach in that RFC. For example, suggest using the CGA generation
algorithm (as you are using it with another name!) and since the address does
not need to be verified, then there is no need to set a sec value or add CGA
options to the options in SEND. Another suggestion might that there is no need
for the other node to process verification because security is not an issue.
> * In 3972, there's no secret. Hence, the attacker might be able to compute
> the IID himself (assuming the algorithm and the input parameters are known).
Not true as I pointed out before.
> * If the CGA Modifier changes (as they are supposed to), then the addresses
> are not constant within the same network (each time you generate a CGA, the
> IID would be different).
See my first paragraph as a response to this.
As I pointed out before, one can make improvements to the privacy extension RFC
and explain the second approach, in more detail for the use of the same
algorithm in CGA as was used (the same as sec value 0, i.e., you just run the
hash algorithm once on the concatenation of a random number, subnet prefix and
etc) and skip the verification mechanism since no verification is needed.
> As noted above, many deployments turn off privacy addresses.
I do not think this is a good reason in this case because they can also do the
same thing using your draft proposal and never implement it, or disable it!
>A.1.3. Revealing the identity of devices performing server-like
Functions
Some devices need to have a fix IP address and these are usually set by an
administrator manually or a fixed range of IP address for the devices being
used. This is what happens in large networks. In small networks, like home
networks, usually the name of the devices are used. For some servers or server
functioning devices, privacy is not important because they should be available
and well known in that network. So for those well-known devices, privacy does
not make sense.
Finally, in your draft you do not completely address the privacy issue. When
the same network is used to connect different places, then your node becomes
vulnerable to tracking. What I think is, as long as you think about stability,
that you need to also forget about privacy. And if you decide to be concerned
with privacy, then you need to use a lifetime for your address. This is again
like the privacy extension RFC, and so, your draft can be written to improve
the second approach described in that RFC as I do not think stability can solve
the privacy issues. At the beginning privacy related attacks might decreased,
but when you plan to use that IP from the same subnet forever, then you are
vulnerable to those types of attack. The attacker only needs to spend more time
gathering information about that node. Then, after a while, it will be easy for
him to track that node again. This means, with your way, the attacks are still
possible; you have just postponed the attacks between networks but done nothing
for those inside the same network.
Thank you,
Hosnieh
From: [email protected] [mailto:[email protected]] On Behalf Of Ole
Troan
Sent: Thursday, December 20, 2012 3:41 PM
To: 6man 6man-wg
Subject: Chairs review: draft-ietf-6man-stable-privacy-addresses-01
all,
the ADs have asked us to ensure that there are good review of documents in the
working group, prior to them being advanced to the IESG.
as a part of document last calls in the 6man working group, Bob and I want to
try
using volunteers and/or w.g. chair reviewers, that take specific responsibility
to
review documents in WG last call.
Bob and I have reviewed this document.
General comments:
--------------------------
We do see the usefulness of a interface-id generation algorithm, that results
in stable identifiers per IPv6 prefix, while not being derived from link-layer
MAC addresses.
The mechanism proposed could be viewed as an modification of temporary
addresses (RFC4941)
with lifetime handling as for SLAAC, or as an extension to CGA (RFC3972) address
generation where the public key is removed from the hash.
The method for generating "Stable privacy addresses" needs to be as well
specified
as temporary addresses (RFC4941).
We do wonder if the method of generating these addresses could be a
modification of the
algorithm in RFC4941, or if at least, larger parts of the text in RFC4941 could
be
references avoiding having to duplicate lots of text into this document.
We do not believe the current revision of the document is ready to advance to
the IESG.
Major points:
-----------------
- Stable Privacy Enhanced Addresses (SPE Addresses) should not be a replacement
for the
algorithm specified in RFC2464. It is an alternative. Section 3 needs
modification.
- The algorithm in the document is underspecified.
o It should specify the hash function. E.g. MD5 as RFC4941.
o It should handle reserved interface-ids (see 4941).
o We suggest renaming the "secret key" to "modifier". And add text describing
how to 'maintain' the modifier (section 3 of RFC3972).
o It would be useful to include an example algorithm as has been done in some
other documents.
o Not all implementations use interface indexes
- Clarify what lifetimes these addresses have.
- Specify the default for DAD retries (IDGEN_RETRIES)
- Clarify the requirements for stable storage (compared to RFC2464)
Minor points:
-----------------
Don't use the term "static addresses" as that implies static aka manual
configuration.
These addresses are not static in that sense.
Section 3, Last Paragraph:
The reference to Node Information Queries only applies if the attacker is
onlink.
Current text overstates the problem. Move to security considerations. Addresses
will
leak regardless, in other communication, email header etc.
6. Security Considerations.
s/in replacement of/as an alternative to/
Third bullet:
The bullet on host-scanning needs some justification.
Fourth bullet: This is not a security issue.
Paragraph after bullets:
s/algorithm is meant to replace/meant to supplement/
Best regards and Merry Christmas,
Bob and Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
