Re: [Masque] I-D Action: draft-ietf-masque-connect-udp-03.txt

Ben Schwartz <bemasc@google.com> Wed, 06 January 2021 15:51 UTC

Return-Path: <bemasc@google.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5BF3A0F02 for <masque@ietfa.amsl.com>; Wed, 6 Jan 2021 07:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTfr0u9mG2xQ for <masque@ietfa.amsl.com>; Wed, 6 Jan 2021 07:51:06 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE253A0F01 for <masque@ietf.org>; Wed, 6 Jan 2021 07:51:06 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id 81so3110164ioc.13 for <masque@ietf.org>; Wed, 06 Jan 2021 07:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Es1P1U/1m17yjZCLfOD4q8CKx96eBHb9x9cajA6mi6Q=; b=HCfzLo/JLxnY9BhNk7aGsjph8+YHI8JOG6FJvOZ1j4lIzmqPzbiYdSsjmRyL1vyyxW 45eKT07DnnbDyI2z0HBXHx0VlLZyxRg46mnrFePnhpscBs/zH8JRd6Z3wseINT9L676L owmK/fUljOmp05BgvyqYLiGaoBIFgdu7vx93CjTrGQ4UU+JPOOo3XmZfyKheKTE1d9Py VmtAWIVEFl+yyaQZ5cpzgnmgXJEuxNm4VdPcpCVuryJhKu7cE2fNgNBnx9xcwuObZljY 2RgSp9DnnHtv5zeynT1t96Rz3aAibwIFrh4fJlztvKfyBpZA6nvxS1/NBzHuw+/hqr0L Jtpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Es1P1U/1m17yjZCLfOD4q8CKx96eBHb9x9cajA6mi6Q=; b=q/9tRPFJ8t+1nZZxuYfCjj+SmXNu39C2TuPWV5Z9OE/cW0qq+LfHQxnvFTdkMobVv4 6Cj58DH+4QB167SWYrWUGSH/s1r00x/9E02Ypa//y44sFF5buLZSv5XXE9R+efXPjtYr PH0/69j05dXG3wrEn6YuW16KwOxePbKcJ7ITE5Fub1SsVZtDYZmBO94vlw/vnKPR6GDa 1sEeC8lwxwkXLEAzfO3RAsa8GSd+FgH2k1R5F+Qesy6/zllIppzeFaz/G3JZd9qmp82y jJIFAQUD8qbt36dfBlPc0rjpXqwLxv6zUOf5SU90rVjwS6N0ePyb+KdeUpHFxQa3Uv5l RkRQ==
X-Gm-Message-State: AOAM530IWKJ5l5gqKurdu9lNouI6qnRN3huQZ60ywcqytF+nV4fs1gfC gwx6axrdRDpaYUtdkrfCSIYKyCdfJ2QvCA7XWfWdIQ==
X-Google-Smtp-Source: ABdhPJwYzyd9E8Uri1rGDteXdB9sQHl/8PS4Z0ALMDMMgkKBlPyzTVqoFtU5yJe+elaDrApIXot2jETTlZkFiKySfSk=
X-Received: by 2002:a05:6638:3012:: with SMTP id r18mr4152627jak.13.1609948265545; Wed, 06 Jan 2021 07:51:05 -0800 (PST)
MIME-Version: 1.0
References: <160985498902.27048.15957041689692483741@ietfa.amsl.com> <CAHbrMsBPZJwWTwAC+K5oVuSn50WwX7fHUvy75WkZyqARiZYkFg@mail.gmail.com> <CAPDSy+6a3f8hQdjY=Vmfd7sJM9Ey2k-xgs8dT10Mk9rn3HnmkQ@mail.gmail.com>
In-Reply-To: <CAPDSy+6a3f8hQdjY=Vmfd7sJM9Ey2k-xgs8dT10Mk9rn3HnmkQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 06 Jan 2021 10:50:54 -0500
Message-ID: <CAHbrMsAupk3bY7sn-zWCfk7HAT1M=LW_dqtSCiwNgAS5PNsYdw@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: MASQUE <masque@ietf.org>, i-d-announce@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000080378505b83d4a65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/g9BL1CHr9AVxiBMoqqzqhMLwnB0>
Subject: Re: [Masque] I-D Action: draft-ietf-masque-connect-udp-03.txt
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 06 Jan 2021 15:51:09 -0000

On Tue, Jan 5, 2021 at 1:26 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Hi Ben,  responses inline
>
> On Tue, Jan 5, 2021 at 6:33 PM Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org> wrote:
>
>> Thanks for updating this.  Quick questions:
>>
>> Why is the destination a URI, and not just host:port like CONNECT?
>>
>
> Because that would violate HTTP specs. Please take a look at these issues
> for background:
> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/23
> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/8
>

