Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why TCP Over TCP Is a Bad Idea (2001)

sites.inka.de

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Why TCP Over TCP Is a Bad Idea (2001)

#31

Post by beefsack »

rahimnathwani wrote: post #27
beefsack wrote: post #18

Earlier quoted context omitted.

TCP over TCP for VPN is pretty useful in places where deep packet inspection blocks UDP by default, eg. GFW in China.

Do you have any information you can share about this? A few years ago, I could reliably use OpenVPN over UDP, as long as I switched ports out frequently. Some time ago (I don't remember when), this ceased to be the case, and I switched to PPTP and, more recently, Shadowsocks. What has been your experience with UDP over GFW?

UDP used to work (~3 years ago) but currently it's blocked wholesale. OpenVPN over TCP gets throttled and blocked thanks to DPI too, an obfuscation layer is required because OpenVPN traffic is identifiable due to a fairly unique encryption fingerprint.

http://blog.strongvpn.asia/china-blocking-udp-ports/

Re: Why TCP Over TCP Is a Bad Idea (2001)

#32

Post by beefsack »

duskwuff wrote: post #25
droopyEyelids wrote: post #24

Earlier quoted context omitted.

Do you have any idea why the GFW blocks UDP by default? I can imagine that for corporate networks, but as far as I know, uninspectable UDP streams only recently came into existence with Google's QUIC (which assumes pre-negotiated encryption keys are still valid) Why block all streams if you can inspect them (or at least their handshake)?

Probably because they determined that most of it was VPN or other encrypted traffic, and that blocking it was easier than trying to inspect it.

While practically no official information exists publicly, this appears to be the reason. My gut tells me that the lack of structure in UDP makes it a little harder to inspect too.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#33

Post by rahimnathwani »

beefsack wrote: post #31
rahimnathwani wrote: post #27

Earlier quoted context omitted.

Do you have any information you can share about this? A few years ago, I could reliably use OpenVPN over UDP, as long as I switched ports out frequently. Some time ago (I don't remember when), this ceased to be the case, and I switched to PPTP and, more recently, Shadowsocks. What has been your experience with UDP over GFW?

UDP used to work (~3 years ago) but currently it's blocked wholesale. OpenVPN over TCP gets throttled and blocked thanks to DPI too, an obfuscation layer is required because OpenVPN traffic is identifiable due to a fairly unique encryption fingerprint. http://blog.strongvpn.asia/china-blocking-udp-ports/

Thanks. This is totally consistent with my experience, and it's good to know that it's not just me :)

Re: Why TCP Over TCP Is a Bad Idea (2001)

#35

Post by chias »

IgorPartola wrote: post #28
chias wrote: post #22

Earlier quoted context omitted.

> It's never a good idea. I disagree with that profoundly: I read the article. Yes, TCP over TCP include unnecessary performance-harming features in certain circumstances, because you have two unrelated collision avoidance systems running at the same time. Even so, in many scenarios TCP over TCP is an excellent idea: it can provide you with many benefits, in practical terms works great, and has no readily-available a…

TCP over UDP.

So sitting at starbucks with my laptop -- what do i do? I am not aware of an option to have SSH run over UDP, although I do know that some VPNs allow you to use UDP instead of TCP.

Unless there is a relatively simple way of getting an encrypted tunnel for my HTTP traffic using tools like ssh and netcat and other things I'm likely to already have installed, I disagree with the notion that it's never a good idea.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#36

Post by chias »

zrm wrote: post #23
chetanahuja wrote: post #8

Earlier quoted context omitted.

Completely agree with your righteous rage about TCP over bad connections. I allowed myself a bitter chuckle to the GP's "networks are generally pretty reliable" thing. Minor disagreement though: "Edit: the only downside of UDP VPNs is that stateful firewalls can have extremely short timeouts of UDP "connections" (e.g. 30 seconds!)" Plenty of mobile networks will timeout inactive TCP connections in less than 30 second…

Timeouts that short violate RFCs. Established TCP connections can't be abandoned unless idle for two hours four minutes (RFC5382 REQ-5) and even UDP timeouts normally have to be at least two minutes (RFC4787 REQ-5). If people are violating the RFCs then applications that detect it should probably start notifying users exactly why their battery life is suffering.

I see a lot of "should"s. When push comes to shove, though, a notification is not going to change the behavior of the network.

There's a lot of complaints I have about how some networks (especially mobile ones) deviate from RFCs and break specifications. A 30 second timeout is not nearly at the top.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#37

Post by seunosewa »

apenwarr wrote: post #21

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. https://github.com/apenwarr/sshuttle

Please explain how it avoids TCP-over-TCP. It doesn't seem to me that multiplexing multiple TCP connections over a single TCP link avoids the problem.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#38

Post by chubot »

seunosewa wrote: post #37
apenwarr wrote: post #21

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. https://github.com/apenwarr/sshuttle

Please explain how it avoids TCP-over-TCP. It doesn't seem to me that multiplexing multiple TCP connections over a single TCP link avoids the problem.

Why wouldn't it? There aren't 2 TCP stacks. There aren't 2 timers as described in the article. I think the burden of proof is on you.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#39

Post by apenwarr »

seunosewa wrote: post #37
apenwarr wrote: post #21

UDP (and datagrams in general) are not the only alternative to TCP-over-TCP. My sshuttle VPN uses TCP but avoids the TCP-over-TCP problem. https://github.com/apenwarr/sshuttle

Please explain how it avoids TCP-over-TCP. It doesn't seem to me that multiplexing multiple TCP connections over a single TCP link avoids the problem.

TCP congestion control fundamentally depends on packet loss to know when to slow down. If the outer TCP makes sure packet loss doesn't happen - because if it does, it retransmits - then the inner TCP won't know what's going on, and will send as fast as it can, creating a mess.

The trick with sshuttle is that you terminate the TCP sessions at the server, and just send the raw data over the multiplexed link; there are no inner TCP headers anymore. Then you add them back at the other end by reconstructing a new TCP session. This eliminates the second layer of TCP congestion control inside the tunnel.

Re: Why TCP Over TCP Is a Bad Idea (2001)

#40

Post by IgorPartola »

chias wrote: post #35
IgorPartola wrote: post #28

Earlier quoted context omitted.

TCP over UDP.

So sitting at starbucks with my laptop -- what do i do? I am not aware of an option to have SSH run over UDP, although I do know that some VPNs allow you to use UDP instead of TCP. Unless there is a relatively simple way of getting an encrypted tunnel for my HTTP traffic using tools like ssh and netcat and other things I'm likely to already have installed, I disagree with the notion that it's never a good idea.

When you are running a SOCKS proxy through ssh, you are not doing TCP over TCP. We are talking about things like OpenVPN which can do TCP over TCP, but that is generally a bad idea. It's default mode is TCP over UDP, as it should be.
Post reply on HN