NetBSD Problem Report #59070

From www@netbsd.org  Tue Feb 11 19:36:26 2025
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)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 5C2AB1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 11 Feb 2025 19:36:26 +0000 (UTC)
Message-Id: <20250211193625.129311A923C@mollari.NetBSD.org>
Date: Tue, 11 Feb 2025 19:36:25 +0000 (UTC)
From: andrew.cagney@gmail.com
Reply-To: andrew.cagney@gmail.com
To: gnats-bugs@NetBSD.org
Subject: net.ipsecif.use_fixed_reqid=1's behaviour
X-Send-Pr-Version: www-1.0

>Number:         59070
>Category:       kern
>Synopsis:       net.ipsecif.use_fixed_reqid=1's behaviour
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 11 19:40:01 +0000 2025
>Last-Modified:  Wed Feb 12 15:10:00 +0000 2025
>Originator:     Andrew Cagney
>Release:        10.1
>Organization:
>Environment:
# uname -a
NetBSD rise 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
An ipsec interface with net.ipsecif.use_fixed_reqid=0 and "no IPv6" gets assigned sequentially vis:

# sysctl -w net.ipsecif.use_fixed_reqid=0 ; ifconfig ipsec1 create ; ifconfig ipsec1 -link2 ; ifconfig ipsec1 inet tunnel 198.18.1.12 198.18.1.15 ; ifconfig ipsec1 inet 198.18.12.12/24 198.18.15.15 ; setkey -PD
net.ipsecif.use_fixed_reqid: 0 -> 0
198.18.1.15[any] 198.18.1.12[any] 4(ipv4)
	in ipsec
	esp/transport//unique#16389
	spid=17 seq=3 pid=947
	refcnt=0
198.18.1.15[any] 198.18.1.12[any] 41(ipv6)
	in discard
	spid=19 seq=2 pid=947
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 4(ipv4)
	out ipsec
	esp/transport//unique#16390
	spid=18 seq=1 pid=947
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 41(ipv6)
	out discard
	spid=20 seq=0 pid=947
	refcnt=0

same for an ipsec interface with IPv6:

# sysctl -w net.ipsecif.use_fixed_reqid=0 ; ifconfig ipsec1 create ; ifconfig ipsec1 inet tunnel 198.18.1.12 198.18.1.15 ; ifconfig ipsec1 inet 198.18.12.12/24 198.18.15.15 ; setkey -PD
net.ipsecif.use_fixed_reqid: 0 -> 0
198.18.1.15[any] 198.18.1.12[any] 4(ipv4)
	in ipsec
	esp/transport//unique#16393
	spid=21 seq=3 pid=1597
	refcnt=0
198.18.1.15[any] 198.18.1.12[any] 41(ipv6)
	in ipsec
	esp/transport//unique#16395
	spid=23 seq=2 pid=1597
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 4(ipv4)
	out ipsec
	esp/transport//unique#16394
	spid=22 seq=1 pid=1597
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 41(ipv6)
	out ipsec
	esp/transport//unique#16396
	spid=24 seq=0 pid=1597
	refcnt=0

however, when I flip net.ipsecif.use_fixed_reqid=1, things get interesting.

With no IPv6, it assigns 8194 for both inbound and outbound:

# sysctl -w net.ipsecif.use_fixed_reqid=1 ; ifconfig ipsec1 create ; ifconfig ipsec1 -link2 ; ifconfig ipsec1 inet tunnel 198.18.1.12 198.18.1.15 ; ifconfig ipsec1 inet 198.18.12.12/24 198.18.15.15 ; setkey -PD
net.ipsecif.use_fixed_reqid: 1 -> 1
198.18.1.15[any] 198.18.1.12[any] 4(ipv4)
	in ipsec
	esp/transport//unique:8194
	spid=29 seq=3 pid=550
	refcnt=0
198.18.1.15[any] 198.18.1.12[any] 41(ipv6)
	in discard
	spid=31 seq=2 pid=550
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 4(ipv4)
	out ipsec
	esp/transport//unique:8194
	spid=30 seq=1 pid=550
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 41(ipv6)
	out discard
	spid=32 seq=0 pid=550
	refcnt=0

and with IPv6, its 8194 for IPv4 and 8195 for IPv6:

# sysctl -w net.ipsecif.use_fixed_reqid=1 ; ifconfig ipsec1 create ; ifconfig ipsec1 inet tunnel 198.18.1.12 198.18.1.15 ; ifconfig ipsec1 inet 198.18.12.12/24 198.18.15.15 ; setkey -PD
net.ipsecif.use_fixed_reqid: 0 -> 1
198.18.1.15[any] 198.18.1.12[any] 4(ipv4)
	in ipsec
	esp/transport//unique:8194
	spid=25 seq=3 pid=1279
	refcnt=0
