netdev - Re: [PATCH net-next 0/3] net/sched: iptunnel encap/decap/classify using TC

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: <CALx6S37=Y0-cNhKLhWfkZ2hCa0EMyo-phed5S3RmsPYGaVz+yg@mail.gmail.com>
Date:   Mon, 22 Aug 2016 15:23:45 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     Amir Vadai <amir@...ai.me>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        John Fastabend <john.r.fastabend@...el.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Hadar Har-Zion <hadarh@...lanox.com>
Subject: Re: [PATCH net-next 0/3] net/sched: iptunnel encap/decap/classify
 using TC

On Mon, Aug 22, 2016 at 7:38 AM, Amir Vadai <amir@...ai.me> wrote:
> Hi,
>
> This patchset introduces iptunnel support using the TC subsystem.
>
> In the decap flow, it enables the user to redirect packets from a shared tunnel
> device and classify by outer and inner headers. The outer headers are extracted
> from the metadata and used by the flower filter. A new action act_iptunnel,
> releases the metadata.
>
> In the encap flow, act_iptunnel creates a metadata object to be used by the
> shared tunnel device. The actual redirection to the tunnel device is done using
> act_mirred.
>
> For example:
> $ tc qdisc add dev vnet0 ingress
> $ tc filter add dev vnet0 protocol ip parent ffff: \
>     flower \
>           ip_proto 1 \
>         action iptunnel encap \
>           src_ip 11.11.0.1 \
>                 dst_ip 11.11.0.2 \
>                 id 11 \
>         action mirred egress redirect dev vxlan0
>
Is the device required to be a tunnel device? Consider that with LWT
we can perform this sort of encapsulation without requiring a special
device...

Tom

> $ tc qdisc add dev vxlan0 ingress
> $ tc filter add dev vxlan0 protocol ip parent ffff: \
>     flower \
>           enc_src_ip 11.11.0.2 \
>                 enc_dst_ip 11.11.0.1 \
>                 enc_key_id 11 \
>         action iptunnel decap \
>           action mirred egress redirect dev vnet0
>
> note: Current implementation supports ipv4 only, but it should be easy to add
>       ipv6 later on.
>
> Amir
>
> Changes from RFC:
> - Add a new action instead of making mirred too complex
> - No need to specify UDP port in action - it is already in the tunnel device
>         configuration
> - Added a decap operation to drop tunnel metadata
>
> Amir Vadai (3):
>   net/ip_tunnels: Introduce tunnel_id_to_key32() and
>     key32_to_tunnel_id()
>   net/sched: cls_flower: Classify packet in ip tunnels
>   net/sched: Introduce act_iptunnel
>
>  drivers/net/vxlan.c                     |   4 +-
>  include/net/ip_tunnels.h                |  19 +++
>  include/net/tc_act/tc_iptunnel.h        |  24 +++
>  include/net/vxlan.h                     |  18 --
>  include/uapi/linux/pkt_cls.h            |  11 ++
>  include/uapi/linux/tc_act/tc_iptunnel.h |  40 +++++
>  net/ipv4/ip_gre.c                       |  23 +--
>  net/sched/Kconfig                       |  11 ++
>  net/sched/Makefile                      |   1 +
>  net/sched/act_iptunnel.c                | 292 ++++++++++++++++++++++++++++++++
>  net/sched/cls_flower.c                  |  59 ++++++-
>  11 files changed, 459 insertions(+), 43 deletions(-)
>  create mode 100644 include/net/tc_act/tc_iptunnel.h
>  create mode 100644 include/uapi/linux/tc_act/tc_iptunnel.h
>  create mode 100644 net/sched/act_iptunnel.c
>
> --
> 2.9.0
>