9 ms·

A small warning about UDP based protocols

188 points by signa11 3y ago

spandextwins 3y ago
The whole tcp/ip stack and packets need to be rebuilt from the ground up. It's not the 1970s anymore.
keepamovin 3y ago
Do these amplification attacks also apply to WebRTC and WebTransport?
- devmunchies 3y ago
  Am curious about QUIC and HTTP3 as well.
  - janosdebugs 3y ago
    QUIC explicitly mentions that it is vulnerable to amplification attacks in the RFC. It suggests sending an extra packet to mitigate, at which point I believe the advantage of QUIC is lost as far as establishing connections is concerned.
    - johncolanduoni 3y ago
      I believe you're referring to the stateless retry mechanism? It's designed to be used only when the server is actually under attack (either as an amplification vector or exhaustion of its own connection capacity). The idea is that the server establishes some threshold for pending QUIC connections, and only if that is exceeded does it start requiring clients to complete the extra stateless, SYN-cookie style roundtrip to validate their source address. So it maintains the advantage of one less roundtrip than TCP+TLS unless the server is receiving large amounts of connections that are not progressing in a timely manner.
  - vasilvv 3y ago
    QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message exceeds one packet, which usually only happens if there is a post-quantum key share in it). 3600 bytes is usually enough, unless your certificate chain is too large, in which case you'd need to compress it. [1] is a nice overview of the problem. (full disclosure: I worked on some of this stuff) [0] https://datatracker.ietf.org/doc/html/rfc9000#name-address-validation https://datatracker.ietf.org/doc/html/rfc9000#name-address-v... [1] https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study https://www.fastly.com/blog/quic-handshake-tls-compression-c...
