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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZT4zUnhvbW2VZlRm@Antony2201.local>
Date: Sun, 29 Oct 2023 11:26:26 +0100
From: Antony Antony <antony@...nome.org>
To: Michael Richardson <mcr@...delman.ca>
Cc: antony.antony@...unet.com, Herbert Xu <herbert@...dor.apana.org.au>,
	netdev@...r.kernel.org, devel@...ux-ipsec.org,
	Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [devel-ipsec] [PATCH v2 ipsec-next 2/2] xfrm: fix source address
 in icmp error generation from IPsec gateway

On Fri, Oct 27, 2023 at 09:30:07AM -0400, Michael Richardson via Devel wrote:
> 
> Antony Antony via Devel <devel@...ux-ipsec.org> wrote:
>     > When enabling support for xfrm lookup using reverse ICMP payload,
>     > We have identified an issue where the source address of the IPv4 e.g
>     > "Destination Host Unreachable" message is incorrect. The IPv6 appear
>     > to do the right thing.
> 
> One thing that operators of routers with a multitude of interfaces want to do
> is send all ICMP messages from a specific IP address.  Often the public
> address, that has the sane reverse DNS name.

While it makes sense for routers with multiple interfaces, receiving ICMP 
errors from private addresses can be confusing. However, wouldn't this also 
make it more challenging to adhere to BCP 32 and BCP 38? Routing with 
multiple interfaces is tricky on Linux, especially when it comes to 
compliance with these BCPs.

> AFAIK, this is not an option on Linux, but Cisco/Juniper/etc. devices usually
> can do this.  I can't recall how today. (I was actually looking that up this week)

I wonder if a netfilter rule would be a solution for you, something like:

"ip protocol icmp type <error codes> snat to x.x.x.x"

I would love see a simple option instead of a SNAT hack. May be a routing 
rule that will choose sourse address for ICMP error code.

> This can conflict however, with the need to get the result back into the
> tunnel.  I don't have a good answer, except that we probably need a fair bit

Forwarding that ICMP packet, which is not covered by your forward IPsec 
policy, would be fixed with the second patch in this series. In that case 
lookup would using the orginal packet as describe in RFC 4301, Section 6.

-antony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