Subject: Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Oct 2004 01:45:37 -0400 (EDT)

Hi Pekka,
  Thanks for the detailed comments. See my responses inline.

Regards
Suresh

On Tue, 12 Oct 2004, Pekka Savola wrote:

>FWIW, I think we should make the specification agnostic of the hash
>algorithm.  Either MD5 and SHA1 or whatever is just fine.  There is no
>interoperability problem because I don't see a need to be able to
>reverse the hashes, and it's just an implementation's internal matter.
>

Please see my reply to Brian earlier on the list and let me know if this
addresses your concern.

>I guess this is intended for Draft Standard (based on the charter 
>page), but there are a few issues which need to be nailed down first 
>(e.g., about the normative refs to lower maturity specs).

I have addressed this later in the mail.

>
>substantial
>-----------
>
>1) 
>
>The document goes at great depth to discuss the scenarios and justification
>for privacy addresses, but I don't think the document produces a concise
>problem statement (like one paragraph of less than 5 sentences) or
>description about the scenarios or the threat model.  The factoids are
>dribbled through section 2 but it might make sense to try to collect the
>important bits together and try to coin up a nice and neat description of
>the problem that's being fixed.

How about the following text for the problem statement?

"Addresses generated using Stateless address autoconfiguration [ADDRCONF]
contain an embedded 64-bit interface identifier which remains constant
over time. Anytime a fixed identifier is used in multiple contexts, it
becomes possible to correlateseemingly unrelated activity using this
identifier. Since the identifier is embedded within the IPv6 address,
which is a fundamental requirement of communication, it cannot be easily
hidden. This document proposes a solution to this issue by generating
interface identifiers which vary over time."

>
>For example, one should take note of the following:
> - what is the observation point? (e.g., first paragraph of 2.1 takes IMHO
>bad example of sniffing the traffic might be better removed or reworded)
> - what is the assumption about the (in)stability of the prefix to the
>effects of privacy addresses?

This is covered in Section 3.6 "Deployment Considerations"

> - how does this effect stationary nodes?  nomadic nodes?

I will cover the effect on nomadic nodes in the section I am going to
write about mobile IP.

>
>Also, security considerations talks about ingress filtering, but
>doesn't really talk about the main meat of
>draft-dupont-ipv6-rfc3041harmful-XX.txt, that is, why privacy
>addresses give privacy only with certain assumptions about the
>dynamicity (or not) of the used prefixes.  This should go in as a
>paragraph of its own in security considerations after the above is
>clear.

I had already added text in the draft, which I thought would address
this issue. It is the last paragraph of Section 3.6 "Deployment
Considerations"

"If a very small number of nodes(say only one) use a given prefix for
 extended  periods of time, just changing the interface identifier
 part of the prefix  may not be sufficient to ensure privacy, since
 the prefix acts as a constant identifier.  The procedures described
 in this document are most effective when the prefix is reasonably non
 static or is used by a fairly large number of nodes"

Do you think this is not sufficient?

>
>2) the document also goes on at least in 3 different places to list
>issues with reverse lookups and such.  Is this really necessary?  I'm
>not objecting strongly, but there have been arguments that rather than
>fiddling with protocols, one should consider fixing the broken
>applications.  This is also discussed in draft-ietf-dnsop-ipv6-issues
>(as are the issues with DDNS), so it might be worth referring to that
>informatively from here.

The dnsop ipv6 issues draft just refers back to RFC3041 regarding
reverse lookups. Would you still like me to reference it?

>
>3) DNA is referred to in section 3.5, unfortunately I think (at least with
>the current wording) this would need to be a normative reference because
>it's required for implementation of this spec.  And normative refs must be
>at least the same maturity level of this spec, and this may pose a problem. 
>A few possibilities which might solve this problem:
> - describe DNA just as one alternative to note whether the link change has
>occurred, and possibly detail some others as well
> - just wait for DNA spec, and keep this as proposed standard
> - remove (some of) the specification about link changes, e.g., just saying
>that for wired interfaces plug in/out and wireless interfaces the interface
>restart could be the events -- no need for DNA then.

