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

[Martin Duke <[e-mail]>]

After wordsmithing with the chairs, a revised edits:

The last service discovery clause now reads: "However, the group may
consider features, such as proxy server identifiers, that aid future
discovery mechanisms."

On Wed, May 20, 2020 at 3:11 PM Martin Duke <[e-mail]> wrote:

> 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
>>
>