Subject: Re: [Momipriv] RE: [Mobopts] Re: [Mip6] Privacy requirements for Mobile IPv6

From: Greg Daley <[email-masked]>
Date: Wed, 16 Mar 2005 14:31:35 +0000 (GMT)

Hi Wassim,

----- Original Message -----
From: Wassim Haddad <[email-masked]>
Date: Wednesday, March 16, 2005 3:12 am
Subject: Re: [Momipriv] RE: [Mobopts] Re: [Mip6] Privacy requirements
for Mobile IPv6
[chop]
> => IMHO, having a good idea of what we intend to solve is enough to 
> startthe work. IMHO, this is well described in the momipriv problem 
> statementdraft (I mean *all* the draft :)

 :)

> > I think that no set of L2 addresses can outlast
> > any L3 address.
> 
> => IMHO, the same statement applies to L3 addresses regarding L2
> addresses.

Well, the relationship isn't reflexive.

I'll talk about this below.
 
> > This is necessary to prevent psudonymity detection as follows:
> >
> >        L3ID1               L3ID2          L3ID3
> > |-------------------|-------------------|------> T
> >
> > L2ID1   L2ID2  L2ID3   L2ID4  L2ID5 L2ID6  L2ID7
> > |----|---------|----|---------|----|----|------> T
> 
> 
> => IMHO, the above scheme can break the unlinkability:
> if I manage to link L2ID1 (and L3ID1) to you then how L2ID2 and 
> L2ID3 can
> help you?
> 
> > In this case, as the L3 ID changes, no residual
> > L2 ID remains to divulge the connection between
> > L3IDn and L3IDn+1.
> 
> => Agree. But it would be better to have in this case (L3ID1, L2ID1)
> switches to (L3ID2, L2ID2) then to (L3ID3, L2ID3), ... in order to 
> achieveanonymity, which in turn implicitely provides the 
> unlinkability feature.
> 
> BUT:
> ---
> 
> - how frequent such change should occur?
> - what are the critical states where such change becomes a MUST?
> - Impact (if any) of the type of application(s) on the lifetime of the
> pseudo-IDs?
> - How the user can control the above?
> - If the other end wants also anonymity, should we have 
> synchronisationbewteen both endpoints regarding the pseudo-IDs 
> updates?

These are appropriate questions.  

I'll tackle the point from above and return to them.

Previously when I said the lifetime of the combined set of
L2IDs mapped to an L3ID could not exist longer than the 
lifetime of the L3ID, this was a requirement, not necessarily
the most efficient way to use L2IDs (in terms of reconfiguration).

Thus the lifetime of an L2ID could be as long as the L3ID (or
exist on all the same links as L3ID, which may be very slightly
longer), but may not exist on any other links.  This matches 
what you said before.

So both multiple L2IDs per L3ID or a single L2ID per L3ID may exist.

In some scenarios it's going to be difficult to tell if the link
is the same one you were on before.   In these links to preserve
the untraceability feature it's going to be necessary to try
a different L2ID (and L3ID) while checking for DNA.

Where L3 based DNA isn't required they could end up only changing
when the L2 changes.

> > Here's what we don't want:
> >
> >        L3ID1               L3ID2          L3ID3
> > |-------------------|-------------------|------> T
> >
> > L2ID1   L2ID2    L2ID3     L2ID4   L2ID5  L2ID6
> > |----|---------|--------|---------|-----|------> T
> >
> > Here L2ID3 is visible as connecting L3ID1 and
> > L3ID2.  This level of connection is what needs to
> > be avoided.
> 
> => Agree.
> 
> > This does not mean that the mechanisms need to
> > be done together, just that the lifetimes of
> > L2 identities need to be bounded by the
> > upper layer.
> 
> => IMHO, if we want to achieve anonymity then the two pseudo-IDs must
> change _AT THE SAME TIME_.

must is such a strong word.

Both IDs may change at the same time, and that will work OK.

There are drawbacks and costs in some scenarios, such as the
DNA scenario mentioned before.  In that case BU would have to
be sent with every L2 cell change.

I'm not saying this is the case in all situations, but
the requirement is not strictly for simultaneous change,
rather the 'must' is tied to the L2IDs not
leaking across boundaries where an L3ID isn't valid anymore.

Greg

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 17 Mar 2005 10:44:31 -0500

Hi Greg,

> Well, the relationship isn't reflexive.

=> IMHO, the relation should be reflexive if you want real anonymity. 
Otherwise,
you'll get no advantage in return (I am not saying that you cannot do 
it).

> the most efficient way to use L2IDs (in terms of reconfiguration).

=> My concern is that while you can change your L2IDs during one L3ID
lifetime, you get nothing in return. We have described this scenario in 
the
threat model draft when we applied it  to the MAC layer. Such scenario
breaks the *unlinkability* (as defined in the problem statement draft 
section
2 - page 4) since you will be always identified via your L3ID.

> a different L2ID (and L3ID) while checking for DNA.

=> OK. But how you achieve "untraceability" while keeping the same
IP address? (Consider the case where you have _many_ bad guys
located in different places in a public WLAN).

Regards,

Wassim H.