Hacker News Reader

> Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs... > So - surprise! - you have no choice but to design a TCP clone.

Some use cases don't really want TCP or a TCP clone, for example multi-player games might only use a semi-reliable loss detection system which has ACK's but does not attempt retransmission on failure to deliver. This works a lot better than TCP for that use case, and is not really a "TCP clone".

The really sad thing about this though is that "the internet" no longer works for stuff which isn't TCP. I guess it does, but not for your whole target market.

The lowest common denominator is users behind an NTLM proxy. Mass market products don't generally work unless they have a fallback which is "I can make it tunnel through proxies". Which is HTTP or CONNECT :( Which means no teams will do something which isn't TCP anymore, since it's not a thing they can tunnel :( Interested in counterexamples though.

This is the same reason why a UDP replacement is a great idea but a waste of time for most people developing a product. This makes me sad.

As mentioned upthread, most multiplayer games are still UDP. And indeed, they generally don't work through proxies.

You have it the wrong way around. People who cordon themselves off and only leave HTTP working aren't on the Internet.

They don't want non-web apps to work. Those networks deliberately rule out networked games, uTP, VoIP, IPsec, WebRTC, etc.

If you want to worry about people teetering on the edge of the Internet, you should worry about people behind NAT and its prevalence to the point of people confusing NAT boxes and routers...

(Re your last sentence, it's not a UDP replacement, see other comments.)

From quic_protocol.h:

  // Defines for all types of congestion feedback that will be negotiated in QUIC,
  // kTCP MUST be supported by all QUIC implementations to guarantee 100%
  // compatibility.
  enum CongestionFeedbackType {
    kTCP,  // Used to mimic TCP.
    kInterArrival,  // Use additional inter arrival information.
    kFixRate,  // Provided for testing.
  };

:-)

Actually, there are also "scavenger" congestion control algorithms that use leftover bandwidth. The most high-profile example is LEDBAT used by BitTorrent's uTP. uTP is indeed a TCP clone, but I had my chance to develop a protocol which was using LEDBAT and it was NOT a TCP clone at all (it later became IETF PPSP). So, TCP eating all the bandwidth is not an issue sometimes.

uTP is designed to let TCP eat all the bandwidth on saturated links, and generally defer to TCP whenever possible. For BitTorrent, that's exactly what you want. For web browsing, you probably want to be more aggressive. I skimmed the source code, and it looks like they're using the same CUBIC congestion control algorithm that Linux's TCP stack has been using by default since 2007.

http://en.wikipedia.org/wiki/CUBIC_TCP

I agree with your original point, but none of the stuff after [EDIT] makes much sense to me.

"Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet."

I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption thingy you use. Otherwise, any modern TCP stack should be able to reject blind FINs or RSTs as out-of-sequence.

Generally, the reason people avoid TCP-over-TCP is not DoS, but basically "timer fights", as per: http://sites.inka.de/~W1011/devel/tcp-tcp.html. That said, everything-over SSL is still popular for practical reasons, such as clientless VPNs which need to work around proxies, firewalls etc.

No, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet.

More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.

Blind, or with some way to observe the sequence numbers?

If it's blind (e.g. window guessing) I'm interested in what your techniques are.

If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that.

Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :)

tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 16284/nc

If you can terminate it with a FIN or an RST in the next hour, I'll post proclaiming your victory. If either the box or my local link drops, we'll call it a draw.

There aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack.

EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.

Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing...

Also, crap, I'm an idiot. Let me do that non-natted ;)

tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc

Write failed: Broken pipe

Well done! Also, you didn't packet me off the Internet, which was nice :)

Bet you can't do it with one packet though!

Sorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?

Nah not silly questions at all.

I changed the remote port from 80 to 4007 because I figured my web server might get DoS'd :)

I have a crappy cable modem which is kind of a "research problem" to root, so I did the netstat on the web server end to get the local port.

Could it have been your NAT which terminated the connection due to inactivity ?

Quite a few stacks have implemented RFC5961, which should make this attack rather challenging.

