Subject: Re: I-D Action: draft-fgont-6man-rfc4941bis-01.txt

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Jul 2018 23:50:42 +0200

Hello, Tim,

Just realized I hadn't responded to this one :-(. Inline....

On 04/01/2018 11:12 AM, Tim Chown wrote:
>> On 31 Mar 2018, at 00:57, Fernando Gont <[email-masked]> wrote:
>>
>> On 03/29/2018 12:23 PM, Tim Chown wrote:
>> [....]
>>> Probably. What I'm complaining about is services that have some
>>>> sort of reputation system based on individual /128s. Temporary
>>>> addresses do create a behaviour pattern that doesn't exist for
>>>> IPv4 clients.
>>>>
>>>>>> The example
>>>>>> I've seen is mentioned below: a service that considers frequent
>>>>>> changes of IP address to be a sign of illicit activity.
>>>>>
>>>>> This is tricky already, anyway. With happy-eyeballs sort of behavior,
>>>>> this can already happen (one connection happens over v4, and a
>>>>> subsequent happens over v6).
>>>>>
>>>>> I do believe that, for all such cases, giving apps more control (and
>>>>> awareness!) regarding v6 addressing and what they can do about it is
>>>>> needed. But that would be out of cope for this particular document, I think.
>>>>>
>>>>> That said, we could add a comment about this issue in this document.
>>>>> Thoughts?
>>>>
>>>> Yes, an explanation of this side-effect issue would help. Also perhaps,
>>>> replace the old "off by default" text by a requirement that it must be
>>>> easy for the user to disable temporary addresses if they cause problems.
>>>> IMHO, netsh interface ipv6 set privacy state=disabled store=persistent
>>>> doesn't count as "easy" for a normal user.
>>>
>>> The current 6434-bis says
>>>
>>> "RFC 4941 SHOULD be supported.  In some scenarios, such as dedicated
>>>   servers in a data center, it provides limited or no benefit, or may
>>>   complicate network management.  Thus devices implementing this
>>>   specification MUST provide a way for the end user to explicitly
>>>   enable or disable the use of such temporary addresses."
>>>
>>> Is that the sort of wording you'd like?
>>
>> Well, this talks about *support* of RFC4941. There's still the question
>> of whether such support should be enabled by default or not?
> 
> RFC 6724 rule 7 says prefer temporary addresses, albeit with some accompanying words on when it makes sense to do otherwise, but that's the default.

BUt, doesn't such rule apply only *if* temporary addresses are enabled?
-- i.e., RFC4941 does not enable them by default. If you do enable them,
then, according to RFC6724, they are preferred.

> 
>>> (https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#page-15)
>>>
>>>> There are real scenarios where "on by default" can be a problem.
>>>> Here are some fragments of the real world:
>>>> http://kb.tableau.com/articles/Issue/identifying-and-disabling-temporary-ipv6-addresses
>>>
>>> This one seems largely about using (or not) privacy addresses for servers?
>>>
>>>> https://lonesysadmin.net/2018/01/23/disable-windows-ipv6-temporary-addresses/
>>>
>>> This is a more pragmatic one, where today ACLs may allow a specific admin's workstation IP access somewhere.
>>> Maybe that's a case for RFC8273, with the ACL on the /64 prefix?
>>
>> Or just RFC7217.
> 
> Not if the admin wants to admin stuff with ACL control and be a regular browsing / application user elsewhere?

mm.. not sure I understood...

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jul 2018 08:42:42 +0000

Hi,

> On 2 Jul 2018, at 22:50, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Tim,
> 

:)

> then, according to RFC6724, they are preferred.

6434bis says 4941 SHOULD be supported, and if they are then there MUST be a way to toggle whether they're enabled. There is currently no statement on whether the default toggle is on or off.

https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#page-15

There is also Rule 7 in RFC6724 to consider.  Again, that can only apply if privacy addresses are enabled.   There is in principle the Privacy Preference flag there.

https://tools.ietf.org/html/rfc6724#section-5

> mm.. not sure I understood...

The case where a user wants a stable source address that can be added to some remote ACL, but also privacy when visiting other remote content. 

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Jul 2018 18:04:26 +0900