Let me try to separate out the arguments there:

1. Forwarding by non-method-aware gateways

If CONNECT-UDP is to be forwarded by gateways that are not specifically
aware of this method, then it obviously must conform to some "generic
method" syntax.  It would be nice if there were a reference to a document
affirming that this is even possible.  Forwarding of unrecognized methods
has long been a sticky point where theory and practice do not exactly agree
(e.g. https://www.rfc-editor.org/errata_search.php?rfc=3143), and I haven't
found RFC text that settles the matter clearly.  However, CONNECT-UDP
Section 8 appears to say that, at least for H3->H3 gateways, method-unaware
forwarding of CONNECT-UDP is not possible.  In general, I think this is
unlikely and can be excluded.

2. HTTP syntax

I think we can update RFC 7231 and 7540, or simply reinterpret "CONNECT" as
meaning "CONNECT-like" in some contexts.  The syntax then only matters when
CONNECT-UDP arrives at a server that cannot process CONNECT-UDP.  In
HTTP/1.1, this trades an HTTP 501 for an HTTP 400.  In HTTP/2, this trades
an HTTP 501 for a stream error.  That seems like a very small loss in
either case.

Assuming a URI is required, I think we should use udp://.  The existing
provisional registrations (
https://www.iana.org/assignments/uri-schemes/prov/udp) seem extremely
unlikely to create a compatibility hazard for CONNECT-UDP.

BTW, it looks like Datagram-Flow-Id is hop-by-hop, so it should be listed
in a "Connection: Datagram-Flow-Id" header (RFC 7230 Section 6.1).

What is the proxy supposed to do with a (bad) request that includes an
>> odd-numbered Datagram-Flow-Id?  (I presume 4xx, but it seems unspecified.)
>>
>
> The doc states that in this case it is malformed, and responses to
> malformed requests are specified in other docs. Please file an issue and
> I'll add a reference.
>

Thanks, I didn't catch the sentence on "malformed".

What's the relationship between "type" in the stream form and "flow-id
>> name" in the datagram form?  It seems like there ought to be some kind of
>> mapping or unified registry for these things, since they'll presumably be
>> largely overlapping.
>>
>
> I expect some might overlap, and some might not. One is an integer and the
> other a string. I wouldn't unify them personally.
>

Keeping two separate registries with overlapping meanings seems
overcomplicated to me.  I would lean toward unifying them entirely,
treating the stream contents as a simple stream encoding of the datagram
format (e.g. ID-length-value).  This would simplify implementation and
could improve relaying of CONNECT-UDP between H2 and H3.

 ...

> We can't make DONT_FRAGMENT mandatory because not all kernels allow
> setting it from userspace. I also don't think this needs to be negotiable,
> as we've demonstrated that IP fragmentation is harmful by now.
>

I'm not aware of an RFC that deprecates IP fragmentation, and I don't think
this working group is chartered to write it.

Can you file an issue? We can add something along the lines of "the proxy
> SHOULD disable fragmentation on its UDP sockets".
>

This design would break support for any simple UDP protocol that lacks
PLPMTUD.  I expect there are dozens, perhaps thousands, of protocols like
that currently in use.  I would want to see a clear recommendation from
INTAREA before imposing such a restriction.


>
>
>> On Tue, Jan 5, 2021 at 8:57 AM <internet-drafts@ietf.org> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Multiplexed Application Substrate over
>>> QUIC Encryption WG of the IETF.
>>>
>>>         Title           : The CONNECT-UDP HTTP Method
>>>         Author          : David Schinazi
>>>         Filename        : draft-ietf-masque-connect-udp-03.txt
>>>         Pages           : 11
>>>         Date            : 2021-01-05
>>>
>>> Abstract:
>>>    This document describes the CONNECT-UDP HTTP method.  CONNECT-UDP is
>>>    similar to the HTTP CONNECT method, but it uses UDP instead of TCP.
>>>
>>>    Discussion of this work is encouraged to happen on the MASQUE IETF
>>>    mailing list masque@ietf.org or on the GitHub repository which
>>>    contains the draft: https://github.com/ietf-wg-masque/draft-ietf-
>>>    masque-connect-udp.
>>>
>>> Discussion Venues
>>>
>>>    This note is to be removed before publishing as an RFC.
>>>
>>>    Source for this draft and an issue tracker can be found at
>>>    https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-masque-connect-udp-03.html
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-masque-connect-udp-03
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> --
>>> Masque mailing list
>>> Masque@ietf.org
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>> --
>> Masque mailing list
>> Masque@ietf.org
>> https://www.ietf.org/mailman/listinfo/masque
>>
>