Subject: [Masque] IP Proxying

From: Martin Duke <[email-masked]>
Date: Fri, 10 Apr 2020 10:46:38 -0700

Apologies for being slow on the uptake, but what is the use case for IP
proxying? For a VPN scenario, simply assigning a stream to each TCP and UDP
flow the client wants should be sufficient, no?

Martin

---

From: David Schinazi <[email-masked]>
Date: Fri, 10 Apr 2020 10:59:53 -0700

What about other protocols such as ICMP or IPv6 extension headers? The
Internet isn’t limited to TCP and UDP :-)

On Fri, Apr 10, 2020 at 10:46 Martin Duke <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Apr 2020 11:09:17 -0700

On Fri, Apr 10, 2020 at 11:00 AM David Schinazi <[email-masked]>
wrote:

> What about other protocols such as ICMP or IPv6 extension headers?
>

What about them? Pretty much any modern application layer protocol has to
be designed under the assumption that they don't exist.

The Internet isn’t limited to TCP and UDP :-)

I've got some bad news for you....

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Fri, 10 Apr 2020 11:21:22 -0700

+1 to Ekr, but somewhat less glibly:

While it is certainly conceivable to do something with IP layer or ICMP
stuff, I would like someone to articulate that they want to deploy a
solution in that space. In the BoF minutes the reason given is VPN, which
as AFAICT doesn't require IP-layer tunneling at all unless you specifically
want to run IPSec or something.

---

From: David Schinazi <[email-masked]>
Date: Fri, 10 Apr 2020 11:37:21 -0700

Please let's not go into the debate of whether there exists anything
beyond TCP+UDP. I think we can agree that today's Web only needs TCP+UDP so
it's fair to say that EKR doesn't need IP proxying for his use-case. But
that's not the only use-case for MASQUE. At Google, we've deployed QBONE in
production because we had a need for an IP-level VPN solution. We have
legacy services that expect their connectivity in a certain way, and to
allow moving these services off-premises without rewriting them we ended up
giving them an IP-level VPN so they think they're on the IP network they
were used to and everything just works. We're interested in moving our
deployment to a standards-based solution, but the requirement that it
provide IP-level connectivity still remains.

David

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Apr 2020 12:16:50 -0700

On 4/10/2020 11:37 AM, David Schinazi wrote:

> beyond TCP+UDP. I think we can agree that today's Web only needs
> TCP+UDP so it's fair to say that EKR doesn't need IP proxying for his
> use-case. But that's not the only use-case for MASQUE. At Google,
> we've deployed QBONE in production because we had a need for an
> IP-level VPN solution. We have legacy services that expect their
> connectivity in a certain way, and to allow moving these services
> off-premises without rewriting them we ended up giving them an
> IP-level VPN so they think they're on the IP network they were used to
> and everything just works. We're interested in moving our deployment
> to a standards-based solution, but the requirement that it provide
> IP-level connectivity still remains.

My personal concern is ease of deployment. Consider 3 options:

1) proxying outgoing TCP connections and/or locally initiated UDP flows

2) proxying incoming TCP connections and/or unsolicited UDP flows

3) VPN

The first option requires that the proxy be able to open TCP or UDP
sockets to send data and listen for data coming back. UDP and TCP ports
can be pooled, as long as each proxied flow is mapped to a unique
5-tuple. It is trivially implemented, and it will work through classic
stateful firewalls without extra configuration.

The second option also requires that the proxy opens TCP or UDP
"listening" sockets, effectively reserving one listening port for each
proxied client. Incoming flows require creating a Quic stream or a
datagram stream to match each incoming flow, which implies adding a flow
management protocol of some kind so the proxy can indicate the remote
addresses and ports to the client. The incoming connections will only
work if the proxy opens a pool of ports in the local firewalls, which
then requires that the proxy protects its resource against abuse on
these ports. Implementation and protocol specification are definitely
more complex than the first solution.

The third option requires that the proxy allocates an IPv4 or IPv6
address to match each IP flow defined by the client. That's about as
complex as managing unsolicited UDP traffic, but with the additional
requirement of managing a pool of IP addresses. That additional
requirement is not trivial. For example, if I rent a virtual machine on
AWS, I can easily program the local firewall to accept traffic on a
range of UDP ports, but getting a range of IP addresses is much more
complex and probably also somewhat more costly.

That means that for me the priorities for MASQUE are clear. The first
option can be easily deployed. We can do interoperability tests fairly
quickly, find bugs, and stabilize the protocol. That should be our first
milestone. The second option builds on the first one, with the addition
of options for managing incoming flows. It is harder to deploy than the
first option, but not so hard that we could not test it. That would be a
reasonable second milestone. But VPN? That looks much harder to deploy
and thus much harder to test. I would rather leave it out of the charter
entirely.

-- Christian Huitema

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 10 Apr 2020 17:28:24 -0700

> and thus much harder to test. I would rather leave it out of the charter

