3 ms·

Did anybody look into how this is going to work with proxies? It seems fairly naive to standardize this without having a solution for that.

by kpcyrd 8y ago

sowbug 8y ago
QUIC connections are always encrypted and authenticated, so they should work just fine with a CONNECT-style proxy that supports UDP. (I don't know for sure; I'm just reasoning from first principles.) EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful concept except in very limited circumstances such as forwarding only to a single destination, because there's no connection to establish that a proxy server could know anything about. Maybe proxy servers don't have a place in a QUIC world.
tomassre 8y ago
Could be client HTTP/3 --> proxy HTTP/1 --> backend gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC https://cloud.google.com/load-balancing/docs/https/#QUIC
lucaspardue 8y ago
Do you mean forward proxies? The HTTP/3 draft currently specifies how the CONNECT method is used. At present, it only allows you to create an onward TCP connection. So you have a QUIC connection between client and proxy, and a TCP connection between proxy and server. Like so QUIC TCP client <----> proxy <----> server Unfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions: https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/ https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n... This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...

Did anybody look into how this is going to work with proxies? It seems fairly naive to standardize this without having a solution for that.

by kpcyrd 8y ago

Did anybody look into how this is going to work with proxies? It seems fairly naive to standardize this without having a solution for that.

sowbug 8y ago

QUIC connections are always encrypted and authenticated, so they should work just fine with a CONNECT-style proxy that supports UDP. (I don't know for sure; I'm just reasoning from first principles.) EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful concept except in very limited circumstances such as forwarding only to a single destination, because there's no connection to establish that a proxy server could know anything about. Maybe proxy servers don't have a place in a QUIC world.

tomassre 8y ago

Could be client HTTP/3 --> proxy HTTP/1 --> backend gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC https://cloud.google.com/load-balancing/docs/https/#QUIC

lucaspardue 8y ago

Do you mean forward proxies? The HTTP/3 draft currently specifies how the CONNECT method is used. At present, it only allows you to create an onward TCP connection. So you have a QUIC connection between client and proxy, and a TCP connection between proxy and server. Like so QUIC TCP client <----> proxy <----> server Unfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions: https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/ https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n... This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-helium.pdf https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...