Subject: [quicwg/base-drafts] Protection against abusive packet numbers (#1751)

From: MikkelFJ <[email-masked]>
Date: Sun, 16 Sep 2018 02:06:00 -0700

There is no easy way for a peer to decided when there are too many packets lost based on the packet numbers - even if the criteria is deployment specific.

The sender does not need to introduce large gaps and by enforcing that, the peer can make an informed decision on the packet number range.

There is also no error to disconnect due to suspected abuse. A too large packet number gap could be for valid reasons, even if the loss is too high to proceed. A new error that can deal with both these conditions would be useful.

-- 
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/issues/1751

---

From: Marten Seemann <[email-masked]>
Date: Sun, 16 Sep 2018 03:33:41 -0700

What’s the harm in sending a big gap?
Sending *too many* gaps is a DoS against my implementation (which I defend against by limiting the number of gaps), but I don’t see how a large gap would be an attack.

-- 
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/issues/1751#issuecomment-421740840

---

From: MikkelFJ <[email-masked]>
Date: Sun, 16 Sep 2018 06:58:16 -0700

Yes, I wanted to protect against a number of gaps as well, but it is difficult to enforce. I needed something simple that is also tolerant to natural loss. If you have a better formulation please suggest.

A big gap can be an attack in the sense that it prevents optimal implementations. You can't use bitmaps safely because you add a few entries per block a bitmap covers. If you can have at most one gap per packet, a bitmap is safe but it will hurt interval maps. Interval maps can guard against this by adopting small bitmaps per node, like a 32 or 64 bit word. You now have a safe upper bound on the number of allocations to expect, and if that fails, you can bail.

-- 
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/issues/1751#issuecomment-421769681

---

From: MikkelFJ <[email-masked]>
Date: Sun, 16 Sep 2018 07:12:17 -0700

Note that I indirectly require the gap count to be low by saying the the packet number SHOULD increase by one. I added some text to keep the gap count low.

-- 
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/issues/1751#issuecomment-421771716

---

From: ianswett <[email-masked]>
Date: Mon, 17 Sep 2018 06:28:13 -0700

Gaps are somewhat costly, but the cost can be limited by limiting the number of intervals in the interval set as Marten said.

I agree that data-structures are more compact and efficient with fewer gaps, but that applies to the sender even more than the receiver, at least in my implementation.

-- 
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/issues/1751#issuecomment-422015758

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Sep 2018 06:33:07 -0700

It may be more costly to the sender, but 1) the sender has the control, and 2) the sender might be malicous. The idea is to provider the receiver with some guarantees that should not be hard for a cooperative sender to comply with.

-- 
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/issues/1751#issuecomment-422017610

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2018 11:32:23 -0700

This is just one of many cases where implementations need to guard themselves.  Nothing we can do about that in the spec.

-- 
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/issues/1751#issuecomment-422122494

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2018 11:32:26 -0700

Closed #1751.

-- 
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/issues/1751#event-1850514444