With no hats, I generally agree with this assessment, modulo the bit about removing IP from the charter. We can always tackle it last without taking any steam out of the UDP and TCP efforts. 

In any case, it seems there is one valid use case (QBONE) that requires IP proxying. Are there others?

Best,
Chris

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 11 Apr 2020 04:45:31 -0500

On Fri, Apr 10, 2020, 19:28 Christopher Wood <[email-masked]> wrote:

> With no hats, I generally agree with this assessment, modulo the bit about
> removing IP from the charter. We can always tackle it last without taking
> any steam out of the UDP and TCP efforts.
>

Possibly, for some definition of "valid" :-)

3GPP ATSSS in Release 16 uses MP-TCP proxies for TCP flows (ignore the
details for now), but they want to add support for UDP and IP in Release 17
(so, that's a study item now).

They are aware that QUIC working group has been chartered to look at
multipath for a very long time, and they've reached out to the IETF through
the formal liaison process, and Magnus asked the QUIC working group to
"consider sending information to 3GPP as requested at key points in the
process of the multi-path extension/version of QUIC."

Details of the liaison are in Magnus's email at
https://mailarchive.ietf.org/arch/msg/quic/eezlU8j-gbhQOzj377QZm7YqoeA/,
and discussion about that topic has happened in that thread, but if 3GPP
networks are going to be using QUIC proxies, they want to use them for IP
proxying.

Follow-ups about that topic should probably happen in QUIC, of course.

Best,

Spencer, with no hats

Best,

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 11 Apr 2020 18:22:51 -0400

>From my perspective, "IP proxying" is clearly a topic of general interest,
as demonstrated by the existence of L2TP, OpenVPN, and most recently
Wireguard.  An IP tunnel that benefits from HTTP/3's management and
security functions seems valuable to me.

As for a specific motivating use case, the most obvious one to me is that
iOS and Android support apps acting as arbitrary IP tunnels through their
NetworkExtension and VpnService APIs, but do not have an equivalent* way to
intercept TCP streams.  If MASQUE doesn't include IP tunnel support, using
it in these systems will require transparent TCP proxying, with all the
complexity and ossification that implies.

*Many OSes provide a way for an HTTP or SOCKS proxy to advertise its
existence to apps, but most OSes do not provide a way to force app traffic
to go through this proxy.  IP-level tunneling, in contrast, can usually be
configured to capture all traffic unconditionally.

On Sat, Apr 11, 2020 at 5:45 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

>> With no hats, I generally agree with this assessment, modulo the bit
>> about removing IP from the charter. We can always tackle it last without
>> taking any steam out of the UDP and TCP efforts.
>>
> details for now), but they want to add support for UDP and IP in Release
> 17 (so, that's a study item now).
>

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 13 Apr 2020 23:36:45 -0400

I think the question is not "do protocols other than TCP and UDP exist",
but more of L3 vs L4 proxying.  L3 forwarding is usually easier to
implement consistently, since it involves creating and configuring a TUN
device and using OS-level mechanisms to ensure all of the traffic goes
there.   L4, on the other hand, requires cooperation from individual
applications.  Of course, *terminating* an L4 proxy is much easier than
terminating a VPN, so they have different applicability domains.

On Fri, Apr 10, 2020 at 2:10 PM Eric Rescorla <[email-masked]> wrote:

> I've got some bad news for you.....
>
> -Ekr
>
>

---

From: Andreas Kassler <[email-masked]>
Date: Tue, 14 Apr 2020 06:59:05 +0000

Its perfectly possible to implement a L4 proxying solution that does NOT require cooperation from the applications. You would create a TUN device and implement a scheduler that schedules IP packets entering the TUN device over different L4 connections that span from the TUN device to the proxy. The proxy can optionally implement reordering methods. By doing so, you could use individual TCP tunnels, MP-TCP tunnels, MP-QUIC tunnels or DCCP tunnels to tunnel IP packets. 
Please see https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-mpdccp-01
for more information. There is also a LCN 2019 paper on this with performance evaluation.

Andreas

> On 14 Apr 2020, at 05:36, Victor Vasiliev <vasilvv=[email-masked]> wrote:
> 
> I think the question is not "do protocols other than TCP and UDP exist", but more of L3 vs L4 proxying.  L3 forwarding is usually easier to implement consistently, since it involves creating and configuring a TUN device and using OS-level mechanisms to ensure all of the traffic goes there.   L4, on the other hand, requires cooperation from individual applications.  Of course, terminating an L4 proxy is much easier than terminating a VPN, so they have different applicability domains.
> 
> On Fri, Apr 10, 2020 at 11:00 AM David Schinazi <[email-masked]> wrote:
> What about them? Pretty much any modern application layer protocol has to be designed under the assumption that they don't exist.
> 
> 
> Apologies for being slow on the uptake, but what is the use case for IP proxying? For a VPN scenario, simply assigning a stream to each TCP and UDP flow the client wants should be sufficient, no?
> 
> Martin
> -- 
> Masque mailing list
> [email-masked]