Subject: Comments on draft-ietf-ipngwg-addrconf-privacy-00.txt

From: Peter Tattam <[email-masked]>
Date: Fri, 15 Oct 1999 18:08:51 +1100 (EST)

Hi all.

Just weighing in on this topic, I have the following to say, and apologies if
it overlaps or has been said before. 

I believe I raised the topic several months ago, but nobody seemed to take much
notice, but I'm glad that the issues have now been discussed in more detail. 
Mind you there has been little outcome except
draft-ietf-ipngwg-addrconf-privacy-00.txt which I think answers the technical
issue elegantly. 

Given the current public concern over the privacy issue, I have decided that I
might improve our product by having an optional facility for the stack to
automatically change it's address using
draft-ietf-ipngwg-addrconf-privacy-00.txt. 

This raises a number of issues..

1.  How frequent should an address change be.  One could make the changes on a
regular basis, and still retain reasonable utilization of the stack.  I would
suggest making it user configuarable, but there may be some practical
limitations. It could potentially be as rapid as an address change per TCP
connection.

The issues to consider would be 

- what should be the minimum time between address changes

- what load on the network would be required. Presumably only one or
two ND exchanges, as well as the duplicate detection phase.  Maybe also some
dynamic DNS.  The address change could be scheduled to happen in advance if
necessary.

- how should the old addresses in the sequence be deprecated, presumably active
sockets should continue to work, but new connections should only use the new
address.  

- how long should we continue to respond to a deprecated address if there are
no active sockets bound to that address.

In all these areas, I presume there would be similar semantics to multihoming.

2.  With my ISP hat on, there might be significant security issues with
allowing this type of mechanism to be common place, and it also brings into the
spotlght address auto config even without the random address assignment.  It is
important for ISPs to track which user is one which address for accounting
reasons and also for security reasons.

From the accounting side, if an ISP can't tell which user is using which
address, some traffic might be untraceable.  Systems for logging traffic might
result in incorrect records, and there might also be implications for protocols
like RADIUS.

From the security side, an ISP must have the ability to locate and filter a
user based on IP address since a potentially hostile user may be mounting a
network attack, and often the only way of locating the user is by IP address.
Having a random component in the address could be problematic.

Having raised both of these ISP issues, I could debunk them by the comment that
in practice, a user might be identifiable by the top 64 bits of the address
anyway.  While this looks likely to be the case for PPP, I am not so sure for
other technologies like cable or xDSL.  If it was indeed the case, the top 64
bits of an IPv6 address would then degenerate into the situation we currently
have in IPv4 with privacy of addresses.

The issue of auto addr conf for IPv6 may also cause difficulties for
technologies that rely on strong binding between mac addresses and IP
addresses.  e.g. Cable & xDSL.  

How does the ISP deal with this?  Do they filter and account for IPv6 traffic
*only* matching the mac address of the customers equipment, or do they allow
willy nilly Ipv6 addresses using auto conf and track and account using the MAC
address on the wire which is only available at the connect point.

This hasn't been an issue in v4 because addresses are so scarce that the ISP
can dictate to the customer which Ipv4 address they must use.  Not so in IPv6.
Typically tools for logging are based on IP addresses which is usefule because
the logs can be applied at all parts of the network.  Having to do it by mac
address means that the logging would need to be done closer to the client which
might be impractical under some circumstances.

There is a counter argument that would imply that customers would need to be
protected from each other anyway.  Does this then imply that each customer
receives their own /64 presumably staticly configured at the ISP end possibily
defeating the whole purpose of address autoconfig.

Regards

Peter
--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Fri, 15 Oct 1999 09:59:07 -0700

At 2:48 AM +1100 10/16/99, Peter Tattam wrote:
> > Yep.  The addresses will identify the customer subnet, but not a specific
> > node within the subnet nor a specific user of a node.  If the customer
> > wants more privacy than that, they have the choice of using various kinds
> > of anonymizer approaches, such as application relays.  Maybe that would
> > be a useful service for an ISP to provide for its customers.
>
>Are you suggesting a NAT might solve the problem? :)

No.

> > Can you be more specific about the difficulties you imagine?
>
>Well, I was thinking of the case where the ISP would filter out addresses
>that didn't match the mac address that the IPv6 address was formed from.
>This might be important if different customers were sharing a subnet.
>Examples would be a shared cable modem segment where it would be important
>to protect customer traffic by preventing spoofing of neighbor's nodes.

Treating a cable segment as a subnet shared among multiple residential
customers seems like a bad idea to me, for a number of reasons.  I would
expect each residential customer to have a router (perhaps disguised as
a "set top box") between the cable and the home network(s), and the home
nodes would be attached to the home networks.  In that sensible
arrangement, the cable segment is a multi-access link interconnecting a
set of home routers with the head-end router, and each home is defended
from unscrupulous neighbors by its home router.  No need for anybody
to filter anything based on MAC addresses.

>Perhaps a clarification of what "customer" means may clear up the confusion. 
>Customer could be a complete subnet, but more typically in the domestic market
>would be a single node.  For ISP models that need to count bytes and packets
>for customer billing, if an individual node can't be tracked, there is a
>problem.

