Draft: draft-ietf-masque-connect-udp

Commentary: This change reduces the strength of recommendation for the default template . It also discusses how clients can figure out whether a server actually supports this template . 
 Please file an issue so we can have the discussion there instead of on a PR 
 For future reference , issue has been filed to discuss this topic . 
 This PR now adjusts the default template recommendation text , instead of removing it . 
 that the URI template is not correct . Servers MUST NOT return these response codes if the request is well - formed and the URI matches a supported template . Generally , we shy away from saying " server MUST NOT return x status code " in HTTP because there are situations where that 's the best thing to do . For example , a MASQUE server could decide that sending a 404 is the best thing to do to hide the existence of a service from a given client . 
 That paragraph was as part of , and thinking about it more it adds more confusion that clarity so I 'm going to remove the paragraph in . 
 As the author of this paragraph , I 'm concerned about its removal . The purpose of this text is to enable clients to figure out that the template they are using is not correct . This is especially important given the default template , which will almost always be incorrect . Without a rule like this , error codes are specific to a single URI ( i.e. a single destination ) , and the client never knows if MASQUE might work for a different destination . It therefore has to try MASQUE for every destination ( even though it will always fail if the template is wrong ) , or implement and tune a heuristic to abandon the use of MASQUE after failures with many destinations ( which creates compatibility problems with MASQUE servers that serve limited destinations ) . 
 I 'm assuming that by " the template is not correct " you mean " the client was configured with a different URI template than what the UDP proxy expects " , please correct me if that 's not the case . Since these error codes do n't tell the client what URI template they should have used , the clients will not treat any errors in in a different way , so specifying error codes does n't change any outcome here . This is very much a binary outcome , either it works or it does n't . Clients will implement heuristics based on this binary response , not on error codes . As  points out , error codes ca n't be used for this purpose in HTTP . 
 No , HTTP error codes can distinguish between transient failures ( e.g. 429 ) , permanent / cacheable failures ( e.g. 404 ) , and even non - error results that some clients might not support ( e.g. 307/8 ) . The " Proxy - Status " header provides further detail , and is normatively recommended in this draft precisely because a binary response is insufficient . Some clients might indeed do that , but HTTP also has many minimal or nearly - stateless clients for whom heuristics of this kind would be difficult to implement well . Also , the draft provides no mention of any such heuristics , or guidance on how they ought to work .  suggested a SHOULD , which does not seem to be the same as " ca n't be used for this purpose " . 
 What is the purpose of the MAY and SHOULD in the resulting paragraph ? In what way would it improve interoperability ? 
 My goal with this text was to enable clients to determine whether an HTTP CONNECT server also supports MASQUE . I 'm not too picky about how that works , but there ought to be some way to do it . The " MAY " documents an approved way to do that , and implicitly threatens servers with incompatibility if they do n't hold up their end . Whether we say " SHOULD " or " MUST " on the server side , the " MAY " for the client creates an effective normative requirement on servers . To be clear , my main concern here has been that server implementors will be tempted to represent NXDOMAIN or " No Route To Host " as 404 , etc . That 's a very logical mapping that would break a lot of client heuristics , but is not prohibited by anything in the draft . 
 I share that goal . The problem is that this gets tricky because in HTTP a server and an origin are n't the same thing . So my thought is that our best outcome is a two - pronged approach : CONNECT - UDP simple , browsers will re - use their " if QUIC breaks often , mark QUIC as broken and use TCP " approach something more formalized like draft - schwartz - masque - access - descriptions later to have something that solves the problem for more than just CONNECT - UDP I think the underlying realization here is that browsers will need to interop with servers that do the wrong thing via a simple " mark CONNECT - UDP as broken for this proxy " heuristic , and that once they do that , adding requirements on error codes does n't gain anything that is n't already covered by    
 I think that 's reasonably likely to be true for browsers , but not all clients are browsers . Part of the problem is that the TCP fallback heuristic is more complicated than that . The client needs to fall back to TCP , see that TCP works , and only then attribute the failure as likely proxy - related . This is only possible if the proxy client is also the HTTP client , able to change the HTTP version . It does not work for system - level proxy layers , as they can not control , or even track , UDP - TCP fallback . Ultimately , some heuristic somewhere will probably make it work , but we 're creating waste and delay that could be avoided by giving some clear instructions about how to tell if this thing is a MASQUE proxy . 
 I agree , though I 'm not aware of system proxy layers having plans to implement CONNECT - UDP just yet . By the time those happen we 'll have a more formalized approach . We ca n't avoid waste and delay with SHOULDs and MAYs so might as well wait for the formalized solution to tackle that problem . 
 I suggested a SHOULD because saying that you MUST send a particular status code in a particular situation precludes sending other status codes that might be more relevant . It also encourages clients to equate seeing that status code to only that error condition , even when it might have been generated by another component . However , there 's something else going on here -- If you want to say something about many resources , it 's best to do so explicitly . While you can infer things about server state from a few HTTP status codes ( e.g. , 505 ) , most are specific to the resource in question . Saying otherwise is changing the semantics of those status codes , and that is n't something this specification can do . 
 The default template 's purpose is to enable compatibility with origin - only proxy configuration schemes . This is a worthwhile goal , but the default template is not a suitable solution : It violates RFC 8615 's definition of .well - known/ as the location for metadata about an origin . A MASQUE service is not metadata . It is not representable as a .well - known " URI suffix " as required by the .well - known registry ( unless we register all ( 2 ^ 128 + 2 ^ 32)2 ^ 16 distinct paths ) . It conflicts with better discovery mechanisms , like the one in the MASQUE development process . It is not compatible with the use of HTTPS records . ( In the targeted legacy context , the client has no other DNS server that can be used when a proxy is in use . ) This is somewhat ironic , as HTTPS records allow bootstrapping QUIC connections , and proxying for QUIC is the primary motivation for CONNECT - UDP . We should defer this problem to a subsequent draft , and provide a cohesive proxy setup flow , presumably with a standardized configuration object that could be served from .well - known/ and extended to cover CONNECT - IP ,  and other relevant capabilities . 
  I disagree with your assessment that this solution is n't good and should be removed . This serves a real purpose . Let 's go into the issues individually : Those points are not an argument to remove the default template , they are an argument to revert PR and switch back to a non - well - known prefix . Let 's set those aside for now . I do n't see a conflict here : the default template does n't preclude using other templates that have been discovered through other means . Can you clarify what the conflict is ? Can you clarify what the incompatibility is here ? I do n't understand what the relationship between the default template and HTTPS records is . Clients are welcome to query their own HTTPS records before using CONNECT or CONNECT - UDP . The way that the client picks its template has no impact on its DNS settings . 
 ... This is called " squatting on the HTTP namespace " , and it would violate the in RFC 7320 . It 's also messy to implement , as it would require mixing MASQUE - specific " routing " rules with the user 's application - specific routing rules . It does n't prevent better discovery mechanisms , but it does n't encourage them either . From the server side , there would be no way to " opt out " of the default path , due to the potential for clients that have implemented this specification but not a later , better discovery mechanism . Servers that would prefer a different path would still have to operate the default path for backwards - compatibility . The relationship is that the default template can not express the existence of a DNS server affiliated with the MASQUE server . No , they are not , as this would violate the privacy guarantees implicit in the legacy proxy settings UI that this feature is trying to preserve . 
 You 're conflating two types of proxies here : enterprise proxies that speak CONNECT today and can be updated to speak CONNECT - UDP proxies designed to protect a user 's privacy from the network Folks wo n't ever be deploying both of these use cases on the same proxy . Your concerns are valid but they only apply to ( 2 ) . ( 2 ) would never use the default template . The default template only applies to ( 1 ) . 
 Client software generally ca n't tell why a proxy is being used . It just knows that an HTTP CONNECT proxy has been configured with a particular protocol , domain , and port . Its behavior has to be correct for any existing use case . I do n't see why privacy proxies would n't use the default template . Privacy proxies that are configured via the existing    configuration mechanisms ( e.g. browser extensions , system settings ) would have no other way to use MASQUE . Also , I think this distinction is false . Enterprises are free to use HTTP CONNECT proxies to conceal certain information from the network ( e.g. using an employees - only browser extension ) , and enterprises are often opinionated about which DNS server ought to be used ( not controllable via a browser extension ) . 
 For completeness , here 's how I think this ought to look : 
 Your discovery draft sounds great - however the default template does n't get in the way of that . I do n't think it 's reasonable to remove a useful feature because we might have a more complete solution later when the useful feature does n't get in the way of the future complete solution . 
 Thanks for the offline discussion , this seems like a good compromise .
Since the original HTTP CONNECT method allowed conveying the target
host and port but not the scheme, proxy authority, path, nor query,
there exist proxy configuration interfaces that only allow the user
to configure the proxy host and the proxy port.  Client
implementations of this specification that are constrained by such
limitations MUST use the default template which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT
are the configured host and port of the proxy respectively.  Proxy
deployments SHOULD use the default template to facilitate
interoperability with such clients.
Since the original HTTP CONNECT method allowed conveying the target
host and port but not the scheme, proxy authority, path, nor query,
there exist proxy configuration interfaces that only allow the user
to configure the proxy host and the proxy port.  Client
implementations of this specification that are constrained by such
limitations MAY attempt to access UDP Proxying capabilities using the
default template, which is defined as:
"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT
are the configured host and port of the proxy respectively.  Proxy
deployments SHOULD offer service at this location if they need to
interoperate with such clients.
Clients MAY interpret HTTP 400, 404, or 405 response codes as
indications that the URI template is not correct.  Servers MUST NOT
return these response codes if the request is well-formed and the URI
matches a supported template.