Subject: Re: I-D Action: draft-gont-6man-non-stable-iids-00.txt

From: [email-masked]
Date: Thu, 2 Jun 2016 09:41:32 +0200

> Minor comment:
> 
>>> Your statement does not mean much unless you define "public". The difference between RFC 4941 addresses and other addresses is not are that RFC 4941 addresses are not persistent.
>> 
>> IPv6 addresses are not persistent. they are all ephemeral. it is just a matter of the lifetime.
> 
> While that may be technically true, it certainly goes against the way
> a lot of people *think* about IPv6 addresses, and could easily lead to
> misunderstanding.
> 
> For example, I have a fixed /64 for the link to my home server, and
> another fixed /64 (out of a /56) for my home LAN. The server has these
> two /64 addresses statically configured on separate Ethernet interfaces.
> To me it's not particularly useful to think of these addresses as
> ephemeral.

Understood. Although you'll thank me the day your ISP renumbers your top 56 bits.
(Even in this case, that's you meeting yourself in the door. ;-))

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Jun 2016 12:59:07 +1200

FYI, I've just decided to end my experiment in running my laptop without
a stable IPv6 address, which I started on May 19th.

The only very minor issue that I noted with my regular workload is that
occasionally the gmail SMTP server asks me for my password again.

However, I did have to spend an hour or so making my prototype of
the Anima WG GRASP protocol robust against unplanned address changes,
especially its discovery mechanism. So the caveat is obvious: there
is certainly software around that has not been made renumbering-proof.
But if something is already roaming-proof, it most likely doesn't care
about stable addresses.

(The only tricky part was that on Windows, the stable address keeps
reappearing every few minutes automatically, so rather than dig around
looking for a way to stop that, I've been running a script that deletes
it every time it appears...)

Regards,
   Brian

On 26/05/2016 16:54, Brian E Carpenter wrote:
> On 26/05/2016 16:45, Lorenzo Colitti wrote:
>> On Tue, May 24, 2016 at 7:38 AM, Fernando Gont <[email-masked]>
>> wrote:
>>
>>>> P.S. My personal experiment in running my laptop for several days
>>>> with no stable address has been completely successful. Including the
>>>> fact that my prototype of the Anima signaling protocol crashed after
>>>> a while, because the address it was relying on went away, which is of
>>>> course the expected behaviour.
>>>
>>> So, the question is: can this be considered "acceptable" behavior?
>>>
>>
>> Yes, because IPv6 address can expire and be replaced at any time in a
>> renumbering event.
> 
> Need I add that we will be putting some words about address stability or
> its absence into the appropriate Anima documents. Obviously, we want the
> autonomic networking infrastructure to be both stable and self-repairing.
> But then I think we'd like all applications to have those properties.
> 
>     Brian
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 Jun 2016 07:28:26 +0000

Hi,

> On 4 Jun 2016, at 01:59, Brian E Carpenter <[email-masked]> wrote:
> 
> it every time it appears…)

So there’s two categories here; one is the issues because you’re running privacy addressing, the other is the issues from not having a stable address. Would you have encountered the above even with a stable address running? And would the software that would in principle prefer a stable address (e.g. the anima stuff) use an API to signal that preference (as per the last part of 3.1 of RFC4941)?

I suspect you would have seen the above effects even with stable addresses available in addition to temporary / privacy addresses?

Tim

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 08:20:05 +1200

Hi Tim,

> I suspect you would have seen the above effects even with stable addresses available in addition to temporary / privacy addresses?

Taking the last question first, no, because when you bind a listening socket to ::,
it appears to latch onto the stable address if there is one, so the appearance or
disapperance of RFC4941 addresses doesn't matter. When there is no stable address,
the listening socket will latch on to the most recent RFC4941 address, which of
course changes from time to time. That is what I had to program around for GRASP.

So in answer to the first question, no, just switching on RFC4941 wasn't a problem.
It was switching off the stable address that gave my code something I will call
colittis (sorry, Lorenzo).

And your second question: RFC4941 indeed says "This document also assumes that
an API will exist that allows individual applications to indicate whether they
prefer to use temporary or public addresses and override the system defaults."
As far as I can see, "public" means what we've been calling "stable" here.
So in practice, the default behaviour (on Windows) is for a listening socket
to prefer a "public" address, and if there isn't one, to prefer the latest
temporary address. Apart from explicit use of bind() to choose a particular
address, I don't know how to change that. Maybe a more experienced socket
programmer knows.

Regards
    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Jun 2016 10:01:27 +0900

On Tue, Jun 7, 2016 at 5:20 AM, Brian E Carpenter <
[email-masked]> wrote:

> it appears to latch onto the stable address if there is one,

