comparison src/event/quic/ngx_event_quic_migration.c @ 9191:618132842e7c

QUIC: ignore duplicate PATH_CHALLENGE frames. According to RFC 9000, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a single packet. The change adds a check to enforce this claim to optimize server behavior. Previously each PATH_CHALLENGE always resulted in a single response datagram being sent to client. The effect of this was however limited by QUIC flood protection. Also, PATH_CHALLENGE is explicitly disabled in Initial and Handshake levels, see RFC 9000, Table 3. However, technically it may be sent by client in 0-RTT over a new path without actual migration, even though the migration itself is prohibited during handshake. This allows client to coalesce multiple 0-RTT packets each carrying a PATH_CHALLENGE and end up with multiple PATH_CHALLENGEs per datagram. This again leads to suboptimal behavior, see above. Since the purpose of sending PATH_CHALLENGE frames in 0-RTT is unclear, these frames are now only allowed in 1-RTT. For 0-RTT they are silently ignored.
author Roman Arutyunyan <arut@nginx.com>
date Wed, 22 Nov 2023 14:48:12 +0400
parents 3a67dd34b6cc
children efcdaa66df2e
comparison
equal deleted inserted replaced
9190:3a67dd34b6cc 9191:618132842e7c
38 { 38 {
39 size_t min; 39 size_t min;
40 ngx_quic_frame_t frame, *fp; 40 ngx_quic_frame_t frame, *fp;
41 ngx_quic_connection_t *qc; 41 ngx_quic_connection_t *qc;
42 42
43 if (pkt->level != ssl_encryption_application || pkt->path_challenged) {
44 ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0,
45 "quic ignoring PATH_CHALLENGE");
46 return NGX_OK;
47 }
48
49 pkt->path_challenged = 1;
50
43 qc = ngx_quic_get_connection(c); 51 qc = ngx_quic_get_connection(c);
44 52
45 ngx_memzero(&frame, sizeof(ngx_quic_frame_t)); 53 ngx_memzero(&frame, sizeof(ngx_quic_frame_t));
46 54
47 frame.level = ssl_encryption_application; 55 frame.level = ssl_encryption_application;