Subject: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004

From: [email-masked]
Date: Wed, 10 Nov 2004 09:29:30 -0600

Thanks to TJ for these notes. And corrections by Jari Arkko.

-----------------------------------------------------------

Notes from IETF61 Privacy BAR BOF -- 35 attendees (names witheld for privacy).
8 Nov 04 -- 10pm - 11:15pm
Basavaraj P. leading. Notes by TJ Kniveton.

James Kempf - Wrote an ISOC paper on the regulatory situation in US,
Japan and Europe about IPv6 location..anyone deploying MIPv6 might
want to look at it. In the US, not much regulation. But in Japan and
Europe, users must be given a meaningful opportunity  
Architectural considerations about privacy. Every protocol
instantiates them differently. 

Raj - privacy means different things to different people..

Wassim - focus on MAC and IP layers. Highlights the need to update
them in a synchronized way, so that you don't change just one and
leave the other unchanged. 

Hesham - there are so many upper layer identifiers, such as
cookies. Thinking we solve the problem of privacy at IP and it's done
isn't true. 

Jari Arkko - Privacy is not fully provided until you have solved it at
the MAC layer, IP layer, authentication layer, mobility
layer. On the other hand, things on those different layers have to be
solved on their own. 

Erik N. - Cases where you want to be reachable under a different
identifier. But other cases you don't want to disclose on outbound
communication, information that allows traceability. 

Hesham - if you're making a call outbound and you try to hide your
identity 

TJ - Who are we trying to keep the privacy from? correspondent?
routing infra? If I make a phone call, I can hide my caller ID
info.. but the phone company still knows who I am, and if the police
wants to know who I called, they can find out. 

RFC 3041 thinks already about crossing boundaries. Shouldn't have a
PTR record that points back to your permanent name. I might want to
use different identities to hide things. 

Raj - We want to talk about link layer identifier. Is that something
the IETF should even be looking at? 

Kempf - we might want to mention it, but don't dwell on it.

Arkko - There's a difference between defining the problem and solving it.

Greg Daley - if we leave it there unresolved, it's an achilles
heel. Because anyone can snoop mac addresses. 

-some talk about cellular networks and whether you send an identifier
 to initiate calls. Sends identity in clear when you first buy the
 phone and turn it on, but not every time you turn it on. 

Kempf - 3GPP2 is interested in what happens in IETF. We don't want to
come up with a solution, and then a year later they come and say,
sorry this doesn't work etc. We should engage them now to get a set of
requirements. 

Hesham - but we haven't even started a BOF yet.

Kempf - 3GPP comes a lot, talks in SIP wgs, etc. 3GPP2 doesn't tend to
do that.. How can we get them to talk to us? 

Arkko - Works 2 ways. It might be useful to tell other bodies as well
if they have something they need to fix. 

Nordmark - does anyone know if IEEE 802.11 has looked at this?

Kempf - They're not even close to this, they have been working on
authentication. 

Pasi Eronen - They looked at this a few times over the years. Now
they're doing the opposite -- getting certificates based on MAC
addresses. 

TJ - Maybe this is a stupid question, but why do we really need to
protect location privacy for IP addresses? I don't care if someone
knows I'm in Washington DC because of the IP i'm using. 

Hesham - Well there are some criminals who really care about that.

Eronen - Well if you're in DC, that's fine. But if someone can tell
where you are within 100m, they can come with an AK-47.. 

TJ - but can they really tell where I am within 100m?...

.... discussion

Kempf - well we need to satisfy regulators.

Some fighting about what MIPv6 spec says for SPI selector, ESP
header.... Can anyone on the home link tell where the MN is, or just
the HA? 

Erik: privacy aspects of multihoming 
Erik - You have a HoA, CoA. might want to use multiple sets of
those. When you switch, you want to switch both at the same time. 

IKE - uses same SPI each time.

Arkko - you always use the same IKE SPI, but you can renegotiate the
IPsec SPI. 

F Dupont - it's only useful if you are close to the security gateway.

Raj - Questions we should ask here
- Is this work even of interest in the IETF?
- Privacy: is this something that should be dealt with on a mobility
aspect, or should it be a broader question that is addressed with a
new charter? 

Hesham - This requires expertise from more than one WG. Location
privacy for MNs can be tackled. 

Arkko - HIP, MIPv6, etc. all have different privacy issues.

Kempf - I would support updating the MIPv6 charter for that purpose.

Arkko - But even beyond that, what about identity issues in MIP? More
than just location privacy. 

Hesham - make it so that location information and home address don't
show up in the same packets. 

Eronen- we need a threat description, because it's not a binary
thing. If you can link things together, sooner or later you end up
losing both location and identity information. You can solve against
unbounded adversary capabilities. 

Kempf - We need something realistic like what we did for binding updates.

nn - The endpoint has to be identified. You can't communicate without
knowing the endpoints. So we want to protect the privacy as far as
possible. You can't eliminate all possible cases where privacy can be
breached. 

Conclusion: Will suggest a change to the charter and contact.
Jari: Conclusion was that the problem is interesting and that 
we should attempt solving parts of the MIPv6 problem at the MIP6 WG,
and amend the charter. In addition there seems to be a need for
some general purpose architectural work around privacy, and James Kempf
promised to start some paper around that.

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Nov 2004 08:12:53 -0800

hi Raj,

I made a comment about how location privacy from the CN can
be achieved by reverse tunneling everything (including the BU)
through an IPsec protected tunnel between the MN and the HA.
this is something we can do today without modifying any
protocol. SPD entries can be easily setup for this.

I mentioned we can use RFC 3041 generated home address
(generated every few days) with an optional dynamic DNS update
from the HA to provide the same level of privacy that is
available in IPv6 today.

I also said we must work on a solution that achieves location
privacy from the visited network while still doing route
optimization with the CN.

all these comments are missing from the minutes.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 2004 17:21:57 +0100

In your previous mail you wrote:

=> we agree too to continue the problem statement effort, including
not MIPv6 issue like the L2/L3 stuff.

Regards

[email-masked]

PS: how the charter will be updated? Will there be a point about this
in the Friday session agenda?

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 10 Nov 2004 20:03:54 +0200 (EET)

Hi all,

There was also another comment about writing a threat model draft (to
answer some comments/questions. I (and Raj) mentioned during the meeting
that we are working on such draft but all what I've read in the minutes
is about the famous architectural draft.

Regards,

Wassim H.

> > Thanks to TJ for these notes. And corrections by Jari Arkko.
Ã> >
> > Arkko - There's a difference between defining the problem and solving it.
©> >

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 2004 19:06:17 +0100

=> I don't believe it is a good idea (it is a part of what I call
the VPN temptation) but I agree we talked about it!

=> I don't know if registering addition home addresses is really supported
but of course it is a way to hide actual home addresses (because the
extra HR BUs will be protected using so will get the first home address).

=> as I have a concrete proposal to provide this I do support you

=> it seems the minutes miss many details???
   
Thanks

PS: good minutes are critical: a common and stupid way to loose
time is to fix the minutes of the previous meeting.