I like option 1. I will reword this and change the DNA reference to
informational.

>
>
>semi-substantial
>----------------
>
> ==> the draft talks a lot about 'global scope addresses',
>but I don't think is really accurate.  The privacy address practices could
>be applied to site-local or ULA addresses as well, it's just a matter of
>local policy.  RFC2462bis might provide some ideas how to express
>'non-link-local' in a better way.

Site local has been deprecated and ULAs are within the scope of the
document. I have the following text in the draft at the end of Section 1

"Introduction"

" The term "global scope addresses" is used in this
  document  to collectively refer to "Global unicast addresses" as
  defined in [ADDRARCH] and "Unique local addresses" as defined in
  [ULA]"

Do you have any issues with this definition?

>
>On the other hand, I see benefit in restricting the scope of privacy
>addresses to just global scope addresses, but then you have to define
>those somehow and that may be tricky.. because ULA addresses, by some
>terminology, are also global scope..
>
>   Not all nodes and interfaces contain IEEE identifiers.  In such
>   cases, an interface identifier is generated through some other means
>   (e.g., at random), and the resultant interface identifier is not
>   globally unique and may also change over time.
>
>==> 'globally unique interface identifier' is a rather absolute
>statement and may not actually be accurate because it has happened
>that identifiers have been duplicated.  Maybe soften the tone a bit.
>(also see the robert elz appeal on addrarch and unique/local bits.)

OK. The problem in fixing this is that there is no explicit claim that
IIDs formed from EUIs are globally unique. Would it be OK if I changed
" resultant interface identifier is not globally unique"
to
" resultant interface identifier may not be globally unique"

>
>  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.
>
>==> the document mentions Mobile IP, but this doesn't actually matter much,
>depending on the actual problem statement.  Remember, unless the mobile node
>would *only* do bidirectional tunneling back to the home agent, every node
>the MN talks to will know the care-of address in any case, which seems equal
>in privacy considerations to just laptop moving without mobile IP.
>
>Mobile IP is actually relatively incompatible with privacy addresses 
>as the home address probably acts as a stable identifier, nullifying 
>the effect of using privacy addresses for care-of address if you do 
>route optimization.  This could maybe be discussed in security 
>considerations.  A workaround is having multiple home addresses 
>(rfc3041 ones), but I don't recall if that's supported or not, and 
>even then, you reveal the stable prefix as the identifier.

I will add a paragraph in "Deployment Considerations" about Mobile IP.

>
>   One way to avoid some of the problems discussed above is to use DHCP
>   for obtaining addresses.  With DHCP, the DHCP server could arrange to
>   hand out addresses that change over time.
>
>==> 'change over time' seems relative.  The key point here is that DHCP
>should not provide the addresses with (similar) stable identifiers.  Looking
>at current or planned DHCPv6 deployments, at least some are using (AFAIR)
>DHCPv6 to give the hosts the same addresses they'd get with stateless
>address autoconfiguration, including EUI64.  Obviously, such would likely
>not change sufficiently often, and would include the stable identifier.
>
>How I see it, the document seems slightly too forthcoming with
>proposing DHCPv6 as a solution for privacy here, but that only works
>if DHCPv6 gives temporary addresses without the stable identifiers,
>and rotates even those non-identifying addresses in a regular basis
>("strict pool").  But that seems unnecessary complexity, because there
>is no need (no address shortage) to do that with IPv6.  So, I don't
>why anyone would use DHCPv6 to avoid this problem rather than privacy
>addresses.

Agreed. DHCP is proposed as a solution and is qualified by the following
sentence

"With DHCP, the DHCP server could arrange to hand out addresses that
 change over time"

and the issue you are mentioning is discussed earlier in section 2.2

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

Would you like me to add stronger wording or to explicitly discourage
the use of DHCPv6 for privacy purposes?

>
>   4.  By default, generate a set of addresses from the same
>       (randomized) interface identifier, one address for each prefix
>       for which a global address has been generated via stateless
>       address autoconfiguration.  Using the same interface identifier
>       to generate a set of temporary addresses reduces the number of IP
>       multicast groups a host must join.  Nodes join the solicited-node
>       multicast address for each unicast address they support, and
>       solicited-node addresses are dependent only on the low-order bits
>       of the corresponding address.  This default behaviour was made to
>       address the concern that a node that joins a large number of
>       multicast groups may be required to put its interface into
>       promiscuous mode, resulting in possible reduced performance.
>
>==> what you seem to be saying, in a rather complex way in these
>steps, that a random address is generated for each received prefix
>[regardless of interfaces].  Wouldn't there a simpler way to specify
>that ?

Not really. The identifier is generated per interface. So a random address
is generated per prefix per interface. The idea of the paragraph is to
explain the rationale behind using the same random identifier with all
the prefixes received on an interface. I agree there might be a simpler 
way of stating this. I will try to come up with something.

>
>      A node highly concerned about privacy MAY use different interface
>       identifiers on different prefixes, resulting in a set of global
>       addresses that cannot be easily tied to each other.  This may be
>       useful, for example, to a mobile node using multiple wireless
>       interfaces to connect to multiple independent networks.
>
>==> I think the example is flawed, or I don't understand this concern.  
>Multiple wireless interfaces have their own MAC addresses, and
>multiple independent networks have their own prefixes.  If you connect
>using interface 1 to network 1 and interface 2 to network 2, there is
>no way to connect the privacy addresses derived from them.  Rather, if
>you use interface 1 to connect to networks 1,2,..,N, you're
>identifiable, but this is then again the the regular roaming scenario
>and requires no special considerations...

This paragraph explicitly allows the following scenario.

Let's say interface IF1 is connected to networks N1,N2 and N3. The node
MAY generate DIFFERENT identifiers I1,I2 and I3 for each of these prefixes
to make addresses N1|I1, N2|I2, and N3|I3 if it so desires, instead of
being limited to N1|I1,N2|I1, and N3|I1.

>
>As it is, there's nothing in the spec that would propose that a
>multi-interface node could pick one of its identifiers and use it as a
>basis for privacy address generation on all of its interfaces.  As I
>read it, for every physical interface, the 'seed' must be different.

Yes. This is true.

>
>...
>
>       B.
>           +  If the received Valid Lifetime is greater than 2 hours
>              update the lifetime of the temporary address to the
>              received lifetime.
>           +  If the RemainingLifetime of the temporary address is less
>              than or equal to 2 hours ignore the received option.
>           +  Otherwise set the valid lifetime to 2 hours.
>       C.  These steps are necessary to prevent a denial of service
>           attack where a bogus advertisement contains prefixes with
>           very small Valid Lifetimes
>
>==> isn't this fundamentally duplication of specification from rfc2462
>checks ?  Couldn't you just specify that the lifetimes are checked as
>specified in section X.X.X.y of rfc2462 ?

No. This check does not exist in RFC2462. It was added later in
RFC2462bis. Since 2462bis is still a draft I included it here. I can
remove it and add a reference to 2462bis if needed. But this needs to be
a normative reference.

>
>   6.  The node MUST Perform duplicate address detection (DAD) on the
>       generated temporary address.  If DAD indicates the address is
>       already in use, the node MUST generate a new randomized interface
>       identifier as described in Section 3.2 above, and repeat the
>       previous steps as appropriate up to 5 times.  If after 5
>       consecutive attempts no non-unique address was generated,
>
>==> 5 times seems like really a strech.  Couldn't we lower that down
>to, say, 3 times?  That would still be sufficiently many repetitions,
>but lower the unnecessary delay and attempts significantly in case
>there are problems.

I will make this a configuration variable and default it to 3.

>
>  When a temporary address becomes deprecated, a new one MUST be
>   generated.  This is done by repeating the actions described in
>   Section 3.3, starting at step 3).  Note that, except for the
>   transient period when a temporary address is being regenerated, in
>   normal operation at most one temporary address corresponding to a
>   public address should be in a non-deprecated state at any given time.
>
>==> I'm flinching back at the 'corresponding' language.  The
>implementation shouldn't need to keep track of public -> private
>address mappings, and if it does, this should be made more explicit.  
>Instead, it may need to track prefixes, and possibly interfaces (or
>interface-identifiers).

I will change the language to make the node track the prefixes instead
of corresponding public addresses.

>
>  If a very small number of nodes(say only one) use a given prefix for
>   extended   periods of time, just changing the interface identifier
>   part of the prefix  may not be sufficient to ensure privacy, since
>   the prefix acts as a constant identifier.
>
>==> i'd rather say s/may not be/is not/, because there's nothing conditional
>(IMHO) about it.

There is. The data collector NEEDS to know that there is only one node.
Otherwise she/he may not be able to correlate the collected data with
two different addresses.

>
>10  References
>
>==> needs to be broken down to informative and normative.  It's not clear
>whether this is intended for PS or DS, but if DS, normative refs must only
>include those specs which are of DS of BCP; if PS, PS is also OK.

OK. I have made this change for the new version of the draft based
on Brian's comments.

>
>editorial
>---------
>
>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.).
>
>==> it's not so much 'home' environments as such but whether the ISP has
>assigned a static (or gives de-facto static) addresses.  This is obviously
>mostly an issue at home, but could maybe be a bit more general in the text.

OK. I will add a more general description.

>
>   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 lessen 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.
>
>==> while the topic was 'Address Usage in IPv4 today', the text jumps in the
>middle to describe v6 considerations (about the prefix portion).  Maybe this
>needs to go somewhere else, or at least broken down more explicitly (e.g.,
>to a different paragraph).

Not necessarily. It is still talking about IPv4 prefixes and IPv4
addresses. 

>
>  Finally, this document assumes that when a node initiates outgoing
>   communication, temporary addresses can be given preference over
>   public addresses, when the device is configured to do so.  This is
>   consistent with on-going work that addresses the topic of
>   source-address selection in the more general case [ADDR_SELECT]
>
>==> on-going work no longer...

Good catch. I will change the text. I already have ADDR_SELECT
referencing RFC3484.

>
>   applications are used by end users.  Thus, the default value given of
>   one week (TEMP_VALID_LIFETIME) may not be appropriate in all
> 
>==> s/default value given/given default value/

OK.

>
> 
>   temporary addresses in order to simply network debugging and
>                                                                                                                                           
>
>==> s/simply/simplify/

OK.

>
>   An implementation might want to keep track of which addresses are
>   being used by upper layers so as to be able to remove a deprecated
>   temporary address from internal data structures once no upper layer
>   protocols are using it (but not before). [...]
>
>==> this issue seems to be discussed in nearly the same fashion in two
>different places in the draft.  Could this just be summarized in one, and
>described in full in the other, or something?

One of the places talks about WHEN an application is allowed to remove
deprecated addresses. The other one talks about Future Work to be done.
I don't see any elegant way of combining these two.

>
>8.  Security Considerations
>                                                                                                                                           
>                                                                                                                                           
>   Ingress filtering is being deployed as a means of preventing the use
>   of spoofed source addresses in Distributed Denial of Service(DDoS)
>   attacks. 
>
>==> s/is being/has been/ ?

Subjective ;-). "Has been" makes it sound like everyone has it deployed
already. I will leave it as it is unless you have strong feelings.

>
>  legitimately changing temporary addresses and spoofed source
>   addresses which "in-prefix"(They use a topologically correct prefix
>   and non-existent interface ID).  This can be addressed by using
> 
>==> s/which/which are/, add space after "

OK.

>
>  [ADDRARCH]
>              Hinden, R. and S. Deering, "IP Version 6 Addressing
>              Architecture", RFC 2373, July 1998.
>
>==> 3513

Will do. 

>
>   [MOBILEIP]
>              Perkins, C., "IP Mobility Support", RFC 2002, October
>              1996.
>
>==> rather use 3775.

Will do.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Oct 2004 16:17:26 +0300 (EEST)

