Subject: Re: [Taps] IPv6 address usage

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 Jul 2018 17:21:41 -0700

Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model.

Here's a straw man proposal of how we can expose this via the TAPS Interface:

- A new property for Local Address Preference, which can be a tuple of:
    1. Stable/Public
    2. Temporary/Private
    3. Unique For Connection
- Listeners would default to (1). Connections would default to (2)
- If you specify (3), the system will try to get an entirely new IPv6 address that has never been used before
- You can find out the address you used on your Listener/Connection

This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to request a new API, but I think marking this on a connection is preferable, since it allows us to enforce this per-path and per-protocol even.

What do people think?

Best,
Tommy

> On May 24, 2018, at 5:11 AM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> Any thoughts?
> 
> Thanks!
> Fernando
> 
> 
> 
> 
> On 03/21/2018 07:58 PM, Fernando Gont wrote:
>> Folks,
>> 
>> Based on the feedback received today, I have split our document
>> <https://www.ietf.org/internet-drafts/draft-gont-taps-address-usage-problem-statement-00.txt>
>> into this two documents:
>> 
>> * Problem statement with respect to limitations of the Sockets API:
>> <https://www.ietf.org/id/draft-gont-taps-sockets-api-limitations-00.txt>
>> 
>> * Analysis of IPv6 address properties:
>> <https://www.ietf.org/internet-drafts/draft-gont-taps-address-analysis-00.txt>
>> 
>> Your feedback will be appreciated. We'd also appreciate guidance on how
>> to move forward. :-)
>> 
>> Thanks!
>> 
>> Best regards,
>> 
> 
> 
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: John Grant <[email-masked]>
Date: Tue, 24 Jul 2018 10:49:26 +0100

> This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to…
Looks good, especially if it's not actually tied to IPv6, i.e. if you 
delete "IPv6" in the two places it occurs above. (I realise this is an 
IETF group and IETF has nailed its colours to the IPv6 mast, but it 
would be good if TAPS could be more widely applicable than just over the 
Internet, e.g. between mobile device and MEC.)

-- 
John Grant
Chair, ETSI ISG NGP
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
https://www.etsi.org/technologies-clusters/technologies/next-generation-protocols
http://www.ninetiles.com

---

From: Christopher Wood <[email-masked]>
Date: Tue, 24 Jul 2018 19:58:27 -0700

> This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to…

Perhaps unsurprisingly, I am fond of this API. Would it be feasible
for connections to default to (3) and fall back to (2) if
unsuccessful?

Best,
Chris

---

From: Tom Jones <[email-masked]>
Date: Wed, 25 Jul 2018 11:01:59 +0100

> for connections to default to (3) and fall back to (2) if

I would like to echo my fondness of the API and the preference for (3)
falling back to (2) if it is feasible.

- Tom

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 25 Jul 2018 14:48:17 +0000

Being a layer-3 person, I am a (just) little concerned by having one IPv6 address per connection as it could put some stress on Neighbor Discovery (mcast traffic draining battery, cache space/maintenance) if used by default on very short live connections

Just a thought

-éric

On 25/07/2018, 12:02, "Taps on behalf of Tom Jones" <[email-masked] on behalf of [email-masked]> wrote:

    
    - Tom

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 25 Jul 2018 08:05:02 -0700

Hi Eric,

Yes, I'm inclined to agree—I think that having a unique address per connection shouldn't be the default; an application could certainly always set it if it wants to decrease linkability? Perhaps a default could be something more per-user or per-application.

Best,
Tommy

> On Jul 25, 2018, at 7:48 AM, Eric Vyncke (evyncke) <evyncke=[email-masked]> wrote:
>

---

From: Christopher Wood <[email-masked]>
Date: Wed, 25 Jul 2018 08:34:31 -0700

On Wed, Jul 25, 2018 at 8:05 AM Tommy Pauly <[email-masked]> wrote:
>
> Yes, I'm inclined to agree—I think that having a unique address per connection shouldn't be the default; an application could certainly always set it if it wants to decrease linkability?

Applications should not have to opt-in to better privacy. Decreased
linkability should be the default. So if doing this per-connection is
shown (not just believed) to be infeasible, then per-application is a
reasonable compromise.

Best,
Chris

> Perhaps a default could be something more per-user or per-application.
>
> Best,
> Tommy
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 25 Jul 2018 15:48:24 +0000

On Wed, Jul 25, 2018 at 3:34 PM, Christopher Wood <
[email-masked]> wrote:

> > Yes, I'm inclined to agree—I think that having a unique address per
> connection shouldn't be the default; an application could certainly always
> set it if it wants to decrease linkability?
>

The problem is that it might not be a dichotomy between "feasible" and
"infeasible". What if the tradeoff is increased connection latency from
acquiring a new address (either by DHCP or SLAAC/DAD)? What if it increases
network load from neighbor discovery so much that the LAN visibly slows
down?

I would argue that the default should be BCP for the network architecture
in question, whatever that is, and leave the determination of BCP to those
SMEs.

Kyle

---

From: Christopher Wood <[email-masked]>
Date: Wed, 25 Jul 2018 08:52:14 -0700

