From cdbfb64a6e93361d3d0cdb709578dc231e138f2f Mon Sep 17 00:00:00 2001 From: huitema Date: Wed, 19 Apr 2017 10:24:45 -0700 Subject: [PATCH 1/9] Additional security section on fragmentation reassembly attacks Describe the equivalent of the Teardrop attack for QUIC, and propose mitigation. --- draft-ietf-quic-transport.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 672c1cda36..17fef4bb4f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2697,6 +2697,35 @@ also be forward-secure encrypted. Since the attacker will not have the forward secure key, the attacker will not be able to generate forward-secure encrypted packets with ACK frames. +## Stream fragmentation and reassembly attacks + +An adversarial client may attempt to exhaust server memory resource by performing +a stream fragmentation and reassembly attack, similar to the UDP/ICMP +"Teardrop" fragmentation attacks. The adversarial client would open a stream, +and send some STREAM DATA packets containing fragments of the stream content. +The goal of the attack is to induce the receiving implementation to commit +memory buffers while waiting that the stream data can be reassembled. + +For example, a client +might send some octets at the beginning of a stream and some octets much further +away in the stream. A vulnerable server, on receiving the stream data fragments, +might allocate memory covering the whole space from beginning to end. The client +would then repeat the process on a large number of streams and a large number +of connections, inducing the server to commit a large amout of memory. + +This attack can be mitigated by not committing memory for stream data reassembly, +and simply keeping the STREAM DATA frames until enough fragments have been +received and the data can be delivered to the application in proper sequence. +However, this is not a complete mitigation. The adversarial client could still send +a large number of STREAM DATA packets separated by holes, forcing the server +to commit memory for a large number of data segments. + +A possible mitigation is for servers to keep a count of the number of +"reassembly holes" in data streams received from the client. In normal operation, +these holes are caused by transmission errors and are promptly filled by the +recovery processes. An abnormal number of holes is caused by either a +very large rate of transmission errors, or by adversarial client behavior. In both +cases, it is reasonable for the server to close the connection. # IANA Considerations From dade254760334723363773208743522fd1ab813d Mon Sep 17 00:00:00 2001 From: huitema Date: Wed, 19 Apr 2017 11:24:09 -0700 Subject: [PATCH 2/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 17fef4bb4f..c3e450521d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2699,7 +2699,8 @@ packets with ACK frames. ## Stream fragmentation and reassembly attacks -An adversarial client may attempt to exhaust server memory resource by performing +An adversarial client may attempt to +exhaust server memory resource by performing a stream fragmentation and reassembly attack, similar to the UDP/ICMP "Teardrop" fragmentation attacks. The adversarial client would open a stream, and send some STREAM DATA packets containing fragments of the stream content. @@ -2707,24 +2708,31 @@ The goal of the attack is to induce the receiving implementation to commit memory buffers while waiting that the stream data can be reassembled. For example, a client -might send some octets at the beginning of a stream and some octets much further +might send some octets at the beginning of a +stream and some octets much further away in the stream. A vulnerable server, on receiving the stream data fragments, might allocate memory covering the whole space from beginning to end. The client would then repeat the process on a large number of streams and a large number of connections, inducing the server to commit a large amout of memory. -This attack can be mitigated by not committing memory for stream data reassembly, +This attack can be mitigated by not +committing memory for stream data reassembly, and simply keeping the STREAM DATA frames until enough fragments have been received and the data can be delivered to the application in proper sequence. -However, this is not a complete mitigation. The adversarial client could still send -a large number of STREAM DATA packets separated by holes, forcing the server +However, this is not a complete mitigation. +The adversarial client could still send +a large number of STREAM DATA packets separated by holes, +forcing the server to commit memory for a large number of data segments. A possible mitigation is for servers to keep a count of the number of -"reassembly holes" in data streams received from the client. In normal operation, -these holes are caused by transmission errors and are promptly filled by the +"reassembly holes" in data streams received from the client. +In normal operation, +these holes are caused by transmission errors and +are promptly filled by the recovery processes. An abnormal number of holes is caused by either a -very large rate of transmission errors, or by adversarial client behavior. In both +very large rate of transmission errors, or by +adversarial client behavior. In both cases, it is reasonable for the server to close the connection. # IANA Considerations From 6a0337c7771fd8787dc42dc58d6adb151f00cc24 Mon Sep 17 00:00:00 2001 From: huitema Date: Wed, 19 Apr 2017 14:49:02 -0700 Subject: [PATCH 3/9] Removing trailing spaces on some of changed lines I have lots of emotional things to say about such checks... --- draft-ietf-quic-transport.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c3e450521d..12e36e29cd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2699,40 +2699,40 @@ packets with ACK frames. ## Stream fragmentation and reassembly attacks -An adversarial client may attempt to +An adversarial client may attempt to exhaust server memory resource by performing a stream fragmentation and reassembly attack, similar to the UDP/ICMP "Teardrop" fragmentation attacks. The adversarial client would open a stream, and send some STREAM DATA packets containing fragments of the stream content. The goal of the attack is to induce the receiving implementation to commit -memory buffers while waiting that the stream data can be reassembled. +memory buffers while waiting that the stream data can be reassembled. For example, a client -might send some octets at the beginning of a -stream and some octets much further +might send some octets at the beginning of a +stream and some octets much further away in the stream. A vulnerable server, on receiving the stream data fragments, might allocate memory covering the whole space from beginning to end. The client would then repeat the process on a large number of streams and a large number of connections, inducing the server to commit a large amout of memory. -This attack can be mitigated by not +This attack can be mitigated by not committing memory for stream data reassembly, -and simply keeping the STREAM DATA frames until enough fragments have been -received and the data can be delivered to the application in proper sequence. -However, this is not a complete mitigation. +and simply keeping the STREAM DATA frames until enough fragments have been +received and the data can be delivered to the application in proper sequence. +However, this is not a complete mitigation. The adversarial client could still send -a large number of STREAM DATA packets separated by holes, +a large number of STREAM DATA packets separated by holes, forcing the server to commit memory for a large number of data segments. A possible mitigation is for servers to keep a count of the number of -"reassembly holes" in data streams received from the client. +"reassembly holes" in data streams received from the client. In normal operation, -these holes are caused by transmission errors and +these holes are caused by transmission errors and are promptly filled by the -recovery processes. An abnormal number of holes is caused by either a -very large rate of transmission errors, or by -adversarial client behavior. In both +recovery processes. An abnormal number of holes is caused by either a +very large rate of transmission errors, or by +adversarial client behavior. In both cases, it is reasonable for the server to close the connection. # IANA Considerations From d2444849b79176f61c79771c66677bec28108d95 Mon Sep 17 00:00:00 2001 From: huitema Date: Wed, 19 Apr 2017 20:34:47 -0700 Subject: [PATCH 4/9] Simplifying the text, per Martin's review --- draft-ietf-quic-transport.md | 45 ++++++++++++++---------------------- 1 file changed, 17 insertions(+), 28 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 12e36e29cd..e1cb9099a3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2697,34 +2697,23 @@ also be forward-secure encrypted. Since the attacker will not have the forward secure key, the attacker will not be able to generate forward-secure encrypted packets with ACK frames. -## Stream fragmentation and reassembly attacks - -An adversarial client may attempt to -exhaust server memory resource by performing -a stream fragmentation and reassembly attack, similar to the UDP/ICMP -"Teardrop" fragmentation attacks. The adversarial client would open a stream, -and send some STREAM DATA packets containing fragments of the stream content. -The goal of the attack is to induce the receiving implementation to commit -memory buffers while waiting that the stream data can be reassembled. - -For example, a client -might send some octets at the beginning of a -stream and some octets much further -away in the stream. A vulnerable server, on receiving the stream data fragments, -might allocate memory covering the whole space from beginning to end. The client -would then repeat the process on a large number of streams and a large number -of connections, inducing the server to commit a large amout of memory. - -This attack can be mitigated by not -committing memory for stream data reassembly, -and simply keeping the STREAM DATA frames until enough fragments have been -received and the data can be delivered to the application in proper sequence. -However, this is not a complete mitigation. -The adversarial client could still send -a large number of STREAM DATA packets separated by holes, -forcing the server -to commit memory for a large number of data segments. - +## Stream Fragmentation and Reassembly Attacks + +An adversarial endpoint might intentionally fragment the data on +stream buffers in order to cause disproportionate memory commitment. +The adversarial endpoint would open a stream, +and send some STREAM DATA packets containing arbitrary +fragments of the stream content. This attack can be +amplifed if used by multiple clients against a single server. + +The attack is mitigated if flow control windows correspond to +available memory. However, some receivers will over-commit memory and advertise +flow control offsets in the aggregate that exceed actual available memory. +The over-commitment strategy may leads to better performance when +endpoints are well behaved, but renders endpoints vulnerable to +the stream fragmentation attack. + +Endpoints that over commit memory should mitigate this attack. A possible mitigation is for servers to keep a count of the number of "reassembly holes" in data streams received from the client. In normal operation, From 46f293cbc6dda6059e8e26e17c4a9bf304590637 Mon Sep 17 00:00:00 2001 From: huitema Date: Thu, 20 Apr 2017 18:20:43 -0700 Subject: [PATCH 5/9] Simplifying the mitigation text Since there is no "one size fits all" mitigation, simplify the recommendations. The point is to draw attention to the problem, and trust developers to do the right thing. --- draft-ietf-quic-transport.md | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e1cb9099a3..5f5e138bee 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2703,8 +2703,7 @@ An adversarial endpoint might intentionally fragment the data on stream buffers in order to cause disproportionate memory commitment. The adversarial endpoint would open a stream, and send some STREAM DATA packets containing arbitrary -fragments of the stream content. This attack can be -amplifed if used by multiple clients against a single server. +fragments of the stream content. The attack is mitigated if flow control windows correspond to available memory. However, some receivers will over-commit memory and advertise @@ -2713,16 +2712,10 @@ The over-commitment strategy may leads to better performance when endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack. -Endpoints that over commit memory should mitigate this attack. -A possible mitigation is for servers to keep a count of the number of -"reassembly holes" in data streams received from the client. -In normal operation, -these holes are caused by transmission errors and -are promptly filled by the -recovery processes. An abnormal number of holes is caused by either a -very large rate of transmission errors, or by -adversarial client behavior. In both -cases, it is reasonable for the server to close the connection. +QUIC deployments SHOULD provide mitigations against the stream fragmentation +attack. Mitigations MAY consist of avoiding over-committing memory, delaying +reassembly of STREAM DATA frames, implementing heuristics based the +age and duration of reassembly holes, or some combination. # IANA Considerations From 040a5fef588e409c2a8a22088768fdfbf443bc81 Mon Sep 17 00:00:00 2001 From: huitema Date: Thu, 20 Apr 2017 18:24:18 -0700 Subject: [PATCH 6/9] And fixing a typo. --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5f5e138bee..fbc4814b3e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2714,7 +2714,7 @@ the stream fragmentation attack. QUIC deployments SHOULD provide mitigations against the stream fragmentation attack. Mitigations MAY consist of avoiding over-committing memory, delaying -reassembly of STREAM DATA frames, implementing heuristics based the +reassembly of STREAM DATA frames, implementing heuristics based on the age and duration of reassembly holes, or some combination. # IANA Considerations From a168b3bd50a08fe0a984abc960452e90950ec19b Mon Sep 17 00:00:00 2001 From: huitema Date: Thu, 20 Apr 2017 18:32:00 -0700 Subject: [PATCH 7/9] STREAM frames. --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fbc4814b3e..4bf20914ff 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2702,7 +2702,7 @@ packets with ACK frames. An adversarial endpoint might intentionally fragment the data on stream buffers in order to cause disproportionate memory commitment. The adversarial endpoint would open a stream, -and send some STREAM DATA packets containing arbitrary +and send some STREAM frames containing arbitrary fragments of the stream content. The attack is mitigated if flow control windows correspond to @@ -2714,7 +2714,7 @@ the stream fragmentation attack. QUIC deployments SHOULD provide mitigations against the stream fragmentation attack. Mitigations MAY consist of avoiding over-committing memory, delaying -reassembly of STREAM DATA frames, implementing heuristics based on the +reassembly of STREAM frames, implementing heuristics based on the age and duration of reassembly holes, or some combination. # IANA Considerations From 31872b3649f9fd01edd84900730d341abe1cff9a Mon Sep 17 00:00:00 2001 From: huitema Date: Thu, 20 Apr 2017 18:33:04 -0700 Subject: [PATCH 8/9] Can lead --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4bf20914ff..d6f6b5fffa 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2708,7 +2708,7 @@ fragments of the stream content. The attack is mitigated if flow control windows correspond to available memory. However, some receivers will over-commit memory and advertise flow control offsets in the aggregate that exceed actual available memory. -The over-commitment strategy may leads to better performance when +The over-commitment strategy can lead to better performance when endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack. From b47c0307b3c07326bd86b59642e70bf7cf1ea34e Mon Sep 17 00:00:00 2001 From: huitema Date: Thu, 20 Apr 2017 18:34:18 -0700 Subject: [PATCH 9/9] MAY -> could --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d6f6b5fffa..39bf7d3c74 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2713,7 +2713,7 @@ endpoints are well behaved, but renders endpoints vulnerable to the stream fragmentation attack. QUIC deployments SHOULD provide mitigations against the stream fragmentation -attack. Mitigations MAY consist of avoiding over-committing memory, delaying +attack. Mitigations could consist of avoiding over-committing memory, delaying reassembly of STREAM frames, implementing heuristics based on the age and duration of reassembly holes, or some combination.