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

[Wassim Haddad <[e-mail]>]

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.

On Wed, 10 Nov 2004, Vijay Devarapalli wrote:

> 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
>
> [e-mail] wrote:
>
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mip6
>
>
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mip6
>
>

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