4 ms·

TCP-in-UDP Solution (eBPF)

88 points by todsacerdoti 1y ago

1oooqooq 1y ago
> This solution relies on eBPF, doesn’t add extra data per packet so none of the security recomendations such exchanging hmac keys and segment counts?
willprice89 1y ago
I know it isn't the intended use case but I wonder how this would perform as a censorship circumvention method. The translation alone may be enough of a change to avoid the pattern matching used by firewalls.
- kreetx 1y ago
  But circumventing censorship does seem to be the intended use case, no? At leas that's how I read the article.
  - zamadatix 1y ago
    The article is focused on general ossification of TCP preventing newer improvements from functioning. E.g. "performance enhancing proxies" from the article is not a euphemism for censorship, it's boxes design to do one thing with TCP which ends up breaking something for MPTCP. Any bypassing of censorship by avoiding ossification is completely incidental (and likely some extremely bad censorship if it just allows any protocol it can't filter through).
  - lxgr 1y ago
    I wouldn't expect this to fare any better at evading deep packet inspection than any other current technique.
- Hikikomori 1y ago
  Might get through if they're incompetent, ie maybe works in your typical enterprise environment. If they're competent they wouldn't allow udp at all, if they do they'll only allow specific things.
- Calwestjobs 1y ago
  90% of IDS, spyware, ADVERTS does not support ipv6... That is why most of (public) internet is not on IPV6 And what is most embarrassing is that truly fully IPV6 capable internet requires less of and lower powered "routers". "routers" will cost single thousands instead of hundred of thousands adn be more capable, speeedier. DDoS mitigations are easier in ipv6 too. And if every customer can have 2^64 IP (or even 2^56) addresses then you do not need "ports" anymore, every service on your server can have their own IP, or even every service customer can have their own ip address how much will that simplify CODE (source of bugs, of latency, of unnecessary payments) and lower energy requirements of login infrastructure ? and debugging ? also just right from bat you can trivially see on upstream router who is initiating DOS... PKI+IPv6 is gift from GODs! If your certificate is not issued for specific ip then "openssl" can drop connection in that instance. Is not that little bit more secure ? faster? less clunky. and with more oversoght for network "manager" ?
  - Calwestjobs 1y ago
    Israeli "network traffic monitoring hw used by law enforcement" was deployed in one European country and after few years of deployment public officials embarrassingly confessed that, device was not capable of monitoring IPv6 at all XD just sayin. people expect things working but even west devices are embarrassingly nonsensically flawed. Huawei / zte etc stealing sourcecode and blatantly copying it is even worse situation because they do not even understand how it should work. XD
  - h4ck_th3_pl4n3t 1y ago
    So what are you using? Is there a softrouter using mutual TLS over IPv6 that you can recommend?
  - immibis 1y ago
    Around 50% of internet packets are IPv6. It's not the future. It's now the present, and IPv4 is the past. It's a shame they still have ports in IPv6, but I can see why: imagine having to ARP (IPv6 calls it ND) every connection separately. At least you can just allocate another privacy address if you need more than 65535 concurrent connections to the same destination.
  - 1y ago
- Bluecobra 1y ago
  It depends on the firewall. For example, a Palo Alto can match by application and do SSL decryption in where the firewall acts as a MITM. A locked down environment would likely only allow SSL on TCP/443, and block UDP/443 to deny QUIC. An application that breaks RFC would likely be blocked. It’s also common to block unknown TCP/UDP applications.
zerof1l 1y ago
Makes total sense to me. But why hasn't this been done a long time ago? Pretty sure people spotted this earlier in TCP and UDP but this was never implemented?
- kev009 1y ago
  Netflix was investigating this a while ago (https://reviews.freebsd.org/D15525 https://reviews.freebsd.org/D15525 - "TCPOUDP")
purplehat_ 1y ago
Cool article! L4 stuff is always fun to read about :) Since TCP-in-UDP seems to be involve implementing end-to-end features over UDP, I feel like a comparison to multipath QUIC might be helpful so that we can understand it better. My impression from reading about HTTP/3 is that QUIC is just kind of better than TCP in performing a lot of end-to-end functions, like recovery, encryption, error correction, duplicate suppression, congestion control, and delivery acknowledgement, and of course multiplexing the connection. (The advantage of TCP seems like its simpler and more mature, but it's honestly not clear to me where TCP wins and I'd be interested in hearing about the situations in which TCP is better than QUIC.) So if we're addressing middleboxes screwing with MPTCP by tunneling TCP over UDP, isn't this very similar to what multipath QUIC does? The article seems to argue this is a simpler, lower-overhead solution than VPN tunnels, which I agree, that would seem like the wrong tool for the job, but I can't really tell which of multipath QUIC and MPTCP-over-UDP is simpler; they seem really similar to me and I'd appreciate help differentiating them. When would one prefer MPTCP-over-UDP over multipath QUIC, and vice versa? How do the two differ in functionality, stability, and ease-of-use?
- the_precipitate 1y ago
  TCP-in-UDP keeps TCP's battle-tested logic but wraps it to bypass middleboxes—great for legacy systems. QUIC is a clean-slate rewrite, better for new apps. Tradeoff: compatibility vs modern features.
  - lxgr 1y ago
    By wrapping TCP in UDP, you essentially lose all benefits of compatibility, though. If neither middleboxes nor your OS are involved, there's not much left to be compatible with.
- lxgr 1y ago
  TCP is a protocol with multiple implementations for several core aspects (most importantly congestion control and loss handling), so it's not exactly 1:1 comparable with QUIC, which currently is essentially both a protocol and an implementation.
Calwestjobs 1y ago
I love any packet which has length field right after destination field. makes processing little bit faster.
somanyphotons 1y ago
I can see that using eBPF would help backport to older kernel, but would the long term goal be to add this as a kernel patch?

