All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: Antony Antony <antony@phenome.org>
Cc: antony.antony@secunet.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, devel@linux-ipsec.org,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [devel-ipsec] [PATCH v2 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway
Date: Tue, 31 Oct 2023 03:59:57 -0400	[thread overview]
Message-ID: <3211020.1698739197@dyas> (raw)
In-Reply-To: <ZT4zUnhvbW2VZlRm@Antony2201.local>

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]


Antony Antony <antony@phenome.org> wrote:
    > On Fri, Oct 27, 2023 at 09:30:07AM -0400, Michael Richardson via Devel
    > wrote:
    >>
    >> Antony Antony via Devel <devel@linux-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.

Yes, that's why sending from a public, topically significant source address
is really important.  Yet, many links are numbered in 1918 because..

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

    > 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.

yeah, I really don't want to do SNAT stuff.
I'd like to have a flag on each interface that says to use the "global" ICMP
source or use the heuristic we have now.  And then we need a way to set that
source address.  Most routing platforms put a /32 address (and /128) on lo
(or a dummy) as the device's reachable address, and then spread that through
OSPF.







[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

  reply	other threads:[~2023-10-31 10:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YTXGGiMzsda6mcm2@AntonyAntony.local>
2021-12-19  0:28 ` [RFC PATCH ipsec-next] xfrm: add forwarding ICMP error message Antony Antony
2023-10-26 14:45   ` [PATCH ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-10-26 19:41     ` kernel test robot
2024-01-30 10:36     ` Dan Carpenter
2024-01-31 19:38       ` Antony Antony
2024-01-31 19:48         ` Dan Carpenter
2024-01-31 19:50           ` Dan Carpenter
2023-10-26 14:45   ` [PATCH ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27  8:16   ` [PATCH v2 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-11-17  9:13     ` Steffen Klassert
2023-11-25 22:48       ` [devel-ipsec] " Antony Antony
2023-10-27  8:16   ` [PATCH v2 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-10-27 13:30     ` [devel-ipsec] " Michael Richardson
2023-10-29 10:26       ` Antony Antony
2023-10-31  7:59         ` Michael Richardson [this message]
2023-11-17  9:21     ` Steffen Klassert
2023-11-25 23:15       ` [devel-ipsec] " Antony Antony
2023-12-19 20:29   ` [PATCH v3 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-19 20:30   ` [PATCH v3 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-21 13:12   ` [PATCH v4 ipsec-next 1/2] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2023-12-21 13:12   ` [PATCH v4 ipsec-next 2/2] xfrm: fix source address in icmp error generation from IPsec gateway Antony Antony
2023-12-22  7:23     ` Steffen Klassert
2023-12-22 12:56       ` Antony Antony
2023-12-22 12:57   ` [PATCH v5 ipsec-next] xfrm: introduce forwarding of ICMP Error messages Antony Antony
2024-01-04  9:39     ` Steffen Klassert
2024-01-19 11:27   ` [PATCH v6 " Antony Antony
2024-01-26  9:11     ` Steffen Klassert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3211020.1698739197@dyas \
    --to=mcr@sandelman.ca \
    --cc=antony.antony@secunet.com \
    --cc=antony@phenome.org \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.