netdev - Re: [RFC PATCH] xfrm: Add option to reset oif in xfrm lookup

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: <3e4bb514a6fc5316c093f5f39cc07762@codeaurora.org>
Date:	Wed, 03 Aug 2016 17:02:57 -0600
From:	subashab@...eaurora.org
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au, netdev-owner@...r.kernel.org
Subject: Re: [RFC PATCH] xfrm: Add option to reset oif in xfrm lookup

> I can't explain the iptables output but from a FIB lookup perspective
> it is using table 8 per the FIB rules, the xfrm is hit and packets
> shift to 192.168.77.1 and go out what you have as eth0.
> 
> Take a look at:
>   perf record -e fib:* -a -g
>   perf script
> 
> And then run tcpdump on both eth0 and eth1. For me on "eth0" (which is
> really eth11 for my VM setup) I see this on the ping:
> 

You can try running these commands as is on UML.
We tried these out on 3.18 as well as on 4.4.

> 20:50:11.389837 ARP, Request who-has 192.168.77.2 tell 192.168.77.1, 
> length 28
> 20:50:11.390079 ARP, Reply 192.168.77.2 is-at 02:00:12:34:02:0a, length 
> 28
> 20:50:11.390101 IP 192.168.77.1 > 192.168.77.2: ICMP 192.168.77.1 udp
> port 4500 unreachable, length 168
> 
> So the packets are going out "eth0" as expected.
> 
> That said, the commands you have given do not totally transfer to
> another setup. In my case I have 2 VMs with eth11 and eth12 directly
> connected (VM1 eth11 <--> VM2 eth11 and ditto for eth12). You have
> given one side of the commands and I have configured the other side
> with the .1 addresses but not bothered to translate the xfrm commands.
> 
> That said, this seems like a contrived example -- you pin ping to
> device eth1 (-I eth1), you are pinging a host on the network for eth1
> but want packets to go out eth0 via the xfrm. Can you elaborate on the
> real use case and problem here?

Applications may be bound to a specific interface but would try to send 
data over multiple types of networks.
Our use case here is wifi calling. In this case, we try to force packets 
to go over wifi after encryption.
The rules which we were using worked on 3.18 but we ran into issues on 
4.4.
Debugging narrowed us down to this oif preservation through xfrm.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project