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

From: Sathya Narayanan <[email-masked]>
Date: Thu, 02 Jun 2005 00:04:31 -0400

Greg -

> > 
> >>Why doesn't it know? because without the landmark you can't tell 
> that it's DNA capable.
> >>
> >>Fortunately, there are plenty of bits left in the RS header (32)
> >>which could be used to identify a DNA solicitation without divulging
> >>the last attached prefix of the host in a landmark option.
> > 
> > 
> > Yeah - we can do this. We just need to be aware that sending unicast-completeRA
> > at fastRA rate from all routers for every received RS message makes the
> > amplification effect more deadly.
> 
> It really depends on the tokens and how they're used.  If a token
> provides ABC (appropriate byte counting), then the transmission of
> a message with completeRA would diminish the number of RA messages to be sent.

Are you suggesting we change the token-bucket behavior to do ABC? I am not very comfortable with it - but I should think more about it.

> > 
> >>Please be aware that I personally consider location privacy to be a 'big issue'.
> > 
> > 
> > I don't understand this concern. When a IPv6 hosts transmits IPv6 packets on
> > the network wouldn't its IPv6 address become public immediately - or when it
> > responds to NS message for that matter - what information are you trying to
> > protect by not including a landmark option in the RS message. Please explain.
> 
> How about if I used a different MAC address and IPv6 address (+key?)
> to do DNA every time I got a link up indication?
> 
> If I was on the same link, I could go back to my existing identity.
> 
> This temporary identity couldn't be tied back to my existing identity.

Hmmmm - thats interesting. I understand. But, since the landmark is only the prefix and not the whole address, you are still not revealing your whole identity - isn't that enough? Or is there use-cases where you don't even want to reveal the prefix you are using? 

Even though the text suggests (with a MUST) in section 5.2.2 to select a prefix being used for its non-link-local address, it is not necessary to keep it as a MUST. We could relax that condition to a SHOULD - will that help with the privacy issue since the host could always chose a different prefix as the landmark.

- Sathya

---

From: Greg Daley <[email-masked]>
Date: Thu, 02 Jun 2005 14:25:08 +1000

Hi Sathya,

Sathya Narayanan wrote:
[cut]
> 
> Are you suggesting we change the token-bucket behavior to do ABC? I am not
 > very comfortable with it - but I should think more about it.

OK.

I was not suggesting we immediately adopt ABC, but if there's
a need to distinguish between RAs with content and those without,
I guess there's a potential way to do so.

RFC 3465 is only 10 pages and TCP's aim in ABC is similar
(self-pacing data into the network, where packet sizes vary),
so it should be possible to evaluate its applicability to DNA
if we need the distinction.

> Hmmmm - thats interesting. I understand. But, since the landmark is only the prefix
 > and not the whole address, you are still not revealing your whole 
identity -
 > isn't that enough? Or is there use-cases where you don't even want to 
reveal
> the prefix you are using? 

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.

> Even though the text suggests (with a MUST) in section 5.2.2 to select a
 > prefix being used for its non-link-local address, it is not necessary to
 > keep it as a MUST. We could relax that condition to a SHOULD - will that
 > help with the privacy issue since the host could always chose a different
 > prefix as the landmark.

Yes, that would help too.

If there's a need to distinguish DNA and non DNA hosts, we'd still need
either a DNA bit in the RS or a landmark.

If a host wanted a high likelihood NO, and still to be able to
(without SEND nonces) it could even craft a nonsense landmark,
this would remove the need for the bit.

I'm not sure if that would be necessary though.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 03 Jun 2005 10:55:07 -0700

> 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

---

From: Greg Daley <[email-masked]>
Date: Mon, 06 Jun 2005 16:48:31 +1000

Hi Erik,

I guess this is largely tangential.

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

> attacker can correlate the packets seen from the host on link 1 and on 

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

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

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.

> 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