Subject: RE: Advantages and disadvantages of using CB64 type of identifiers

From: "Christian Huitema" <[email-masked]>
Date: Sun, 4 Jul 2004 23:12:04 -0700

> i don't fully understand why do you think that having an identifier in
> the address is worse than current IPv4 situation (where the id and
> locator are one, and multihomed sites have a single address) or the
> current IPv6 situation (i guess that something similar to privacy
> extensions could be achieved by periodically creating new keys hence
> new identifiers)

First, I don't believe in arguments such as "this is not worse than what
we did in the past" when it comes to security and privacy. We should be
on a path to improvement, not a soft descent into complacency. Second,
having a unique 64 bit identifier in the addresses is actually worse
than the current situation in either IPv4 or IPv6. 

In IPv4, the addresses are often dynamically affected; it is possible,
if a site manager so chooses, to give nodes a different address at each
session. Hosts using dial-up connections receive new addresses for each
connection. Hosts using broadband connections often receive new
addresses every 24 hours. When a host is multi-homed to several
networks, it will indeed receive different IPv4 addresses on each of
these networks.

The current IPv6 practice is to have the 64 bit identifier be either an
IEEE 802 identifier (default) or a random number (temporary addresses,
SEND). When a host is multi-homed through several interfaces, the
different identifiers are used on different interfaces. When a host
configures addresses from multiple prefixes on the same interface, the
802 identifier will often be the same, but the random identifiers will
be different. The current ND spec allows for using the same identifier
with different prefixes, but it certainly does not mandate it.

-- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Jul 2004 09:33:00 +0300

> than the current situation in either IPv4 or IPv6. 

Agreed.

> with different prefixes, but it certainly does not mandate it.

Right. I believe "does not mandate same interface identifier" part
should be our guideline in multi6 too.

(I think we heard an argument here a while back that while
privacy is good to have, it should not be mandatory and managers
should be able to choose whether they use the same or different
interface identifier. But on the other hand, if we choose a multi6
mechanism that mandates the same interface ID to be used, then
that choice is taken away from the managers: they can either
give up multihoming or privacy.)

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jul 2004 10:31:08 +0200

Jari Arkko wrote:
...
>  But on the other hand, if we choose a multi6

Let's be clear that all they are giving up is the small amount of
privacy that is optionally available in IPv6 by using temporary
values in the IID. They are not giving up privacy in any general
sense, which is mainly an applications layer issue.

We have to be very careful about this to avoid any risk of
misinformed urban legends about multi6 and privacy.

If multi6, for example, extends the scope of a temporary IID
from one to several interfaces or even from one to several sessions,
we don't have a privacy problem. If it *only* works with an Ethernet-
derived IID, we might have a problem.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 5 Jul 2004 10:36:58 +0200

On 5-jul-04, at 8:12, Christian Huitema wrote:

> In IPv4, the addresses are often dynamically affected;

Don't forget we're talking about SITE multihoming. Current multihoming 
requires registration in various whois databases. I don't see how 
something equivalent for a multi6 solution would be problematic.

> When a host
> be different.

This is true for SEND, but not necessarily so for RFC 3041. The only 
implementation of RFC 3041 that I've worked with (Windows XP) uses the 
same random identifier for all advertised prefixes.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 5 Jul 2004 15:26:33 +0200

El 05/07/2004, a las 8:12, Christian Huitema escribió:

> on a path to improvement, not a soft descent into complacency.

imho it is not the goal of multi6 to improve current security.
i do agree that if it is possible to provide an enhanced security, it 
would be nice.
But i don't see the fact that a solution does not improve current 
security as a compelling argument to discard a solution

>  Second,

> with different prefixes, but it certainly does not mandate it.

Do you think that generating a new identifier every day would do the 
trick?

i mean it would be possible, as Erik mentions, to create a new crypto 
based id every day, i guess

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jul 2004 17:25:45 +0200

>> on a path to improvement, not a soft descent into complacency.

If we were on that track, we would not have just adopted the threats
draft as a WG document.

> imho it is not the goal of multi6 to improve current security.

Our baseline is "first do no harm", i.e. not create new exposures.

> security as a compelling argument to discard a solution

