Hi Allison.
Thanks for the comments. I (and Rich) agree with pretty much all of
them. Your comments on Section 2 in particular really improved the
document. Here is a breakdown of our response:
> 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
Done.
> 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/
Second suggestion accepted.
> 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"
Done.
> 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"
Done.
> 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)".
Wording changed as follows:
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, unless some form of anonymous DNS
names were used as well (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.
Agree on your basic points. Much of this section has been
reorganized/rewritten. New text below:
2.2. Address Usage in IPv4 Today
Addresses used in today's Internet are often non-changing in practice
for extended periods of time, especially in non-home environments
(e.g., corporations, campuses, etc.). In such sites, addresses are
assigned statically and typically change infrequently. Over the last
few years, sites have begun moving away from static allocation to
dynamic allocation via DHCP [DHCP]. In theory, the address a client
gets via DHCP can change over time, but in practice servers often
return the same address to the same client (unless addresses are in
such short supply that they are reused immediately by a different
node when they become free). Thus, even within sites using DHCP,
clients frequently end up using the same address for weeks to months
at a time.
For home users accessing the Internet over dialup lines, the
situation is generally different. Such users do not have permanent
connections and are often assigned temporary addresses each time they
connect to their ISP (e.g., AOL). Consequently, the addresses they
use change frequently over time and are shared among a number of
different users. Thus, an address does not reliably identify a
particular device over time spans of more than a few minutes.
A more interesting case concerns always-on connections (e.g., cable
modems, ISDN, DSL, etc.) that result in a home site using the same
address for extended periods of time. This is a scenario that is just
starting to become common in IPv4 and promises to become more of a
concern as always-on internet connectivity becomes widely available.
Although it might appear that changing an address regularly in such
environments would be desirable to lesson privacy concerns, it should
be noted that the network prefix portion of an address also serves as
a constant identifier. All nodes at (say) a home, would have the same
network prefix, which identifies the topological location of those
nodes. This has implications for privacy, though not at the same
granularity as the concern that this document addresses.
Specifically, all nodes within a home would be grouped together for
the purposes of collecting information. This issue is difficult to
address, because the routing prefix part of an address contains
topology information and cannot contain arbitrary values.
Finally, it should be noted that nodes that need a (non-changing) DNS
name generally have static addresses assigned to them to simplify the
configuration of DNS servers. Although Dynamic DNS [DDNS] can be used
to update the DNS dynamically, it is not yet widely deployed. In
addition, changing an address but keeping the same DNS name does not
really address the underlying concern, since the DNS name becomes a
non-changing identifier. Servers generally require a DNS name (so
clients can connect to them), and clients often do as well (e.g.,
some servers refuse to speak to a client whose address cannot be
mapped into a DNS name that also maps back into the same address).
Section 4 describes one approach to this issue.
2.3. The Concern With IPv6 Addresses
The division of IPv6 addresses into distinct topology and interface
identifier portions raises an issue new to IPv6 in that a fixed
portion of an IPv6 address (i.e., the interface identifier) can
contain an identifier that remains constant even when the topology
portion of an address changes (e.g., as the result of connecting to a
different part of the Internet). In IPv4, when an address changes,
the entire address (including the local part of the address) usually
changes. It is this new issue that this document addresses.
If addresses are generated from an interface identifier, a home
user's address could contain an interface identifier that remains the
same from one dialup session to the next, even if the rest of the
address changes. The way PPP is used today, however, PPP servers
typically unilaterally inform the client what address they are to use
(i.e., the client doesn't generate one on its own). This practice, if
continued in IPv6, would avoid the concerns that are the focus of
this document.
A more troubling case concerns mobile devices (e.g., laptops, PDAs,
etc.) that move topologically within the Internet. Whenever they move
(in the absence of technology such as mobile IP [MOBILEIP]), they
form new addresses for their current topological point of attachment.
This is typified today by the "road warrior" who has Internet
connectivity both at home and at the office. While the node's address
changes as it moves, however, the interface identifier contained
within the address remains the same (when derived from an IEEE
Identifier). In such cases, the interface identifier can be used to
track the movement and usage of a particular machine [SERIALNUM]. For
example, a server that logs usage information together with a source
addresses, is also recording the interface identifier since it is
embedded within an address. Consequently, any data-mining technique
that correlates activity based on addresses could easily be extended
to do the same using the interface identifier. This is of particular
concern with the expected proliferation of next-generation network-
connected devices (e.g., PDAs, cell phones, etc.) in which large
numbers of devices are in practice associated with individual users
(i.e., not shared). Thus, the interface identifier embedded within an
address could be used to track activities of an individual, even as
they move topologically within the internet.
In summary, IPv6 addresses on a given interface generated via
Stateless Autoconfiguration contain the same interface identifier,
regardless of where within the Internet the device connects. This
facilitates the tracking of individual devices (and thus potentially
users). The purpose of this document is to define mechanisms that
eliminate this issue, in those situations where it is a concern.
> 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)"?
Done.
> 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....
Sentence changed as follows:
Picking identifiers from a pseudo-random sequence suffices, so
long as the specific sequence cannot be determined by an outsider
examining information that is readily available or easily
determinable (e.g., by examining packet contents)
> 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.
The one refers to the "implementation". Fixed.
> Finally, this document assumes that when a node initiates outgoing
> communication, anonymous addresses can be given preference over other
> public addresses.
> Delete "other".
Done.
> 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".
Done.
> 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.
Added a paragraph in the "future work" section:
The determination as to whether to use public vs. temporary
addresses can in some cases only be made by an application. For
example, some applications may always want to use temporary
addresses, while others may want to use them only in some
circumstances or not at all. Suitable API extensions will likely
need to be developed to enable individual applications to indicate
with sufficient granularity their needs with regards to the use of
temporary addresses.
> Sec 3.2
> a randomized interface identifier may need to be
> generated at random.
> Repetitive.
> s/at random/without previous state/
Replace sentence with:
A second approach addresses the case where stable storage is
unavailable and there is a need to generate randomomized interface
identifiers 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.
Added a 0 - RANDOM_DELAY component (suggest value of 10 minutes) in
the setting of certain timers.
> 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/
Paragraph changed to:
The IPv6 addressing architecture goes to some lengths to ensure
that interface identifiers are likely to be globally unique where
easy to do so. 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 may complicate
providing such a 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).
Done.
> 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).
Reworded (and moved to section 4):
Use of the extensions defined in this document may complicate
debugging and other operational troubleshooting activities.
Consequently, it may be site policy that temporary addresses
should not be used. Implementations may provide a method for a
trusted administrator to override the use of temporary addresses.
A new draft will be submitted shortly.
Thomas
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
