Subject: [quicwg/base-drafts] Additional security section on fragmentation reassembly attacks (#444)

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 10:25:10 -0700

Describe the equivalent of the Teardrop attack for QUIC, and propose mitigation.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/444

-- Commit Summary --

  * Additional security section on fragmentation reassembly attacks

-- File Changes --

    M draft-ietf-quic-transport.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/444.patch
https://github.com/quicwg/base-drafts/pull/444.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 11:24:12 -0700

@huitema pushed 1 commit.

dade254  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/cdbfb64a6e93361d3d0cdb709578dc231e138f2f..dade254760334723363773208743522fd1ab813d

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 14:49:05 -0700

6a0337c  Removing trailing spaces on some of changed lines

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/dade254760334723363773208743522fd1ab813d..6a0337c7771fd8787dc42dc58d6adb151f00cc24

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 17:49:40 -0700

martinthomson requested changes on this pull request.

This doesn't talk about flow control.  It needs to.

Like #443, I think that this is far more detailed than we need.  The point of this is to make an implementer aware that a malicious peer might intentionally fragment the data on receive buffers in order to cause disproportionate memory commitment (either disproportionate to the number of bytes that were transmitted, or disproportionate to the flow control offset that was provided, in practice probably both are necessary to make the attack worthwhile).  This can be said more concisely, I think.

The most interesting case for this attack is where receivers over-commit memory and advertise flow control offsets in the aggregate that exceed actual available memory.  This strategy works in most cases given that most clients are not attempting denial of service.  The very tail of a receive window is rarely needed in practice.  Over-commitment fails badly when under this kind of attack.

> @@ -2697,6 +2697,43 @@ 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,

citation?

> @@ -2697,6 +2697,43 @@ 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

Title Case

> @@ -2697,6 +2697,43 @@ 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

This is any endpoint, though I agree that it's (usually) not very interesting for a server to mount the attack.

> +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.

Saving STREAM frames only works if the data provided is sufficiently sparse, at some point the overhead of saving the frames exceeds the overheads of assembling the data into a buffer and tracking the holes.

The real mitigation is not to over-commit on flow control.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#pullrequestreview-33652348

---

From: Marten Seemann <[email-masked]>
Date: Wed, 19 Apr 2017 18:15:46 -0700

marten-seemann commented on this pull request.

Saving frames is the only way the connection-level flow control window makes sense. Otherwise, you'd have to commit (number of streams)*(stream flow control window) memory.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112347805

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 18:24:33 -0700

martinthomson commented on this pull request.

Hmm, that's true.  That suggests a different way to write this: assume that frames are saved (and maybe merged opportunistically).  Then the attack is on the overhead associated with saved frames.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112348621

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 20:13:13 -0700

huitema commented on this pull request.

OK. Rewriting to"endpoint" instead of client.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112357681

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 20:34:49 -0700

d244484  Simplifying the text, per Martin's review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/6a0337c7771fd8787dc42dc58d6adb151f00cc24..d2444849b79176f61c79771c66677bec28108d95

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 20:45:29 -0700

Shortened the text, added reference to flow control. The point is that (some) receivers will over-commit, and will need to mitigate the attack. This will require some kind of heuristic. I proposed one -- counting holes, and if they are not commensurate with the packet loss rate abort the connection. If you believe there is something smarter to do, please chime in.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#issuecomment-295568645

---

From: huitema <[email-masked]>
Date: Wed, 19 Apr 2017 20:47:15 -0700

Just dropping the name quoting. Could not find a good Teardrop reference.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112360312

---

From: Aron-Schats <[email-masked]>
Date: Thu, 20 Apr 2017 10:47:48 -0700

On Wed, Apr 19, 2017 at 9:15 PM, Marten Seemann <[email-masked]>
wrote:

> Saving frames is the only way the connection-level flow control window
> makes sense. Otherwise, you'd have to commit (number of streams)*(stream
> flow control window) memory.
>
I don't see it: why would you have to commit more than the connection flow
control window?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#issuecomment-295830852

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Apr 2017 13:45:48 -0700

mikkelfj commented on this pull request.

Depending on what is meant by using up system memory, an attack may focus on locking out other connections new, or existing by forcing low congenstion windows. Avoiding overcommits can make this situation worse if the attacker succesfully increases flow control budgets.