- toast0 3y ago
  WebRTC generally goes through a probing process to verify two-way connectivity before sending media. I not familiar with WebTransport. My understanding of QUIC was that the handshake was designed so the client would pad their initial datagram such that the response was of similar size, avoiding a small request/large response pattern. And that typical connection establishment did a key exchange on the first round trip; primarily for privacy, but also to confirm two way connectivity. I could be wrong though; especially around resumption and/or connection agility, where a client moves addresses and the session moves with the client.
  - kkielhofner 3y ago
    > WebRTC generally goes through a probing process to verify two-way connectivity before sending media. To expand on this WebRTC is extremely complex but it certainly has one thing in common with more traditional VoIP systems - the UDP flows for media are negotiated dynamically. You establish a signaling channel using whatever (WebRTC famously doesn't mandate a signaling protocol). This signaling channel with any authentication, verification, etc you want transports SDP (session description payload) bodies between each party (typically via a web server and websocket/datachannel/HTTP). What you end up with is a set of dynamically negotiated send/receive ports on each side and the application establishes the socket and flow between them with the receiving sockets on each side typically making sure the source IP:port pair matches what was negotiated. The listening socket on each side discards any junk that may show up from an unverified source IP:port pair. The process you're referencing to is called ICE (Interactive Connectivity Establishment). ICE is very complex but basically what ends up happening is a series of candidates of all potential IPs, source ports, etc are evaluated for bidirectional connectivity between the parties. Once a reliable session candidate is verified the rest of the media session is established using the same source and destination IP:port pairs. At the risk of getting too into the weeds WebRTC also does UDP port multiplexing so everything related to the session from ICE to the media, datachannel, etc are sent and received on the same socket. This is how you can have relatively high certainty you can establish a bi-directional flow between parties - because you only get this far when ICE has confirmed the IP:port flow on each side can reach the other.
- johncolanduoni 3y ago
  WebTransport requires an established HTTP3 (and therefore QUIC) connection or an established HTTP2 (and therefore TCP) connection, so its vulnerability to reflection attacks corresponds to the vulnerability of the underlying handshakes.
kazinator 3y ago
> That's one reason for the TCP three-way handshake. No it isn't. The TCP three-way handshake precedes all imagination of these kinds of problems. Edit: remember how that three-way handshake was susceptible to memory DoS attacks before SYN cookies were introduced to patch the problem!
- wmf 3y ago
  Maybe we should say amplification attacks are a reason why the three-way handshake hasn't been removed.
  - amtamt 3y ago
    I guess one example of this was DoS attack on Yahoo (when it was the google of its time) from a single 56k modem connection. Unfortunately can't find the original article, may be someone will share a link.
tptacek 3y ago
I mean, it’s definitely not one of the reasons for the TCP 3WH, though that may be a happy accident of it.
gary_0 3y ago
Speaking of denial of service, it looks like HN killed the guy's server. https://web.archive.org/web/20231028021348/https://boston.conman.org/2023/10/25.1 https://web.archive.org/web/20231028021348/https://boston.co...
- pronoiac 3y ago
  It responded eventually for me, but the Wayback Machine has it - https://web.archive.org/web/20231028021348/https://boston.conman.org/2023/10/25.1 https://web.archive.org/web/20231028021348/https://boston.co...
KirillPanov 3y ago
> Any time you have a UDP-based protocol where a small packet to the server results in a large packet from the server will be exploited In other news, water is wet. Seriously folks, if you don't already know this you shouldn't be designing any protocols. Datagram or stream-based. > That's one reason for the TCP three-way handshake. And its horrendous latency. All of the mitigations for that open up resource exhaustion attacks; frying pan, meet fire. There's no free lunch. Datagram protocols are not going away.
- wmf 3y ago
  I just checked Beej's Guide and there's no mention of amplification. I wouldn't be surprised if TCP/IP Illustrated doesn't teach it either. This means most people won't know about it and they won't know that they don't know. The mitigation of requiring a "SYN" style packet to be MTU-sized sounds pretty good to me. It obviously uses a little more bandwidth but the network may be underutilized on the upstream path anyway.
  - 10000truths 3y ago
    > I just checked Beej's Guide and there's no mention of amplification. I wouldn't be surprised if TCP/IP Illustrated doesn't teach it either. This means most people won't know about it and they won't know that they don't know. The issue isn't a lack of understanding of networking, it's a lack of understanding of the threat model.
- d-z-m 3y ago
  > Seriously folks, if you don't already know this you shouldn't be designing any protocols. Datagram or stream-based. I find this kind of gatekeeping distasteful. Knowing about various ways network protocols can be exploited is important, but this can be communicated without trampling curiosity.
mannyv 3y ago
None of this would be an issue if ISPs actually dropped UDP packets. They should run at a lower QoS by design. After all, the UDP spec explicitly calls out that it's unreliable. Yet IRL nobody drops them, ever, except during mitigation. Just drop them already. It's been decades.
- yjftsjthsd-h 3y ago
  > None of this would be an issue if ISPs actually dropped UDP packets. They should run at a lower QoS by design. After all, the UDP spec explicitly calls out that it's unreliable. Yet IRL nobody drops them, ever, except during mitigation. There's a difference between unreliable best-effort and "just throw out packets indiscriminatly". > Just drop them already. It's been decades. ... Decades since what? UDP is still very much in use
- chungy 3y ago
  The "U" doesn't stand for Unreliable. It's basically the simplest possible packetization that doesn't offer much of anything that the underlying IPv4/IPv6 layer doesn't, besides filtering out packets based on port numbers. It's very commonly used for games and video services, where applications can recover from the odd dropped or out-of-order packet. As the sibling comment mentions, what does "It's been decades?" supposed to imply? It's also been decades since TCP was invented, are you calling for its discontinuation too?
- 3c6bYDXLMj 3y ago
  If you could put yourself in the shoes any position/s in any organisation/s necessary to implement your grand vision, what would you do? How would you do it? This just sounds like the sort of absurd proposition that can only be made by people that don’t have a seat at the table.
- bouncycastle 3y ago
  UDP is used by Wireguard, for example. Quote from Wikipedia: "WireGuard uses only UDP, due to the potential disadvantages of TCP-over-TCP. Tunneling TCP over a TCP-based connection is known as "TCP-over-TCP", and doing so can induce a dramatic loss in transmission performance (a problem known as "TCP meltdown").
sillysaurusx 3y ago
A couple commenters have disagreed with the author saying “That’s one reason for the TCP three-way handshake”. But I’ve been implementing uTP, the UDP protocol that torrents use (https://www.bittorrent.org/beps/bep_0029.html https://www.bittorrent.org/beps/bep_0029.html) and it seems to avoid amplification attacks thanks to a three-way handshake. So the author seems correct to say it’s one (good) reason for the three-way handshake. (It turns out when you want to spider libgen for all epubs for training data, the most straightforward way to do this, apart from downloading >40TB, is to write your own torrent client that selectively recognizes epub files and fetches only those.) The uTP spec (BEP 29, linked above) also gives a good overview of why UDP is sometimes the correct choice over TCP in modern times. uTP automatically throttles itself to yield excess bandwidth to any TCP connection that wants it. Imagine trying to write an app that uses all the bandwidth on your network, without impacting anyone else on the network. You’d find it quite hard. uTP does it by embedding time deltas in the packets and throttling itself whenever the timestamp goes over ~100ms, which indicates either a connection dropout or bandwidth saturation. I.e. if your ping suddenly spikes, it’s because someone is hogging all the bandwidth. Normally you have to track down who’s doing it, like a detective hunting a murderer. But uTP knows that it’s the murderer, so it throttles itself back. Presto, perfect bandwidth utilization. But why bother with UDP? Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right? Good question, and I don’t have a good answer. Perhaps one of you can give a persuasive one, lest you agree that ISPs should just throttle UDP by design. It’s certainly simpler to solve this at a protocol level, but one could imagine a BEP that adds time deltas to the torrent spec and prevents sending pieces too quickly (“if the deltas spike, send fewer blocks per second"). It might even be simpler than bothering to reimplement TCP over UDP. But perhaps there’s a good reason. One idea that comes to mind is that the goal is to throttle sends and receives. You control your sends, but you’re at the mercy of the counterparty for receives. You’d need to keep throttle info for every peer, and notice when their pings spike, not just yours. Then you’d send fewer packets. But that’s what uTP does, and that doesn’t answer “Why do it in UDP instead of TCP?”
- habitue 3y ago
  Wait, doesn't TCP have automatic throttling too?
chmike 3y ago
The problem result from the ability to forge a fake origin IP address. This can be avoided by adding a certificate for the IP address. It adds a processing and size overhead, but it also preserves the single round trip transaction.
- tjoff 3y ago
  How do you do that and still allow access from anyone without any prior configuration?
  - jzwinck 3y ago
    One way could be to require signing with a TLS certificate whose hostname resolves to the source IP(s).
    - tjoff 3y ago
      How is that no prior configuration on the client side?
      - jzwinck 3y ago
        Clients could use the same certificate for every server, so there is only a one-time setup. Analogous to how clients need to be "configured" with an IP address, the certificate could be given to them by their internet gateway if desired.
        tjoff 3y ago
        Yeah, and in what universe could that work? I need directions. Seems far simpler to send a physical mail to the service operator who then hardcodes the IP in the server. Or, maybe do a handshake once and cache it for X amounts of time whatever makes sense for that service.
    - tonyarkles 3y ago
      When NAT gets involved things get very complicated very quickly for that. For many networks and ISPs this would need to happen at the IP egress level and couldn’t happen on the end device, since the end device doesn’t even know its own IP and neither does the on-prem router.
exDM69 3y ago
I'm starting to think that TCP is past its prime and UDP based protocols (like QUIC) are the way forward. The problem is exacerbated by TLS encryption. It requires six packets, or three round trip times, to establish a TLS over TCP connection. That is hundreds of milliseconds before a single byte of payload can be transferred. The QUIC protocol combines the three way handshake and the three way key exchange to half the time I takes to set up a connection and provides a fast start (0rtt) for resuming a previously configured connection. Additionally TCP connections do not survive a changed IP address like when changing from wifi to mobile data. The stream model of TCP with head of the line blocking is conceptually easy but ultimately the wrong model for transmitting blobs of data. Rejecting a valid packet because the order got shuffled is wasteful, when we could just as easily reassemble the packets on the receiver side (even outside the sliding window). There are a lot of times when the stream model is a good choice (dynamically generated data) but I would argue that sending sized blobs (like images) is a larger volume of traffic in terms of bytes transferred. But the OP is right, writing custom UDP protocol is fraught with peril. DDoS amplification is just one way to screw up.
- defrost 3y ago
  TCP is overkill for the vast bulk of modern data transmission by volume; "short hops" within and between data centres on backbones that have near zero error. TCP was designed for higher error rates on less reliable paths; from the clustered data centres out to the more remote home computers today is likely better than 1980s internet. There are good proposals for low error high bandwidth TCP-lite replacements that are gaining ground.
  - agumonkey 3y ago
    Could you name a few of these proposals ?
    - defrost 3y ago
      Yes. Homa for one: * (2018) https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.pdf https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.... * (2022) https://arxiv.org/abs/2210.00714 https://arxiv.org/abs/2210.00714 * (2022) https://www.theregister.com/2022/07/27/replace_tcp_datacenter/ https://www.theregister.com/2022/07/27/replace_tcp_datacente... * https://github.com/PlatformLab/Homa https://github.com/PlatformLab/Homa
imhoguy 3y ago
Crazy idea: could amplification attack be avoided by Proof of Work in the requesting UDP packet?
- michh 3y ago
  You’d have to keep track of which proofs you’ve already seen, to prevent re-use. You’d have to make sure the (source, source port, destination and destination port)-tuple is a cryptographic part of the algorithm, to prevent me using the same proof of work for like a million machines. Then there’s the issue of low power and/or battery-powered devices. You want people to be able to use your protocol without draining the battery. But by lowering the computational cost to accomodate that, you’re enabling the bad guys that can afford a fast GPU to go back to abusing the protocol cause the cost isn’t sufficiently high to deter them anymore. And I’m sure there are plenty of other things I haven’t thought of.
- iforgotpassword 3y ago
  There's an even simpler solution I've used ever since I became aware of the first amplification attacks during the 00s: either implement your own simple 3wh, or if you really want a simple request/reply protocol with no state associated, pad the request so it matches the reply in size. Sometimes your reply is large though and needs a couple dozen packets so then you're usually forced to use the first solution.
  - chmike 3y ago
    I suggested the certificate solution but it's far from being lightweight. I found a simpler solution that may fit some use cases. The client sends a request, the server returns a response that may be big that also contains a random value. The client must return this random value in a thank you message. If the server doesn't receive the thank you message, it slows down responses to that ip address and eventually blacklist it if it's repeated. From the client perspective, the answer is obtained in one round trip time. The price to pay on the server is the need to keep track of the expected thank you messages, and the throttled or blacklisted addresses.
- exDM69 3y ago
mhandley 3y ago
You can avoid being used for amplification attacks by simply requiring the request packet be at least as large as the response. Burns some extra inbound bandwidth and doesn't protect you from DoS attacks on your server, but at least avoids being used as an amplifier. Or you can implement a three-way handshake with a cookie or hash of a secret and the requestor's IP address, but just requiring large request packets is simpler if you're designing a really simple protocol.
- londons_explore 3y ago
  Being used for amplification attacks isn't bad if the amplification factor is low (ie. <5), and there is no way to chain amplifiers. You can also protect further against it by limiting the amount of un-acked data per second to each AS. Well behaved connections generally will ack nearly all data sent to them, whereas attacks will ACK none. That way, users have to wait one extra roundtrip if an attack on them is in progress - doesn't sound so bad. Amplification was only a really bad problem when amplification factors over 100 were possible.
em-bee 3y ago
TCP is like automated driving or a taxi. you get in your car, tell it the destination, and it takes you there. UDP is driving yourself. you have to adjust the speed and direction as you go. if you go to fast accidents can happen. so obviously, when using UDP you have to add safeguards against attacks, but, you get more flexibility to adjust things along the way. you are not locked into the way TCP does it, and that is the benefit of creating a UDP based protocol instead of just using TCP. TCP is not built on top of UDP, but i think it could be: https://stackoverflow.com/questions/10680592/can-tcp-be-implemented-via-udp https://stackoverflow.com/questions/10680592/can-tcp-be-impl... and it is a good idea to not just use UDP blindly, but implement the necessary saveguards on top of it. but claiming that all UDP based protocols are bad because of UDP is like saying, cars are bad because of bad drivers. (well, they are, but that's a different topic) so UDP based protocols aren't bad. only using UDP without safeguards is bad.
- rixrax 3y ago
  This is a bit similar to roll your own crypto conversation. It is fun, and a great way to learn. And once done, you should do well to never deploy your own crypto in any real life application. Friends don't let (or shouldn't at least) friends roll their own protocol over UDP either (or IP; I mean why not?). There are very few apps that have such an explicit requirements that they can't do away with TLS over any number (==2) of existing, and well known transport protocols (e.g. TCP, maybe QUIC). For presentation layer, instead of implementing their own spec, most should probably stick to Protobuf[0] (or some of it's derivatives[1]), and encode the application data into JSON. Check. Protocol design done. [0] https://protobuf.dev https://protobuf.dev [1] https://capnproto.org https://capnproto.org
  - em-bee 3y ago
    i don't quite agree because there are legitimate uses for UDP, but there are no legitimate uses for hand rolled crypto (except learning). also the issues with UDP mentioned in the article can easily be mitigated, which is not at all true for issues with hand rolled crypto. and there is one important use for UDP that is not well served with TCP or QUIC, which is tunneling. tunneling TCP over TCP does not work very well. also, the feature of mosh to keep a connection alive over network changes may not be easy to implement over TCP, i am not sure.
