search

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

Other
12 stars 7 forks source link

Detecting Connection mapping conflicts #34

Closed gloinul closed 3 years ago

gloinul commented 3 years ago

Section 2.4

"The proxy treats two mappings as being in conflict when a conflict is detected for all elements on the left side of the mapping diagrams above."

I think diagrams makes it uncertain what is referred to here. I assume it is the mapping statements in Section 2.1-2.3.

I think this statement is missing to detect conflicts for the case related to proxy reuse request that are not QUIC flows. Thus two rules are missing. A server-socket that doesn't have any connection-IDs bound to it can't be reused as this is in non-QUIC mode. Secondly, any attempt to reuse a server-socket that has one or more connection-IDs bound to it must not be reused by a connection-ID less request.

I think maybe a table in this section would be clearer for which values to check to ensure that mapping is okay.

tfpauly commented 3 years ago

Sure, I think the "no-connection-ID" case can fold into an empty connection ID, but we can describe that. That would make the rules work as is.

gloinul commented 3 years ago

@tfpauly that can probably be made to work but the case do need consideration as a CONNECT-UDP request without client-connection-ID need to behave as it gotten client-connection-ID=0. I don't think you can "upgrade" a existing connection to forwarding mode, if the first CONNECT-UDP request didn't include a client-connection-id.

tfpauly commented 3 years ago

Yes, I think we should specify that no connection ID is equivalent to setting 0 as the connection ID—it means no socket reuse and prohibits forwarding later.