PATH_CHALLENGE Retransmission Reuses Payload

[t-minzheng]

Description

According to RFC 9000 §9.3:

An endpoint MUST NOT reuse a PATH_CHALLENGE payload if it sends a new PATH_CHALLENGE frame on the same path.

However, PATH_CHALLENGE retransmissions reuse the same challenge payload stored in Path->Challenge. This violates the RFC requirement that each PATH_CHALLENGE frame carry a unique payload per path.
The retransmission logic sets a flag to resend the PATH_CHALLENGE, but does not regenerate the payload:

msquic/src/core/loss_detection.c

Lines 829 to 855 in 29ae7aa

	case QUIC_FRAME_PATH_CHALLENGE: {
	uint8_t PathIndex;
	QUIC_PATH* Path = QuicConnGetPathByID(Connection, Packet->PathId, &PathIndex);
	if (Path != NULL && !Path->IsPeerValidated) {
	uint64_t TimeNow = CxPlatTimeUs64();
	CXPLAT_DBG_ASSERT(Connection->Configuration != NULL);
	uint64_t ValidationTimeout =
	CXPLAT_MAX(QuicLossDetectionComputeProbeTimeout(LossDetection, Path, 3),
	6 * MS_TO_US(Connection->Settings.InitialRttMs));
	if (CxPlatTimeDiff64(Path->PathValidationStartTime, TimeNow) > ValidationTimeout) {
	QuicTraceLogConnInfo(
	PathValidationTimeout,
	Connection,
	"Path[%hhu] validation timed out",
	Path->ID);
	QuicPerfCounterIncrement(
	Connection->Partition, QUIC_PERF_COUNTER_PATH_FAILURE);
	QuicPathRemove(Connection, PathIndex);
	} else {
	Path->SendChallenge = TRUE;
	QuicSendSetSendFlag(
	&Connection->Send,
	QUIC_CONN_SEND_FLAG_PATH_CHALLENGE);
	}
	}
	break;
	}

This is also confirmed by the comment in QuicConnRecvPostProcessing:

msquic/src/core/connection.c

Lines 5454 to 5458 in 29ae7aa

	// NB: The path challenge payload is initialized here and reused
	// for any retransmits, but the spec requires a new payload in each
	// path challenge.
	//
	CxPlatRandom(sizeof((*Path)->Challenge), (*Path)->Challenge);