88 points by todsacerdoti 1y ago

> This solution relies on eBPF, doesn’t add extra data per packet so none of the security recomendations such exchanging hmac keys and segment counts?

willprice89 1y ago

I know it isn't the intended use case but I wonder how this would perform as a censorship circumvention method. The translation alone may be enough of a change to avoid the pattern matching used by firewalls.

kreetx 1y ago
But circumventing censorship does seem to be the intended use case, no? At leas that's how I read the article.
- zamadatix 1y ago
  The article is focused on general ossification of TCP preventing newer improvements from functioning. E.g. "performance enhancing proxies" from the article is not a euphemism for censorship, it's boxes design to do one thing with TCP which ends up breaking something for MPTCP. Any bypassing of censorship by avoiding ossification is completely incidental (and likely some extremely bad censorship if it just allows any protocol it can't filter through).
- lxgr 1y ago
  I wouldn't expect this to fare any better at evading deep packet inspection than any other current technique.
Hikikomori 1y ago
Might get through if they're incompetent, ie maybe works in your typical enterprise environment. If they're competent they wouldn't allow udp at all, if they do they'll only allow specific things.
Calwestjobs 1y ago
90% of IDS, spyware, ADVERTS does not support ipv6... That is why most of (public) internet is not on IPV6 And what is most embarrassing is that truly fully IPV6 capable internet requires less of and lower powered "routers". "routers" will cost single thousands instead of hundred of thousands adn be more capable, speeedier. DDoS mitigations are easier in ipv6 too. And if every customer can have 2^64 IP (or even 2^56) addresses then you do not need "ports" anymore, every service on your server can have their own IP, or even every service customer can have their own ip address how much will that simplify CODE (source of bugs, of latency, of unnecessary payments) and lower energy requirements of login infrastructure ? and debugging ? also just right from bat you can trivially see on upstream router who is initiating DOS... PKI+IPv6 is gift from GODs! If your certificate is not issued for specific ip then "openssl" can drop connection in that instance. Is not that little bit more secure ? faster? less clunky. and with more oversoght for network "manager" ?
- Calwestjobs 1y ago
  Israeli "network traffic monitoring hw used by law enforcement" was deployed in one European country and after few years of deployment public officials embarrassingly confessed that, device was not capable of monitoring IPv6 at all XD just sayin. people expect things working but even west devices are embarrassingly nonsensically flawed. Huawei / zte etc stealing sourcecode and blatantly copying it is even worse situation because they do not even understand how it should work. XD
- h4ck_th3_pl4n3t 1y ago
  So what are you using? Is there a softrouter using mutual TLS over IPv6 that you can recommend?
- immibis 1y ago
  Around 50% of internet packets are IPv6. It's not the future. It's now the present, and IPv4 is the past. It's a shame they still have ports in IPv6, but I can see why: imagine having to ARP (IPv6 calls it ND) every connection separately. At least you can just allocate another privacy address if you need more than 65535 concurrent connections to the same destination.
- 1y ago
Bluecobra 1y ago
It depends on the firewall. For example, a Palo Alto can match by application and do SSL decryption in where the firewall acts as a MITM. A locked down environment would likely only allow SSL on TCP/443, and block UDP/443 to deny QUIC. An application that breaks RFC would likely be blocked. It’s also common to block unknown TCP/UDP applications.

zerof1l 1y ago

Makes total sense to me. But why hasn't this been done a long time ago? Pretty sure people spotted this earlier in TCP and UDP but this was never implemented?

kev009 1y ago
Netflix was investigating this a while ago (https://reviews.freebsd.org/D15525 https://reviews.freebsd.org/D15525 - "TCPOUDP")

purplehat_ 1y ago

Cool article! L4 stuff is always fun to read about :) Since TCP-in-UDP seems to be involve implementing end-to-end features over UDP, I feel like a comparison to multipath QUIC might be helpful so that we can understand it better. My impression from reading about HTTP/3 is that QUIC is just kind of better than TCP in performing a lot of end-to-end functions, like recovery, encryption, error correction, duplicate suppression, congestion control, and delivery acknowledgement, and of course multiplexing the connection. (The advantage of TCP seems like its simpler and more mature, but it's honestly not clear to me where TCP wins and I'd be interested in hearing about the situations in which TCP is better than QUIC.) So if we're addressing middleboxes screwing with MPTCP by tunneling TCP over UDP, isn't this very similar to what multipath QUIC does? The article seems to argue this is a simpler, lower-overhead solution than VPN tunnels, which I agree, that would seem like the wrong tool for the job, but I can't really tell which of multipath QUIC and MPTCP-over-UDP is simpler; they seem really similar to me and I'd appreciate help differentiating them. When would one prefer MPTCP-over-UDP over multipath QUIC, and vice versa? How do the two differ in functionality, stability, and ease-of-use?

the_precipitate 1y ago
TCP-in-UDP keeps TCP's battle-tested logic but wraps it to bypass middleboxes—great for legacy systems. QUIC is a clean-slate rewrite, better for new apps. Tradeoff: compatibility vs modern features.
- lxgr 1y ago
  By wrapping TCP in UDP, you essentially lose all benefits of compatibility, though. If neither middleboxes nor your OS are involved, there's not much left to be compatible with.
lxgr 1y ago
TCP is a protocol with multiple implementations for several core aspects (most importantly congestion control and loss handling), so it's not exactly 1:1 comparable with QUIC, which currently is essentially both a protocol and an implementation.

Calwestjobs 1y ago

I love any packet which has length field right after destination field. makes processing little bit faster.

somanyphotons 1y ago

I can see that using eBPF would help backport to older kernel, but would the long term goal be to add this as a kernel patch?