netdev - Re: [PATCH net-next] net: PIM register decapsulation and Forwarding.

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

Date:   Wed, 18 May 2022 09:18:30 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     David Ahern <dsahern@...nel.org>
Cc:     Ido Schimmel <idosch@...dia.com>,
        Saranya Panjarathina <plsaranya@...il.com>,
        netdev@...r.kernel.org, Saranya_Panjarathina@...l.com,
        davem@...emloft.net, yoshfuji@...ux-ipv6.org, edumazet@...gle.com,
        pabeni@...hat.com, linux-kernel@...r.kernel.org,
        g_balaji1@...l.com, Nikolay Aleksandrov <razor@...ckwall.org>
Subject: Re: [PATCH net-next] net: PIM register decapsulation and
 Forwarding.

On Wed, 18 May 2022 08:36:26 -0600 David Ahern wrote:
> >> Trying to understand the problem:
> >>
> >> 1. The RP has an (*, G) towards the receiver(s) (receiver joins first)
> >> 2. The RP receives a PIM Register packet encapsulating the packet from
> >> the source
> >> 3. The kernel decapsulates the packet and injects it into the Rx path as
> >> if the packet was received by the pimreg netdev
> >> 4. The kernel forwards the packet according to the (*, G) route (no RPF
> >> check)
> >>
> >> At the same time, the PIM Register packet should be received by whatever
> >> routing daemon is running in user space via a raw socket for the PIM
> >> protocol. My understanding is that it should cause the RP to send a PIM
> >> Join towards the FHR, causing the FHR to send two copies of each packet
> >> from the source: encapsulated in the PIM Register packet and over the
> >> (S, G) Tree.
> >>
> >> If the RP already has an (S, G) route with IIF of skb->dev and the
> >> decapsulated packet is injected into the Rx path via skb->dev, then what
> >> prevents the RP from forwarding the same packet twice towards the
> >> receiver(s)?
> >>
> >> I'm not a PIM expert so the above might be nonsense. Anyway, I will
> >> check with someone from the FRR teams who understands PIM better than
> >> me.  
> > 
> > We discussed this patch in FRR slack with the author and PIM experts.
> > The tl;dr is that the patch is working around what we currently believe
> > is an FRR bug, which the author will try to fix.
> > 
> > After receiving a PIM Register message on the RP, FRR installs an (S, G)
> > route with IIF being the interface via which the packet was received
> > (skb->dev). FRR also sends a PIM Join towards the FHR and eventually a
> > PIM Register Stop.
> > 
> > The current behavior means that due to RPF assertion, all the
> > encapsulated traffic from the source is dropped on the RP after FRR
> > installs the (S, G) route.
> > 
> > The patch is problematic because during the time the FHR sends both
> > encapsulated and native traffic towards the RP, the RP will forward both
> > copies towards the receiver(s).
> > 
> > Instead, the suggestion is for FRR to install the initial (S, G) route
> > with IIF being the pimreg device. This should allow decapsulated traffic
> > to be forwarded correctly. Native traffic will trigger RPF assertion and
> > thereby prompt FRR to: a) Replace the IIF from pimreg to the one via
> > which traffic is received b) Send a PIM Register Stop towards the FHR,
> > instructing it to stop sending encapsulated traffic.
> >   
> 
> Thanks for diving into the problem and for the detailed response.

+1, thanks Ido!