It isn't, but demonstrating that there are no new exposures is
proving a negative, which is always hard work.

>> than the current situation in either IPv4 or IPv6.

For people who believe that such a thing is a privacy issue, yes.
But it may or may not be a security issue - that requires threat
analysis of a specific solution.

> Do you think that generating a new identifier every day would do the trick?

It depends what trick you think is needed. If you mean: defeating some
spyware that tracks usage of a given IID, then presumably yes. But if you
are talking about a specific security attack (for example replay) - I don't
know in the abstract.

> based id every day, i guess

Or at whatever frequency you like... every DHCP refresh for example.

The question for us is whether such a mechanism would set bounds on
multihoming sessions. What happens to TCP sessions that live longer
than the IID?

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Jul 2004 10:35:49 -0700 (PDT)

> multihoming sessions. What happens to TCP sessions that live longer

A reasonable approach would be to apply the RFC 3041 way, but for
the identifiers instead of the addresses, that is an identifier
would become deprecated and not used for some outbound communication
at time T1, but packets to that identifier would be accepted until time T2 >>
T1.

If you want sessions that survive longer than T2 you'd need to
use an identifier that has longer stability.

Christian wrote:
> No, I don't think so. It would break correlation in time, but it would
> still enable correlation in space, as in "these two locators lead to the
> same location". That may or may not be a problem for *site* multihoming,
> but it definitely is a problem for *host* multihoming, e.g. a host with
> a WiFi and a GPRS connection.
> 
> Come to think of it, the only way to not disclose these relations to
> third parties is to (1) make sure that the identifier is not disclosed
> as part of the IPv6 address and (2) make sure that the identifier is
> only exchanged over an encrypted channel between the corresponding
> hosts.

I guess there is a difference between making the correlation discoverable
from a publicly available infrastructure (e.g., the DNS) and requiring
that the node, malicious or not, that wants to discover the correlation  
has to communicate with the host in question.
But in any case, to be able to prove to a peer that some communcation
can fail over to use different locators, the host will need to disclose 
the correlation between those locators to the peer.

I don't think we can argue that all peers with which a host communications
(based on URLs embedded in whatever web pages the host might access, for
instance for ad insertion) are uninterested in discovering such correlation.

So I don't see how you can have your cake an eat it too;
if the host doesn't want the correlation between its locator on WiFi and GPRS
to be discoverable then it must not enable multihoming support which allows
rehoming between those locators.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2004 23:47:02 +0200

> at time T1, but packets to that identifier would be accepted until 

Actually this is more an RFC 246x thing.

> the correlation between those locators to the peer.

:-)

Note that there are very different requirements for servers, clients 
and participants in peer-to-peer communication. I'm going to assume 
that there are few privacy issues for servers as they need to be known 
to do their job. For clients there are privacy issues but they don't 
need long-lived ids so it's not too bad. For peer-to-peer participants 
it's harder because they can't switch ids as easily.

Also, for clients it should be possible to hide any additional locators 
and just send over auth info. Then, if there is loss of connectivity, 
the client switches locators and says "hi, it's me, remember my hash 
chain?" or something similar.

Obviously this way it's still fairly trivial for an adversarial 
correspondent to find out additional locators.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 8 Jul 2004 11:58:39 -0700 (PDT)

> it's harder because they can't switch ids as easily.

Are you talking about clients, servers, and p2p participants as
different products that contain different protocol stacks (or
differently configured stacks) which make different assumptions?

I think there are *communication roles* called client, server,
and p2p participant, but the same application might play different roles
over time or depending on usage, so I don't see how a given protocol stack
can have different defaults unless that stack is bundled with a non-extensible
set of applications.
Thus, while the application that different roles have different requirements,
I don't see that being useful unless we think it makes sense to define APIs
by which an application is required to express its role or its requirements.

> chain?" or something similar.

That doesn't prevent the curious peer from discovering them by
pretending that locator the client is using is having a problem
(worst case the peer should be able to force this by just
dropping the packets from the client until the client
tries a different locator).

> correspondent to find out additional locators.

Yes.

So it isn't clear to me what problem we are actually trying to solve
in the privacy space.

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 Jul 2004 00:56:59 +0200

