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

From: Greg Daley <[email-masked]>
Date: Mon, 14 Mar 2005 22:53:39 +0000 (GMT)

Hi Wassim, 

----- Original Message -----
From: Wassim Haddad <[email-masked]>
Date: Monday, March 14, 2005 9:32 pm
Subject: Re: [Momipriv] RE: [Mobopts] Re: [Mip6] Privacy requirements
for Mobile IPv6

> Hi Greg,
> 
> On Fri, 11 Mar 2005, Greg Daley wrote:
> 
> > Hi Wassim and Michael,
> >
> > ----- Original Message -----
> > From: Wassim Haddad <[email-masked]>
> > Date: Thursday, March 10, 2005 2:27 pm
> > Subject: [Momipriv] RE: [Mobopts] Re: [Mip6] Privacy requirements 
> for> Mobile IPv6
> >
> > > On Wed, 9 Mar 2005 [email-masked] wrote:
> > >
> > > > The cross protocol mechanism you mention has been identified 
> in the
> > > > 802.21 work as potentially useful. Yes, some tunnels/layers 
> end in
> > > > different stacks. The layers that "stack" together at the
> > > endpoints and
> > > > first point of attachment tend to be what are used to
> > > manage/influence> full path behavior.
> > > >
> > > > The privacy issue is one manifestation of a lack of cross 
> protocol> > > coordination.
> > >
> > > => I tend to agree. Achieving anonymity is mainly about managing
> > > pseudo-identities at different (i.e., concerned) layers. IMHO, 
> such> > management may be easier to perform via cross layer 
> coordination.>
> >
> > I guess I tend to think of things in an
> > All-or-nothing approach which would suit a
> > co-ordinated solution well.
> 
> => Two things:
> 
> - In the momipriv context, having coordination between layers is 
> not a
> feature/option . It is needed otherwise any privacy solution will 
> disclosean identity, which may in turn break the unlinkability 
> feature.

Agreed.

> - An All-or-nothing approach, which addresses all privacy issues is 
> toomuch complicated. IMHO, starting with the MAC and IP layers 
> (i.e., as
> described in the momipriv work) makes sense.
> The remaining issues and the privacy in the network can/should be
> addressed first in an IRTF WG.

I think we can at least establish a problem
statement or threat model in order to describe
the problem which is _not_ going to be solved.

Certainly the requirement to fix things is
at L3 here, and probably L2 elsewhere...

I do think that IRTF for the "whole of problem"
approach may be a good idea.
 
> > There's actually some value though, in
> > dealing strictly with L3 issues at L3.
> 
> => Please check the momipriv drafts.

It would have been nice if you were specific
as to which one, or which section... :)

I guess things are summarized in 3.4 of the
problem statement...

> > I'm not sure that IETF can do appropriate work
> > at L2, or the other way around for IEEE.
> 
> > The capabilities at lower layers may need careful
> > attention at L3 though, for example because
> > continued use of a particular MAC address beyond
> > the lifetime of an Private IP address can be used
> > to associate them.
> >
> > Therefore, I guess that determining needs for L2
> > from L3, or for L3 from L2 will need coordination,
> > without necessarily having one complete silution
> > including L2, L3(, L4??)
> 
> => Again: please check the momipriv drafts :)

You didn't really provide a lot of information
in your response!

OK.  Let's get down to nuts and bolts.

I think that no set of L2 addresses can outlast
any L3 address. This is necessary to prevent
psudonymity detection as follows:

       L3ID1               L3ID2          L3ID3
|-------------------|-------------------|------> T
 
L2ID1   L2ID2  L2ID3   L2ID4  L2ID5 L2ID6  L2ID7
|----|---------|----|---------|----|----|------> T

Please be aware that I've got fixed width fonts.

In this case, as the L3 ID changes, no residual
L2 ID remains to divulge the connection between
L3IDn and L3IDn+1.

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.

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.

Please comment.

Greg

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2005 08:22:55 +0200

>L2 identities need to be bounded by the 
Yes, I think this is the issue. Some additional complexity is
added by thinking about the issue in terms of N layers, N>2.
Also, the endpoints in different layers are typically different.
Having your MAC address stay the same does not necessarily
disclose your identity to others on the Internet, not connected
to the same L2. And encryption affects things too. Encryption
at L2 prevents outsiders, but not the access point from seeing
your IP or upper layer identities. Encryption at L3 prevents
IP outsiders, but not your security gateway or peer from seeing
the actually used internal adddresses or upper layer identities.

Given that there are different endpoints in different layers,
the central question seems to be: how do we make sure that
we can change the addresses at different layers in a synchronized
way, without having a protocol that crosses multiple layers?
It seems that having all parties able to initiate addresses changes
at any time is a key part in the solution. For instance, if only the
access points control L2 address changes, then client hosts
may have trouble matching those changes with the L3 or ULP
changes they need. But if the client can initiate an L2 address
change then it can change all its identifiers at the same time.

--Jari

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 16 Mar 2005 05:12:28 +0200 (EET)

Hi Greg,

> the problem which is _not_ going to be solved.

=> IMHO, having a good idea of what we intend to solve is enough to start
the work. IMHO, this is well described in the momipriv problem statement
draft (I mean *all* the draft :)

> any L3 address.

=> IMHO, the same statement applies to L3 addresses regarding L2
addresses.

> This is necessary to prevent psudonymity detection as follows:
>
>        L3ID1               L3ID2          L3ID3

=> 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?

> L2 ID remains to divulge the connection between

=> Agree. But it would be better to have in this case (L3ID1, L2ID1)
switches to (L3ID2, L2ID2) then to (L3ID3, L2ID3), ... in order to achieve
anonymity, 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 synchronisation
bewteen both endpoints regarding the pseudo-IDs updates?

> L3ID2.  This level of connection is what needs to

=> Agree.

> L2 identities need to be bounded by the

=> IMHO, if we want to achieve anonymity then the two pseudo-IDs must
change _AT THE SAME TIME_.

Regards,

Wassim H.