On Wed, Jul 25, 2018 at 8:48 AM Kyle Rose <[email-masked]> wrote:
>
> On Wed, Jul 25, 2018 at 3:34 PM, Christopher Wood <[email-masked]> wrote:
>>
> The problem is that it might not be a dichotomy between "feasible" and "infeasible". What if the tradeoff is increased connection latency from acquiring a new address (either by DHCP or SLAAC/DAD)? What if it increases network load from neighbor discovery so much that the LAN visibly slows down?

I would consider that infeasible, then. Note that I am simply
advocating for a change in mindset wherein we consider privacy first
at marginal costs. I realize that's an unpopular opinion.

> I would argue that the default should be BCP for the network architecture in question, whatever that is, and leave the determination of BCP to those SMEs.

That might work, too.

Best,
Chris

---

From: "Aaron Falk" <[email-masked]>
Date: Wed, 25 Jul 2018 12:49:53 -0400

On 25 Jul 2018, at 11:52, Christopher Wood wrote:

> Note that I am simply

Consider it first?  Not unpopular as I see it.  Prioritize it above all 
other considerations?  (Or below, for that matter.) That would be a 
concern.  And AFAICT no one is suggesting that.

>
>> I would argue that the default should be BCP for the network 
>> architecture in question, whatever that is, and leave the 
>> determination of BCP to those SMEs.
>
>
> That might work, too.

I assume by 'network architecture' we are talking about 'access 
technologies', yes?  If those BCPs are stated somewhere, that seems 
reasonable.   I'm not sure whether this has been considered in depth or 
in an access-technology-specific way.  Any citations?

--aaron

---

From: Kyle Rose <[email-masked]>
Date: Wed, 25 Jul 2018 17:08:08 +0000

On Wed, Jul 25, 2018 at 4:49 PM, Aaron Falk <[email-masked]> wrote:

> technologies', yes?
I was intentionally being very generic. You're unlikely to come up with
privacy addresses (as such) on v4, given the paucity of the address space,
but the NAT itself can do useful things to hide the identity of an
individual user if the network behind the NAT is large enough.

> If those BCPs are stated somewhere, that seems reasonable. I'm not sure
> whether this has been considered in depth or in an
> access-technology-specific way. Any citations?
>
RFC 7217 has no BCP number, but it is a proposed standard and is
widely-accepted best practice for v6 operators using SLAAC. The DHCPv6 bis
document (full disclosure: which I reviewed for secdir) contains some
language around user privacy.

For v4 with NAT, there's 1631:

q[ On the other hand, NAT itself can be seen as providing a kind of
   privacy mechanism. This comes from the fact that machines on the
   backbone cannot monitor which hosts are sending and receiving traffic
   (assuming of course that the application data is encrypted) ]

and the document that obsoleted it, 3022, which reorders the

q[ Traditional NAT can be viewed as providing a privacy mechanism as
   sessions are uni-directional from private hosts and the actual
   addresses of the private hosts are not visible to external hosts. ]

Curious to know what the IESG thinks about this one (or indeed anything
related to NAT) now, but any further discussion along those lines can
probably be taken to ietf@. ;-)

Kyle

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Jul 2018 15:10:02 +0200

Tommy,

> This type of API would allow us to add in the functionality Erik had asked for, to allow a client to be able to request a new address. The other alternative would be to have some out-of-band API to…

I think that there are three key issues here:

1) Discussion of tradeoffs
2) Specification of mechanisms that allow us to convey different policies
3) Selection of e.g. defaults/desired actions

First step is #1, which is what we did in one of our IDs, and of course
needs more work. This helps us understand the implications f each of the
possible options, and maybe decide what to expose in #2, and e.g. what
the defaults should be for #3 -- and maybe even rule out some cases.

That's what at least I'd suggest that we start with #1
(draft-gont-taps-address-usage-problem-statement &
draft-gont-taps-address-analysis).

In many cases, there are tradeoffs. So one should provide the mechanisms
that allow apps/OSes t make the tradeoffs. But everything starts with
understanding the problem, and understanding the tradeoffs.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Jul 2018 15:18:27 +0200

> Being a layer-3 person, I am a (just) little concerned by having one IPv6 address per connection as it could put some stress on Neighbor Discovery (mcast traffic draining battery, cache space/maint…

FWIW, while "one address per connection" is certainly mentioned as "an
extreme case" in
<https://tools.ietf.org/html/draft-gont-taps-address-analysis-00#page-4>,
I do agree and share Eric's concern. If anything, one might think f "one
address per module" (whatever that is), or one address per
process/thread... but I'm not sure I'd default to "one address per
connection".

I think that there might only be specific cases/scenarios where one
might want to do this.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Jul 2018 15:20:45 +0200

> shown (not just believed) to be infeasible, then per-application is a

Certainly, one address per application would be a more sensible default.
However, I'm of the idea that whatever default one picks is the result
of an analysys of tradeoffs, and not the other way around.

---

From: Christopher Wood <[email-masked]>
Date: Thu, 26 Jul 2018 10:13:24 -0700

> of an analysys of tradeoffs, and not the other way around.

I concur. Privacy is not binary, as Aaron suggests. It's a gradient,
so tradeoffs must necessarily be made based on use case analysis.

Best,
Chris