Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS

Ben Schwartz <bemasc@google.com> Thu, 25 June 2020 01:31 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE53A0D08 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Jun 2020 18:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_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 0FMPT6BfsFgm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Jun 2020 18:31:49 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457503A0D07 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Jun 2020 18:31:48 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1joGhP-0004WN-FO for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Jun 2020 01:29:07 +0000
Resent-Date: Thu, 25 Jun 2020 01:29:07 +0000
Resent-Message-Id: <E1joGhP-0004WN-FO@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1joGhN-0004Va-Vg for ietf-http-wg@listhub.w3.org; Thu, 25 Jun 2020 01:29:05 +0000
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1joGhL-0001Ah-MK for ietf-http-wg@w3.org; Thu, 25 Jun 2020 01:29:05 +0000
Received: by mail-wr1-x42a.google.com with SMTP id j94so4167558wrj.0 for <ietf-http-wg@w3.org>; Wed, 24 Jun 2020 18:29:03 -0700 (PDT)
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=xOhvY008geMq1cTTOsAfKzUee/B0TCe/yfeMHmj5DaQ=; b=D3BdGoVXXkQ991jjb2oZC5/IGvE8e2KK2zBBJ9YWgjQw0hWaP3ctZYbLj4uvWguWD3 kuDxvRsdHpcAGfEEL1a/gV3qa/uPmOazmqMdGyD1kiNPTKrzsj9LXQ40QJPWak0fJpmV OSCH4TuK/wqyn+2/Ndyc4BW8ZdYDJlmzqZ+93qCBzLm3VStGrpSSGoYbhfQ9qkl7tLRE KK8cXD4cQB3oMxEyviIgiZld4AVLHMNYVinRZ6Fxz7PmYTEr5diob9K7BvMSzklFhMT1 YZ00kt8/u+sWGpmAqqaHWGIf7DtvWhuctgc2nzbgyW+uMsGbDd2m+IFN+227h8r2SIqC HjPQ==
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=xOhvY008geMq1cTTOsAfKzUee/B0TCe/yfeMHmj5DaQ=; b=UfV6TYzZpAgfprMCF+wwtG6QG7BK39i5iMdD+s8oA37KUQGOi5c/EVkDWR0Fq+yvTP txBGX7SI77Y6MGjO4OuL6HqJrlytg/cmCIfd9tNg+uIsSTVrrWhqpX0Xuu2uTR44UNry 1j0NuAv5PqUrq9RWNmirH5yvIrL5UcI96iHanJo7lmfp0lUx5jlc5EQkoidr3uj4C2vB GHxDAJhDtKvwR7F5U4iU3ymPNK++rDQq2FCux8a/VlBniLw1rPRjBudrEr1dgX/9mUS2 0fSXrSFPKH5wfYRt1PVWm2g7bLs1O4Nbq3Msf+h2KLkz/c1jF66EAKupAoZ8D5kO2Bcp E7UA==
X-Gm-Message-State: AOAM530EtQUtJ/SOghuvMay6kB6xDjlaGbhrOqj32PJ2Hipu1VpCLKt9 F/EJX/uQBBmarCu+8yZo5C2zhaCAxkRzkLBtIhJiZQ==
X-Google-Smtp-Source: ABdhPJx4QroFBeq5ep9PM2UVKwE/OaiW0m4qHjWyWaF3f0elPnaECA58jhbBV2YnZE/iMaXUQUEWBacH8FXhkefRg/Y=
X-Received: by 2002:a5d:5381:: with SMTP id d1mr16851157wrv.177.1593048531587; Wed, 24 Jun 2020 18:28:51 -0700 (PDT)
MIME-Version: 1.0
References: <54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net> <02858E1D-C010-4404-ADF3-5EB97D4B32B3@mnot.net> <CAHbrMsAjuNPcytNHicCUs4-rR2TESNFwGNOX9Pu+xHbEVx0L5A@mail.gmail.com> <CAPDSy+54b3LbHE-+Kodh_xWNNvQtMi=rcw4iwBz8yskT=6CtsQ@mail.gmail.com>
In-Reply-To: <CAPDSy+54b3LbHE-+Kodh_xWNNvQtMi=rcw4iwBz8yskT=6CtsQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 24 Jun 2020 21:28:39 -0400
Message-ID: <CAHbrMsCThXrqqhjr8A3PkSZ3Lqs8TL6R+yzD89FLfuEN2cKNcA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e144fd05a8de8360"
Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=bemasc@google.com; helo=mail-wr1-x42a.google.com
X-W3C-Hub-Spam-Status: No, score=-20.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1joGhL-0001Ah-MK dcab4aada532a8936fb3bf513918c8a8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <https://www.w3.org/mid/CAHbrMsCThXrqqhjr8A3PkSZ3Lqs8TL6R+yzD89FLfuEN2cKNcA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37823
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Wed, Jun 24, 2020 at 5:33 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> @Ben I don't think reusing extended CONNECT is an option for CONNECT-UDP,
> because of backwards compatibility: if a proxy were to receive a CONNECT
> request with ":protocol" set to "udp", it might ignore the ":protocol"
> header and create a TCP connection to the host and port instead of UDP.
>

I don't think that's true.  Support for :protocol has to be signaled at
startup with SETTINGS_ENABLE_CONNECT_PROTOCOL, so it cannot be sent to a
server that does not understand it.  RFC 8441 also says "On requests
bearing the :protocol pseudo-header field ... the server MUST NOT create a
tunnel to the host indicated by the :authority as it would with a
CONNECT method
request that was not modified by this extension.", so it's quite explicit
that extended-CONNECT does not silently fall back to old-fashioned CONNECT.

