From: Paolo Abeni <pabeni@redhat.com>
To: Guy Avraham <guyavrah1986@gmail.com>,
davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
kuba@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net:ipv4:ip_route_input_slow: Change behaviour of routing decision when IP router alert option is present
Date: Thu, 19 Sep 2024 12:06:01 +0200 [thread overview]
Message-ID: <49d32698-e226-46b5-bee8-46e9aad5754b@redhat.com> (raw)
In-Reply-To: <20240912141440.314005-1-guyavrah1986@gmail.com>
Hi,
On 9/12/24 16:14, Guy Avraham wrote:
> When an IP packet with the IP router alert (RFC 2113) field arrives
> to some host who is not the destination of that packet (i.e - non of
> its interfaces is the address in the destination IP address field of that
> packet) and, for whatever reason, it does not have a route to this
> destination address, it drops this packet during the "routing decision"
> flow even though it should potentially pass it to the relevant
> application(s) that are interested in this packet's content - which happens
> in the "forwarding decision" flow. The suggested fix changes this behaviour
> by setting the ip_forward as the next "step" in the flow of the packet,
> just before it (previously was) is dropped, so that later the ip_forward,
> as usual, will pass it on to its relevant recipient (socket), by
> invoking the ip_call_ra_chain.
>
> Signed-off-by: Guy Avraham <guyavrah1986@gmail.com>
> ---
> The fix was tested and verified on Linux hosts that act as routers in which
> there are kerenls 3.10 and 5.2. The verification was done by simulating
> a scenario in which an RSVP (RFC 2205) Path message (that has the IP
> router alert option set) arrives to a transit RSVP node, and this host
> passes on the RSVP Path message to the relevant socket (of the RSVP
> deamon) even though upon arrival of this packet it does NOT have route
> to the destination IP address of the IP packet (that encapsulates the
> RSVP Path message).
>
> net/ipv4/route.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 13c0f1d455f3..7c416eca84f8 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2360,8 +2360,12 @@ out: return err;
>
> RT_CACHE_STAT_INC(in_slow_tot);
> if (res->type == RTN_UNREACHABLE) {
> - rth->dst.input= ip_error;
> - rth->dst.error= -err;
> + if (IPCB(skb)->opt.router_alert)
> + rth->dst.input = ip_forward;
> + else
> + rth->dst.input = ip_error;
> +
> + rth->dst.error = -err;
> rth->rt_flags &= ~RTCF_LOCAL;
> }
>
I think this is not the correct solution. At very least you should check
the host is actually a router (forwarding is enabled) and someone has
registered to receive router alerts. At that point you will be better
off processing the router alert in place directly calling
ip_call_ra_chain().
However I'm unsure all the above is actually required. It can be argued
your host has a bad configuration.
If it's a AS border router, and there is no route for the destination,
the packet not matching any route is invalid and should be indeed
dropped/not processed.
Otherwise you should have/add a catch-up default route - at very least
to handle this cases. If you really want to forward packets only to
known destination, you could make such route as blackhole one.
Cheers,
Paolo
next prev parent reply other threads:[~2024-09-19 10:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 14:14 Guy Avraham
2024-09-19 10:06 ` Paolo Abeni [this message]
2024-09-22 16:36 ` Guy Avraham
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=49d32698-e226-46b5-bee8-46e9aad5754b@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=guyavrah1986@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®