(Though, I totally agree with the fundamental problem).

PREFIX: this is going to sound really cynical. Also, I haven't read RFC5961, so thanks :)

Yeah, actually it might have been. But I prefer to give HN the benefit of the doubt.

Umm I try and be gentle. But let's talk about the fundamental problem, since you appear to understand it.

TCP-RST DoS is like the worst denial of service ever, since it has such massive negative amplification. You're spending like something like 30k * (required window guess packets) to interrupt one connection, which requires like say less than 10 packets to re-establish. Unless you're talking about BGP, which shit, we normally use TCP-MD5 for anyway. Even commodity home bullshit throws most of your packets away for free.

I take things quite slowly. The normal HN methodology is to go "Incorrect. blah blah blah.". Reality is nuanced and complicated. I try and avoid doing that, because honestly most statements are actually right when you squint at them the right way. Unfortunately, I get the most fake internet points when I say stupid and ultimately unsupportable bullshit while drunk. I still try to avoid doing that :/ But ahhhh here I go anyway.

The nuanced version of this is that most people's devices are going to get DoS'd way harder by fake ipsec traffic which forces checksums in CPU than it is by out of sequence packets which get handled in hardware.

But why don't we live in this fantasy world where we can all terminate TCP connections with imaginary sniper packets and ipsec solves everything.

> fake ipsec traffic

..., most of it, is filtered out by the replay protection at virtually no processing cost. The HMAC verification is not exactly a CPU killer either, even less so if there's some sort ASIC/accelerator involved, which won't be that unusual if there is an IPsec involved.

To not multiple the comments - what I said above about a single TCP packet obviously implies being on the route between the parties.

> ..., most of it, is filtered out by the replay protection at virtually no processing cost

Really? Think about that and reply, given the ability of your adversary to send arbitrary traffic.

> To not multiple the comments - what I said above about a single TCP packet obviously implies being on the route between the parties.

How is this seriously distinguishable from MITM? I mean what the hell. Come on you're stretching definitions here.

Uhhh anyway, I think in about 5 years you might be right. Practically speaking no consumer hardware has ipsec embedded but hopefully everyone will in the next few years.

The last time I was in Taiwan working on ASIC hardware none of the white brands did (and most of the big brands are just buying that crap and re-labelling it). Yeah designed in $country? Nah. Taiwan is super good at design, they just need the vendor and the label on the box. Anwyay, that was 2 years ago though, and I was just doing consumer bullshit.

In case you're interested (and you're probably not) the ASIC NAT hardware was the only there coz it enabled the anemic CPU to NAT at the box rated speed. Unfortunately it also turns out, that's why most home users can't seriously torrent or do nice things :( Damn ASICs.

People wonder sometimes why "open source" version is more expensive, and in terms of consumer routers, it's because the pure linux versions don't have the secret sauce. You gotta use more CPU and memory. It's a worthwhile trade-off for not putting up with a real RTOS. But also, good luck MIMO 450 Mbps wireless N using just the broadcom CPU at the rated Mhz :) I'm not even sure if they license the drivers for open source now, I know they definitely didn't before.

There are some really hilarious things which happen where like $marketing from $vendor decide that not only they need a custom enclosure (everyone needs that), but that the box would look way better if the antennas were arranged in certain way. This triggers multiple all-nighters from the engineers who have to relayout the boards and redo the EMC tests.

Wait, I'm way off topic. I think my original point is that you probably don't have ipsec in hardware at home. I await brutal smackdown, coz the community is knowledgable.

"Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions."

Maybe I'm missing something (likely) but it seems to me any potential replacement for UDP specifically doesn't care about packet loss, acks, etc. The whole point of UDP is speed over reliability, yes?

Yea you end up with a udp retrans storm on saturated links. It will start losing the rerequests and the rerequest for the lost packets.

Some solutions to this use tcp to do the resetting of the connection.

TCP has more than a few other issues as well, not the least of which is that signalling for those windowing semantics doesn't effectively distinguish between congestion and packet loss.