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.
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.
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" ?
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.
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?
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?
10 comments
[ 5.8 ms ] story [ 29.4 ms ] threadAnd 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" ?
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?
so none of the security recomendations such exchanging hmac keys and segment counts?