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

From: [email-masked]
Date: Tue, 05 Jan 2021 05:56:29 -0800

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 [email-masked] 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/

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 5 Jan 2021 12:33:19 -0500

Thanks for updating this.  Quick questions:

Why is the destination a URI, and not just host:port like CONNECT?

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

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.

How do you expect this to interact with MTU?  It seems like PMTUD is not
possible here, which makes me sad.  Even "PLPMTUD" will not work, because
there is no way to set a "don't fragment" flag.  I presume the intention is
that "don't fragment" would be encoded by a registered flow-id name.  Apart
from the potential for a "combinatorial explosion" if there are multiple
flags in play, this seems OK, but I worry that anything written as an
extension won't be widely deployed.  I think we should consider putting
"don't fragment" support in the base spec, maybe even mandatory to
implement.  Otherwise we'll break MTU discovery entirely, and we'll just
have hacky hardcoded MTU values forever*.

*Or we'll have to invent "Transport Layer Path MTU discovery", where the
sender asks the recipient for a fragmentation report, and the recipient
observes whether the packet was fragmented and reports this back to the
sender in-band.

On Tue, Jan 5, 2021 at 8:57 AM <[email-masked]> wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 5 Jan 2021 19:26:41 +0100

Hi Ben,  responses inline

> 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

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

> mapping or unified registry for these things, since they'll presumably be

I expect some might overlap, and some might not. One is an integer and the
other a string. I wouldn't unify them personally.

> observes whether the packet was fragmented and reports this back to the

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. Can you file an
issue? We can add something along the lines of "the proxy SHOULD disable
fragmentation on its UDP sockets".

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 6 Jan 2021 10:50:54 -0500

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

> malformed requests are specified in other docs. Please file an issue and

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

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