Specify IPv6 flow label for QUIC

[huitema]

There is an ongoing push in the IPv6 working group for conformance to RFC 6437. 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?

[britram]

Probably. There are (probably minor) caveats here.

If/when RFC 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.

[becarpenter]

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; persistence will be hampered, but that will presumably be a challenge anyway.

[martinthomson]

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.

[huitema]

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...

[becarpenter]

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 says about firewalls, they might regenerate the flow label.

[martinthomson]

@huitema,

flow_label = F(dest_address, dest_port, DCID, per_node_seed)

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.

[huitema]

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

[martinthomson]

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

[ianswett]

This was closed by #2399