Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adding a description of stream commitment attacks in security section #445

Merged
merged 7 commits into from
Apr 24, 2017
Merged

Adding a description of stream commitment attacks in security section #445

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
c4cad2f
Adding a description of stream commitment attacks in security section
huitema Apr 19, 2017
12dd1f5
Update draft-ietf-quic-transport.md
huitema Apr 19, 2017
464a222
Splitting long lines so the verification does not complains so much.
huitema Apr 19, 2017
ddefb66
Removing a trailing white space.
huitema Apr 19, 2017
105e26e
Remove the trailing white space???
huitema Apr 19, 2017
693758b
Shortening the text, per Martin Thomson's review
huitema Apr 20, 2017
a169a17
Trailing white spaces. This check is heinous.
huitema Apr 20, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 8 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2707,23 +2707,27 @@ attack is in some ways similar to SYN flooding attack in TCP, in which the
attackers try to exhaust a server memory by creating a large number of half
open TCP connections. It is less potent than the SYN flooding attack, since
stream creation is much lighter weight than the creation of TCP-IP connections,
and stream control data presumably requires less memory resource than a TCP protocol
and stream control data presumably requires less
memory resource than a TCP protocol
control block. However, the attack can be amplified if the adversarial
client can open multiple streams with a single message.

Normally, clients will open streams sequentially, as explained in {{stream-identifiers}}.
Normally, clients will open streams sequentially,
as explained in {{stream-identifiers}}.
However, when several streams are initiated at short intervals,
transmission error may cause STREAM DATA frames opening streams to be
received out of sequence. Some implementations will have provisions to
open all intermediate streams in case of out-of-sequence arrival. For example,
a server that receive STREAM DATA for streams 3 and then 9 may decide to
open stream 5 and 7 immediately. An adversarial client would for example exploit that
open stream 5 and 7 immediately. An adversarial client
would for example exploit that
design by sending STREAM DATA for streams 3 and the 2,000,001, causing the
server to open 1 million connections, and contributing to server resource
exhaustion.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this is much easier: a receiver is obligated to open intervening streams if a higher-numbered stream ID is received. Thus, on a new connection, opening stream 2000001 opens 1 million streams, as required by the specification. The stream concurrency limit protects against this sort of attack.


The number of active streams is limited by the concurrent stream limit transport
parameter, as explained in {{stream-concurrency}}. If chosen judisciously, this limit
parameter, as explained in {{stream-concurrency}}.
If chosen judisciously, this limit
mitigates the effect of the stream commitment attack. However, setting the limit
too low could affect performance when applications expect to open large number
of streams.
Expand Down