Subject: Node Requirements: Issue 14 - Privacy Extensions

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Jul 2009 10:34:45 -0400

The document currently says:

>    5.7.3.  Privacy Extensions for Address Configuration in IPv6 - RFC 4941
> 
>    Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
>    SHOULD be supported.  It is recommended that this behavior be
>    configurable on a connection basis within each application when
>    available.  It is noted that a number of applications do not work
>    with addresses generated with this method, while other applications
>    work quite well with them.

IMO, additional context is needed. As 4941 itself states, RFC 4941 is
only useful for mobile devices -- devices that actually move around
within the network. Servers generally do not do that. Plus, servers
are by definition visible (so folk can access them). Thus, in the case
of servers, a blanket SHOULD is not appropriate. I'd like to propose
the following replacement text:

   Privacy Extensions for Stateless Address Autoconfiguration
   [RFC4941] addresses a specific problem involving a mobile device
   that regularly changes its point of attachment to the
   Internet. When using Stateless Address Autoconfiguration [RFC
   4862], the Interface Identifier portion of formed addresses stays
   constant and is globally unique. Thus, although a node's global
   IPv6 address will change as it changes its point of attachment, the
   Interface Identifier portion of those addresses remain the same,
   making it possible for servers to track the location of an
   individual device as it moves around. This may raise privacy
   concerns as described in [RFC 4862].

   That said, the problem addressed by Privacy Extensions only happen
   when a device regularly changes its point of attachment (i.e., for
   mobile devices) and where the mobile device is associated with a
   single (or small number) of users In such sitatuations, privacy may
   be a concern and RFC4941 SHOULD be implemented. In other cases,
   RFC4941 provides limited or no benefit. In particular, RFC4941
   provide little benefit to servers.
   
Note also that I propose dropping:

   It is recommended that this behavior be configurable on a
   connection basis within each application when available.  It is
   noted that a number of applications do not work with addresses
   generated with this method, while other applications work quite
   well with them.

The above recommendation is not in RFC 4941, and I do not believe it
is appropriate for an AS to be adding a requirement that 4941 itself
does not mention.

Comments?

Thomas

---

From: <[email-masked]>
Date: Sat, 25 Jul 2009 07:54:13 +0200

Thomas,

I don't think that client / server functionality are so well defined in most of the IPv6 RFCs, but are more of the node / router functional split.  I think giving some additional information about how a particular node is used is good - but at the end of the day, most of the node functionality will be delivered in terms of an OS, where the client / server functionality split is really not important, IMO.

Additionally, in an IPv6-world, my hope is that things will be a bit more interesting in terms of the roles of IPv6 nodes.  As you might know, we have made a port of the Apache web server to mobile phones, and have that in trial (using IPv4).  We use DDNS to manage connectivity to the server.  In an IPv6 world, we definitely would like to use privacy extentions, as we do not consider that the mobile web server should be accessed by everyone, but would want to use some level of authentication for clients connecting to the webserver. 

In summary, I am not sure if this paragraph:

makes sense, I would prefer dropping this paragraph.  
 
About this paragraph:

I remember during discussions that some people were worried that not all applications would work with privacy extensions.  Maybe it makes sense to remove the requirement, but adjust it so that it provides a bit more information, something like:

   It is
   noted that a number of applications do not work with addresses
   generated with this method, while other applications work quite
   well with them. One should consider how applications might use
   addresses generated with this mechanism.

-- or something like that.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Thomas Narten
Sent: Friday, July 24, 2009 10:35 AM
To: [email-masked]
Subject: Node Requirements: Issue 14 - Privacy Extensions

>    work quite well with them.

IMO, additional context is needed. As 4941 itself states, RFC 4941 is only useful for mobile devices -- devices that actually move around within the network. Servers generally do not do that. Plus, servers are by definition visible (so folk can access them). Thus, in the case of servers, a blanket SHOULD is not appropriate. I'd like to propose the following replacement text:

   

The above recommendation is not in RFC 4941, and I do not believe it is appropriate for an AS to be adding a requirement that 4941 itself does not mention.

Comments?

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

---

From: Hongyu Li <[email-masked]>
Date: Sat, 25 Jul 2009 15:16:52 +0800

It would be a helpful reminder for AS if we keep the second sentence:

 It is
>    generated with this method, while other applications work quite

Hongyu

=================================
> The above recommendation is not in RFC 4941, and I do not 
> believe it is appropriate for an AS to be adding a 
> requirement that 4941 itself does not mention.
> 
> Comments?
> 
> Thomas

---

From: Tim Chown <[email-masked]>
Date: Sat, 25 Jul 2009 08:23:03 +0100

On Sat, Jul 25, 2009 at 07:54:13AM +0200, [email-masked] wrote:

> Additionally, in an IPv6-world, my hope is that things will be a bit more
> interesting in terms of the roles of IPv6 nodes.  As you might know, we have
> made a port of the Apache web server to mobile phones, and have that in trial  
> (using IPv4).  We use DDNS to manage connectivity to the server.  In an IPv6   
> world, we definitely would like to use privacy extentions, as we do not
> consider that the mobile web server should be accessed by everyone, but would
> want to use some level of authentication for clients connecting to the
> webserver.

The suggestion to use 'rolling' IP addresses for 'servers' was included in
early drafts of RFC 5157, but it was removed because it was deemed out of
scope at the time.   The suggestion was made in the context of static 
systems, but the above use case seems quite valid to me.   

The property we've implicitly had for Privacy Addresses in general is that 
nodes have a static global address listed in DNS that they can be reached 
by, but may use Privacy Address(es) when acting as initiators/clients, and
those Privacy Address(es) are not listed in the DNS.   

> makes sense, I would prefer dropping this paragraph.  

I think the notion that Privacy Extensions are only useful for mobile
nodes is somewhat limiting.   e.g. in RFC4864 the use of Privacy Addresses 
is discussed for static nodes in the context of making it harder for nodes
to be profiled over time.    
  
>    addresses generated with this mechanism.

There are certainly some application uses (we first ran into these with 
certain conferencing tools in 6NET) and there are also significant 
implications for network management (tying IPs to specific nodes over 
time, use of ACLs etc).

However my feeling about the node requirements text is that we should be
defining what priorities we put on capability, not advocating whether that 
capability should be used or not in certain cases.   

In that sense having the use of Privacy Addresses configurable on a per
application basis is desirable, but to include that requirement in an
Informational document when no API exists(or does it?) may be rather
premature? (But something the wg should look at)

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2009 09:55:26 +1200

> makes sense, I would prefer dropping this paragraph.  

Privacy addresses are supposed to have quite short lifetimes and
to change quite often. I don't see any way that can be useful for
servers, whether fixed or mobile. A server could certainly be configured
with a pseudo-random IID but it needs to be a static value. A server
could, I suppose, use the RFC4941 algorithm to generate an IID but
then use an infinite lifetime for it. However, as far as I can see,
RFC4941 only allows finite lifetimes (unless you ignore the first
SHOULD in section 3.5).

It seems to me that this is not an intended use of RFC4941. That's
not to say it's wrong in any way, and we could make this issue go away
in the present document simply by deleting the last sentence in
the above quote.

However, I disagree with the assertion that 4941 is only of interest
for mobile devices. I think it can be equally relevant to fixed client
devices, in any situation where the user may be concerned about Big
Brother watching. That suggests a rewrite of both of the proposed
new paragraphs:

   Privacy Extensions for Stateless Address Autoconfiguration
   [RFC4941] addresses a specific problem involving a client device
   whose user is concerned about its activity or location being
   tracked. The problem arises both for a static client and for
   one that regularly changes its point of attachment to the
   Internet. When using Stateless Address Autoconfiguration [RFC
   4862], the Interface Identifier portion of formed addresses stays
   constant and is globally unique. Thus, although a node's global
   IPv6 address will change if it changes its point of attachment, the
   Interface Identifier portion of those addresses remain the same,
   making it possible for servers to track the location of an
   individual device as it moves around, or its pattern of activity
   if it remains in one place. This may raise privacy concerns as
   described in [RFC 4862].

   In such situations, RFC4941 SHOULD be implemented. In other cases,
   RFC4941 provides limited or no benefit.

>    addresses generated with this mechanism.

I think that's too vague to be useful. This document is addressed to a
stack implementor and the "configurable" recommendation can in theory
be implemented, whereas "one should consider" can't be turned into a
product requirement. I think Thomas is right to drop it until we have
an actual spec of what it would mean.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Jul 2009 14:06:45 -0400

To clarify, my usage of the word "server" was meant to cover "server
only" devices, i.e., ones that don't have individual users using them
to initiate activities like web surfing.

Think rack mounted servers, storage devices, content servers,
etc. There is an entire industry surrounding those platforms, and a
key point is that many applications and protocols that apply to client
devices (e.g., laptops, cell phones, PDAs, etc.) just aren't relevant
to such servers.

I fully agree that there are general purpose operating systems that
can support both client systems or servers (e.g., linux, windows,
etc.). But there are also appliances and other devices that are not
intended for use as client devices by individual users.

Those types of devices do not need to implement Privacy Extensions.

That said, I generally like Brian's proposed text:

> That suggests a rewrite of both of the proposed
> new paragraphs:

>    RFC4941 provides limited or no benefit.

One possible tweak on the last sentence, how about:

     In such situations, RFC4941 SHOULD be implemented. In other
     cases, such as with standalone servers, RFC4941 provides limited
     or no benefit.

> >    generated with this method, while other applications work quite

More to the point, there was (at the time) and (probably) still is
today some controversy as to whether the above statement is actually
correct. There have certainly been anectdotes to the effect that
privacy addresses don't work well in some cases (because they aren't
in the DNS properly), but I am also quite sure that the reverse DNS is
not well populated generally, so its unclear how real an issue that is
in practice. (For example, those of you that travel a lot will likely
find that often the "local" hotel address you are given is not in the
DNS.)

Just to give an indication of how controversial the "requirement" that
addresses be in the reverse DNS is, consider the dnsop document:

http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07

It is expired presumably because the WG could not really reach
agreeement on what to do with it. I recall they had many discussions
about whether the document was needed or whether it solved a non
problem...

Thomas

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Jul 2009 23:24:15 +0100

> That said, I generally like Brian's proposed text:

I agree.
 
>      cases, such as with standalone servers, RFC4941 provides limited

How about - to avoid the 'server' terminology turning it around to say:

      In such situations, RFC4941 SHOULD be implemented.  However, if
      the node is not expected to initiate connections, or the potential
      tracking or correlation over time of such connections is not a
      concern, RFC4941 provides limited or no benefit.
  
> find that often the "local" hotel address you are given is not in the

It's not just reverse DNS issues.   For example I recall a videoconferencing
app that used multiple connections initiated in different directions between
two participating hosts.   Between v4 hosts the code assumed a single global
address was used between peers, and that worked, but when ported to support 
v6 it failed due to attempts to connect back to the observed privacy address 
of the remote peer failing because a firewall hole only existed to talk to 
the peer's 'static' global v6 address.  I suspect similar 'referal' issues
may happen in other cases.

-- 
Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jul 2009 11:58:21 +1200

I'm very happy with Thomas' tweak to my tweak to his words.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 Jul 2009 11:32:13 +0000

The problem is that the usage of the word "server" is not defined in the
document.  I'd prefer to not use the word "server" at all, but instead
say what you mean... "devices that never initiate communication".
"server" means other things to other people and we don't want to
confuse people.

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Tuesday, July 28, 2009 8:07 PM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked]
> Subject: Re: Node Requirements: Issue 14 - Privacy Extensions
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 29 Jul 2009 11:33:29 +0000

Tim's wording is better but still uses the word
"connections" which implies TCP to many readers, and hence
I prefer "communication".

> Tim Chown
> Sent: Wednesday, July 29, 2009 12:24 AM
> To: Thomas Narten
> Cc: [email-masked]; [email-masked]; Brian E Carpenter
> cases,

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 Jul 2009 16:12:03 +0100

That would be better, I agree.

--
Tim

On 29 Jul 2009, at 12:33, Dave Thaler <[email-masked]> wrote:

>> of the remote peer failing because a firewall hole only existed to  
>> talk
>> to

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Jul 2009 13:38:54 -0400

> "server" means other things to other people and we don't want to

Agreed that server is not well defined...

But, all devices initiate communication, even servers. I.e., the web
server may well initiate lots of connections with other entities in a
data center (e.g., file server), or even to external sites as part of
fulfilling a request. So just saying "initiating communication" isn't
enough either.

The key aspect for where Privacy Extensions provide value is where

1) the device initiates connections, and

2) servers that are the targets of those connections (or other
   monitoring devices that see the connections) use them to correlate
   activity associated with that connection with previous activities
   from previous connections from the same device (usually, hours,
   days or weeks earlier), and

3) those activities can also be traced back to a single (or very small
   group of) end users. (i.e, typically if the device has only a
   single user).

Hence, for "clients" (i.e., single-user systems, or any system where
the user's keyboard connects), Privacy Extensions have value.

But for what I normally think of a stand-aline server (not a client
device), there is very limited, if any benefit.

Also, for static clients (those that don't move), the benefits of
Privacy Extensions are open to debate. For a home DSL (or cable) user,
the /64 they have remains constant. So you can correlate activity just
via the /64 and get a pretty good approximation. Privacy Extensions
have some benefit here, but just how much is up for debate.

That said, I'm not sure right off how to capture all the above without
making the reader's eyes glaze over.

I was trying to use "standalone server" to describe a device that is
exclusively a server, and not a client device that (possibly) serves
in a dual role of having providing both server and client servics.

Thomas