Subject: Comments on the Privacy Extensions draft

From: Allison Mankin <[email-masked]>
Date: Mon, 20 Nov 2000 23:13:34 -0500

[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-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Niels M�ller)
Date: 21 Nov 2000 21:40:42 +0100

> addresses in packet addresses....

If also non-anonymous adresses, based on the link-level address, are
used, som knowledge about the address are leaked. 

For instance, consider a link with a few dozen nodes, each of them
having

(i)   a globally unique addess, constructed as prefix + EUI-64,
(ii)  link-level address, also based on the same EUI-64 id, 
(iii) a bunch of anonymous addresses based on, say,
      md5(EUI-64 + small counter), using the same prefix as the global
      address 

If you connect somewhere using an anonymous address, and the server
has a list of previously observed global addresses, the server can
lookup the global addresses that happened to match your prefix. Next,
the EUI-64 ids for the matching addresses are extracted, and a
reasonably small search will tell if any of those identifiers match
your anonymous address, and if so, which one.

There may also be other means of getting network-card addresses
(imagine a customer database listing the customers and serial numbers
of all purchased hardware).

Perhaps I'm missing something, but it seems wise to me not to assume
that link local addresses or network serial numbers and similar data
are secret.

You probably also don't want to assume that the "arbitrary remote
peer" isn't cooperating with other less arbitrary and more determined
peers.

/Niels

---

From: Matti Aarnio <[email-masked]>
Date: Wed, 22 Nov 2000 03:11:28 +0200

>       md5(EUI-64 + small counter), using the same prefix as the global

   IF there is *small* counter.  Indeed the draft gives me more of
   an idea of using some good randomness source, like hosts need to
   have against TCP sequence number start spoof attacks anyway.
   Algorithm at chapter 3.2.1 seems to have very strong randomness
   property, not a trivial counter at all.

   Indeed doing pure pick of 8 random bytes, masking some, and doing
   DAD driven duplicate avoidance does yield similar result as the
   whole complicated scheme of calculating new value from real EUI-64 +
   previous (8) history pseudorandom bytes.  But being purely random,
   they have no relationship with the real EUI-64 at the machine.

   For second and third reasons mentioned at chapter 4, I still prefer
   DHCP approach.  ISC's DHCP does fluently issue (IPv4) addresses out
   of pool to machines: first come, first free issued.

   The only problem at the DHCP approach is that it doesn't support
   time variability of the address in gracefull manner.
   ... but that is developeable, perhaps as an extension.
   (chapter 6 mentions this issue also.)

   The DHCP does give traceability for local network administrators
   (presuming it is used -- not an absolute requirement, after all),
   while external people have no clue as to who is where when.

   The "blame-traceability" is important thing to many network admins,
   anonymization should not make that too difficult.
   (A thing analogous to 'arpwatch' can handle Layer2/Layer3 binding
    tracking for IPv6, but it mandates a set of machines not otherwise
    needed.)

> peer" isn't cooperating with other less arbitrary and more determined

	If the badies are at your local L2 network, you have been had
	anyway...  Your privacy, at least, possibly also your data.

> /Niels

/Matti Aarnio

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Nov 2000 23:26:19 -0500

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

> s/ANON_PREFERRED_LIFETIME/ANON_VALID_LIFETIME

Done.

> s/is globally unique/is likely to be globally unique/

Second suggestion accepted.

> This is good, but should say "globally unique and/or persistent"

Done.

> individual users and in environments where such concerns are significant"

Done.

> anonymous addresses might also use some form of anonymous DNS names

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).

> 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.

> Nit: sentence already has "may," so why add further distance with

Done.

> 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)

> as saying there's an algorithmic conversion from the anonymous

The one refers to the "implementation". Fixed.

> Delete "other".

Done.

> initiated by the node".

Done.

>  Mention somewhere that applications

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.

> 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.

> could have their new randomized interface timers synch up and cause

Added a 0 - RANDOM_DELAY component (suggest value of 10 minutes) in
the setting of certain timers.

> s/eliminate that future flexibility/possibly complicate that future

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.

>  in DNS using random names (for example a string version of the

Done.

> 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