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

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>.
>>> > 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/
>>>
>>>
>>>