For practical large scale solutions, the implementation needs to overcommit very significantly. There can be 100K connections of which only a few hundred are active. Each of these need write capacity immediately. If not, it both impacts responsiveness, and it ties up resources by having more concurrent active work going on. The same applies by number of streams vs active streams in some use cases while other cases normally expect streams to be active or closed. If each connection classified as active gets a connection level budget, it doesn't really matter what the stream budget is - this is more for the application consumption management. If the connection budget is abused with holes, it just hurts throughput of the sender and could limit the ability to start new streams. The real problem is to decide which connections are active and which are sleeping without preventing fast rampup of new and sleeping connections, and how to throttle back when connections are no longer active. The attack is then to appear active while commiting the least possible sender resources. A heuristic could be the age of holes. If retransmission does not kick in timely, packets could be dropped deliberately on that connection despite having a reasonable connection level budget.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112556592

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Apr 2017 14:17:11 -0700

I should perhaps clarify that in the above, a connection level budget is not a linear function of flow control. There is a fixed amount of internal memory, and as that is released, the congestion window is expanded. So storing lots of fragments will use memory faster and release memory slower, and thus reduce the connection level congestion window. And, when the memory fills, packets starts to drop. In this way, the worst case is that the full budget is consumed with holes, whereas a friendly peer would feel the same budget with linear stream data. The adversary can only create so many holes before the cost of whole punching is more expensive than linear data. Of course, there a endless different ways this can be handled, and it depends on the use case, risk, degradation when not under attack, etc., therefore it is hard to provide general advise.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112563071

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 14:39:38 -0700

As you say, Mikkel, "it is hard to provide general advice". So maybe that's own we should rewrite the "advice" part of this PR. Something like "It is hard to provide general advice. QUIC deployments SHOULD provide mitigations against the stream fragmentation attack, which MAY be avoiding over-committing memory, delaying reassembly of STREAM DATA frames, or implementing heuristics based the age and duration of reassembly holes."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112566918

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:13:23 -0700

Aaron: "why would you have to commit more than the connection flow control window?" It happens if the sum of the per stream windows is larger than the congestion window. For example, when the endpoint cannot predict which of the streams the other endpoint will fill first.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#issuecomment-295999114

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:20:48 -0700

46f293c  Simplifying the mitigation text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/d2444849b79176f61c79771c66677bec28108d95..46f293cbc6dda6059e8e26e17c4a9bf304590637

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:22:43 -0700

Modified the mitigations part. Martin,  I think that the new text addresses your review. Can you give it a look? Thanks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#issuecomment-296001838

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:24:21 -0700

040a5fe  And fixing a typo.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/46f293cbc6dda6059e8e26e17c4a9bf304590637..040a5fef588e409c2a8a22088768fdfbf443bc81

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Apr 2017 18:28:33 -0700

martinthomson approved this pull request.

Yep, looks fine.  I'll give others a chance to poke at this a little before merging.

> @@ -2697,6 +2697,25 @@ also be forward-secure encrypted.  Since the attacker will not have the forward
 
+## 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.
+
+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

"may leads" -> "can lead"

+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.
+
+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.
+
+QUIC deployments SHOULD provide mitigations against the stream fragmentation
+attack. Mitigations MAY consist of avoiding over-committing memory, delaying

Don't use "MAY" here, it's not permissive.  "could" is fine.

> +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.
+
+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.
+
+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

"STREAM frames"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#pullrequestreview-33920897

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:32:02 -0700

a168b3b  STREAM frames.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/040a5fef588e409c2a8a22088768fdfbf443bc81..a168b3bd50a08fe0a984abc960452e90950ec19b

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:33:07 -0700

31872b3  Can lead

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/a168b3bd50a08fe0a984abc960452e90950ec19b..31872b3649f9fd01edd84900730d341abe1cff9a

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:34:21 -0700

b47c030  MAY -> could

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/444/files/31872b3649f9fd01edd84900730d341abe1cff9a..b47c0307b3c07326bd86b59642e70bf7cf1ea34e

---

From: huitema <[email-masked]>
Date: Thu, 20 Apr 2017 18:34:51 -0700

OK, I believe I fixed all that...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#discussion_r112593755

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Apr 2017 18:28:10 -0700

Merged #444.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/444#event-1053967899