[Masque] Erik Kline's No Objection on draft-ietf-masque-connect-udp-14: (with COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Tue, 14 June 2022 01:06 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 9199FC14F737; Mon, 13 Jun 2022 18:06:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-masque-connect-udp@ietf.org, masque-chairs@ietf.org, masque@ietf.org, ekinnear@apple.com, ekinnear@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <165516879058.39452.14276389104602931870@ietfa.amsl.com>
Date: Mon, 13 Jun 2022 18:06:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/xv1wwfAIiZAUwqkZAMce-cjfszA>
Subject: [Masque] Erik Kline's No Objection on draft-ietf-masque-connect-udp-14: (with COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 14 Jun 2022 01:06:30 -0000

Erik Kline has entered the following ballot position for
draft-ietf-masque-connect-udp-14: 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.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Internet AD comments for {draft-ietf-masque-connect-udp-14}
CC @ekline

## Comments

### S3.5

* Should the 2xx discussion here include additional reference to the extended
  commentary in masque-h3-datagram#section-3.2?

### S7

* I *really* wish there could be more said about tunnel security.  I was
  tempted to try to formulate some DISCUSS on the matter, but I cannot
  seem to see where any more extensive text was ever written for the CONNECT
  method.

  Nevertheless, there are plenty of concerns that could be mentioned, like
  what should a proxy do if the target_host is one if its own IP addresses,
  or a link-local address, and so on.

  I'm not entirely convinced that it suffices to claim that because the
  tunnel is not an IP-in-IP tunnel certain considerations don't apply.
  Anything and everything can be tunneled over UDP, especially if RFC 8086
  GRE-in-UDP is what the payloads carry (or ESP, of course).  It seems like
  most of the points raised in RFC 6169 apply; perhaps worth a mention.

  But as I said, I think all these concerns apply equally to CONNECT (in
  principle, anyway), and the text here is commensurate with the text for
  its TCP cousin (that I could find, anyway).