NetBSD Problem Report #58559

From www@netbsd.org  Wed Aug  7 12:49:55 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 368951A923A
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  7 Aug 2024 12:49:55 +0000 (UTC)
Message-Id: <20240807124954.020EC1A923C@mollari.NetBSD.org>
Date: Wed,  7 Aug 2024 12:49:53 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: experimental wg(4) never times out of INIT_PASSIVE state
X-Send-Pr-Version: www-1.0

>Number:         58559
>Category:       kern
>Synopsis:       experimental wg(4) never times out of INIT_PASSIVE state
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 07 12:50:01 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The NotWG Foundwhere are you?
>Environment:
>Description:
When wg(4) receives a handshake initiation, it will send a handshake response and wait for the first data packet from the peer:

[W] 6.3 Key Rotation
"But, keep in mind that after an initiator receives a handshake response (section 5.4.3), the responder cannot send transport data messages (section 5.4.6) until it has received the first transport data message from the initiator."

If the peer initiates and never sends that first data packet -- e.g., the network blips out for a couple minutes between the handshake initiation and the first data packet, so the initiator gives up -- then wg(4) gets stuck, even if it has packets to send, because the session destruction timer:

1. destroys the _unstable_ session only when it is in DESTROYING state, and
2. destroys the _stable_ session only when it is in ESTABLISHED state,

but in this case the unstable session is in INIT_PASSIVE state.
>How-To-Repeat:
Send a handshake initiation message to wg(4) and don't follow up with a data message.
>Fix:
Teach the session destruction timer to destroy the unstable session if it is in INIT_PASSIVE state and old enough.

(INIT_ACTIVE state will be handled by the handshake retry logic, so there is no need to handle that differently.)

Home	PR Database Search