Subject: [quicwg/base-drafts] Specify IPv6 flow label for QUIC (#2348)

From: Christian Huitema <[email-masked]>
Date: Fri, 18 Jan 2019 00:03:15 -0800

There is an ongoing push in the IPv6 working group for conformance to [RFC 6437](https://tools.ietf.org/html/rfc6437). The pseudo random flow label enables routers to perform flow-preserving load balancing without having to parse the transport header, which in IPv6 is sometimes hidden behind a chain of extension headers.

For QUIC, that would probably mean setting the IPv6 flow label to a pseudorandom value function of the source and destination addresses and ports and the Destination Connection ID (if present). Should we mention that in the transport spec?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348

---

From: Brian Trammell <[email-masked]>
Date: Fri, 18 Jan 2019 02:15:12 -0800

Probably. There are (probably minor) caveats here.

If/when [RFC 6437](https://tools.ietf.org/html/6437) is widely deployed in the forwarding plane (I have neither data nor intuition about this), this will cause ECMP to operate on the DCID, so switching DCID will cause packets to be grouped along a different path. 

The upside of this is that in cases where ECMP is balanced across different _interdomain_ paths (this does happen, though I'm not sure how rarely -- though I know of recent work on traceroute enhancements to compensate for increasingly complex multipath topologies in the Internet), the cost of timing-correlation linkability across DCID change goes way up in the Internet core.

The downside is that a DCID switch will be more likely to cause latency discontinuity; when the switch hashes on to a faster path, there will be a spike in reordering at the receiver. This won't break anything per se (QUIC handles reordering just fine as specified), but it may lead to adverse performance in the few windows around a DCID switch that isn't currently there.

tl;dr it's certainly worth doing, but let's not be surprised by the (minor) effects of the decision.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-455496194

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jan 2019 11:37:04 -0800

What you say is correct for in-transit ECMP, if a DCID switch triggers a change of flow label and therefore a possible path change. It's a bit worse if a server load balancer uses the flow label too as per [RFC 7098](http://tools.ietf.org/html/rfc7098); persistence will be hampered, but that will presumably be a challenge anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-455663270

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Jan 2019 20:53:17 -0800

So the real problem here is that if we do have labels, we want to guarantee that we don't create linkability at the IP layer.  The costs for forwarding in the network seem manageable, and the load balancer is supposed to know what connection IDs are and use those for consistently routing.  Using the flow label for the first packet, assuming a stateful load balancer, as described in RFC 7098 seems fairly consistent with this.  The stateless processing is made worse by virtue of having to find the connection ID, so much of the benefit there is lost for a purely stateless load balancer.

BTW, I don't like this statement in 7098:

>    o  SSL and HTTP proxies, if present, should forward the flow label
      value towards the server.  This usually has no performance
      benefit, but it is consistent with the general model for the flow
      label described in RFC 6437.

That's only really going to benefit traffic analysis, which isn't a great outcome.  One advantage of terminating TLS is that there is some remixing and re-encryption of inbound and forwarded data.  In any case, simple 1:1 mappings across this sort of proxy aren't always feasible as the proxy tends to route requests and not connections.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-455948049

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Jan 2019 02:34:48 -0800

I have been thinking about linkability, but I don't think that's actually an issue. Assume that we set:
```
flow_label = F(dest_address, dest_port, DCID, per_node_seed)
```
This does not volunteer any information that is not in the packet already. In particular, if the DCID changes, so does the label. The only concern is if there is no DCID (L=0) and the packet traverses a NAT. In that case, the flow label could survive, which could be useful for tracking. But then, in theory, there are no NAT in IPv6...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-456026290

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jan 2019 11:22:39 -0800

Not only are there in theory no IPv6 NATs, but as a consequence their behaviour is not specified - in particular, whether they should copy the flow label. By analogy with what [RFC 6437](https://tools.ietf.org/html/rfc6437) says about firewalls, they might regenerate the flow label.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-456176501

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 13:14:06 -0800

@huitema,
> This does not volunteer any information that is not in the packet already. 

This is only true if `F()` isn't reversible.  If `per_node_seed` can be extracted, that's a very good correlator, really only limited by the 20 bits the label carries.  Assuming you mean to use HKDF or similar here, that would be fine.

The zero-length connection ID case is interesting.  We might simply advise that the flow label be derived from a counter in that case, which is incremented each time the connection ID would otherwise change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-456200542

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Jan 2019 14:47:09 -0800

@martinthomson Yes, I meant to use a non-reversible function. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-456217907

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jan 2019 23:32:46 -0800

Tokyo conclusion: sure, seems fine.  Needs a PR.  Assigning to @huitema.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2348#issuecomment-458841219