Proxying of IP packets

[mirjak]

So there are two scenarios here: One is the network-to-network where the client receives and IP and feeds that into the QUIC tunnel to the proxy. The other scenario, e.g. in the VPN case, is where the client is the origin of the data transfer. In this case it could be easier if the client only feeds the IP payload into the tunnel and does need to worry about the IP header at all. I would like to see both cases covered in the base protocol as any function that is needed between the client and proxy in order for the proxy to create the IP header will be needed to be implemented for CONNECT-UDP case anyway.

[DavidSchinazi]

@mirjak can you elaborate on your use-case? Where are you thinking of deploying it, on what kind of network and with what kind of traffic?

[achernya]

I believe the scenario Mirja describes as "in the VPN case [...] easier if the client only feeds the IP payload into the tunnel and does need to worry about the IP header at all" is not an accurate representation of VPN technologies today. Commercial VPN providers, such as Palo Alto Networks, Cisco AnyConnect, as well as open source solutions like Wireguard all operate at the virtual NIC level, providing an OS-level network device and altering routing tables. This is at odds with the model of having the endpoint provide the IP headers. (In fact, the VPN client software would have to go out of its way to remove the IP headers installed by the OS)

I believe the single IP endpoint model described here that allows eliding the IP header to be an edge case.

What use case would want a single IP endpoint that would not be better served by CONNECT or CONNECT-UDP? I suppose ICMP is a possibility, but that's generally unreliable on the open internet and we can also provide those signals through a side-band on CONNECT/CONNECT-UDP.

[mirjak]

The single IP endpoint model, as you name it, is what we have in mind for ATSSS in 3GPP. There is already a solution for TCP and CONNECT-UDP would address QUIC traffic, however, a tunnel based solution in a mobile network would also be required to handling any other kind of IP traffic.

[achernya]

Thank you for providing a specific use case, the ATSSS for 3GPP. Could you please help me understand what sort of IP traffic exists on the mobile networks that you need to handle that cannot already be handled with CONNECT or CONNECT-UDP? I would have expected the vast majority of mobile traffic to be TCP or QUIC already, which if true, means that any non-TCP, non-UDP IP traffic should be comparatively rare and has very different design requirements. Further, I'm curious to learn what these non-TCP, non-UDP traffic are such that it would be easier for the userspace application to construct the payload directly rather than using OS-level APIs that will produce an IP packet.

[mirjak]

Most traffic on mobile network is TCP or UDP, however, as there is a requirement from 3GPP that a multipath solution should be able to address all kind of traffic as mobile networks are a general purpose network. And I guess there are actually also newer use case for e.g. industry automatisation where you might expect a lot more other kind of traffic.

[chris-wood]

Based on the previous meeting show of hands and April 27 consensus call, there is consensus to close this issue without any change. (That is, support for proxying packets remains a core requirement, and the document will neither require nor prohibit support for proxying payloads.)

[mirjak]

I just want to record here that I don't think there was consensus on taking one or the other approach. And I would still like to see an additional requirement that the base protocol should also consider to IP proxying where unmodified forwarding of the entire IP header is not required.