Multiplexed Application Substrate over QUIC Encryption
charter-ietf-masque-03

[Ballot comment]
# Internet AD comments for charter-ietf-masque-02-02
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

* Don't think it's necessary to get overly specific about IEEE 802.3.
  RFC 7241, and RFCs 7042 and its -bis, all just use the phrase "IEEE 802".

[Ballot comment]
This is a minor edit to add CONNECT-ETHERNET and coordination with IEEE 802.3.

26 Feb: Updated coordination requirements in accordance with Eric V's review.

[Ballot comment]
Proxying Ethernet frames over MASQUE is a good idea, and I am supportive. Please consider the following comments as a way to improve the project.

1) why limiting to Ethernet only ? Why not trying to be more generic (at least 802.11 frames but also any layer-2 PDU) ? Possibly with other I-Ds

2) beyond coordination with IEEE (or other layer-2 SDO), should intarea WG also be consulted (as it covers sub-IP layers) ?

About draft-ietf-masque-connect-ethernet, I am really surprised to see that this I-D has been adopted in contradiction to the current charter. I would also suggest that the document borrows from L2TPv3 and others rather than only from connect-udp as layer-2 is a different beast.

Hope this helps this good idea

[Ballot comment]
Thanks for addressing my previous comments in the charter text itself.

But, *NOT* in the milestones... There is still the rather vague "QUIC-aware" text and the intended status are still missing.

Regards

-éric

[Ballot comment]
Thanks for the updated charter.

I am just wondering why HTTP/TCP is within the charter but not in the milestone, is there not enough interest to working on those?

[Ballot comment]
To be honest, I wonder what is meant by "QUIC-aware proxying" (is it about using QUIC over MASQUE?), as this is a major work item, let's be clear.

The paragraph about multicast is unclear (possibly because too long, i.e., the first and last sentences are probably enough).

The last paragraph "When these deliverables are complete..." is probably useless but is also harmless.

Please add the intended status for the work items.

Regards

-éric

[Ballot comment]
Some nits:

- Is it a "and" or a "or" in "...is not possible ***and*** can apply..." ?

- Unsure what is meant by "migration" in "...multiplexed streams, migration,..."

- To exhibit my lack of understanding, should the first "HTTP" be qualified as "HTTP/2" ? in "...The group will specify HTTP and/or HTTP/3..."

- Suggest to start a new paragraph at "The group will focus on a limited set..."

More fundamentally:
- there is an unbalance between UDP CONNECT (no requirement doc required) and IP proxying (requirement doc required). If there was prior work, then I would suggest to reference it. Also, I do not understand why IP proxying protocol solution has to wait until UDP CONNECT is done.

- please add working with INT area for all IP proxying work (requirements & solution) >>> mostly a BLOCK for me

- how can MASQUE have some non goals (multicast, discovery, ...) but may consider solution for extensibility (OK, I understand the goal of course but the wording sounds really weird and illogical)

[Ballot comment]
Some nits:
- Is it a "and" or a "or" in "...is not possible ***and*** can apply..." ?
- Unsure what is meant by "migration" in "...multiplexed streams, migration,..."
- To exhibit my lack of understanding, should the first "HTTP" be qualified as "HTTP/2" ? in "...The group will specify HTTP and/or HTTP/3..."
- Suggest to start a new paragraph at "The group will focus on a limited set..."

More fundamentally:
- there is an unbalance between UDP CONNECT (no requirement doc required) and IP proxying (requirement doc required). If there was prior work, then I would suggest to reference them. Also, I do not understand why IP proxying protocol solution has to wait until UDP CONNECT is done.
- please add working with INT area for all IP proxying work (requirements & solution) >>> mostly a BLOCK for me
- how can MASQUE have some non goals (multicast, discovery, ...) but may consider solution for extensibility (OK, I understand the goal of course but the wording sounds really weird and illogical)

[Ballot comment]
* 4th paragraph says "over MASQUE" without previously declaring the term
  MASQUE.  Suggest either to reword without MASQUE or add sentence declaring
  "all of the above proxying games are collectively called MASQUE", or
  something.

[Ballot 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.)

  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.

  The primary goal of this working group is to develop mechanisms that allow

nit: maybe "mechanism(s)"?

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

  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?

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

  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.