LWN: Comments on "Foo over UDP"

Foo over UDP

elic307 — Tue, 25 Jun 2019 10:25:27 +0000

As far as I understand, fou allows for generic encapsulation; it can be IP or Ethernet.
The receiver does not know what is encapsulated so you have to tell it explicitly. When you say ipproto 4 you let it know that IPv4 is encapsulated.

Foo over UDP

flussence — Thu, 12 Nov 2015 20:56:05 +0000

Well I went looking for the documentation and came back empty-handed. My bad.

lksctp-tools and the kernel code make mention of tunnelling udp/tcp inside sctp, but not vice-versa. I may have been misremembering based on that.

Foo over UDP

tysonite — Wed, 11 Nov 2015 19:56:56 +0000

I am not aware of how it is possible. Could you elaborate please?

Foo over UDP

flussence — Wed, 11 Nov 2015 18:13:03 +0000

I thought the existing SCTP implementation in the kernel already supported UDP tunnelling without this?

Foo over UDP

tysonite — Wed, 11 Nov 2015 16:15:53 +0000

Am I right that I can't encapsulate SCTP packets in today's implementation?
For instance, to meet requirements as stated here: https://tools.ietf.org/html/rfc6951

Access to firewalled ports

Baylink — Fri, 26 Dec 2014 15:17:16 +0000

The argument could be made -- and would and should be made -- that this isn't "internet service" and either

1) buyers should have beworn, or
2) they should get sued for not warning people that what they were advertising wasn't what they were selling,

but I understand your point of view (which, I suspect, is roughly that "retail customers can't be expected to understand the difference" and "I have shit to *do*". :-)

We weren't really talking about this particular edge case, though, I don't think.

Access to firewalled ports

nix — Sun, 14 Dec 2014 17:02:47 +0000

It's Tooway and all its resellers, a UK satellite broadband provider. They are very expensive (hundreds of quid for installation, and as much for 5GiB/month as most people would expect to pay for 100+), but if you use them it's because BT in their infinite wisdom have decided you can't get ADSL in your locality (in my parent's case, the exchange is full, and if anyone asks for ADSL they are told to pay the £250,000+ upgrade costs first) and nothing else is available. So the only people using this are a captive market, and Tooway knows it.

They actually work quite well as a service, speed-of-light-induced latency being what it is: the only real problem with them is that ToS and filtering, blocking virtually everything and thus making me feel like I'm breaking some rule whenever I dare log in to work from my parents' house, let alone set up a tunnel so I can do a git pull or some other dark and dire activity like that.

As for where this is called out in their terms of service... well, I can't even *find* the terms of service any more, they're so well hidden: when last I found them several years ago they marked almost everything as FORBIDDEN including things like 'terminal emulation': only HTTP and HTTPS were marked PERMITTED. Note: the things calling themselves terms of service on Tooway's website are for the website, not for the service. For all I know the TOS has changed, in which case this comment is mostly of historical interest. :)

I thought maybe the prohibition was due to bandwidth considerations, given that this is satellite broadband, but they allow iPlayer... so I guess not. Maybe they're caching the hell out of something and don't like things that break it, but even so, the only thing they'd save on is bandwidth to and from their Italian downlink site, not to/from orbit, and to be honest if they can afford to contract with Eutelsat for satellite service they can damn well afford decent bandwidth to their downlink site!

It's not like they can rely on everyone viewing the same thing in iPlayer at the same time: they'll be using limited downlink bandwidth from orbit for every independent viewer. This is not multicast! And terminal service does not strain it, ffs. Certainly not more than all those ack packets for an iPlayer stream (and yes, the acks do flow back, or at least *something* flows back while you're watching iPlayer, so they don't have a special optimization for that case).

Access to firewalled ports

mathstuf — Thu, 11 Dec 2014 19:35:56 +0000

Would you mind outing the offending ISP so that those with the luxury may avoid it in the future? :)

Access to firewalled ports

nix — Thu, 11 Dec 2014 17:03:47 +0000

It's only a matter of viewpoint. My mother's ISP has a transparent proxy/firewall combo in the way that blocks everything but HTTP and HTTPS, specifically calls out vaguely stated 'security' as their reason, and is completely unresponsive to requests to unblock anything else. To them, my use of httptunnel to get my SSH session (and thus much else) through their stupid block is precisely "tunneling a protocol through a port number not assigned for that purpose so that people charged with maintaining security cannot execute their responsibilities". To me, it's "getting my job done while I'm at my parents' house" and "unbreaking the Internet".

Access to firewalled ports

Baylink — Thu, 11 Dec 2014 02:40:18 +0000

Certainly, Jon.

But "using a VPN" is a different thing entirely from "tunneling a protocol through a port number not assigned for that purpose so that people charged with maintaining security cannot execute their responsibilities", surely?

Foo over UDP

malor — Sun, 12 Oct 2014 12:38:15 +0000

I don't remember seeing anything about that in the documentation, but I imagine you could probably hack the code to make it work how you wanted.

How easy that would be, though, I dunno.

Foo over UDP

mathstuf — Fri, 10 Oct 2014 11:15:14 +0000

