You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The important point here is the fact that server changes SCID on its INITIAL after retry, (see Initial: DCID=C1, SCID=S3).
However, it seems the HANDSHAKE packet afterwards generated by the server does not correctly populate the quic transport parameter. In particular, the retry_source_connection_id (0x10).
That field should contain the SCID used in the RETRY packet (from the example above would be S2).
Instead, in quiche code seems that field is always populated with the SCID build for the INITIAL packet (in the example would be S3): here -today mainline commit-.
If I am not wrong, this will make all handshakes fail because of this check on the client side (which comes from the RFC9000#7.3).
The only workarounds I see (with possible drawbacks) are:
Do not perform RETRY mechanism. This makes denial of service attacks easier tho.
Do not change SCID during RETRY/INITIAL (that is having S2 == S3).
Essentially, this is what has been made in the example of this repo example/server.rs.
I am not sure if there are security implications into having S2 == S3 and whether it's fine keeping the same connection id.
Is this a known limitation or am I missing something else?
The text was updated successfully, but these errors were encountered:
// This is a simplified and illustrative example.
impl Connection {
fn handle_retry(&mut self, retry_packet: &RetryPacket) {
// Store the SCID from the RETRY packet
self.retry_source_connection_id = retry_packet.scid.clone();
}
fn generate_initial_packet(&self) -> InitialPacket {
let mut initial_packet = InitialPacket::new();
// Ensure retry_source_connection_id is set correctly
initial_packet.retry_source_connection_id = self.retry_source_connection_id.clone();
initial_packet
}
}
From RFC 9000#7.3, the scenario is:
The important point here is the fact that server changes
SCID
on itsINITIAL
after retry, (seeInitial: DCID=C1, SCID=S3
).However, it seems the
HANDSHAKE
packet afterwards generated by the server does not correctly populate the quic transport parameter. In particular, theretry_source_connection_id (0x10)
.That field should contain the
SCID
used in theRETRY
packet (from the example above would beS2
).Instead, in quiche code seems that field is always populated with the
SCID
build for theINITIAL
packet (in the example would beS3
): here -today mainline commit-.If I am not wrong, this will make all handshakes fail because of this check on the client side (which comes from the RFC9000#7.3).
The only workarounds I see (with possible drawbacks) are:
S2 == S3
).S2 == S3
and whether it's fine keeping the same connection id.Is this a known limitation or am I missing something else?
The text was updated successfully, but these errors were encountered: