netdev - Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

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: <CALx6S35BrV_KTgbwSKc-CiW4RRwHinKXJNhB+gmU9kQgvfTC+w@mail.gmail.com>
Date:   Thu, 27 Oct 2016 15:35:27 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     Jakub Sitnicki <jkbs@...hat.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        James Morris <jmorris@...ei.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded
 ICMP errors from offending packet

On Mon, Oct 24, 2016 at 2:28 AM, Jakub Sitnicki <jkbs@...hat.com> wrote:
> Same as for the transmit path, let's do our best to ensure that received
> ICMP errors that may be subject to forwarding will be routed the same
> path as flow that triggered the error, if it was going in the opposite
> direction.
>
Unfortunately our ability to do this is generally quite limited. This
patch will select the route for multipath, but I don't believe sets
the same link in LAG and definitely can't help switches doing ECMP to
route the ICMP packet in the same way as the flow would be. Did you
see a problem that warrants solving this case?

Tom


> Signed-off-by: Jakub Sitnicki <jkbs@...hat.com>
> ---
>  net/ipv6/route.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 1184c2b..c0f38ea 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1150,6 +1150,30 @@ struct dst_entry *ip6_route_input_lookup(struct net *net,
>  }
>  EXPORT_SYMBOL_GPL(ip6_route_input_lookup);
>
> +static u32 ip6_multipath_icmp_hash(const struct sk_buff *skb)
> +{
> +       const struct icmp6hdr *icmph = icmp6_hdr(skb);
> +       const struct ipv6hdr *inner_iph;
> +       struct ipv6hdr _inner_iph;
> +
> +       if (icmph->icmp6_type != ICMPV6_DEST_UNREACH &&
> +           icmph->icmp6_type != ICMPV6_PKT_TOOBIG &&
> +           icmph->icmp6_type != ICMPV6_TIME_EXCEED &&
> +           icmph->icmp6_type != ICMPV6_PARAMPROB)
> +               goto standard_hash;
> +
> +       inner_iph = skb_header_pointer(
> +               skb, skb_transport_offset(skb) + sizeof(*icmph),
> +               sizeof(_inner_iph), &_inner_iph);
> +       if (!inner_iph)
> +               goto standard_hash;
> +
> +       return icmpv6_multipath_hash(inner_iph);
> +
> +standard_hash:
> +       return 0; /* compute it later, if needed */
> +}
> +
>  void ip6_route_input(struct sk_buff *skb)
>  {
>         const struct ipv6hdr *iph = ipv6_hdr(skb);
> @@ -1168,6 +1192,8 @@ void ip6_route_input(struct sk_buff *skb)
>         tun_info = skb_tunnel_info(skb);
>         if (tun_info && !(tun_info->mode & IP_TUNNEL_INFO_TX))
>                 fl6.flowi6_tun_key.tun_id = tun_info->key.tun_id;
> +       if (unlikely(fl6.flowi6_proto == IPPROTO_ICMPV6))
> +               fl6.mp_hash = ip6_multipath_icmp_hash(skb);

I will point out that this is only
>         skb_dst_drop(skb);
>         skb_dst_set(skb, ip6_route_input_lookup(net, skb->dev, &fl6, flags));
>  }
> --
> 2.7.4
>