On 8-jul-04, at 20:58, Erik Nordmark wrote:

>> and participants in peer-to-peer communication.

> differently configured stacks) which make different assumptions?

I was thinking about systems running a single type of application. 
(Obviously the real world is more complex but we can backport that 
later when we have a better understanding of the issues.)

> can have different defaults unless that stack is bundled with a 
> non-extensible set of applications.

I'm certainly not arguing for different stacks. But I think it's 
possible that the three types of systems are configured with different 
identifiers or different constraints on the use of their identifiers.

> by which an application is required to express its role or its 

Are you saying we should treat applications as black boxes and be 
prepared to handle any combination of actions from all of them?

> tries a different locator).

Well, yes. But in this scenario the client hasn't committed to anything 
at session start, it may very well decide later that it doesn't want to 
reveal any information after all. For instance, the client may want to 
forego multihoming for shortlived, non-TLS or otherwise unimportant 
sessions.

But it seems trying to hide locators/identifiers is pretty much a dead 
end.

> So it isn't clear to me what problem we are actually trying to solve

That's what I asked Christian.

Iljitsch

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 9 Jul 2004 11:37:39 +0200

> So it isn't clear to me what problem we are actually trying to solve

Looking at a very cool presentation made by Alberto Escudero at the 
IPv6 cluster meeting, there is a definition of privacy rights as:

"1.The right to be left alone
  2.The right to decide: when, how, and to  what extent information 
about them is  communicated to others.
  3.The right to secrecy, anonymity and  solitude."

which it translates for mobile nodes as

"The capability of a mobile  node to conceal the  relation between  
location and personal  identifiable  information from third  parties 
while the user is  on the move."

