Subject: [Masque] Review and questions on draft-pauly-masque-quic-proxy

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 17 Dec 2020 14:04:42 +0000

Hi Tommy,

I finally reviewed your draft in more detail. I'm very supportive of the general idea as this is a neat way to reduce overhead (and MTU limitations).

I have one questions first: It seem in the intro that you expect the proxy to NAT (as you say the target can't see client's IP address and the proxy is on path). However then later (in section 5 or elsewhere) you don't really say anything about NATing anymore. Is it the assumption that the client will use the proxy IP as dest and the proxy will rewrite both dest and src address?

Also what's about UDP ports? Would/can the proxy rewrite the src port of out-going traffic to the target? If so, it seems that for target-to-client traffic using the port number for the mapping might always be the preferred/default option as to my understanding client connection ID are usually omitted.

Then you say that you can only use this extension if datagram mode is supported. Is this because you need to send another CONNECT-UDP on the same stream when announcing the server connection ID and you don't want to interleave that with data on that stream? Or what's the reason that stream mode is not supported? However, I'm also wondering if there is a better way to announce a (new) server connection ID (associated with a certain stream and/or datagram flow id). This information does not need to be send "in-band" with the end-to-end data and while we currently only have this "negotiation" at CONNECT-UDP setup, I think it could be useful to also have a more general signal channel between the client and proxy that can be used when a forwarding association is already active.

One more concrete comment: In section 4.4. you say:

   "A proxy MUST NOT forward packets from the target to the client until
   after the client has sent at least one packet in forwarded mode."

But if read this correctly, this actually seem to contradict what's shown in the example...?

And finally, one high level editorial/structural comment: To me it seems that some of the text applies quite general for CONNECT-UDP and not only the extension described in this draft, e.g. section 2.1 or thing related to NATing and IP privacy. So maybe there an opportunity to move some text over. 

And as a side note: I found the use of the term socket sometimes rather a bit confusing. I think just talking about 5-tuple would be easier in most cases. But I guess that a matter of taste...

Thanks!
Mirja