Binding a listening socket to :: shouldn't attach to any address. The
socket should accept connections that arrive at any address on the system.
The address that is used for the connection is the one that the other side
of the connection decides to connect to.

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Jun 2016 11:27:57 +1000

That's been my understanding (and experience I think, although it has been
a while).

Is it possible that the sockets interface in the language Brian is using
(Python?) isn't quite providing the true sockets API?

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 13:36:35 +1200

> of the connection decides to connect to.

Duh, of course, but only if that address is still valid when the SYN
arrives.

Thanks for the correction.

    Bian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Jun 2016 13:38:18 +1200

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> (Python?) isn't quite providing the true sockets API?

No. I was just confused. (In my brain, not in my code, which was doing exactly
the right thing.)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 May 2016 19:37:44 -0300

On 05/30/2016 04:00 AM, [email-masked] wrote:
>> 3. Update to RFC4941
>> 
>> The temporary addresses specified in [RFC4941] MAY be used alone, 
>> without configuring any stable addresses. In particular the word 
>> 'additional' is deleted from bullet 2 in Section 3 of RFC 4941.
> 
> do we agree that the privacy of a given address is compromised as
> soon as it is used in a way that identifies the user?

It's not black or white. e.g., maybe the address is not tied to an
identity... but it might b useful for an attacker  to correlate network
activity.

OTOH, an app with no identity linkeage might use an address for multiple
similar apps (and this might seem beningn), but then another up which
*does* link to an identity uses the same addresses, and the former apps
now become linked to an identity.

In "paranoid mode", you'd use "throw away connections" (this is
mentioned in the id), but this obviously has implications -- including
implications to the network.

> that would imply that any address used to reach facebook, google, etc
> is tainted and cannot be used for any other connection.
> 
> pretty much all my devices have umbilical cords back to the "cloud"
> for applications, software updates, management, data dumping etc.
> those cords are also connected to an identity.
> 
> I'd argue that there are no deployed hosts / application combinations
> that can only use privacy addresses (they might use privacy addresses
> as short lived stable addresses, but in that case they would be
> better off with stable addresses).

We agree. At the end of the day if you really care about network
activity correlation, privacy addresses simply last for too long. At
which point, you might wonder if they are worth the hassle.

> if the consequence of this is that a temporary address can only be
> used within a single connection, then I can guarantee you that there
> will be many networks that will not support that. bridges do not have
> unlimited space.

Agreed.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 May 2016 19:39:12 -0300

On 05/30/2016 04:12 AM, Lorenzo Colitti wrote:
>     will be many networks that will not support that. bridges do not
>     have unlimited space.
> 
> 
> But some can. 3GPP mobile networks and
> draft-ietf-v6ops-unique-ipv6-prefix-per-host networks, need not be
> limited. Residential networks aren't limited but they might have space
> for thousands of ND cache entries, so thousands of addresses.

If host gets s single prefix, you just track the prefix.

Thanks,

---

From: joel jaeggli <[email-masked]>
Date: Wed, 8 Jun 2016 07:37:46 -0700

> identity... but it might b useful for an attacker  to correlate network

In many cases where useful work is done, the act of using an address to
send  a packet or establish a connection identifies you to the endpoint
that is the recipient. this is inherent in the id/locator role of ip
addresses. throwing them away after use doesn't eliminate that
identifier role, it does make them less useful as locators.

>> will be many networks that will not support that. bridges do not have
4

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Jun 2016 20:54:07 +0200

On 05/31/2016 09:23 AM, [email-masked] wrote:
> Lorenzo,
> 
>>> I'd argue that there are no deployed hosts / application combinations that can only use privacy addresses
>>>
>>> Privacy addresses as defined by RFC4941? Perhaps not today, but it's not hard to change that.
>>
>> give me a functioning host that has no umbilical cord somewhere that leaks identity...
>>
>> What are you suggesting? That RFC4941 addresses don't provide any useful privacy? Or that hosts can't use only RFC4941 addresses? Something else?
> 
> I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses. and that you cannot reuse an address you have coupled identity with for any other connection.
> 
> 4941 may improve privacy, but it clearly isn't sufficient in itself.

I think the part in RFC4941 that is of help is that (assumption?) that
the IID is recomputed on attachment. i.e., lack of stability across
attachment. For the temporary-ness... well, in theory changing the
address once per day is better than never changing it, but...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Jun 2016 20:56:46 +0200

On 05/31/2016 10:36 AM, [email-masked] wrote:
>> I'm making the observation that if you have a host with only RFC4941 addresses, you will end up using 4941 addresses as public addresses.
>>
> a public address is one registered in DNS or some other external registry.
> I would argue that the address you use to reach facebook (and thereby couple address and identity) you have made that address a public address.

That's the case for "throw away" addresses made in
draft-gont-6man-non-stable-iids. Obviously, it comes at a cost.