I think it's important that CONNECT-UDP to a non-supporting proxy fail
> instead of fallback to TCP.
>

I believe Extended-CONNECT gives you this behavior.

David
>
> On Wed, Jun 24, 2020 at 11:30 AM Ben Schwartz <bemasc@google.com> wrote:
>
>> One direction I think could be interesting is to embrace the Extended
>> CONNECT as used by WebSocket-H2 (RFC 8441).  If we define ":protocol = tcp"
>> as a synonym for the old-fashioned CONNECT, then ":protocol = udp" could
>> represent the basic MASQUE case nicely, and ":protocol = webtransport"
>> might go naturally as well (if we can't reuse ":protocol = websocket").
>>
>> The combination of :protocol and transport (H3 vs. H2) might be
>> sufficient to indicate whether datagrams are allowed.
>>
>>
>>
>> On Tue, Jun 23, 2020 at 4:49 AM Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> My personal .02 on this (and I'd be very curious to hear others'
>>> reactions) --
>>>
>>> We don't have a good track record of creating extensions or new
>>> capabilities that don't map into HTTP semantics. Server Push is probably
>>> the poster child here. As such, creating a version-specific extension for
>>> DATAGRAMs without mapping them into a method (or whatever) seems like it's
>>> leaving an attractive nuisance around; how will it show up in APIs? How
>>> will it interact with intermediaries? Etc.
>>>
>>> We also don't have a lot of precedent for a HTTP version-specific
>>> extension that does something completely separate to the HTTP interaction
>>> that's happening on the connection. I'm not sure that it would be something
>>> we want to encourage.
>>>
>>> All that said, we're not the protocol police; I don't think we should
>>> _stop_ this, but I do think that if we want this to succeed, it might work
>>> better as something packaged together with CONNECT-UDP (or however it gets
>>> expressed in HTTP).
>>>
>>> AIUI the one big argument for factoring it out into a separate draft is
>>> that MASQUE might want to use it *without* a method (etc.) for IP proxying.
>>> So that might be a conversation to have (although that use case has been
>>> delayed, I think).
>>>
>>> Another potential consumer could be a header on CONNECT (or even other
>>> methods?) that allows unreliable delivery but degrades gracefully to
>>> reliable delivery on hops that don't provide it. Even then, it seems like
>>> such a spec could reference the wire formats, etc., in CONNECT-UDP once
>>> that's defined.
>>>
>>> Overall - I have a preference for this to be rolled into a CONNECT-UDP
>>> (or similar) spec, but can live with it as a separate doc, provided that
>>> some thought is put into warning potential users about some risks.
>>>
>>> What do other folks think?
>>>
>>>
>>> > On 23 Jun 2020, at 9:40 am, Mark Nottingham <mnot@mnot.net> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > The new MASQUE[1] and WEBTRANS[2] working groups both wish to define
>>> new protocols using QUIC DATAGRAM frames[3] that are not conveying
>>> (existing) HTTP semantics, but are intended to be usable over (at least
>>> some versions of) a HTTP connection.
>>> >
>>> > MASQUE's purpose is to proxy UDP and potentially IP (like a VPN) over
>>> a HTTP/3 connection. For WEBTRANS, the purpose is to create a
>>> browser-exposed, WebSocket-like protocol that allows unreliable delivery
>>> (which may also use CONNECT-UDP). These summaries are just my
>>> understanding; for a more complete picture, see the respective charters and
>>> related WG discussion.
>>> >
>>> > It's not yet clear how or even if these protocols will map into HTTP
>>> semantics. Some have proposed something like a CONNECT-UDP method; others
>>> seem to favour negotiating a new protocol using SETTINGS or a similar
>>> version-specific mechanism directly, avoiding the definition of any generic
>>> HTTP semantics.
>>> >
>>> > So far, the most concrete proposal we have is
>>> draft-schinazi-quic-h3-datagram,[4] which defines how QUIC DATAGRAM frames
>>> are surfaced in HTTP/3 without any mapping them into generic HTTP semantics
>>> (like a method, status code, header, etc.). Thus, a specification using
>>> them has the choice of defining a generic HTTP extension (like CONNECT-UDP,
>>> mapping them into HTTP semantics) or a version-specific extension(like
>>> SETTINGS, bypassing generic semantics).
>>> >
>>> > Before these groups get too far down the road, we have an opportunity
>>> to give them some guidance about how to extend both HTTP's semantics
>>> overall, and specific versions of HTTP -- keeping in mind recent core
>>> discussions.[5]
>>> >
>>> > The most relevant question is whether new, non-HTTP protocols on a
>>> HTTP connection should be bootstrapped by generic HTTP semantics (e.g., a
>>> method), version-specific semantics (e.g., SETTINGS), or something else.
>>> >
>>> > There's also a question as to whether something like
>>> draft-schinazi-h3-datagram is the right approach, or whether it should also
>>> include generic HTTP semantics "bundled in."
>>> >
>>> > Do folks have any thoughts about this?
>>> >
>>> > Cheers,
>>> >
>>> >
>>> > 1. <https://datatracker.ietf.org/wg/masque/about/>.
>>> > 2. <https://datatracker.ietf.org/wg/webtrans/about/>.
>>> > 3. 'An Unreliable Datagram Extension to QUIC', <
>>> https://tools.ietf.org/html/draft-ietf-quic-datagram>gt;.
>>> > 4. <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram>.
>>> > 5. <https://github.com/httpwg/http-core/issues/44>.
>>> >
>>> > --
>>> > Mark Nottingham   https://www.mnot.net/
>>> >
>>> >
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>>