Re: [Masque] Benjamin Kaduk's No Objection on charter-ietf-masque-00-00: (with COMMENT)

[Martin Duke <[e-mail]>]

Thanks Ben, replies inline.

Please see this PR to see the changes in context:
https://github.com/chris-wood/ietf-masque/pull/7


On Wed, May 20, 2020 at 10:16 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Just "HTTP" does not imply any particular level of security mechanism,
> though
> "HTTP/3" would.  I think we need to say something about what security
> properties we expect MASQUE to provide, even if it's just "equivalent to
> HTTP/3
> or better".  (This would be a BLOCK at external-review time but may not
> need to
> hold up asking for external review.)
>

[MD] Shall I simply change HTTP to HTTPS? There is not an intent to run
this over plaintext HTTP.


>
>   Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit
> with
>   their own shortcomings. For example, SOCKS signalling is not encrypted
> and HTTP
>   CONNECT is currently limited to TCP. In contrast, HTTP/3 is a viable
> candidate
>   protocol for proxying arbitrary traffic, as it provides secure
> connectivity,
>   multiplexed streams, and migration for a single connection while taking
>   advantage of a unified congestion controller. An HTTP/3 datagram
> construct
>
> Am I parsing this properly that the last thing in the list of what HTTP/3
> provides is just "migration", and that the "for a single connection [...]"
> stuff applies to all of it?  I'm not sure if another comma would help make
> that separation more clear.
>

[MD] Clarified to make it clear "for a single connection" applies to all of
it.


>
>   The primary goal of this working group is to develop mechanisms that
> allow
>
> nit: maybe "mechanism(s)"?
>

[MD] done

  and/or HTTP/3 extensions to enable this functionality. The group will
> focus on
>   a limited set of client-initiated services: (1) UDP CONNECT and (2) IP
>   proxying. Server-initiated services are out of scope. The working group
> will
>   first deliver a protocol solution for UDP CONNECT and a requirements
> document
>   for IP proxying. Once both are complete, the working group will focus on
> a
>   protocol solution for IP proxying.
>
> I assume there's a reason to do UDP separately instead of just letting UDP
> run on top of proxied IP.  (Expediency?)
>

[MD] Yes, IP proxying raises a number of issues about addresses, etc. that
make it much more challenging. UDP proxying covers most use cases, likely
neatly corresponds to HTTP CONNECT, and has less packet overhead.


>
>   The working group will consider fallback to versions of HTTP that
> operate over
>   TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working
> group will
>   consider implications of tunneling protocols with congestion control and
> loss
>   recovery over MASQUE, and may issue recommendations accordingly. New
> congestion
>
> This sounds like "nested congestion controllers".  Is that more of a
> research
> question or an engineering one?
>

[MD] A true nested congestion controller would indeed be research into a
new algorithm, which is forbidden in the charter. Instead, the WG will make
some sensible recommendations to tune existing congestion controls, e.g.
"turn off the outer congestion control" or "raise the reordering threshold
on the inner loss recovery".


>   Multicast UDP and multicast IP support are out of scope. However, the
> group may
>   specify extension points that would enable future work on multicast.
> Specifying
>   proxy server discovery mechanisms is also out of scope, but the group may
>   specify techniques for identifying proxy servers to aid future discovery
>   mechanisms.
>
> How do "techniques" differ from "mechanisms"?
>

[MD] One is a service discovery protocol, the other is some sort of server
identifier and capability report that a future service might use. IIUC DoH
had a similar split.

I changed it to "... but the group may specify identifiers and capability
reports for proxy servers to aid future discovery mechanisms."


>
>   Impacts on address migration, NAT rebinding, and future multipath
> mechanisms of
>   QUIC are not anticipated. However, the working group should document
> these
>   impacts if they arise.
>
> Presumably we also want to pay attention to any other developments in QUIC
> that would be impacted by MASQUE, and document those, too.
>

[MD] added

>
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>