[These are comments that were sent to the authors at the end
of the IETF Last Call. A new rev soon to appear will reflect
these comments and since they were extensive, it was deemed useful
for the WG to see them]
I reviewed draft-ietf-ipngwg-addconf-privacy-03.txt carefully
and I have a number of small and larger comments. I found the
draft to be strong (parts of it very strong) but I thought it
could use a new thorough review.
There is a pressing need for this spec so I strongly support
its publication when these comments have been addressed.
In addition to this draft getting published as a standard,
I'd like to urge that work be done on the API for use of the
privacy extensions.
Allison
------------------
Typo
----
Sec 3.5
applications are used by end users. Thus the default value given of
one week (ANON_PREFERRED_LIFETIME) may not be appropriate in all
environments. Implementations should provide end users with the
ability to override both of these default values.
s/ANON_PREFERRED_LIFETIME/ANON_VALID_LIFETIME
Detailed comments
-----------------
Sec 1
By design, the interface
identifier is globally unique when generated in this fashion. The
interface identifier is in turn appended to a prefix to form a
128-bit IPv6 address.
Since RFC2462 doesn't allow counting on the EUI-64 interface id being
unique even on the link (MUST do DAD on the generated link-local
address) this bit of intro is too strong. A more accurate wording would
be: "There is an expectation that the interface identifier
generated in this way will be globally unique, and that this might
be a valuable property for future approaches to hierarchical routing,
as explained in [ADDRARCH]." Or more simply:
s/is globally unique/is likely to be globally unique/
described may also apply to interfaces with other types of globally
unique and persistent identifiers.
This is good, but should say "globally unique and/or persistent"
This document discusses concerns associated with the embedding of
non-changing interface identifiers within IPv6 addresses and
describes extensions to stateless address autoconfiguration that can
help mitigate those concerns in environments where such concerns are
significant.
Nit: the last phrase sounds like a diminution of likelihood of
such concerns existing. An alternative phrasing that implies
a bit more concern for privacy: "help mitigate those concerns for
individual users and in environments where such concerns are significant"
Sec 2.1
serves as a similar identifier. Although the DNS name associated with
an address is more work to obtain (it may require a DNS query) the
information is often readily available. In such cases, changing the
address on a machine over time would do little to address the concern
raised in this document, as the DNS name would become the correlating
identifier.
Instead of the "would do little..." final sentence, which suggests
that anonymous addresses are defeated by inverse DNS, this paragraph
should send with a sentence like "In such cases, nodes using
anonymous addresses might also use some form of anonymous DNS names
(see Section 4)".
Sec 2.2
Sec 2.2's first paragraph begs for a comparison with the Intel
PIII serial number. It seems to me that it would be best to be
up-front about the problems being comparable.
Sec 2.2 (cont)
Many network services require that the client authenticate itself to
the server before gaining access to a resource. The authentication
step binds the activity (e.g., TCP connection) to a specific entity
(e.g., an end user). In such cases, a server already has the ability
to track usage by an individual, independent of the address they
happen to use. Indeed, such tracking is an important part of
accounting.
This paragraph undercuts the whole purpose of the draft and ought
to be rewritten. Sec 2.2 in fact sends an undercutting message:
becasue identification and tracking goes on, therefore
don't worry about your IP addresses being trackable. A better
message from the section (and one more appropriate to the draft)
would be: don't undermine higher level technologies for improving
the privacy of applications by leaving every packet trackable at
low level.
Examples of attempts to improve privacy at higher level that could
be undercut by trackable packets:
1. varying one's registrations at a web-based service
2. rejecting persistent cookies and only allowing session cookies
It is possible to avoid persistent higher level identifiers. People
create changing or multiple identities per site or for different sites.
Even sites where registration is an email address can be given
varied inputs by using multiple free email accounts. Credit card
registration is the subject of a US mandate to go to one-time credit
card numbers. However, all of these kinds of anonymizing are
undermined by having a trackable IP address.
Sec 2.3
In such environments, one may need multiple addresses: a "public" (i.e.,
non-secret) server address, registered in the DNS, that is used to
accept incoming connection requests from other machines, and
(possibly) an "anonymous" address used to shield the identity of the
Nit: sentence already has "may," so why add further distance with
the "(possibly)"?
To make it difficult to make educated guesses as to whether two
different interface identifiers belong to the same node, the
algorithm for generating alternate identifiers must include input
that has an unpredictable component from the perspective of the
outside entities that are collecting information. Picking identifiers
from a pseudo-random sequence suffices, so long as the specific
sequence cannot be determined by an outsider examining just the
identifiers that appear in addresses or are otherwise readily
available (e.g., a node's link-layer address).
It's bad news if the node's link-layer address is "readily
available" to arbitrary remote peers - the last parenthesis
doesn't make sense in this draft about not embedding link-layer
addresses in packet addresses....
Sec 3.1
The algorithm also assumes that for a given anonymous address, one
can determine the corresponding public address.
Who does "one" refer to? I think this sentence must intend to
say "The algorithm also assumes that there is an internal data
structure available to address autoconfiguration matching a given anonymous
address to its corresponding public address", but it can be read
as saying there's an algorithmic conversion from the anonymous
back to the public.
Finally, this document assumes that when a node initiates outgoing
communication, anonymous addresses can be given preference over other
public addresses.
Delete "other".
This can mean that all outgoing connections use
anonymous addresses by default, or that applications individually
indicate whether they prefer to use anonymous or public addresses.
Replace "outgoing connections" with "connections
initiated by the node". Mention somewhere that applications
indicating their preference for an anonymous address is one
example of API work that is needed in conjunction with this
spec.
Sec 3.2
a randomized interface identifier may need to be
generated at random.
Repetitive.
s/at random/without previous state/
Sec 3.5
This can be achieved automatically by
generating a new randomized interface identifier at least once every
(ANON_PREFERRED_LIFETIME - REGEN_ADVANCE) time units. As described
above, generating a new anonymous address REGEN_ADVANCE time units
before an anonymous address becomes deprecated produces addresses
with a preferred lifetime no larger than ANON_PREFERRED_LIFETIME.
I think this should have the same mechanism of desynchronizing the nodes
that RFC2461 has, because nodes that start up after a power failure
could have their new randomized interface timers synch up and cause
a daily DAD flood.
Sec 4
The IPv6 addressing architecture goes to great lengths to ensure that
interface identifiers are globally unique.
s/great lengths/some lengths/
s/are globally unique/may be globally unique/
The sentence is too strong, compared with the address architecture
RFC (even the new i-d). And as before, saying the EUI-64's are
surely globally unique is contradicted by Addrconf requiring DAD
on them.
During the IPng
discussions of the GSE proposal [GSE], it was felt that keeping
interface identifiers globally unique in practice might prove useful
to future transport protocols. Usage of the algorithms in this
document would eliminate that future flexibility.
I disagree that the anonymous addresses would eliminate a GSE-like
future scheme, any more than using any addresses where the u/l bit is
unset is doing so already. There are other ways that a GSE-like
future scheme might be work, for instance, using global interface ids
as input to a cryptographic registry that would return an anonymized
interface id to use in the address. Wording suggestion:
s/eliminate that future flexibility/possibly complicate that future
flexibility/
DNS name (if non-changing) serves as a constant identifier. If the
extension described in this document becomes widely deployed, servers
will likely need to change their behavior to not require every
address be in the DNS. Another alternative is to register anonymous
addresses in DNS using random names (for example a string version of
the address itself).
Sweeping changes to server behavior are unlikely/hard to drive.
The prospect of anonymized DNS names (as mentioned next) is better.
Perhaps change the last two sentences to be both more realistic and more
constructive:
The wide deployment of the extension described in this document could
challenge the practice of inverse-DNS-based "authentication," which
is has little validity, though it is widely implemented. In order
to meet server challenges, nodes could register anonymous addresses
in DNS using random names (for example a string version of the
random address itself).
Sec 6
Use of the extensions defined in this document is likely to make
debugging and other operational troubleshooting activities more
difficult.
Not certain - when the troubleshooting regards nodes that are
in LAN segments controlled by an administrator, it should be
possible to register and identify nodes by their layer 2 addresses
(RMON can give access to that sort of trace). If the troubleshooting
regards distant nodes, it's already the case that the addresses
won't give much help (e.g. in DDos).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
