Subject: [quicwg/base-drafts] stateful routing by intermediaries (#821)

From: jpinner-lyft <[email-masked]>
Date: Tue, 03 Oct 2017 17:35:57 +0000 (UTC)

Intermediaries in a QUIC connection do not (and cannot) participate in transport parameter negotiation and endpoints in a connection may not be able to configure or even have knowledge of any intermediaries. Nonetheless, those intermediaries may require connection id to do proper address translation or connection management but have no way to signal to the endpoints that the `omit_connection_id` parameter must not be set.

In particular intermediaries (especially those acting on behalf of, or in concert with, the client and server -- e.g. L4 load-balancers, client gateways, configured proxies) that attempt to manage routing through address migration or NAT re-bindings would require connection ids in both directions.

Further, some aspects of client privacy are currently assumed to be achieved by clients not sending a connection id but the specification does not require this. And some aspects of connection id migration require the servers to send the client a new connection id preemptively which they are not currently required to do. Simply requiring connection ids without requiring the servers to provide clients with the ability to migrate them does not seem to provide sufficient privacy.

My suggestion here would be to modify the specification to always require connection ids be sent by both endpoints and further require endpoints to exchange the necessary information that allows connection id migration to be initiated at will by the client.

-- 
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/821

---

From: ianswett <[email-masked]>
Date: Tue, 03 Oct 2017 10:44:14 -0700

The original motivation for not including a connection id was saving bytes on the wire, not privacy.

Given both endpoints have to agree to omit it, and omitting it doesn't have a negative privacy impact, I don't see a negative of allowing it to be omitted.

-- 
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/821#issuecomment-333923136

---

From: jpinner-lyft <[email-masked]>
Date: Tue, 03 Oct 2017 18:28:37 +0000 (UTC)

This assumes that the endpoints have control and knowledge of the entire path to know that it's safe to omit.

-- 
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/821#issuecomment-333935825

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 12:34:31 -0700

Any intermediary has to be working with teh server or the client, since the keys aren't available to an intermediary otherwise. Isn't it adequate to have the end that teh intermediary is in cahoots with not send omit_connection_id? Meaning, if this is a reverse proxy, then the server *knows* to not send omit_connection_id, and itself always sends the connection ID. Why is that not enough?

-- 
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/821#issuecomment-336547456

---

From: jpinner-lyft <[email-masked]>
Date: Fri, 13 Oct 2017 19:52:03 +0000 (UTC)

@janaiyengar: Intermediaries do not need to be able to decrypt the packet to access the connection id and perform tasks like routing or NAT'ing. There are also many examples of routing intermediaries that are not under direct control of the client or the server (things like Amazon's ELB, WLAN access points, etc). In addition, with the ability to migrate the connection across different paths, the presence of such intermediaries may change throughout the course of the connection.

-- 
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/821#issuecomment-336551211