Re: [DNA] No FastRA unlessLandmark?(draft-pentland-dna-protocol-00)

[Erik Nordmark <erik.nordmark@sun.com>]

Greg Daley wrote:

> If the user community is small enough on the previous link,
> the timing of your last packet receptions combined with the
> prefix from that link can create a pseudo-identifier.
> 
> These pseudo-identifiers can be tracked across link boundaries,
> and can prevent movement and location-identity(if the identity was
> revealed on a previous or future link) privacy.

I guess I don't understand the problem you are trying to solve here, so 
that I can gauge what the current threat situations looks like without DNA.

Is the threat is that of an attacker which can simultaneously observe 
packets on both link 1 and link 2, and you are concerned that such an 
attacker can correlate the packets seen from the host on link 1 and on 
link 2?

Without DNA this can be easily accomplished by looking at the traffic 
patterns. For example, given TCP connection might attempt to continue 
with the same source port number and destination port/ip after the move, 
or the host might have done IKE+ESP to IP address 1.2.3.4 before the 
move and after the move the host restarts IKE to IP address 1.2.3.4 (the 
host's VPN gateway). If mobile IP is used then you'll see an ESP 
protected packet (with a size of a binding update) being sent to the 
same IP address as before (the host's HA); it might even have a Home 
address option in the clear. And for http in the clear, the fact that 
the host has RSS feeds from their favorite places will tell it apart.

So traffic analysis can do lots in this space when the movement is near 
instantaneous.

That is quite different than the threat of an attacker which saw 
Ethernet address X (and an IPv6 address with X as the IID) 2 months ago 
and again sees the same Ethernet address. In that case some traffic 
analysis might be helpful to the attacker even when the Ethernet address 
has changed, but the host's traffic patterns might have changed in the 
meantime.

So I suggest we define what privacy problems we think we need to 
address, and compare those with non-DNA related threats, before we start 
working on solutions to privacy issues.

   Erik