netdev - Re: [RFC net-next 0/2] net/sched: cls_flower, act

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]

Date:	Mon, 15 Aug 2016 11:17:40 +0300
From:	Amir Vadai <amir@...ai.me>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.fastabend@...il.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Jiri Pirko <jiri@...lanox.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Hadar Har-Zion <hadarh@...lanox.com>,
	Oded Shanoon <odeds@...lanox.com>,
	Amir Vadai <amirva@...lanox.com>
Subject: Re: [RFC net-next 0/2] net/sched: cls_flower, act_mirred: VXLAN
 redirect using TC

On Mon, Aug 15, 2016 at 09:11:22AM +0200, Jiri Pirko wrote:
> Sun, Aug 14, 2016 at 07:53:30PM CEST, xiyou.wangcong@...il.com wrote:
> >On Sun, Aug 14, 2016 at 7:06 AM, Amir Vadai <amir@...ai.me> wrote:
> >> tc qdisc add dev $ETH ingress
> >>
> >> # ENCAP rule for ARP
> >> tc filter add dev $ETH protocol 0x806 parent ffff: prio 11 \
> >>                 flower \
> >>                 action mirred egress redirect dev $VXLAN enc_src_ip 11.11.0.1 enc_dst_ip 11.11.0.2 enc_key_id 11 enc_dst_port 4789
> >>
> >> # ENCAP rule for ICMP
> >> tc filter add dev $ETH protocol ip parent ffff: prio 10 \
> >>                 flower ip_proto 1 \
> >>                 action mirred egress redirect dev $VXLAN enc_src_ip 11.11.0.1 enc_dst_ip 11.11.0.2 enc_key_id 11 enc_dst_port 4789
> >>
> >
> >I don't like this. This makes mirred action unnecessarily
> >complex, it should really just mirror or redirect packets as
> >it is, why it should be aware of tunnel information?
> >
> >I think you probably need to introduce a new tc action
> >for these tunnel information and pipe it to mirred.
> 
> that is the first thing that I thinked of when I saw the patch. I think
> you can introduce act_vxlan similar to act_vlan.

introducing a new action was the first thing I thought of, but it felt
problematic because the actual encap is done by the redirection to the
vxlan device. This action is only responsible to supply the metadata and
work tightly with the mirred. It is not exactly like vlan that the
push/pop actions can live without mirroring/redirecting.
But still as all of you said, it makes mirred complex with stuff that
shouldn't be there. And between the two options it is better to
introduce a new action.

I will go in this direction.

Thanks,
Amir