4 ms·

TCP has an advantage over UDP which hasn't been mentioned yet in this thread: it effectively prevents source IP spoofing. This is a huge issue for some UDP-base

by eeZi 11y ago

TCP has an advantage over UDP which hasn't been mentioned yet in this thread: it effectively prevents source IP spoofing. This is a huge issue for some UDP-based protocols, since it allows an attacker to send a packet with a spoofed source IP address. The response is then sent to that IP address. Protocols like DNS and NTP, which send large answers for comparatively small requests, can be misused for DDoS attacks this way (amplification).

kazinator 11y ago
This is only an advantage of TCP over raw UDP per se. Of course, the idea is that you don't use raw UDP, but you build some session layer over it. The UDP server won't reply to a spoofed client because the packet doesn't validate. For instance, the session could be encrypted (with proper integrity checks) and the spoofer doesn't have the session key. In fact, UDP servers typically handle a large number of clients with a single socket. So each `recv` system call on the UDP socket pulls a message from a different client. The source IP and port number could be used to do the basic matching of the message to the client, but then subject to more checks. This can end up being more robust than TCP. TCP can be subject to IP spoofing, and because it doesn't have the crypto, this spoofing can interfere with the session (a form of DDoS): e.g. inject bytes into the TCP stream, which then screw up the stream so that it has to be scrapped and reconnected. A UDP based protocol can robustly drop garbage, so that the session is not affected (except for the network and CPU usage of these spoofed packets).
rudolf0 11y ago
QUIC, Google's experimental TCP replacement (at least for web traffic), does in fact prevent IP spoofing. It uses token authentication instead of a handshake like TCP does. Spoofing discussion is actually the very first paragraph in its security document: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pli=1 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...
acomjean 11y ago
That and TCP can send more the 64k Bytes at a time. UDP is really fast, multicast! and when you get a message its all there (not a stream) . For large messages breaking them/ reassembling them into chunks is a pain.. By the time you do all the processing/ handshaking you end up back at TCP. Interestingly the size limit is around 64k and varries slightly between Solaris, hpux and linux.
- drblast 11y ago
  The "it's all there" part is important, and sometimes not being a stream is a big advantage. When you write a protocol using TCP you inevitably have to send the "content length" as part of the protocol, and then you have to account for spoofing of that number and other ways an attacker can create a denial of service, and also account for breaks in transmission. It's a pain in the ass for anything where you'd want to send small messages.
  - acomjean 11y ago
    I really do like that when you get a UDP message, its the whole thing is nice. UDP is awesomely easy, and I honestly liked it better as long as the messages are small. (although I'm old enough to remember whole computers with 1 UDP packet worth:64K bytes of memory, that isn't alot today) The loop and keep reading of tcp does gets tiresome, and if the sender goes down broken pipe...Memory allocation for the read... We used a lot udp and udp multicast, and it was great to be able to fire up a diagnosing tool to join the multicast group and listen in. Though in multicast the OS networking stack handles keeping your subscription, with no intervention from the software.
gnopgnip 11y ago
This is a solved problem with BCP38. By filtering ingress traffic that does not originate from the networks they claim to be from handshakeless protocols are possible and abuse is prevented.
- PhantomGremlin 11y ago
  A quick read of Wiki tells me that BCP 38 was introduced by RFC 2827 in May 2000. But it's still not a "solved problem" since many ISPs and companies don't implement it. How do you get more widespread adoption? It's been 15 years.

by eeZi 11y ago

kazinator 11y ago

This is only an advantage of TCP over raw UDP per se. Of course, the idea is that you don't use raw UDP, but you build some session layer over it. The UDP server won't reply to a spoofed client because the packet doesn't validate. For instance, the session could be encrypted (with proper integrity checks) and the spoofer doesn't have the session key. In fact, UDP servers typically handle a large number of clients with a single socket. So each `recv` system call on the UDP socket pulls a message from a different client. The source IP and port number could be used to do the basic matching of the message to the client, but then subject to more checks. This can end up being more robust than TCP. TCP can be subject to IP spoofing, and because it doesn't have the crypto, this spoofing can interfere with the session (a form of DDoS): e.g. inject bytes into the TCP stream, which then screw up the stream so that it has to be scrapped and reconnected. A UDP based protocol can robustly drop garbage, so that the session is not affected (except for the network and CPU usage of these spoofed packets).

rudolf0 11y ago

QUIC, Google's experimental TCP replacement (at least for web traffic), does in fact prevent IP spoofing. It uses token authentication instead of a handshake like TCP does. Spoofing discussion is actually the very first paragraph in its security document: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pli=1 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...

acomjean 11y ago

That and TCP can send more the 64k Bytes at a time. UDP is really fast, multicast! and when you get a message its all there (not a stream) . For large messages breaking them/ reassembling them into chunks is a pain.. By the time you do all the processing/ handshaking you end up back at TCP. Interestingly the size limit is around 64k and varries slightly between Solaris, hpux and linux.

drblast 11y ago
The "it's all there" part is important, and sometimes not being a stream is a big advantage. When you write a protocol using TCP you inevitably have to send the "content length" as part of the protocol, and then you have to account for spoofing of that number and other ways an attacker can create a denial of service, and also account for breaks in transmission. It's a pain in the ass for anything where you'd want to send small messages.
- acomjean 11y ago
  I really do like that when you get a UDP message, its the whole thing is nice. UDP is awesomely easy, and I honestly liked it better as long as the messages are small. (although I'm old enough to remember whole computers with 1 UDP packet worth:64K bytes of memory, that isn't alot today) The loop and keep reading of tcp does gets tiresome, and if the sender goes down broken pipe...Memory allocation for the read... We used a lot udp and udp multicast, and it was great to be able to fire up a diagnosing tool to join the multicast group and listen in. Though in multicast the OS networking stack handles keeping your subscription, with no intervention from the software.

gnopgnip 11y ago

This is a solved problem with BCP38. By filtering ingress traffic that does not originate from the networks they claim to be from handshakeless protocols are possible and abuse is prevented.

PhantomGremlin 11y ago
A quick read of Wiki tells me that BCP 38 was introduced by RFC 2827 in May 2000. But it's still not a "solved problem" since many ISPs and companies don't implement it. How do you get more widespread adoption? It's been 15 years.