The single-node customer is just an (uninteresting?) special case, which
will become less dominant over time, as people move from having one PC at
home to having a network (or internetwork) of PCs and other devices at
home.  Those ISPs that feel the need to bill by byte or packet can do so
based on customer prefix -- whether one host sends two packets or two hosts
send one packet each, it's the same cost to the ISP.

>Having said that, one would hope that Ipv6 opens up a new sphere of internet by automatically providing all customers with at least a full /64 at their
>disposal.  Presumably this is one of the goals that auto address config
>attempts to achieve.

This is one of the goals of providing a bigger address space for IP.
It has nothing particularly to do with auto address config.

>In conclusion would it be fair to say that actual practice would imply a 1-1
>mapping between customer and prefix?

Yes.  (Well, actually, there might be a many-to-one mapping from prefixes
to customer, in the case of customers connected to multiple ISPs.)

>If so, the whole privacy argument is blown wide open again.

A "customer" in this discussion is not an individual, but rather a
collection of nodes operated and used by possibly many individuals,
e.g., all the members of a family or all the employees of a company.
So a customer prefix is not an identifier for a individual human being.

Steve

---

From: Peter Tattam <[email-masked]>
Date: Sat, 16 Oct 1999 04:21:17 +1100 (EST)

> customers seems like a bad idea to me, for a number of reasons.  

It happens.  I've heard stories of sites snooping neighbors traffic and even
breaking into shared drives on windows based machines.  Consider that the
margins are low for installing this stuff.  It might be plausible for a cable
provider to service as many clients off the one wire as possible without much
regard for security, and getting the cheapest deal on the client hardware
required.

> I would

Perhaps some more enlightened members of the list would be able to shed light
on what is current and best practice in the cable modem internet industry.  Are
these set top boxes really that smart?  

Peter

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Oct 1999 10:43:28 -0700

At 4:21 AM +1100 10/16/99, Peter Tattam wrote:
>breaking into shared drives on windows based machines.

Like I said, it's a bad idea.

>Consider that the margins are low for installing this stuff.  It might
>be plausible for a cable provider to service as many clients off the one
>wire as possible without much regard for security, and getting the cheapest
>deal on the client hardware required.

That just means the customers will have to install their own security,
e.g., by putting a router/firewall between the cable modem and their
home network.  Similar things are happening now, to deal with another
bad idea that the ISPs are fond of, that is, only assigning one IPv4
address per household (or charging more money for more than one address);
that's caused customers to deploy NAT boxes at home, and now we are
starting to see similar consumer-targeted devices, such as Apple's
combination wireless basestation/router/NAT thingy.  In the future, I
hope those devices can simply be IPv6 routers.

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Oct 1999 07:22:37 -0700

>draft-ietf-ipngwg-addrconf-privacy-00.txt.

Peter,

I think a better approach is to add the capability of *adding* additional,
"transient" addresses, rather than completely replacing the stable address
with a transient one.  More and more devices will be required to act both
as initiators of communication (for which a transient address if fine),
and as targets of communication initiated by others (for which a stable
address is needed).  It seems feasible and reasonable to have different
kinds of addresses (i.e., stable vs. transient) for those different
purposes.

>limitations. It could potentially be as rapid as an address change per TCP

I think the ideal would be per-TCP connection (or per-"session" for those
apps that have a notion of session that includes multiple TCP connections),
but we will probab;y want to be less aggressive than that in order to
avoid too much DAD overhead on the links.

>dynamic DNS.

Arggh!  No way the DNS should be dynamically updated to track these
transient addresses.  Since I think they ought to be used only when
acting as a "client" (initiator), they needn't have entries in the DNS.
Maybe for those silly servers that refuse to serve any clients for whom
a reverse mapping exists in the DNS, we need a DNS hack that will
fabricate and return a dummy name to any reverse look-up of addresses
within a given subrange of a customers address range (and will do the
complementary thing for a forward look-up of such a dummy name).

>no active sockets bound to that address.

If you buy my argument that the transient addresses are only for the
purpose of initiating communication, then it should be fine to forget
about a transient address as soon as all the local apps are finished
with it.

>anyway.

Or more generally, the customer is identified by whatever prefix was
assigned to that customer -- the typical prefix lengths would be 48
and 64.

> While this looks likely to be the case for PPP, I am not so sure for

>address on the wire which is only available at the connect point.

It's none of the ISP's business to track customer machines at the granularity
of individual nodes.  It ought to be enough for you to do whatever tracking
and accounting you need at the granularity of customer prefix.

>defeating the whole purpose of address autoconfig.

IPv6 autoconfig, currently, is for the purpose of assigning host addresses
within a subnet, not for assigning subnet prefixes within a site or
site prefixes within an NLA.  Yes, each customer should be receiving a
statically allocated /48 (or at the very least a /64); that static
allocation does not defeat the purpose of host address autoconfig
within those prefixes.

Steve

---

From: Peter Tattam <[email-masked]>
Date: Sat, 16 Oct 1999 02:48:49 +1100 (EST)

