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

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

I guess this is largely tangential.

Please tell me if you think we're going too far for on-list.

Erik Nordmark wrote:
> 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?

I think primarily this is the case which would be applicable to DNA.


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


Yes, that's certainly the case.  when the user communities are small,
it's fairly hard to hide movement from traffic analysis.

On the other hand, one of the things to come out of the MoMiPriv
list (and MobileIP based privacy work), is that there's a requirement
for privacy analysis with each of the protocols used when attempting
to maintain privacy.

So the Application layers, ESP, IKE, MIPv6, DNAv6, and 802.1X etc.
all have a role to play in maintaining dissociation between particular
locations and identities (or movements across network boundaries).

Certain of this information may not be possible to hide from AAA or
Home Agents for example.  I guess though, that there's an interest in
the longer term to make communications casually untraceable.

Some of this may require protocol re-engineering, although it may be
possible to make some "Privacy Considerations", if we're aware of the
basic problems around specification time.

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

Definitiely, I agree.  The distinction is also a good one.

It would be good though to have flexibility in DNAv6,
to avoid passing out identifiers if a host doesn't explicitly
need to.

If we need to have a look at these issues in depth, there's likely to
be work in Mobopts and MIP6, as well as on a couple of existing lists
such as MoMiPriv.

Some of the assumptions under which the discussions have been operating
may be directly applicable to DNA.  (So we may not have to develop them
ourselves... I'll have a look at these if I have time soon).

Greg