Sorry for the delay to respond to your quick response.. long email ;-)

OK.

> interface identifiers which vary over time."

This describes rather well the approach against correlation, but what 
I was more concerned about was what I wrote below -- i.e., that the 
case _where_ and _by whom_ you expect that correlation to happen.

> This is covered in Section 3.6 "Deployment Considerations"

See above.  At least some of this should probably be prominent in the 
justification of this mechanism.

OK.

> Do you think this is not sufficient?

Yes -- that seems like an afterthought which is not applied
sufficiently to the rest of the document -- the discussion & problem
statement in the introduction and the first paragraphs and the
security considerations in particular.

The point is that if you use stable prefixes, RFC3041 addresses don't
help you at all to ensure privacy for stationary nodes in that
network.  That needs to be said loud and clear in the critical places
in the document.
 
> reverse lookups. Would you still like me to reference it?

The part in dnsop ipv6 issues draft I referred to was the discussiona
bout the techiniques for using DDNS, and the discussion of the
applicability of reverse DNS in the first place.

Not sure if it needs to be referred to here, but if the draft talks a 
bit about these subjects, referring to another document which tries to 
do a more extensive discussion might not hurt.

> I like option 1. I will reword this and change the DNA reference to

OK.  I guess some other techniques than DNA also need to be noted
(maybe less optimal as DNA)?

> Do you have any issues with this definition?

Yes -- this brings up the issue why one would like to use privacy
addresses with unique local addresses ?  This gets back to the
question of correlating by whom and where.  In the domains where you 
use ULA addresses, I'd expect you wouldn't be concerned of 
correlation..

> " resultant interface identifier may not be globally unique"

That seems to be sufficiently softening the wording and it's OK by me.

OK.

> the use of DHCPv6 for privacy purposes?

The discussion in section 2.2 is about IPv4 where there arguably there 
can be some some address shortage.  The quote you give is not 
sufficiently strong for DHCPv6, because the node would basically NEVER 
have to change the address.  So DHCPv6 does not practically address 
this concern, unless the address rotation is manually configured, and 
nobody will bother to do that.

Therefore I think stating that DHCP(v6) can solve this problem needs
to be stated rather in a fashion like "DHCPv6 could only solve the
problem if addresses it gave didn't have stable identifiers, and those
addresses were manually rotated periodically so that each node would
get new addresses suitably frequently.  Because this does not happen
automatically, and manual renumbering operations can be considered
extremely burdensome, DHCPv6 is not a solution for address privacy;  
DHCPv6 can only be used as an alternative for handing temporary
addresses [but explain why this doesn't necessarily make much
difference compared to just doing RFC3041]".

OK.

> being limited to N1|I1,N2|I1, and N3|I1.

Then you should be saying 'a single wireless interface' instead of 
'multiple wireless interfaces', and this would be OK.

> remove it and add a reference to 2462bis if needed. But this needs to be

2462bis is slated for (recycling at) DS, and is also relatively far in
the process, so I don't think it would be a problem normatively
referring to what that doc specifies.

That is, if there are folks who would implement the RFC3041bis but not
2462bis could just look at 2462bis and take that specification from
there.

OK.

OK.

> Otherwise she/he may not be able to correlate the collected data with

This depends on whether the data collector is interested in tracking a 
particular user inside the prefix, or just the prefix and whoever are 
using it.

For example, FBI might want to correlate traffic that's originated
from the particular house.  They might not care that much whether it's
the father or the son whose laptop is doing the talking -- it wouldn't
probably even much, because the people inside the prefix might even
share their computers.

What the data collector NEEDS to know (or make an educated guess
about) AFAICS is whether the specific set of prefixes have a small or
large number of users behind them.  But that kind of information can
usually be gleaned from publically available information if they
really want.

OK.

> Not necessarily. It is still talking about IPv4 prefixes and IPv4

I fail to see that.. homes aren't allocated a /24, /25, /26 or
whatever v4 prefixes, so saying that "the network prefix portion of an
address also serves as a constant identifier" seems wrong --
especially if the observer cannot know or reasonably guess where the
prefix part ends and the address part begins.

