Em 27-01-2014 14:30, Nick Bender escreveu: > On Mon, Jan 27, 2014 at 8:19 AM, Simon Perreault < > simon.perrea...@viagenie.ca> wrote: > >> Le 2014-01-25 14:40, Richard Procter a écrit : >> >> I'm not saying the calculation is bad. I'm saying it's being >>> calculated from the wrong copy of the data and by the wrong >>> device. And it's not just me saying it: I'm quoting the guys >>> who designed TCP. >>> >> Those guys didn't envision NAT. >> >> If you want end-to-end checksum purity, don't do NAT. >> >> Simon >> >> > Relying on TCP checksums is risky - they are too weak. > > I live at the end of a wireless link that starts at around 7K feet > elevation, goes over a 12K foot ridge, lands at my neighbors roof at 10k > feet and then bounces across the street to my house. At one point I was > having lots of issues with data corruption - updates failing, even images > on web pages going technicolor half way through the download. The ISP > ultimately determined there was a bad transmitter and replaced it. The > corruption was so severe that it was overwhelming the TCP checksums to the > point that as far as TCP was concerned it was delivering good data (just > not the same data twice :-). Until they fixed the issue I was able to run a > proxy over ssh which gave me slower but reliable network service. > > -N > I had the same issue on a different scenario. I traveled to a place where the internet connection was so slow and so unreliable, that almost all https handshakes would never complete. And yet checksums had a rate of almost 60% of them being ok. That's why I always have a VPN server lying around, to route my traffic to. In my experience, on very unreliable connections, a UDP vpn, such as openvpn, saves the day. NAT should (and will) have a very slow and painful death. But, then again, IPv4 is about to die for more than a decade, and it's still here. I guess the death will be very, very, very slow.
Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
