Subject: re when and how to change Connection ID (and who should generate)

From: Kazuho Oku <[email-masked]>
Date: Wed, 25 Jan 2017 17:48:03 +0900

>From what I see, there are two types of network address changes; one
that can be detected by an endpoint (e.g. network interface up) and
one that cannot be detected (NAT rebind).

For those that can be detected, we should change the connection ID.
For those that cannot be detected, what we could do the most is
periodically change the connection ID.

Regarding how we change connection ID, there are two methods.

One is to register the next connection ID prior to switching between
the IDs. In this case, after establishing a QUIC connection you would
immediately register the next ID over the encrypted channel. It would
be analogous to how we send NewSessionTicket in TLS 1.3.

The other method is to send a packet marked by the new ID that
contains the old ID.

Considering the fact that in some server-side deployments there would
be load balancers that route incoming packets based on connection IDs,
it would be beneficial to choose the first approach, since you would
have some time on the server side to have the mapping for the new ID
registered to the load balancer. In the latter approach, the binding
between the IDs cannot be found until you decrypt the packet, but it
is unlikely for a load balancer to be able to decrypt all the packets.

And considering this, it would be beneficial if the first connection
ID and the next connection IDs are generated on the server-side (in
that case, the first connection ID will be assigned to the client at
the point of the TLS handshake and the next connection ID will be sent
along the session ticket), since in case of rebinding from Wifi to
cellular network (or vice-versa) there is an non-negligible chance
that packets will start arriving at a different POP (of CDN
deployments).

For example, when I am at Kyoto (500km from Tokyo) using Wifi, a POP
located in Osaka (50km from Kyoto) will likely be used as a
destination (thanks to anycast). But once I get switched to a cellular
network, I will going though a L3 gateway located in Tokyo, and
therefore my packets will start arriving at a POP in Tokyo.

In such case, we'd still want to continue sending responses (at least
for those already in-flight, we would send GOAWAY so that new requests
would come through a new connection). It seems to me that using
server-generated connection ID (with the ID of the POP) would be the
most concise option.

-- 
Kazuho Oku

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 25 Jan 2017 10:05:20 +0100

Sorry if i missed this, but why do you want to change the connection id 
udring the lifetime of a connection?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jan 2017 22:32:42 +0900

There was a link to this document in the agenda:

https://docs.google.com/document/d/16vHie4Qe44-SKZzxNzL4cClbCKqO7P3B-DYEAFRgWGs

In short, the current design of this feature - the ability to continue
a connection after one or other peer changes its point of network
attachment - creates a new way to track activity across those
different points of network attachment.

For example, if I continue a connection from WiFi to cellular as I
leave my house, my two different ISPs for those uplinks (which where I
live is often the same entity) can match the two connections up and
track me as I come and go.