Note that the QUIC bit cannot be used with forwarding mode #89
Conversation
|
You might want to cite or defer to the managability draft that is related - https://www.rfc-editor.org/rfc/rfc9312.html#section-3.1 |
|
@LPardue Thanks, that's interesting. I couldn't figure out how to reference it here though. It occurs to me that we might also want to say something about disabling the Spin Bit, which is normally a bit dangerous in forwarding mode because it reveals the end-to-end latency of each Connection ID. However, I'm not sure exactly what the advice would be, especially because it's possibly safe when "scramble" is enabled (#87). |
|
I was thinking something simple like - "The considerations of Identifying QUIC traffic in Section 3.1 of QUIC-MANAGEABILTIY] apply to forwarding proxies. Specifically, ... " but if that doesn't help, or feels shoehorned, feel free to ignore |
|
It's tricky because the proxy is both an endpoint and a middlebox (for QUIC). QUIC-MANAGEABILITY doesn't apply to endpoints. In the proxy's role as a middlebox, there is no protocol identification involved because (formally) only QUIC can flow through the forwarder, so QUIC-MANAGEABILITY doesn't apply there either. The weird thing is that the forwarder shares a 5-tuple with the proxy endpoint, so some of the protocol identification restrictions on middleboxes spill over onto the proxy's QUIC endpoint. |
No description provided.