netdev - Re: [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter

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: <CAHsH6GvT=Af-BAWK0z_CdrYWPn0qt+C=BRjy10MLRNhLWfH0rQ@mail.gmail.com>
Date:   Wed, 9 Dec 2020 16:40:23 +0200
From:   Eyal Birger <eyal.birger@...il.com>
To:     Phil Sutter <phil@....cc>, Eyal Birger <eyal.birger@...il.com>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        linux-crypto@...r.kernel.org, netfilter-devel@...r.kernel.org,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>
Subject: Re: [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter

Hi Phil,

On Tue, Dec 8, 2020 at 8:51 PM Phil Sutter <phil@....cc> wrote:
>
> Hi Eyal,
>
> On Tue, Dec 08, 2020 at 04:47:02PM +0200, Eyal Birger wrote:
> > On Mon, Dec 7, 2020 at 4:07 PM Phil Sutter <phil@....cc> wrote:
> > >
> > > With an IPsec tunnel without dedicated interface, netfilter sees locally
> > > generated packets twice as they exit the physical interface: Once as "the
> > > inner packet" with IPsec context attached and once as the encrypted
> > > (ESP) packet.
> > >
> > > With xfrm_interface, the inner packet did not traverse NF_INET_LOCAL_OUT
> > > hook anymore, making it impossible to match on both inner header values
> > > and associated IPsec data from that hook.
> > >
> >
> > Why wouldn't locally generated traffic not traverse the
> > NF_INET_LOCAL_OUT hook via e.g. __ip_local_out() when xmitted on an xfrmi?
> > I would expect it to appear in netfilter, but without the IPsec
> > context, as it's not
> > there yet.
>
> Yes, that's right. Having an iptables rule with LOG target in OUTPUT
> chain, a packet sent from the local host is logged multiple times:
>
> | IN= OUT=xfrm SRC=192.168.111.1 DST=192.168.111.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21840 DF
> | PROTO=ICMP TYPE=8 CODE=0 ID=56857 SEQ=1
> | IN= OUT=eth0 SRC=192.168.111.1 DST=192.168.111.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21840 DF PROTO=ICMP TYPE=8 CODE=0 ID=56857 SEQ=1
> | IN= OUT=eth0 SRC=192.168.1.1 DST=192.168.1.2 LEN=140 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0x1000
>
> First when being sent to xfrm interface, then two times between xfrm and
> eth0, the second time as ESP packet. This is with my patch applied.
> Without it, the second log entry is missing. I'm arguing the above is
> consistent to IPsec without xfrm interface:
>
> | IN= OUT=eth1 SRC=192.168.112.1 DST=192.168.112.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=49341 DF PROTO=ICMP TYPE=8 CODE=0 ID=44114 SEQ=1
> | IN= OUT=eth1 SRC=192.168.2.1 DST=192.168.2.2 LEN=140 TOS=0x00 PREC=0x00 TTL=64 ID=37109 DF PROTO=ESP SPI=0x1000
>
> The packet appears twice being sent to eth1, the second time as ESP
> packet. I understand xfrm interface as a collector of to-be-xfrmed
> packets, dropping those which do not match a policy.
>
> > > Fix this by looping packets transmitted from xfrm_interface through
> > > NF_INET_LOCAL_OUT before passing them on to dst_output(), which makes
> > > behaviour consistent again from netfilter's point of view.
> >
> > When an XFRM interface is used when forwarding, why would it be correct
> > for NF_INET_LOCAL_OUT to observe the inner packet?
>
> A valid question, indeed. One could interpret packets being forwarded by
> those tunneling devices emit the packets one feeds them from the local
> host. I just checked and ip_vti behaves identical to xfrm_interface
> prior to my patch, so maybe my patch is crap and the inability to match
> on ipsec context data when using any of those devices is just by design.
>

I would find such interpretation and behavior to be surprising for an IPsec
forwarder...
I guess some functionality of policy matching is lost with these
devices; although they do offer the ability to match ipsec traffic based on
the destination interface it is possible to have multiple ipsec flows share
the same device so netfilter doesn't provide the ability to distinguish
between different flows on the outbound direction in such cases.

Thanks,
Eyal.