The attack was creating many connection contexts, each opening a file. In hindsight, the reason is obvious: there is a limit to how many files a given process can open. Even with debugging messages turned off, there was still an issue with Picoquic unable to create enough logging files. In simulated time, the attack was sending 10,000 messages in one second, but logging all these debug messages took a minute and a half. In the first run, the test console filled up with a lot of debug traces, complaining that connections could not be logged. The code had been stressed before, but this was the first try of a full scale DDOS attack and as with any first time I expected there might be a few glitches. The simulation was running in simulated time, but I was measuring also the “real” time needed by the code to process that series of messages. I wrote a small simulation, in which the simulated attacker first built a long series of “initial” messages and then sent them to the server, as shown below in the Attack figure. I wanted to check what happens if a server that did not instantiate that option was the target of an attack. Picoquic does support the Retry process, and has supported it for a long time, but it was a startup option. Otherwise, they just use the standard QUIC handshake, pictured in the QUIC Handshake figure below. That’s why the QUIC transport draft specifies a “Retry” process, in many ways similar to the SYN Cookies of TCP, but servers only use that when they anticipate attacks. The server would attempt to execute as many sets of cryptographic computations, in the process exhausting its CPU resources and becoming unable to service real customers. A botnet could manufacture vast quantities of client handshake messages, apparently coming to a variety of IP addresses. The handshake involves a lot of cryptographic computations. The first messages of a QUIC session carry a TLS handshake between client and server. The working group knows since the beginning of the QUIC project that QUIC servers can be the target of Distributed Denial of Service (DDOS) attacks. Guess what, this turned out to be a vivid illustration of the classic software development principle: if it is not tested, it probably does not work. I had some free time, it seemed easy, so I just started the work. I entered that issue four weeks ago, when doing a review of possible improvements. I just did that two days ago, looking at issue #1023 in the Picoquic project, “Simulate DDOS by repeated Client-Hello”. Sometimes, one looks at a bug list and find one that seems easy enough.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |