#2532 closed defect (fixed)

Nginx close connection immeadiately when handle quic connection migration

Reported by: xhrlog@… Owned by:
Priority: minor Milestone:
Component: http/3 Version: 1.25.x
Keywords: Cc: xhrlog@…
uname -a:
nginx -V: ginx version: nginx/1.25.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
built with OpenSSL 1.1.1u 25 May 2023
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-http_realip_module --with-http_image_filter_module --with-http_sub_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_stub_status_module --with-http_perl_module --with-http_slice_module --with-http_auth_request_module --with-pcre --without-pcre2 --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY__SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wno-sign-compare -DAZN_NGX_HTTP_UPSTREAM_RESOLVER -I/usr/local/include -O0 -g' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/lib64/'

Description (last modified by xhrlog@…)

Hi! After patch https://hg.nginx.org/nginx/rev/f3412ec3b6d1, I found it still can return error.

The scenarios is: client send a request after some idle time(like 10s) with a new socket. And server triggered connection migration.Before validating the new path, it would validate old path first.

The problem is when server call sendmsg to send path_challeng frame,some clients would return a ICMP message which contains "Destination unreachable". And sendmsg would return NGX_ERROR and nginx close the connection immeadiately.

But in this situation, I think nginx should try to send response with new path and shouldn't close the connection.

Attachments (2)

problem.jpg (89.9 KB ) - added by xhrlog@… 11 months ago.
quic-old-path-validation (1.2 KB ) - added by Roman Arutyunyan 11 months ago.

Download all attachments as: .zip

Change History (8)

by xhrlog@…, 11 months ago

Attachment: problem.jpg added

comment:1 by xhrlog@…, 11 months ago

Description: modified (diff)

comment:2 by xhrlog@…, 11 months ago

Description: modified (diff)

comment:3 by Roman Arutyunyan, 11 months ago

Normally ICMP takes some time to arrive and error is not returned by the same sendmsg(). That's why we rely on sendmsg() being always successful under normal conditions. We'll look deeper into this.

by Roman Arutyunyan, 11 months ago

Attachment: quic-old-path-validation added

comment:4 by Roman Arutyunyan, 11 months ago

Please try the attached patch.

comment:5 by Roman Arutyunyan <arut@…>, 11 months ago

In 9154:f6b6f3dd7ca0/nginx:

QUIC: ignore path validation socket error (ticket #2532).

Previously, a socket error on a path being validated resulted in validation
error and subsequent QUIC connection closure. Now the error is ignored and
path validation proceeds as usual, with several retries and a timeout.

When validating the old path after an apparent migration, that path may already
be unavailable and sendmsg() may return an error, which should not result in
QUIC connection close.

When validating the new path, it's possible that the new client address is
spoofed (See RFC 9000, 9.3.2. On-Path Address Spoofing). This address may
as well be unavailable and should not trigger QUIC connection closure.

comment:6 by Roman Arutyunyan, 11 months ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.