search

ietf-wg-masque / draft-ietf-masque-quic-proxy

Other
12 stars 7 forks source link

Note that the QUIC bit cannot be used with forwarding mode #89

Open bemasc opened 11 months ago

LPardue commented 11 months ago

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

bemasc commented 11 months ago

@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).

LPardue commented 11 months ago

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

bemasc commented 11 months ago

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.