> I don't see any elegant way of combining these two.

Couldn't one just say in section 3.4 like:

   As an optional optimization, an implementation MAY remove a
   deprecated temporary address that is not in use by applications or
   upper-layers as outlined in section 6. 

.. and delete the rest ?

(Note: I'm not sure whether this has been even implemented -- if not, 
it should be removed completely, at least from sect 3.4)

> already. I will leave it as it is unless you have strong feelings.

Sufficiently fine with me right now.  'is being' just sounds as if it
hasn't been deployed at all yet, and it was just recently started
being deployed..

The more complex way would be to say "has been and is being"..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Oct 2004 00:03:27 -0400 (EDT)

Hi Pekka,
  I am proposing the following changes to resolve the issues that you 
raised. 

* I have made all the changes we both agreed on.

* I have added the following problem statement

  "Addresses generated using Stateless address autoconfiguration
   [ADDRCONF]contain an embedded 64-bit interface identifier, which
   remains constant over time.  Anytime a fixed identifier is used in
   multiple contexts, it becomes possible to correlate seemingly
   unrelated activity using this identifier.

   The correlation can be performed by
   o  An attacker who is in the path between the node in question and
      the peer(s) it is communicating to, and can view the IPv6
      addresses present in the datagrams.
   o  An attacker who can access the communication logs of the peers
      with which the node has communicated.

   Since the identifier is embedded within the IPv6 address, which is a
   fundamental requirement of communication, it cannot be easily hidden.
   This document proposes a solution to this issue by generating
   interface identifiers which vary over time."

* I have added the following text to the background section 2.1

  "Although it might appear
   that changing an address regularly in such environments would be
   desirable to lessen 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 could be grouped together for the purposes of
   collecting information.  If the network contains a very small number
   of nodes, say just one, changing just the interface identifier will
   not enhance privacy at all, since the prefix serves as a constant
   identifier."

* Added an informative reference to the dnsop issues draft.

* I hope the problem statement above justifies the use of privacy 
addresses for ULAs

* Added the following text specifying the conditions for DHCPv6 to be used 
for privacy 

  "One way to avoid some of the problems discussed above is to use
   DHCPv6 [DHCPV6] for obtaining addresses.  The DHCPv6 server could be
   configured to hand out addresses that change over time.  But DHCPv6
   will solve the privacy issue only if it frequently handed out
   constantly changing addresses to the nodes.  Since this does not
   happen automatically, and is difficult to configure manually, DHCPv6
   is not really suited for solving the privacy issues addressed by this
   document."

* Removed the text about processing router advertisements and added a 
normative reference to rfc2462bis

* Removed the v6 specific text in "Address Usage in IPv4 today"

Let me know if these changes address your concerns.

Thanks
Suresh

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 10:23:35 +0300 (EEST)

>       with which the node has communicated.

In other words, this extension is not only aimed at protecting the
privacy the outside observers (like the nodes you're communicating
with), but also those who are able to perform on-the-path privacy
violations (ISPs, FBI/NSA intercepting the packets, etc.).

Has the protection from your ISPs and federal agencies etc. really
been the requirement/goal from the start?

I'd like to observe that anyone who will be able to do on-the-path
analysis will be able to jeopardize the privacy of the user typically
in any case.  While I think privacy is pretty important, I fear that
this mechanism is insufficient to provide privacy to the users if
we're concerned about on-path analysis, and I'd be hesitant to include
it in the problem statement without warnings.

I'm interested if others have comments on this.

> * I hope the problem statement above justifies the use of privacy 

I'm not so sure: so, you'd assume that the evil enterprise 
administrator would be eavesdropping and correlating enterprise's 
internal traffic, or the enterprise's internal web servers would be 
correlating the behaviour?

As far as I can see, it's exactly the opposite -- privacy extensions 
should not be enabled by default for ULAs.

>    is not really suited for solving the privacy issues addressed by this

