Subject: [Masque] Fwd: New Version Notification for draft-duke-masque-other-transport-00.txt

From: Martin Duke <[email-masked]>
Date: Mon, 25 Jan 2021 15:01:43 -0800

Hi MASQUE,

As an individual, I submitted this draft on a straightforward extension to
tunnel SCTP, DCCP, UDP-Lite (and even TCP!) packets over CONNECT-UDP. This
was inspired by a colleague who asked how one would tunnel SCTP over MASQUE.

It is clearly out of charter scope right now, but perhaps it is a useful
straw man for thinking about the IP proxying requirements. Comments are
welcome. Github is here:
https://github.com/martinduke/connect-other

Thanks to David, whose ECN document structure I copied verbatim, and Lucas
for some early comments.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Jan 25, 2021 at 2:52 PM
Subject: New Version Notification for
draft-duke-masque-other-transport-00.txt
To: Martin Duke <[email-masked]>

A new version of I-D, draft-duke-masque-other-transport-00.txt
has been successfully submitted by Martin Duke and posted to the
IETF repository.

Name:           draft-duke-masque-other-transport
Revision:       00
Title:          The Other-Transport Extension: Arbitrary Transports over
CONNECT-UDP
Document date:  2021-01-25
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/archive/id/draft-duke-masque-other-transport-00.txt
Status:
https://datatracker.ietf.org/doc/draft-duke-masque-other-transport/
Html:
https://www.ietf.org/archive/id/draft-duke-masque-other-transport-00.html
Htmlized:
https://tools.ietf.org/html/draft-duke-masque-other-transport-00

Abstract:
   This document describes an extension to the HTTP CONNECT-UDP method
   [CONNECTUDP] that supports tunneling of other transport protocols, as
   long as the first four octets of those protocols encode the source
   and destination ports.

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.

The IETF Secretariat

---

From: David Schinazi <[email-masked]>
Date: Mon, 25 Jan 2021 16:36:35 -0800

Hi Martin,

Thanks for writing this document! I think it helps reason about
where we should draw the line between CONNECT-UDP and
IP Proxying.

On one hand of the use-case spectrum, we have use-cases that
want to send as little information over the client-to-proxy wire as
possible with limited control - those are well suited for
CONNECT-UDP (and its extensions). You negotiate the target IP
and port (and IP protocol) with the proxy, and then you don't send
those in every single client-to-proxy packet because they'd be
repeated in every packet in this flow.

On the other hand of this spectrum, we have use-cases that wish
to control every aspect of the IP header, including the addresses
of the inner IP headers. An example of this is a site-to-site VPN
where there are multiple machines on either side of the VPN.
Those are well suited by IP Proxying: the IP packets are sent
in their unmodified entirety with their full IP header, because in this
scenario the IP header will vary between packets in the same tunnel.

The distinction really comes down to one question: does the client
care about the source IP address in packets from the proxy to the
target? If no, use CONNECT-UDP (modulo extensions); if yes, use
IP proxying.

David

On Mon, Jan 25, 2021 at 3:01 PM Martin Duke <[email-masked]> wrote:

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