Security issue notifications
If you discover a potential security issue in s2n-quic we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
During a dcQUIC handshake, the expectation is that for a successful handshake both sides emit a dc_state_changed=Complete event. In practice, it seems that this is not true.
I've attached a log.txt of events from such a handshake where dc_state_changed=Complete is only reached on the client, not the server. Some rough poking suggests this is because there's no ACK for the StatelessResetTokens sent by the server, but that may not be an accurate root cause.
This was reproduced under ~30% packet loss configured via:
sudo yum install iproute-tc iproute
sudo tc qdisc add dev lo root netem
sudo tc qdisc change dev lo root netem loss 30%
but we have seen this as a spurious test failure in a build fleet repeatedly, which presumably doesn't have packet loss to that extent on loopback (but perhaps non-zero).
Need By Date:
n/a
Solution:
Needs more investigation. It may involve changing what is sent over the wire or the logic for when to close connections (e.g., ConfirmComplete).
- Does this change what s2n-quic sends over the wire? maybe, but at most new ACKs probably
- Does this change any public APIs? no
Requirements / Acceptance Criteria:
- RFC links: not aware of any
- Related Issues: n/a
- Will the Usage Guide or other documentation need to be updated? no
- Testing: bach tests verifying dc_state_changed continues to get reached under packet loss reliably
Out of scope:
Nothing known.
Security issue notifications
If you discover a potential security issue in s2n-quic we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.
Problem:
During a dcQUIC handshake, the expectation is that for a successful handshake both sides emit a dc_state_changed=Complete event. In practice, it seems that this is not true.
I've attached a log.txt of events from such a handshake where dc_state_changed=Complete is only reached on the client, not the server. Some rough poking suggests this is because there's no ACK for the StatelessResetTokens sent by the server, but that may not be an accurate root cause.
This was reproduced under ~30% packet loss configured via:
but we have seen this as a spurious test failure in a build fleet repeatedly, which presumably doesn't have packet loss to that extent on loopback (but perhaps non-zero).
Need By Date:
n/a
Solution:
Needs more investigation. It may involve changing what is sent over the wire or the logic for when to close connections (e.g., ConfirmComplete).
Requirements / Acceptance Criteria:
Out of scope:
Nothing known.