Thursday, April 16, 2020

In-path Proxy for QUIC

I've recently started researching on the QUIC protocol and came across the following while reading the QUIC Manageability draft - " QUIC proxies must be fully-fledged QUIC endpoints, implementing the transport as defined in [QUIC-TRANSPORT] and [QUIC-TLS] as well as proxy-relevant semantics for the application(s) running over QUIC (e.g. HTTP/3 as defined in [QUIC-HTTP])."
I understand why the proxies would have to be terminating proxies and complete handshakes individually with the client and server, however, why would they require to be "fully-fledged QUIC Endpoints" is what I don't understand properly. If they support handshakes, and repackage the packets from the client and server, with the correct connection ids and checksums, wouldn't that be sufficient or are there specific features of this protocol that make this unfeasible ?



No comments:

Post a Comment