This doesn't mention that DHCPv6 can hand out the temporary addresses, 
but that there is little benefit to do so compared to just doing 
RFC3041 (unless the site has disabled stateless address autoconf 
complately), but this is good enough for me now.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Oct 2004 08:36:40 -0400 (EDT)

Hi Pekka,
  Thanks for the quick review. See comments inline

Regards
Suresh

>violations (ISPs, FBI/NSA intercepting the packets, etc.).

Yes. 

>been the requirement/goal from the start?

On-path does not have to be FBI/NSA or ISPs. It can be anyone on an 
upstream network (even in the same organization as the user). I would
assume if the FBI/NSA or the ISPs wanted to intercept they could do 
so at the layer 2 connection to the provider. Do you want me to add a 
statement about lawful intercept still being possible?

>should not be enabled by default for ULAs.

This is already the case. Privacy extensions are disabled by default for 
ALL types of global addresses (including the ULA). 

>complately), but this is good enough for me now.

OK. That was the reason I left it out. I will leave it as is.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Oct 2004 10:06:08 -0400

I disagree with the wording of this section regarding the use of DHCPv6 for
privacy addresses:

>    is not really suited for solving the privacy issues addressed by this

DHCPv6 includes mechanisms for assignment and management
of "temporary addresses" (see section 12 of RFC 3315).  The frequency of
reassignment for temporary addresses can be as often as desired, and is
independent of the lifetimes for non-temporary addresses.  "difficult to
configure manually" is an entirely subjective assessment, and is dependent
on the specific implementation rather than the protocol itself.

Therefore, I think the text should be edited to read:

    One way to avoid some of the problems discussed above is to use
    DHCPv6 [DHCPV6] for obtaining addresses.  Section 12 of RFC 3315
    discusses the use of DHCPv6 for the assignment and management of
    "temporary addresses" (privacy addresses).  Temporary addresses are
    managed separately from non-temporary addresses, so a host can
    differentiate between the two types of addresses.  The lifetimes of
    temporary addresses are independent of the lifetimes of any other
    addresses, so the frequency of replacement for temporary addresses
    can be adjusted as required.

I wonder if section 2.2 is required at all?  I don't think experience with
IPv4 addressing has much bearing on IPv6.  For example, a device gets an
entirely new IPv4 address when it moves to a new connection point, so
tracking that device as it moves between connection points is hard.  If
section 2.2 is retained, some of the details should be corrected.

Finally, at the risk of nit-picking, I wonder if the phrase "without the
necessity of a Dynamic Host Configuration Protocol (DHCP) server" is really
necessary?  Is the sole purpose of stateless address autoconfiguration to
avoid the menace of DHCP, or does stateless address autoconfiguration avoid
manual configuration, as well?  How about "Nodes use IPv6 stateless address
autoconfiguration generate addresses using a combination of locally
available information and information advertised by routers." (borrowed from
RFC 2462)?

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2004 16:05:03 +0200

Pekka Savola wrote:
...
> should not be enabled by default for ULAs.

Certainly not by default; the default IID for ULAs is whatever it is
for any other native IPv6 address. Actually, it will be a matter of
corporate IT policy what IIDs are used within an enterprise network.
As draft-vandevelde-v6ops-nap-00.txt discusses, privacy addresses
will be useful in enterprise networks for use with global prefixes,
but there is no obvious need to use them with ULA prefixes.

But I don't find anything in draft-ietf-ipv6-privacy-addrs-v2-00
that makes privacy addresses a default, unless the implementer
happens to make that a configuration choice, which isn't the
IETF's decision.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 18:06:43 +0300 (EEST)

> statement about lawful intercept still being possible?

It doesn't need to be about lawful intercept, but I'd add something 
about the power of being on the path, maybe like:

                                   However, note that such on the path 
       attacks are likely able to perform significant correlation 
       even with RFC 3041 addresses especially if the payloads are not 
       encrypted.

> ALL types of global addresses (including the ULA). 

Yes, it's not default -- but what I want to have is being able to 
distinguish between "enabling privacy for all prefixes" and "enabling 
privacy for global range prefixes".

