[Masque] Benjamin Kaduk's No Objection on charter-ietf-masque-00-00: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 20 May 2020 17:16 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: masque@ietf.org
Delivered-To: masque@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57173A0CA6; Wed, 20 May 2020 10:16:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: masque-chairs@ietf.org, masque@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158999499543.12397.7137358356514385454@ietfa.amsl.com>
Date: Wed, 20 May 2020 10:16:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/mgkQwMbH3xU00WuRVYOtfLeBdZ0>
Subject: [Masque] Benjamin Kaduk's No Objection on charter-ietf-masque-00-00: (with COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 17:16:36 -0000
Benjamin Kaduk has entered the following ballot position for charter-ietf-masque-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-masque/ ---------------------------------------------------------------------- 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.
- [Masque] Benjamin Kaduk's No Objection on charter… Benjamin Kaduk via Datatracker
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Martin Duke
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Martin Duke
- Re: [Masque] Benjamin Kaduk's No Objection on cha… Benjamin Kaduk