> kinds of addresses (i.e., stable vs. transient) for those different

In retrospect considering a future postings I made about having your cake and
eating it, I would tend to agree with you.  This would seem to be a useful
extension for the purpose of privacy.

> avoid too much DAD overhead on the links.

One could optimize the process by doing the DAD in advance.  i.e. keep so many
addresses in advance by interleaving with normal traffic.

> complementary thing for a forward look-up of such a dummy name).

This is what I meant when I was referring to "synthesizing" DNS records at the
meeting.  There is a subtle difference between synthesized DNS and real DNS,
although they look identical on the wire.

The issue of matching DNS names will become important when IPv6 is widely
deployed.  It is common to be locked out of certain services if your address
does not reverse.  Examples are SMTP servers doing spam prevention and certain
web sites.  Also, often when no reverse address mapping is present, web servers
have a tendency to stall while the DNS tries to resolve the address to a name.
This could be a performance issue when addresses are changing rapidly, and
could even cause a denial of service on a web server.

> about a transient address as soon as all the local apps are finished

My thoughts entirely.  One might envisage a stack only containing those
addresses for the duration of a TCP socket, and possible an unbounded number of
pseudo addresses potentially running simultaneoulsy on the host.  Heck we have
63 or so bits to play with :)

Now here's a bizarre thought....  one could arrange for *only* that TCP session
to respond to the transient address, it would be a pseudo extension of the srce
and dest port of the TCP session.  It could have the effect of fortifying the
TCP session somewhat.  Could this be a possible way of reducing certain types
of DoS attacks like RST attacks?

> Can you be more specific about the difficulties you imagine?

Well, I was thinking of the case where the ISP would filter out addresses that
didn't match the mac address that the IPv6 address was formed from.  This might
be important if different customers were sharing a subnet.  Examples would be a
shared cable modem segment where it would be important to protect customer
traffic by preventing spoofing of neighbor's nodes.

> and accounting you need at the granularity of customer prefix.

I would beg to differ.  While I don't have direct experience, Telstra Big Pond
Cable here in Aus tracks individual user's bandwidth and charges accordingly. 
I believe they currently use DHCP to dish out Ipv4 addresses.  If the user
could not be tracked by Ipv6 address, this would break their charging model
severely unless they allocated a /64 per customer for billing purposes.  This
could not work if several users are on the same logical subnet.

Having said that, one would hope that Ipv6 opens up a new sphere of internet by
automatically providing all customers with at least a full /64 at their
disposal.  Presumably this is one of the goals that auto address config
attempts to achieve.

> allocation does not defeat the purpose of host address autoconfig

I wasn't even prepared to go there... but you have raised the issue of yet
another layer of possible autoconfiguration :) 

In conclusion would it be fair to say that actual practice would imply a 1-1
mapping between customer and prefix?  If so, the whole privacy argument is
blown wide open again.

Peter

---

From: Jeff Williams <[email-masked]>
Date: Fri, 15 Oct 1999 15:00:43 +0100

Peter Steve and all,

> regard for security, and getting the cheapest deal on the client hardware

  It indeed has happened more times that the media has reported BTW.

> these set top boxes really that smart?

  Some are, yes.  But most aren't but can be made to be.

> Peter

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Jeff Williams <[email-masked]>
Date: Fri, 15 Oct 1999 14:01:45 +0100

Peter and all,

> draft-ietf-ipngwg-addrconf-privacy-00.txt which I think answers the technical

  Agreed and true that these issues were raised some months ago as I
believe I was the first on to raised them on this list anyway.  But it seems
still that they are not yet viewed by someone as being critical.  I of course
disagree with this for obvious business and technical reasons, not to
mention possible legal concerns that are bound to crop up if not
addressed before large scale deployment as it seems that MCI/SPRINT
and Vinton Cerf seems to be advocating.  It would also seem
from Scott Bradner's post yesterday, that he prefers a PR campaign
rather than a technical solution.  Not a wise move in my humble
opinion, FWIW.

> draft-ietf-ipngwg-addrconf-privacy-00.txt.

  Ok, this seems like a reasonable starting point approach at least.

> limitations. It could potentially be as rapid as an address change per TCP

  Ok I agree completely and this is what I suggested some months ago
essentially.  But it went ignored and a few opposed this just recently.
Per TCP connection should be adequate, unless you are doing multiple
TCP connections per connection.  ANd yes this should be user configurable
and also default in autoconfiguration.

> - what should be the minimum time between address changes

Per TCP connection or per change of connection within a session
should be adequate.

> dynamic DNS.  The address change could be scheduled to happen in advance if

  Exactly right.

> sockets should continue to work, but new connections should only use the new

  Ok this seems adequate in most instances.

> no active sockets bound to that address.

20 to 30msec.

> reasons and also for security reasons.

  I don't agree here.  Accounting can be done on the user him/herself not
on the IP assigned at connect time.

> result in incorrect records, and there might also be implications for protocols

  RADIUS can indeed handle this given some modification (Minimal)

Regards,