Is there a way to hide the SSL key exchange with a password? I guess a two-factor setup would be possible as well. I'll have to look into that.

OT: SSH over UDP

nye — Thu, 09 Oct 2014 14:44:17 +0000

>You are probably looking for mosh: http://mosh.mit.edu/

I can't recommend this highly enough. It gives a great experience even over unreliable (eg. mobile or crappy NAT) links where ssh is largely unusable.

Foo over UDP

malor — Tue, 07 Oct 2014 00:23:00 +0000

Most stateful firewalls will set up an implicit accept rule allowing UDP traffic back in for a couple of minutes after you send a packet out. (in iptables, this entry goes into the ESTABLISHED table.) As long as a packet shows up at least once every couple of minutes, the connection will normally stay alive.

Details, of course, are dependent on what OS is being used on the router, its NAT engine, and its configuration. But usually, most of the time, replies are allowed back in.

I don't think I've ever been in a network that blocked OpenVPN. If you use a password, rather than an SSL key exchange, the connection just looks like random bytes. If you're using SSL certs, packet inspection can see the connection setup and key exchange, so they can tell it's a VPN. Inspection engines could block either scenario, and firewall rules could block the UDP traffic, but I've never seen either done in a guest-oriented network.

Foo over UDP

jonabbey — Tue, 07 Oct 2014 00:12:04 +0000

To ask a silly question, how are you guaranteed to receive the UDP packets sent back to you? Why wouldn't firewalls be filtering those out if you were in a hotel, etc.?

Foo over UDP

malor — Sat, 04 Oct 2014 17:11:09 +0000

>SSH tunnels are implemented over TCP, while protocols like GRE and IPIP work directly at the IP level. Increasingly, though, there is interest in implementing tunneling inside the UDP protocol.

The article doesn't hit on this, but one major reason to tunnel over UDP instead of TCP is when you're on a poor quality network.

When you're on fast, reliable bandwidth, TCP-over-TCP is fine. But as soon as you start getting packet loss, you end up with a real mess: you have two levels of TCP trying to handle retransmits and flow control. Your connection will go completely to heck with just a little bit of loss, as the inner layer fights with the outer layer, both timing out and demanding repeats of the same packets. This can cascade into total failure very, very quickly.

Tunneling over UDP avoids that whole mess; it's much, much more reliable on a poor network. This is the primary reason why I use OpenVPN in UDP mode whenever I can, rather than SSH tunneling. It's much faster on your typical crappy hotel or convention network; you can usually maintain a somewhat useful connection even on low quality bandwidth, where SSH tunneling can easily croak and die if the connection is even a little spotty.

This tunneling method would be more interesting to me, personally, if it supported good solid encryption. Plaintext tunneling, post-Snowden, strikes me as a bad idea. Yes, you can run encryption at the TCP layer, but you're giving away more data than you need to. Among other things, packet inspection engines could easily see the inner layer, and throttle or otherwise interfere with the connection based on its content, and of course more of your habits can end up in the NSA's databases.

Foo over UDP

corbet — Sat, 04 Oct 2014 12:36:56 +0000

The latter, mainly; the implementations have been augmented with FOU support. There is an RFC for GRE over UDP, at least, and the Linux code follows it.

Access to firewalled ports

gerdesj — Sat, 04 Oct 2014 11:26:30 +0000

For a similar reason I generally have my OpenVPN servers listen on 443/tcp. Client traffic looks like a https session from a web browser.

Hotels etc generally allow web traffic through unmolested. When operating on a site with a mandatory web proxy then simply use the proxy as well - if necessary via cntlm.

The main problem with tcp in tcp tunnelling is exponential standoffs making latency potentially horrendous but the general increase in bandwidth available nowadays makes this less of a problem than in the past. Maybe I ought to look into 53/udp instead 8)

Foo over UDP

tomgj — Sat, 04 Oct 2014 07:59:54 +0000

When the article says that "support has been added to the IPIP, SIT [...] and GRE [...] protocols", I am not sure whether this means that support for UDP encapsulation is in the definition / specification of those protocols, or if it means that support has been added to the implementations of those protocols within Linux. Can anyone clarify this?

Foo over UDP

josh — Fri, 03 Oct 2014 21:28:00 +0000

You could run each of those services in containers to which you assigned the corresponding service address.

Foo over UDP

noxxi — Fri, 03 Oct 2014 17:20:11 +0000

> We firewalled those ports for a reason...

Unfortunatly simple firewalling of ports is not enough today. Because most ports except http(80) and https(443) are closed today everybody is tunneling through these ports already so if you want to have security today you need to look at the application layer.

FOU just encasulates layer 3 traffic into layer 4 to pass through existing systems. This is similar to Websockets which encapsulate layer 4 capabilities into layer 7. At the end you have the same or worse security problems then before, but need more bandwith and beefier hardware to compensate for the overhead.

Foo over UDP

mbunkus — Fri, 03 Oct 2014 16:30:00 +0000

You can open ports as non-root, but you cannot assign IPv6 addresses. It would be very bad if each daemon required network admin capabilities.