(if you are interested, you can find the full presentation at the 
author's home page http://www.it.kth.se/~aep/)

So, i agree with Erik that there are three roles that an app can play:
- Server
- Client
- p2p participant

I guess that the privacy concerns don't apply to the server role, since 
it is the server's will to be publicly available, in order to be 
reachable by clients.

So, imho the clients may require some privacy features. Basically this 
means (trying to apply above definition) that a client may wish to 
conceal the act that it is the same client who performs different 
communications. That is, if a client contacts a given server, then this 
client may wish to conceal the fact that he is contacting the same 
server again, or another server. So, privacy in a client, for me is 
being capable of hiding that the same client have performed multiple 
communications with the same of different servers.

In the case of p2p participants, i guess that the main difference from 
the server case is that the p2p participant may not want to disclose 
its identity to everyone (assuming that a server is a public server). 
so in the case of a p2p participant it may behave in a hybrid mode, 
where it allows some nodes to be able to recognize it as the same of 
previous communications, while in other cases, it may which not to be 
recognized.

Now, imho, this goals don't impose that we have to have different 
identities for different interfaces, but that we need different 
identities for different communications.
The problem as usual, is how the wedge layer can find out which packets 
belong to which communication.

I guess that in the current arch, privacy extensions provide some 
support for this, and it is based on periodically changing the iid. i 
guess we could try to do the same

Now, just to mix things a bit more, how would a solution like NOID 
support the privacy requirements? Are the DNS times compatible with 
this requirement?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jul 2004 12:20:06 +0200

marcelo bagnulo braun wrote:

> Now, just to mix things a bit more, how would a solution 
 > like NOID support the privacy requirements? Are the DNS times
 > compatible with this requirement?

I'm not sure we have consensus that we even have a privacy goal,
except maybe the "do no harm" property compared to RFC 3041.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 9 Jul 2004 12:32:01 +0200

> I'm not sure we have consensus that we even have a privacy goal,

agree

> except maybe the "do no harm" property compared to RFC 3041.

i personally agree with this goal, and i was just wondering how this 
could be achieved by NOID like solutions

regards, marcelo

---

From: Jeff Williams <[email-masked]>
Date: Fri, 09 Jul 2004 06:32:32 -0700

Marcelo and all,

> > I'm not sure we have consensus that we even have a privacy goal,

  Whether there is a privacy goal or not, as much privacy that
can be achieved or realized should be effected.

> could be achieved by NOID like solutions

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Jul 2004 08:58:04 -0700 (PDT)

> except maybe the "do no harm" property compared to RFC 3041.

FWIW draft-ietf-multi6-multihoming-threats tries to capture that
level, with some additional words about the current state of
IP address privacy in IPv4 and IPv6.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Jul 2004 08:56:53 -0700 (PDT)

> belong to which communication.

That part is hard; mapping the communicating to the privacy requirements.

But it is also hard for the wedge leayer to know the beginning and end
of a session, which is also needed. For instance, an application session
might silently assume that multiple TCP connections (to the same peer, or
even to different peers) use the same IP address today to represent the host.
As a result, if such an application isn't modified for multihoming somehow,
it would assume that the same AID (application-visible identifier) is
representing the host for that set of connections.

But at the same time one might want to have different sessions (where
there isn't a need to present the same identifier to the peer)
explicitly use different identifiers for privacy reasons.

One can definitely create APIs by which the applications can express both
the privacy requirements for communication, and the set of communication
that must use the same identifier for the host.
But if we do that then the question is what the default settings should
be for (unmodified) applications which do not express anything using those
APIs.
Should we err on the side of privacy? Should we err on the side of
making as many unmodified applications as possible work by using the
same identifier all the time by default?

> support the privacy requirements? Are the DNS times compatible with 

draft-nordmark-multi6-noid-02 (which I submitted on Wed so it should be
in the I-D directory any day now) talks a bit more about this.
Briefly:
For a host to take advantage of itself (or its site) being multihomed
for rehoming, the host needs to have a FQDN and consistent forward and reverse
information for itself in the DNS.

For such a host to have multiple pseudonyms, this implies having multiple
FQDNs. (Such as host-2002-8192-56bb-9258-0-0-8192-5882.example.com i.e.
the FQDN doesn't have to provide any mnemonic meaning to a user.)

If the host doesn't need to take advantage of itself being multihomed,
but uses NOID to take advantage of the peer/server being multihomed,
then it doesn't need a FQDN. Hence it can have pseudonyms just using 
RFC 3041 temporary addresses.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Jul 2004 08:38:46 -0700 (PDT)

Yes.

If we can't do that we have to require application changes (or configuration
external to the applications) so that the stack can know what requirements
the applications have on the identifiers they use.

(Requring such application changes is quite different than for instance
suggesting that applications that do callbacks or referrals invoke some new
API or do something different to take *full advantage* of multihoming.)

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jul 2004 10:02:09 +0200

>>prepared to handle any combination of actions from all of them?

I hate to inject reality, but I think Erik is correct. Thousands of applications
believe that an address is an address is an address, and only see addresses
via the socket API. We have to accept that.

The good news about porting apps to IPv6 is that it is easy, if a little
boring, since no redesign is needed. Multi6 won't get deployed if it
breaks that property.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 Jul 2004 16:07:45 +0200

> representing the host for that set of connections.

Question: wouldn't this application also break when RFC3041 addresses 
are used? in particular when a new temporary address is used

> the FQDN doesn't have to provide any mnemonic meaning to a user.)

ok, but in order to support RFC3041 addresses the host would need to 
dynamically update the DNS (creating a new record for its new temporary 
addresses), right? this would imply that multihomed hosts will need to 
support Dyn DNs or something similar right?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2004 23:47:22 -0700 (PDT)

[Catching up after vacation]

> are used? in particular when a new temporary address is used

There are two related aspects for "identity comparison" and "callbacks".
For identity comparison i.e. when the responder wants to verify whether
multiple communications are from the same initiator, then RFC 3041 will
make this fail when the preferred lifetime expires for the old address
(1 day by default).
For callbacks, the use of RFC 3041 addresses will cause failure when the valid
lifetime expires for the original address (7 days by default).

But these time constants are quite different than e.g. using ephemeral IDs
where each transport connection might use a different ID.

> support Dyn DNs or something similar right?

If you're using NOID-style DNS-based verification and want to take
advantage of multihoming of the host's site, and at the same time use 
RFC 3041 address, then
yes - the host needs to be able to update its forward DNS zone and create
the reverse DNS entries somehow.

  Erik