netdev - Re: [devel-ipsec] Re: [PATCH RFC ipsec-next] esp: Consolidate esp4 and esp6.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6ceb36e2-383b-b30f-bc99-a95dff5e7008@nohats.ca>
Date: Mon, 27 Oct 2025 13:14:41 -0400 (EDT)
From: Paul Wouters <paul@...ats.ca>
To: Sabrina Dubroca <sd@...asysnail.net>
cc: Steffen Klassert <steffen.klassert@...unet.com>, netdev@...r.kernel.org, 
    devel@...ux-ipsec.org
Subject: Re: [devel-ipsec] Re: [PATCH RFC ipsec-next] esp: Consolidate esp4
 and esp6.

On Mon, 27 Oct 2025, Sabrina Dubroca via Devel wrote:

>> +		/* XXX: perhaps add an extra
>> +		 * policy check here, to see
>> +		 * if we should allow or
>> +		 * reject a packet from a
>> +		 * different source
>> +		 * address/port.
>>  		 */
>
> Maybe we can get rid of those "XXX" comments? Unless you think the
> suggestion still makes sense. But the comments (here and in
> esp6_input_done2) have been here a long time and it doesn't seem to
> bother users.

The whole NAT-T mapping assumptions / rewriting are not RFC compliant
anyway, and need fixing. Similar to accepting encap/non-encap
with a single state. So I guess yes, this one comment on the whole issue
might as well get removed here.

Paul