I.e., the implementations, when privacy is enabled, should not start
using privacy extensions by default for ULA addresses, but doing so
might be configurable.

I think that would be in line with most ULA users' goals.. too bad 
it's relatively difficult to unambugously say what those global, 
non-ULA addresses should be called..

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 18:59:57 +0300 (EEST)

> I disagree with the wording of this section regarding the use of DHCPv6 for

I thought you would, it was just a question when ;-)

> on the specific implementation rather than the protocol itself.

The statement was referring to the changing the permanent addresses 
regularly to avoid giving out stable identifiers.
 
>     can be adjusted as required.

I think this misses the main point.  The text seems to be saying, "if
you want privacy, DHCPv6 allocating public + privacy addresses
provides you a way to do that", but there is no fundamental reason why 
to use DHCPv6 for that.

Certainly it wouldn't make sense to deploy DHCPv6 privacy address 
assignment (if public ones are done with SLAAC), right?

So, I think the tone of text should be something like:

 "If DHCPv6 is already used for address assignment, it makes sense to
use DHCPv6 for privacy address assignment as well especially if SLAAC
is not used at all; if not, using RFC 3041(bis) for privacy addresses
makes much more sense"

> available information and information advertised by routers." (borrowed from

No objections from me, even though I don't think that's an issue one
way or the other.  "Menace of DHCP" for address assignment may or may
not be an issue.  Beyond that, whether or not DHCP server (e.g., for
info requests) exists is irrelevant.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Oct 2004 14:54:11 -0400 (EDT)

Hi Pekka,
  Please see comments inline.

Thanks
Suresh

>       even with RFC 3041 addresses especially if the payloads are not 

I would rather state something like this

"However, note that an attacker, who is on path, may be able to
 perform significant correlation based on the payloads of the packets
 on the wire. Use of temporary addresses will not prevent such payload
 based correlation"

This clearly indicates that the correlation is done using data present 
in the payload. Is this text acceptable to you?

>non-ULA addresses should be called..

One way to go about this will be to attach a disable flag for specific 
prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the 
global enable setting if present for the fc00::/7 range.

I will add the following text after the first paragraph of 
"Deployment Considerations"

"Additionally, sites might wish to disable the use of temporary 
 addresses for some prefixes while still using them for other global 
 prefixes. For example, a site might wish to disable temporary address 
 generation for "Unique local" [ULA] prefixes while still generating
 temporary addresses for all other global prefixes.To support this behavior,
 implementations MAY provide a way  to disable generation of temporary
 addresses for specific prefix subranges. This setting, if present, 
 MUST override the global settings on the node with respect to the
 specified prefix subranges."

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Oct 2004 07:49:59 +0300 (EEST)

> in the payload. Is this text acceptable to you?

That's fine.

>  specified prefix subranges."

I'm slightly unconformtable with this approach for a couple of
reasons.  First, by default, privacy addresses are generated for ULAs
as well.  Second, such a flag is just a MAY.

What I'd propose is specify that ULAs SHOULD be excluded by default
when privacy addresses are enabled, but that there MAY [or SHOULD] be 
a flag to enable privacy addresses for ULAs.

Would that be reasonable?

Note that this will create a dependency on ULA spec(s) becoming RFC
before this one does (so that the IANA assigns the prefix range), but
that might not be a problem, as AFAIR they're relatively far in the
process.  There's no need for normative reference as we want just to
know the prefix(es).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2004 16:27:48 +0200

Suggestion at the end...

> process.  There's no need for normative reference as we want just to

I think it would be better to RECOMMEND that an implementation should
support netmasks for privacy addresses to be enabled, e.g. enable
them for 2001::/16 and 2002::/16 only, else disable. Then you don't
have to call out ULAs at all.

     Brian

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Oct 2004 11:12:22 -0400

> > in the payload. Is this text acceptable to you?

I would also mention packet sizes and timing in addition to payload
content.  My understanding is that you can recover a surprising amount
of useful information without even looking at the payloads.