Subject: [MMUSIC] ICEbis and IPv6 Privacy adresses

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 25 Jul 2014 00:21:16 +0000

Hi,

I think we need some text in ICEbis saying that if IPv6 Privacy addresses is in use, some care should be taken not to expose too many of the other potential candidates you have. 

Can you reveal your IPv4 host address?
What about SRFX and RELAY adresses? 
Do we need an TURN extension to ask the TURN server to also use a IPv6 privacy address when allocation a REALY address for you?

Seems to be problematic to find the right balance between privacy and ensured connectivity.

.-.
Pål-Erik

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 22:33:12 -0400

I believe the point of temporary addresses is to prevent tracking, not to
prevent computing an approximate location. Therefore I don't think we need
to do anything about the other (non-trackable) addresses.

On Thu, Jul 24, 2014 at 8:21 PM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> Hi,
>
> I think we need some text in ICEbis saying that if IPv6 Privacy addresses
> is in use, some care should be taken not to expose too many of the other
> potential candidates you have.
>
> Do we need an TURN extension to ask the TURN server to also use a IPv6
> privacy address when allocation a REALY address for you?
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Jul 2014 08:39:26 -0400

Le 2014-07-24 22:33, Justin Uberti a écrit :
> I believe the point of temporary addresses is to prevent tracking, not
> to prevent computing an approximate location. Therefore I don't think we
> need to do anything about the other (non-trackable) addresses.

Uh? Other addresses *are* trackable, that's the whole point.

The addresses I have right now:

>     inet6 2001:67c:1231:998:9dec:20b7:9edc:fe13/64 scope global temporary dynamic 
>        valid_lft 604798sec preferred_lft 604798sec
>     inet6 2001:67c:1231:998:8e70:5aff:fec5:72e4/64 scope global dynamic 
>        valid_lft 2591999sec preferred_lft 2591999sec
>     inet6 fe80::8e70:5aff:fec5:72e4/64 scope link 
>        valid_lft forever preferred_lft forever

Only the privacy address is not trackable. The other two have fixed
lower 64 bits.

I think Pål's request makes a lot of sense for host candidates.
Server-reflexive and relayed candidates don't matter as they are not
trackable. Asking a TURN server to use a temporary address doesn't make
sense either IMHO.

Therefore, proposed text:

If one or more host candidates corresponding to IPv6 privacy addresses
are advertised, host candidates corresponding to other kinds of IPv6
addresses on the same interface MUST NOT be advertised.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Jul 2014 10:25:04 -0400

> addresses on the same interface MUST NOT be advertised.

Updated text, per today's live discussion:

If one or more host candidates corresponding to IPv6 privacy addresses
are advertised, host candidates corresponding to other kinds of IPv6
addresses on the same interface and having the same network prefix MUST
NOT be advertised.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Jul 2014 10:43:04 -0400

> addresses on the same interface and having the same network prefix MUST

Trying to take into account up-to-date nomenclature, and the link-local
case (which is almost always stable):

=============<cut here>=============
If one or more host candidates corresponding to IPv6 address generated
using a mechanism that prevents location tracking
[draft-ietf-6man-ipv6-address-generation-privacy-01] are advertised:

    - host candidates corresponding to IPv6 addresses that do allow
location tracking, that are configured on the same interface, and are
part of the same network prefix MUST NOT be advertised; and

    - host candidates corresponding to IPv6 link-local addresses MUST
NOT be advertised.
=============<cut here>=============

Simon

---

From: Justin Uberti <[email-masked]>
Date: Mon, 28 Jul 2014 18:01:24 -0700

> Uh? Other addresses *are* trackable, that's the whole point.

I was referring to the cases that Pal pointed out, namely srflx and relay
candidates, as well as IPv4 host candidates.

> addresses on the same interface MUST NOT be advertised.

Agreed. This is what Chrome currently does for IPv6 addresses.