On Tue, Mar 27, 2018 at 4:11 AM Brian E Carpenter <
[email-masked]> wrote:

> I realise that we want to encourage privacy by default, so this is
> a dilemma. I don't know what the answer is.
>

The answer is that they SHOULD be enabled by default. A service that
objects to clients changing address is already broken since it will fail if
the device reconnects from a different network (e.g., wifi vs 3g) or
different protocol (v4 vs. v6). If a user wants to use such a broken
service, then the privacy addresses can be disabled.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Jul 2018 18:16:38 +0900

On Wed, Mar 28, 2018 at 4:10 AM Brian E Carpenter <
[email-masked]> wrote:

> > I think that we need to extend the IPv6 APIs so that applications
> > can either request stable addresses or demand a new privacy address.
>

+1. We particularly need a way to provide per-application IP addresses to
VMs and emulators running as unprivileged applications.

> > I think that we have quite a number of things that merit a revision
> > to the IPv6 socket API.    I don't know to get this work funded.
>
> That's a very complicated thing... not just POSIX, but every o/s,
> and every language with a socket library, needs to be on board.
>

It's easier than that if you only want it to be commonly deployed as
opposed to ubiquitous. You only need to get it into a handful of platforms
and the majority of users will have access to it.

By funding did you mean funding the implementation or funding the document?
If there is indication that we might reach consensus on the semantics of
such an API, we could look at how much work it would be to implement parts
of it in Android.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jul 2018 11:41:41 +0200

On 07/03/2018 11:16 AM, Lorenzo Colitti wrote:
> On Wed, Mar 28, 2018 at 4:10 AM Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> +1. We particularly need a way to provide per-application IP addresses
> to VMs and emulators running as unprivileged applications.

FWIW, this, among others, is/was the goal behind:
* draft-gont-taps-address-analysis
* draft-gont-taps-address-usage-problem-statement
* draft-gont-taps-sockets-api-limitations

Thanks!

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jul 2018 10:06:48 +0000

> On 3 Jul 2018, at 10:04, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Tue, Mar 27, 2018 at 4:11 AM Brian E Carpenter <[email-masked]> wrote:
> The answer is that they SHOULD be enabled by default. A service that objects to clients changing address is already broken since it will fail if the device reconnects from a different network (e.g., wifi vs 3g) or different protocol (v4 vs. v6). If a user wants to use such a broken service, then the privacy addresses can be disabled.

Should that be stated, perhaps conditionally on user-oriented devices, in 6434-bis?   

See https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-08#page-15

Tim

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jul 2018 12:12:49 +0200

Hello, Tim,

> https://tools.ietf.org/html/rfc6724#section-5

So.. would you agree that if we want to make the default "on", we should
explicitly say so in rfc4941bis?

> The case where a user wants a stable source address that can be added to some remote ACL, but also privacy when visiting other remote content. 

RFC7127+RFC4941 would do for that. But the app or system should be able
to tell the API what it wants. Right now, for the most part it boils
down to system-wide settings.

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Tue, 3 Jul 2018 10:52:57 +0000

Hi,

> On 3 Jul 2018, at 11:12, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Tim,
> 

I would take the chairs' steer on that.  As you saw, I have asked whether it's something to consider adding to 6434-bis.

> down to system-wide settings.

In theory :)

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Jul 2018 16:07:14 +1200

> service, then the privacy addresses can be disabled.

I don't think that works for Joe Average User, which is why I think
it's a dilemma. I don't see any reasonable alternative to on by default,
but it leaves this problem unsolved.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Jul 2018 09:26:31 +0200

> but it leaves this problem unsolved.

I'd say that in most of those cases the problem really has to do with
changing MAC addresses as opposed to changing internet-layer addresses.
e.g. "pay per surf the web" typically authorize access based on the MAC
address rather than based on the internet-layer address. -- and it seems
e.g. Microsoft has addressed this by doing ala-rfc7217 mac address
randomization.

Of course, temporary addresses do affect ACLs. However, in this respect
Microsoft Windows has been shipping with temporary addresses for a
while, already. So enterprise environments, at least, wouldn't be
surprised by the change we are introducing... because in those
environments, such change was already ubiquitous, anyway.

And, we agree that privacy should be "on" by default of course.

Thanks,