Additionally selecting the correct source address for outgoing connections becomes interesting in multiple-address situations. For example, if you have a DNS master server running on a machine with three IPv6 addresses then you most likely have some slave servers somewhere else which are configured to accept notifications from certain IPv6 addresses only. Therefore you have to tell your DNS server which source address to use for outgoing packates (yes, this comes from my own experience). It increases administrative work by a considerable amount.

Access to firewalled ports

corbet — Fri, 03 Oct 2014 15:24:02 +0000

Here at LWN, we use tunnels all the time to get at stuff that we do not wish to expose to the world as a whole. That's what VPNs do too. It's not an abusive use at all.

Next time you find yourself in a hotel that thinks that IMAP, say, is a hostile protocol, you might appreciate this feature more as well.

Foo over UDP

Baylink — Fri, 03 Oct 2014 14:32:04 +0000

"they allow access to otherwise firewalled ports" our fearless editor says in the lede to this article. Says it like its a good thing, you understand...

Does that strike anybody else as a bit beyond the pale given the tenor of the front page in this week's edition? We firewalled those ports for a reason...

Foo over UDP

luto — Thu, 02 Oct 2014 21:02:21 +0000

It does, but I think you're confused for the same reason I was.

That "4" means that this is an IPIP tunnel (so the next header is IP) as opposed to, say, a GRE tunnel with a different format.

Foo over UDP

jhoblitt — Thu, 02 Oct 2014 20:55:08 +0000

Why wouldn't the nested IP header have a valid protocol field?

Foo over UDP

josh — Thu, 02 Oct 2014 19:35:50 +0000

With IPv6, I wonder to what extent we need port numbers. Just give each machine a range of addresses large enough to give a unique one to each of its services, and let each address correspond to exactly one service.

Foo over UDP

drag — Thu, 02 Oct 2014 17:47:25 +0000

Tunneling is interesting in itself to work around some of the natural deficiencies in IP networking.

For example with mobile networking I can setup a laptop or smartphone to use a 'tinc'-based VPN. This allows for more of a 'mesh' style VPN networking rather then a traditional 'hub and spoke' style networking. Tunnels can be setup to work on a best-effort basis. So if I am on my private network it connects to the vpn to internal addresses, when I am on a public network it connects to the public points I have setup. It can use udp or tcp, etc etc.

What this gets me (at least in theory) is then a continuous, persistent, private network connection regardless of were I am at. That way I, although it isn't perfect, can keep a persistent network connection for things like ssh and whatnot. I don't end up using it a whole lot this way, but it's pretty handy.

Tunneling can actual alleviate a whole host of issues associated with TCP/IP style networking. Just like with virtual machines separating the logical from the physical has it's own benefits.

Foo over UDP

luto — Thu, 02 Oct 2014 15:47:21 +0000

And, to answer my own question for real:

On receive, the UDP header will be stripped and the payload will be processed as though it the IP sub-protocol specified in the fou configuration. If that's protocol 4 (IPIP), then the next header will be another IP header, which will be matched against an ip tunnel config.

So the RX and TX paths aren't quite as split as the article made me think.

OT: SSH over UDP

fpletz — Thu, 02 Oct 2014 09:33:24 +0000

You are probably looking for mosh: http://mosh.mit.edu/

OT: SSH over UDP

debacle — Thu, 02 Oct 2014 09:13:43 +0000

Btw. is it possible to run SSH (or a SSH tunnel) over UDP? Just curious.

Foo over UDP

luto — Thu, 02 Oct 2014 04:59:36 +0000

Is it?

The number 4 could refer to IP protocol 4, which is ipip (in the same numbering system in which TCP is 6) or to IPv4.

If it's IPIP, then does 4 mean that the UDP payload is to be treated as an IPIP payload? If so, then would 6 mean TCP on UDP on IP (as opposed to TCP on IP on UDP on IP)?

If it's the 4 in IPv4, then 6 would mean IPv6 on UDP on IPv4.

I found this bit of the article to be unclear. Looking at the patch description, I'm pretty sure it's the former. I think that the TX/RX split is a bit odd, though.

Foo over UDP

Fowl — Thu, 02 Oct 2014 03:54:33 +0000

So that it knows to treat them as IPv4 packets? Equivalent to the EtherType field in the Ethernet header, I'd imagine.

Foo over UDP

raven667 — Thu, 02 Oct 2014 03:23:23 +0000

This seems fundamentally a NAT problem, maybe the designers of IP should have given up and put port/service numbers in the IP header instead of the individual protocols, effectively making everything encapsulated in UDP, and then removing ports from TCP. It seems that in modern networking we either have stuff tunneled in UDP (VXLAN, IP, etc.) or over TCP on port 80/443 (VPNs, every kind of RPC is now JSON or XML over HTTP), every other port and IP protocol doesn't exist anymore and can't work because of NAT and overzealous firewalls.

Foo over UDP

luto — Thu, 02 Oct 2014 00:48:30 +0000

I don't understand. If I type:

# ip fou add port 5555 ipproto 4

then incoming UDP packets destined for port 5555 will have the UDP header stripped and the contents will be interpret as... what?

From the diagram, it looks like it's just an IP header in the UDP packet. But what does ipproto 4 have to do with it?