...continued from
part 121.5 Request Forgery Attacks
This paragraph focuses on the risk posed by reflected datagrams. The concerns are somewhat similar to these in the anti-amplification section, except that here the focus is on sending datagrams to otherwise inaccessible services, and forging datagrams that would make the inaccessible services react in a specific way.
Most of the concerns listed here apply to the server side; other than using the server-supplied preferred address, the client does not migrate to other addresses. We do not support preferred address at the moment, so that doesn't apply either.
21.6 Slowloris attack
Slowloris aims at making the endpoint keep as many open connections as possible.
HttpClient may keep multiple connections to the same server. The number of open connections to a single server is at most the number of outstanding requests plus one. It's the user's responsibility to limit the number of concurrently executing requests.
21.7 Stream Fragmentation and Reassembly Attacks
QUIC implementation needs to buffer stream data on on the sending side until the data is acknowledged by peer, and on the receiving side until the data is received by the higher layer. If there are gaps in the received stream, the data needs to be buffered until the gaps are filled. This can lead to excessive memory consumption.
On the receiver side, HttpClient limits the MAX_DATA QUIC parameter to a maximum of 15 MB per connection at all times. If certain portions of stream data are received multiple times, only one copy is preserved until the data is received by the application. Buffer memory utilization is therefore bounded.
Memory structures used to store discontinuous ranges of stream data might consume excessive amounts of memory. The maximum memory usage has not been measured.
Crypto stream receive buffer is limited to 64KB per connection.
On the sender side, we buffer as much data as the congestion controller allows. This might lead to memory overcommit if the receiver successfully inflates the congestion window.
EDIT 24.04.2025:
We now detect when the peer sends excessive number of small frames, and close the connection if that happens. The detector is configured to verify that the average fragment size is above a certain threshold when the number of undeliverable fragments gets large.
21.8 Stream Commitment Attack
We limit the number of streams the peer can open at any time to 100 per stream type per connection.
21.9 Peer Denial of Service
This section recommends to "track cost of processing relative to progress and treat [excess] as indicative of an attack".
We do not track the cost of processing.
EDIT 24.04.2025:
see the edit on point 21.7 above
21.10 Explicit Congestion Notification Attacks
No additional requirements.
HttpClient's QUIC implementation does not support sending or receiving ECN yet.
21.11 Stateless Reset Oracle
Every QUIC endpoint uses a different randomly generated key for generating stateless reset tokens. The keys are never shared, so a stateless reset is only generated if a connection ID is not in use.
EDIT 24.04.2025:
Recipe for a stateless reset oracle:
The client can open multiple endpoints. All endpoints use the same key to generate stateless reset token, but each endpoint keeps its own list of active connection IDs.
Our client keeps a different key on every associated endpoint.
21.12 Version Downgrade
The current implementation only supports QUIC v1 and v2. These versions offer identical security properties, so version downgrade is not a concern.
21.13 Targeted Attacks by Routing
This section describes deployment concerns, as opposed to implementation concerns. No additional implementation requirements.
21.14 Traffic Analysis
Currently our QUIC API offers no way to obscure the length of the packet content.
This concludes the review of RFC 9000 security considerations.
continued in part 3...