api 3y ago
You will be exploited for amplification attacks if you design your protocol badly.
Aachen 3y ago
TL;DR: amplification attacks It was the first downside that came to mind, but it's so common knowledge that I expected the post to be about something else
ttyyzz 3y ago
Quic = TCP inside UDP and its great for e.g. streaming, instead of sending a bunch of Acks all the time it tells the other side which packet to resend in case of loss. Great for a buffered Video stream.
- bcrl 3y ago
  Streaming is pretty much, by definition, not latency sensitive. Getting a video stream to display in a browser or on a TV requires transferring a lot more data than saving 1 or 2 round trips can achieve. Personally, the bigger impact on user experience is all tha Javascript crap. My banking website changed to an infinite scrolling page for transactions and the user experience was ruined as a result. Static content scrolls way faster.
cebert 3y ago
Couldn’t most of the UDP packet spoofing be mitigated if we mandated ISPs and networking equipment to drop packets with addresses that couldn’t have possibly originated from downstream?
- liquidpele 3y ago
  Most firewalls and gateway routers already do. The issue is more for internet connected services, where backbone routing can’t do that for scale/redundancy routing reasons.
- musicale 3y ago
  Indeed it could, as recommended in BCP38 (mentioned in m3047's comment) and BCP84: https://www.internetsociety.org/deploy360/anti-spoofing/ https://www.internetsociety.org/deploy360/anti-spoofing/ m3047 also notes: > The simple way to avoid amplification with UDP is not to send a reply
Joel_Mckay 3y ago
We once had to pronounce a company product dead-on-arrival due to a naive UDP based cellular product, and regrettably had to pass on the mission difficult. The problem wasn't the lousy data link (Iodine tunnels exist), but rather the ridiculous scaling-cost server side. Think about a large fleet of vehicles all trying to report at the same time. Sure one could rate-limit the bandwidth... but then the link throughput is even more probabilistic. =) Sometimes it is better to run... rather than walk from Doomed projects. The contract-manufacturer ended up with a warehouse of products no one could fix. All thanks to some under-powered-module manufacturers naive understanding of networks. Its a shame really, the people were good folks with a viable business plan. I have a bag of popcorn ready for the idealists rolling out HTTP/3 with QUIC into their data-centers and NOC. I remain skeptical most infrastructure can survive the traffic asymmetry reliably at scale. Hard pass for now... Have a wonderful day, and remember to have fun =)
m3047 3y ago
> you will be exploited for amplification attacks! Is that the gripe? Am I missing something? Your bellybutton is not subject to these amplification attacks, it is strangers on the internet and this is an altruistic appeal: you will be exploited for amplification attacks directed at others. What is the root cause of this vulnerability? The root cause is that anonymous[0] packets on the internet contain a destination address the packet is to be delivered to, and a source address to which responses should be directed. That might be a different construction than the average programmer internalizes. In the absence of countermeasures either address can be rewritten and this is commonly done in firewalls with e.g. NAT. The attack is to specify a source address "on behalf of" some other party, causing replies to be delivered there. Are there other ways to validate or render packets as not anonymous? Yes, to varying degrees. One is to establish a dialogue with the source address before sending payloads; in fact that's pretty much the good which abnegates perfection. There has been a BCP for many years that ASNs should validate that source addresses are valid.[1] Amplification is possible both in velocity and volume. Volume is when a reply packet is larger than the source packet. Velocity occurs when mulitple replies are sent. Even when no amplification occurs, attacks are mounted with e.g. ICMP. UDP amplification typically occurs when the reply packet is larger than the initiating packet. TCP amplification occurs when a SYN can elicit multiple SYN/ACKS.[3] (Both TCP and UDP are capable of eliciting ICMP backscatter.) The simple way to avoid amplification with UDP is not to send a reply. This is done a lot. For instance streaming data over UDP with a TCP pipe for control information. A bonus for this approach is that UDP is conducive to multicast[4], for which specific address ranges are reserved. Changing tuning parameters is an effective way to mitigate the TCP SYN/ACK problem, barring the appearance of flying monkeys.[5] DNS may be illustrative in a number of ways. First off clients aggressively retry queries due to "happy eyeballs", so the servers constantly face an identify friend or foe operating environment. DNS only ever sends one response to a particular query. A common server (if not protocol) extension is the implementation of response rate limiting, which drops a certain portion of UDP replies and returns the rest with TC=1.[6] Congratulations on reading this far. Now go get yourself a job as a cybersecurity analyst.[7] [0] If you trust the source in some other fashion and mark or validate packets in some way based on that, they're not anonymous. [1] https://www.rfc-editor.org/bcp/bcp38.txt https://www.rfc-editor.org/bcp/bcp38.txt I've worked with Ferg[2] [2] and Merike. [3] Which is pretty much all the time, because the default tuning everywhere is to send multiple SYN/ACKs. [4] Sending the same packet for delivery to multiple recipients. [5] /proc/sys/net/ipv4/tcp_synack_retries [6] Next time we'll talk about the fractured history of frags and the DNS. [7] Feel free to hire me!
deleted 3y ago
[deleted]
dathinab 3y ago
I personally would rephrase it an instead say: "any developer building protocols on top of UDP has the responsibility to appropriately handle the various attack vectors which come from udp being "connectionless"" This also means you have to add functionality to avoid various applification attacks against you (e.g. package forging/cloning/reply variations) but also much more important against others caused by you (e.g. you mustn't provide any form of unauthenticated UDP replay server which could be used for amplification attacks, this includes protocols which through bad design can be used as such replay servers even if they are not meant to be such servers). Note that this always stays in the territory of "appropriately". Still this means that developing acceptable protocols on top of UDP if they are meant to be used on the internet (e.g. not just inside of an VPN) is kinda way harder then doing so on top of TCP instead of "simpler" like some of the sources the article refers to argue.
bullen 3y ago
The real problem is IPv4, and IPv6 overshoots. The ports wont be opened ubiquitely. UDP can only do (P2P) punch through and if one person uses the designated port on their IP, the next person to connect gets an elevated port number. It's janky, and you cannot guarantee QoS. Also scaling UDP server needs the same multicore cooperation as TCP. UDP solves nothing interesting. And now we are closing 25, 53 and 80 with ISP port blocks, anti-viruses and browser defaults. Good job humanity, closing the working door before you open a new window trapping yourself forever in centralized root-certificate hell. Flash and Applets got killed by locked down iOS and Android. The browser is now dead.

188 points by signa11 3y ago

spandextwins 3y ago

The whole tcp/ip stack and packets need to be rebuilt from the ground up. It's not the 1970s anymore.

keepamovin 3y ago

Do these amplification attacks also apply to WebRTC and WebTransport?

devmunchies 3y ago
Am curious about QUIC and HTTP3 as well.
- janosdebugs 3y ago
  QUIC explicitly mentions that it is vulnerable to amplification attacks in the RFC. It suggests sending an extra packet to mitigate, at which point I believe the advantage of QUIC is lost as far as establishing connections is concerned.
  - johncolanduoni 3y ago
    I believe you're referring to the stateless retry mechanism? It's designed to be used only when the server is actually under attack (either as an amplification vector or exhaustion of its own connection capacity). The idea is that the server establishes some threshold for pending QUIC connections, and only if that is exceeded does it start requiring clients to complete the extra stateless, SYN-cookie style roundtrip to validate their source address. So it maintains the advantage of one less roundtrip than TCP+TLS unless the server is receiving large amounts of connections that are not progressing in a timely manner.
- vasilvv 3y ago
  QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message exceeds one packet, which usually only happens if there is a post-quantum key share in it). 3600 bytes is usually enough, unless your certificate chain is too large, in which case you'd need to compress it. [1] is a nice overview of the problem. (full disclosure: I worked on some of this stuff) [0] https://datatracker.ietf.org/doc/html/rfc9000#name-address-validation https://datatracker.ietf.org/doc/html/rfc9000#name-address-v... [1] https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study https://www.fastly.com/blog/quic-handshake-tls-compression-c...
toast0 3y ago
WebRTC generally goes through a probing process to verify two-way connectivity before sending media. I not familiar with WebTransport. My understanding of QUIC was that the handshake was designed so the client would pad their initial datagram such that the response was of similar size, avoiding a small request/large response pattern. And that typical connection establishment did a key exchange on the first round trip; primarily for privacy, but also to confirm two way connectivity. I could be wrong though; especially around resumption and/or connection agility, where a client moves addresses and the session moves with the client.
- kkielhofner 3y ago
  > WebRTC generally goes through a probing process to verify two-way connectivity before sending media. To expand on this WebRTC is extremely complex but it certainly has one thing in common with more traditional VoIP systems - the UDP flows for media are negotiated dynamically. You establish a signaling channel using whatever (WebRTC famously doesn't mandate a signaling protocol). This signaling channel with any authentication, verification, etc you want transports SDP (session description payload) bodies between each party (typically via a web server and websocket/datachannel/HTTP). What you end up with is a set of dynamically negotiated send/receive ports on each side and the application establishes the socket and flow between them with the receiving sockets on each side typically making sure the source IP:port pair matches what was negotiated. The listening socket on each side discards any junk that may show up from an unverified source IP:port pair. The process you're referencing to is called ICE (Interactive Connectivity Establishment). ICE is very complex but basically what ends up happening is a series of candidates of all potential IPs, source ports, etc are evaluated for bidirectional connectivity between the parties. Once a reliable session candidate is verified the rest of the media session is established using the same source and destination IP:port pairs. At the risk of getting too into the weeds WebRTC also does UDP port multiplexing so everything related to the session from ICE to the media, datachannel, etc are sent and received on the same socket. This is how you can have relatively high certainty you can establish a bi-directional flow between parties - because you only get this far when ICE has confirmed the IP:port flow on each side can reach the other.
johncolanduoni 3y ago
WebTransport requires an established HTTP3 (and therefore QUIC) connection or an established HTTP2 (and therefore TCP) connection, so its vulnerability to reflection attacks corresponds to the vulnerability of the underlying handshakes.

kazinator 3y ago

> That's one reason for the TCP three-way handshake. No it isn't. The TCP three-way handshake precedes all imagination of these kinds of problems. Edit: remember how that three-way handshake was susceptible to memory DoS attacks before SYN cookies were introduced to patch the problem!

wmf 3y ago
Maybe we should say amplification attacks are a reason why the three-way handshake hasn't been removed.
- amtamt 3y ago
  I guess one example of this was DoS attack on Yahoo (when it was the google of its time) from a single 56k modem connection. Unfortunately can't find the original article, may be someone will share a link.

tptacek 3y ago

I mean, it’s definitely not one of the reasons for the TCP 3WH, though that may be a happy accident of it.

gary_0 3y ago

Speaking of denial of service, it looks like HN killed the guy's server. https://web.archive.org/web/20231028021348/https://boston.conman.org/2023/10/25.1 https://web.archive.org/web/20231028021348/https://boston.co...

pronoiac 3y ago
It responded eventually for me, but the Wayback Machine has it - https://web.archive.org/web/20231028021348/https://boston.conman.org/2023/10/25.1 https://web.archive.org/web/20231028021348/https://boston.co...

KirillPanov 3y ago

> Any time you have a UDP-based protocol where a small packet to the server results in a large packet from the server will be exploited In other news, water is wet. Seriously folks, if you don't already know this you shouldn't be designing any protocols. Datagram or stream-based. > That's one reason for the TCP three-way handshake. And its horrendous latency. All of the mitigations for that open up resource exhaustion attacks; frying pan, meet fire. There's no free lunch. Datagram protocols are not going away.

wmf 3y ago
I just checked Beej's Guide and there's no mention of amplification. I wouldn't be surprised if TCP/IP Illustrated doesn't teach it either. This means most people won't know about it and they won't know that they don't know. The mitigation of requiring a "SYN" style packet to be MTU-sized sounds pretty good to me. It obviously uses a little more bandwidth but the network may be underutilized on the upstream path anyway.
- 10000truths 3y ago
  > I just checked Beej's Guide and there's no mention of amplification. I wouldn't be surprised if TCP/IP Illustrated doesn't teach it either. This means most people won't know about it and they won't know that they don't know. The issue isn't a lack of understanding of networking, it's a lack of understanding of the threat model.
d-z-m 3y ago
> Seriously folks, if you don't already know this you shouldn't be designing any protocols. Datagram or stream-based. I find this kind of gatekeeping distasteful. Knowing about various ways network protocols can be exploited is important, but this can be communicated without trampling curiosity.

mannyv 3y ago

None of this would be an issue if ISPs actually dropped UDP packets. They should run at a lower QoS by design. After all, the UDP spec explicitly calls out that it's unreliable. Yet IRL nobody drops them, ever, except during mitigation. Just drop them already. It's been decades.

yjftsjthsd-h 3y ago
> None of this would be an issue if ISPs actually dropped UDP packets. They should run at a lower QoS by design. After all, the UDP spec explicitly calls out that it's unreliable. Yet IRL nobody drops them, ever, except during mitigation. There's a difference between unreliable best-effort and "just throw out packets indiscriminatly". > Just drop them already. It's been decades. ... Decades since what? UDP is still very much in use
chungy 3y ago
The "U" doesn't stand for Unreliable. It's basically the simplest possible packetization that doesn't offer much of anything that the underlying IPv4/IPv6 layer doesn't, besides filtering out packets based on port numbers. It's very commonly used for games and video services, where applications can recover from the odd dropped or out-of-order packet. As the sibling comment mentions, what does "It's been decades?" supposed to imply? It's also been decades since TCP was invented, are you calling for its discontinuation too?
3c6bYDXLMj 3y ago
If you could put yourself in the shoes any position/s in any organisation/s necessary to implement your grand vision, what would you do? How would you do it? This just sounds like the sort of absurd proposition that can only be made by people that don’t have a seat at the table.
bouncycastle 3y ago
UDP is used by Wireguard, for example. Quote from Wikipedia: "WireGuard uses only UDP, due to the potential disadvantages of TCP-over-TCP. Tunneling TCP over a TCP-based connection is known as "TCP-over-TCP", and doing so can induce a dramatic loss in transmission performance (a problem known as "TCP meltdown").

sillysaurusx 3y ago

A couple commenters have disagreed with the author saying “That’s one reason for the TCP three-way handshake”. But I’ve been implementing uTP, the UDP protocol that torrents use (https://www.bittorrent.org/beps/bep_0029.html https://www.bittorrent.org/beps/bep_0029.html) and it seems to avoid amplification attacks thanks to a three-way handshake. So the author seems correct to say it’s one (good) reason for the three-way handshake. (It turns out when you want to spider libgen for all epubs for training data, the most straightforward way to do this, apart from downloading >40TB, is to write your own torrent client that selectively recognizes epub files and fetches only those.) The uTP spec (BEP 29, linked above) also gives a good overview of why UDP is sometimes the correct choice over TCP in modern times. uTP automatically throttles itself to yield excess bandwidth to any TCP connection that wants it. Imagine trying to write an app that uses all the bandwidth on your network, without impacting anyone else on the network. You’d find it quite hard. uTP does it by embedding time deltas in the packets and throttling itself whenever the timestamp goes over ~100ms, which indicates either a connection dropout or bandwidth saturation. I.e. if your ping suddenly spikes, it’s because someone is hogging all the bandwidth. Normally you have to track down who’s doing it, like a detective hunting a murderer. But uTP knows that it’s the murderer, so it throttles itself back. Presto, perfect bandwidth utilization. But why bother with UDP? Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right? Good question, and I don’t have a good answer. Perhaps one of you can give a persuasive one, lest you agree that ISPs should just throttle UDP by design. It’s certainly simpler to solve this at a protocol level, but one could imagine a BEP that adds time deltas to the torrent spec and prevents sending pieces too quickly (“if the deltas spike, send fewer blocks per second"). It might even be simpler than bothering to reimplement TCP over UDP. But perhaps there’s a good reason. One idea that comes to mind is that the goal is to throttle sends and receives. You control your sends, but you’re at the mercy of the counterparty for receives. You’d need to keep throttle info for every peer, and notice when their pings spike, not just yours. Then you’d send fewer packets. But that’s what uTP does, and that doesn’t answer “Why do it in UDP instead of TCP?”

habitue 3y ago
Wait, doesn't TCP have automatic throttling too?

chmike 3y ago

The problem result from the ability to forge a fake origin IP address. This can be avoided by adding a certificate for the IP address. It adds a processing and size overhead, but it also preserves the single round trip transaction.

tjoff 3y ago
How do you do that and still allow access from anyone without any prior configuration?
- jzwinck 3y ago
  One way could be to require signing with a TLS certificate whose hostname resolves to the source IP(s).
  - tjoff 3y ago
    How is that no prior configuration on the client side?
    - jzwinck 3y ago
      Clients could use the same certificate for every server, so there is only a one-time setup. Analogous to how clients need to be "configured" with an IP address, the certificate could be given to them by their internet gateway if desired.
      - tjoff 3y ago
        Yeah, and in what universe could that work? I need directions. Seems far simpler to send a physical mail to the service operator who then hardcodes the IP in the server. Or, maybe do a handshake once and cache it for X amounts of time whatever makes sense for that service.
  - tonyarkles 3y ago
    When NAT gets involved things get very complicated very quickly for that. For many networks and ISPs this would need to happen at the IP egress level and couldn’t happen on the end device, since the end device doesn’t even know its own IP and neither does the on-prem router.

exDM69 3y ago

I'm starting to think that TCP is past its prime and UDP based protocols (like QUIC) are the way forward. The problem is exacerbated by TLS encryption. It requires six packets, or three round trip times, to establish a TLS over TCP connection. That is hundreds of milliseconds before a single byte of payload can be transferred. The QUIC protocol combines the three way handshake and the three way key exchange to half the time I takes to set up a connection and provides a fast start (0rtt) for resuming a previously configured connection. Additionally TCP connections do not survive a changed IP address like when changing from wifi to mobile data. The stream model of TCP with head of the line blocking is conceptually easy but ultimately the wrong model for transmitting blobs of data. Rejecting a valid packet because the order got shuffled is wasteful, when we could just as easily reassemble the packets on the receiver side (even outside the sliding window). There are a lot of times when the stream model is a good choice (dynamically generated data) but I would argue that sending sized blobs (like images) is a larger volume of traffic in terms of bytes transferred. But the OP is right, writing custom UDP protocol is fraught with peril. DDoS amplification is just one way to screw up.

defrost 3y ago
TCP is overkill for the vast bulk of modern data transmission by volume; "short hops" within and between data centres on backbones that have near zero error. TCP was designed for higher error rates on less reliable paths; from the clustered data centres out to the more remote home computers today is likely better than 1980s internet. There are good proposals for low error high bandwidth TCP-lite replacements that are gaining ground.
- agumonkey 3y ago
  Could you name a few of these proposals ?
  - defrost 3y ago
    Yes. Homa for one: * (2018) https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.pdf https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.... * (2022) https://arxiv.org/abs/2210.00714 https://arxiv.org/abs/2210.00714 * (2022) https://www.theregister.com/2022/07/27/replace_tcp_datacenter/ https://www.theregister.com/2022/07/27/replace_tcp_datacente... * https://github.com/PlatformLab/Homa https://github.com/PlatformLab/Homa

imhoguy 3y ago

Crazy idea: could amplification attack be avoided by Proof of Work in the requesting UDP packet?

michh 3y ago
You’d have to keep track of which proofs you’ve already seen, to prevent re-use. You’d have to make sure the (source, source port, destination and destination port)-tuple is a cryptographic part of the algorithm, to prevent me using the same proof of work for like a million machines. Then there’s the issue of low power and/or battery-powered devices. You want people to be able to use your protocol without draining the battery. But by lowering the computational cost to accomodate that, you’re enabling the bad guys that can afford a fast GPU to go back to abusing the protocol cause the cost isn’t sufficiently high to deter them anymore. And I’m sure there are plenty of other things I haven’t thought of.
iforgotpassword 3y ago
There's an even simpler solution I've used ever since I became aware of the first amplification attacks during the 00s: either implement your own simple 3wh, or if you really want a simple request/reply protocol with no state associated, pad the request so it matches the reply in size. Sometimes your reply is large though and needs a couple dozen packets so then you're usually forced to use the first solution.
- chmike 3y ago
  I suggested the certificate solution but it's far from being lightweight. I found a simpler solution that may fit some use cases. The client sends a request, the server returns a response that may be big that also contains a random value. The client must return this random value in a thank you message. If the server doesn't receive the thank you message, it slows down responses to that ip address and eventually blacklist it if it's repeated. From the client perspective, the answer is obtained in one round trip time. The price to pay on the server is the need to keep track of the expected thank you messages, and the throttled or blacklisted addresses.
exDM69 3y ago

mhandley 3y ago

You can avoid being used for amplification attacks by simply requiring the request packet be at least as large as the response. Burns some extra inbound bandwidth and doesn't protect you from DoS attacks on your server, but at least avoids being used as an amplifier. Or you can implement a three-way handshake with a cookie or hash of a secret and the requestor's IP address, but just requiring large request packets is simpler if you're designing a really simple protocol.

londons_explore 3y ago
Being used for amplification attacks isn't bad if the amplification factor is low (ie. <5), and there is no way to chain amplifiers. You can also protect further against it by limiting the amount of un-acked data per second to each AS. Well behaved connections generally will ack nearly all data sent to them, whereas attacks will ACK none. That way, users have to wait one extra roundtrip if an attack on them is in progress - doesn't sound so bad. Amplification was only a really bad problem when amplification factors over 100 were possible.

em-bee 3y ago

TCP is like automated driving or a taxi. you get in your car, tell it the destination, and it takes you there. UDP is driving yourself. you have to adjust the speed and direction as you go. if you go to fast accidents can happen. so obviously, when using UDP you have to add safeguards against attacks, but, you get more flexibility to adjust things along the way. you are not locked into the way TCP does it, and that is the benefit of creating a UDP based protocol instead of just using TCP. TCP is not built on top of UDP, but i think it could be: https://stackoverflow.com/questions/10680592/can-tcp-be-implemented-via-udp https://stackoverflow.com/questions/10680592/can-tcp-be-impl... and it is a good idea to not just use UDP blindly, but implement the necessary saveguards on top of it. but claiming that all UDP based protocols are bad because of UDP is like saying, cars are bad because of bad drivers. (well, they are, but that's a different topic) so UDP based protocols aren't bad. only using UDP without safeguards is bad.

rixrax 3y ago
This is a bit similar to roll your own crypto conversation. It is fun, and a great way to learn. And once done, you should do well to never deploy your own crypto in any real life application. Friends don't let (or shouldn't at least) friends roll their own protocol over UDP either (or IP; I mean why not?). There are very few apps that have such an explicit requirements that they can't do away with TLS over any number (==2) of existing, and well known transport protocols (e.g. TCP, maybe QUIC). For presentation layer, instead of implementing their own spec, most should probably stick to Protobuf[0] (or some of it's derivatives[1]), and encode the application data into JSON. Check. Protocol design done. [0] https://protobuf.dev https://protobuf.dev [1] https://capnproto.org https://capnproto.org
- em-bee 3y ago
  i don't quite agree because there are legitimate uses for UDP, but there are no legitimate uses for hand rolled crypto (except learning). also the issues with UDP mentioned in the article can easily be mitigated, which is not at all true for issues with hand rolled crypto. and there is one important use for UDP that is not well served with TCP or QUIC, which is tunneling. tunneling TCP over TCP does not work very well. also, the feature of mosh to keep a connection alive over network changes may not be easy to implement over TCP, i am not sure.

api 3y ago

You will be exploited for amplification attacks if you design your protocol badly.

Aachen 3y ago

TL;DR: amplification attacks It was the first downside that came to mind, but it's so common knowledge that I expected the post to be about something else

ttyyzz 3y ago

Quic = TCP inside UDP and its great for e.g. streaming, instead of sending a bunch of Acks all the time it tells the other side which packet to resend in case of loss. Great for a buffered Video stream.

bcrl 3y ago
Streaming is pretty much, by definition, not latency sensitive. Getting a video stream to display in a browser or on a TV requires transferring a lot more data than saving 1 or 2 round trips can achieve. Personally, the bigger impact on user experience is all tha Javascript crap. My banking website changed to an infinite scrolling page for transactions and the user experience was ruined as a result. Static content scrolls way faster.

cebert 3y ago

Couldn’t most of the UDP packet spoofing be mitigated if we mandated ISPs and networking equipment to drop packets with addresses that couldn’t have possibly originated from downstream?

liquidpele 3y ago
Most firewalls and gateway routers already do. The issue is more for internet connected services, where backbone routing can’t do that for scale/redundancy routing reasons.
musicale 3y ago
Indeed it could, as recommended in BCP38 (mentioned in m3047's comment) and BCP84: https://www.internetsociety.org/deploy360/anti-spoofing/ https://www.internetsociety.org/deploy360/anti-spoofing/ m3047 also notes: > The simple way to avoid amplification with UDP is not to send a reply

Joel_Mckay 3y ago

We once had to pronounce a company product dead-on-arrival due to a naive UDP based cellular product, and regrettably had to pass on the mission difficult. The problem wasn't the lousy data link (Iodine tunnels exist), but rather the ridiculous scaling-cost server side. Think about a large fleet of vehicles all trying to report at the same time. Sure one could rate-limit the bandwidth... but then the link throughput is even more probabilistic. =) Sometimes it is better to run... rather than walk from Doomed projects. The contract-manufacturer ended up with a warehouse of products no one could fix. All thanks to some under-powered-module manufacturers naive understanding of networks. Its a shame really, the people were good folks with a viable business plan. I have a bag of popcorn ready for the idealists rolling out HTTP/3 with QUIC into their data-centers and NOC. I remain skeptical most infrastructure can survive the traffic asymmetry reliably at scale. Hard pass for now... Have a wonderful day, and remember to have fun =)

m3047 3y ago

> you will be exploited for amplification attacks! Is that the gripe? Am I missing something? Your bellybutton is not subject to these amplification attacks, it is strangers on the internet and this is an altruistic appeal: you will be exploited for amplification attacks directed at others. What is the root cause of this vulnerability? The root cause is that anonymous[0] packets on the internet contain a destination address the packet is to be delivered to, and a source address to which responses should be directed. That might be a different construction than the average programmer internalizes. In the absence of countermeasures either address can be rewritten and this is commonly done in firewalls with e.g. NAT. The attack is to specify a source address "on behalf of" some other party, causing replies to be delivered there. Are there other ways to validate or render packets as not anonymous? Yes, to varying degrees. One is to establish a dialogue with the source address before sending payloads; in fact that's pretty much the good which abnegates perfection. There has been a BCP for many years that ASNs should validate that source addresses are valid.[1] Amplification is possible both in velocity and volume. Volume is when a reply packet is larger than the source packet. Velocity occurs when mulitple replies are sent. Even when no amplification occurs, attacks are mounted with e.g. ICMP. UDP amplification typically occurs when the reply packet is larger than the initiating packet. TCP amplification occurs when a SYN can elicit multiple SYN/ACKS.[3] (Both TCP and UDP are capable of eliciting ICMP backscatter.) The simple way to avoid amplification with UDP is not to send a reply. This is done a lot. For instance streaming data over UDP with a TCP pipe for control information. A bonus for this approach is that UDP is conducive to multicast[4], for which specific address ranges are reserved. Changing tuning parameters is an effective way to mitigate the TCP SYN/ACK problem, barring the appearance of flying monkeys.[5] DNS may be illustrative in a number of ways. First off clients aggressively retry queries due to "happy eyeballs", so the servers constantly face an identify friend or foe operating environment. DNS only ever sends one response to a particular query. A common server (if not protocol) extension is the implementation of response rate limiting, which drops a certain portion of UDP replies and returns the rest with TC=1.[6] Congratulations on reading this far. Now go get yourself a job as a cybersecurity analyst.[7] [0] If you trust the source in some other fashion and mark or validate packets in some way based on that, they're not anonymous. [1] https://www.rfc-editor.org/bcp/bcp38.txt https://www.rfc-editor.org/bcp/bcp38.txt I've worked with Ferg[2] [2] and Merike. [3] Which is pretty much all the time, because the default tuning everywhere is to send multiple SYN/ACKs. [4] Sending the same packet for delivery to multiple recipients. [5] /proc/sys/net/ipv4/tcp_synack_retries [6] Next time we'll talk about the fractured history of frags and the DNS. [7] Feel free to hire me!

deleted 3y ago

[deleted]

dathinab 3y ago

I personally would rephrase it an instead say: "any developer building protocols on top of UDP has the responsibility to appropriately handle the various attack vectors which come from udp being "connectionless"" This also means you have to add functionality to avoid various applification attacks against you (e.g. package forging/cloning/reply variations) but also much more important against others caused by you (e.g. you mustn't provide any form of unauthenticated UDP replay server which could be used for amplification attacks, this includes protocols which through bad design can be used as such replay servers even if they are not meant to be such servers). Note that this always stays in the territory of "appropriately". Still this means that developing acceptable protocols on top of UDP if they are meant to be used on the internet (e.g. not just inside of an VPN) is kinda way harder then doing so on top of TCP instead of "simpler" like some of the sources the article refers to argue.

bullen 3y ago

The real problem is IPv4, and IPv6 overshoots. The ports wont be opened ubiquitely. UDP can only do (P2P) punch through and if one person uses the designated port on their IP, the next person to connect gets an elevated port number. It's janky, and you cannot guarantee QoS. Also scaling UDP server needs the same multicore cooperation as TCP. UDP solves nothing interesting. And now we are closing 25, 53 and 80 with ISP port blocks, anti-viruses and browser defaults. Good job humanity, closing the working door before you open a new window trapping yourself forever in centralized root-certificate hell. Flash and Applets got killed by locked down iOS and Android. The browser is now dead.