198.18.1.15[any] 198.18.1.12[any] 41(ipv6)
	in ipsec
	esp/transport//unique:8195
	spid=27 seq=2 pid=1279
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 4(ipv4)
	out ipsec
	esp/transport//unique:8194
	spid=26 seq=1 pid=1279
	refcnt=0
198.18.1.12[any] 198.18.1.15[any] 41(ipv6)
	out ipsec
	esp/transport//unique:8195
	spid=28 seq=0 pid=1279
	refcnt=0

I can't find anything documenting this.
>How-To-Repeat:

>Fix:

>Audit-Trail:
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59070: net.ipsecif.use_fixed_reqid=1's behaviour
Date: Tue, 11 Feb 2025 22:24:52 -0500

 I suspect there's also a bug.  But this assumes I understand the behaviour.

 Because different REQIDs are put on the IPv4 and IPv6 policy, I
 presumably need to install four SAs:
 - in reqid=IPv4
 - in reqid=IPv6
 - out reqid=IPv4
 - out reqid=IPv6
 instead of the standard two.

 On Tue, 11 Feb 2025 at 14:40, <gnats-admin@netbsd.org> wrote:
 >
 > Thank you very much for your problem report.
 > It has the internal identification `kern/59070'.
 > The individual assigned to look at your
 > report is: kern-bug-people.
 >
 > >Category:       kern
 > >Responsible:    kern-bug-people
 > >Synopsis:       net.ipsecif.use_fixed_reqid=1's behaviour
 > >Arrival-Date:   Tue Feb 11 19:40:01 +0000 2025
 >

From: Kengo Nakahara <k-nakahara@iij.ad.jp>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org, andrew.cagney@gmail.com
Cc: 
Subject: Re: kern/59070: net.ipsecif.use_fixed_reqid=1's behaviour
Date: Wed, 12 Feb 2025 12:46:53 +0900

 Hi,

 The behavior is by design.  I will update man later.

 Thanks,

 On 2025/02/12 12:30, Andrew Cagney wrote:
 > The following reply was made to PR kern/59070; it has been noted by GNATS.
 > 
 > From: Andrew Cagney <andrew.cagney@gmail.com>
 > To: gnats-bugs@netbsd.org
 > Cc:
 > Subject: Re: kern/59070: net.ipsecif.use_fixed_reqid=1's behaviour
 > Date: Tue, 11 Feb 2025 22:24:52 -0500
 > 
 >   I suspect there's also a bug.  But this assumes I understand the behaviour.
 >   
 >   Because different REQIDs are put on the IPv4 and IPv6 policy, I
 >   presumably need to install four SAs:
 >   - in reqid=IPv4
 >   - in reqid=IPv6
 >   - out reqid=IPv4
 >   - out reqid=IPv6
 >   instead of the standard two.
 >   
 >   On Tue, 11 Feb 2025 at 14:40, <gnats-admin@netbsd.org> wrote:
 >   >
 >   > Thank you very much for your problem report.
 >   > It has the internal identification `kern/59070'.
 >   > The individual assigned to look at your
 >   > report is: kern-bug-people.
 >   >
 >   > >Category:       kern
 >   > >Responsible:    kern-bug-people
 >   > >Synopsis:       net.ipsecif.use_fixed_reqid=1's behaviour
 >   > >Arrival-Date:   Tue Feb 11 19:40:01 +0000 2025
 >   >
 >   

 -- 
 //////////////////////////////////////////////////////////////////////
 Internet Initiative Japan Inc.

 Device Engineering Section,
 Core Product Development Department,
 Network Division,
 Technology Unit

 Kengo NAKAHARA <k-nakahara@iij.ad.jp>



From: Andrew Cagney <andrew.cagney@gmail.com>
To: Kengo Nakahara <k-nakahara@iij.ad.jp>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org
Subject: Re: kern/59070: net.ipsecif.use_fixed_reqid=1's behaviour
Date: Wed, 12 Feb 2025 10:06:04 -0500

 On Tue, 11 Feb 2025 at 22:46, Kengo Nakahara <k-nakahara@iij.ad.jp> wrote:
 >
 > Hi,
 >
 > The behavior is by design.  I will update man later.

 There's something I'm not understanding.

 > >   Because different REQIDs are put on the IPv4 and IPv6 policy, I
 > >   presumably need to install four SAs:
 > >   - in reqid=IPv4
 > >   - in reqid=IPv6
 > >   - out reqid=IPv4
 > >   - out reqid=IPv6
 > >   instead of the standard two.

 One of IKEv2's SOPs is to establish a single ESP SA and use that to
 tunnel all traffic - both IPv4 and IPv6.
 Here, that would presumably mean creating SAs that are identical other
 than the REQID (same keys, same alg, same inbound/outbound SPIs).
 What I'm not understanding is how the kernel, given only the inbound
 SPI, can select the correct SA.  Perhaps it uses the Next Header
 field.

Home	PR Database Search