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] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 13 Dec 2020 11:32:43 -0800
From:   Pravin Shelar <pravin.ovn@...il.com>
To:     Jonas Bonn <jonas@...rbonn.se>
Cc:     Pravin B Shelar <pbshelar@...com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Pablo Neira Ayuso <pablo@...filter.org>, laforge@...monks.org
Subject: Re: [PATCH net-next v2] GTP: add support for flow based tunneling API

On Sat, Dec 12, 2020 at 11:56 PM Jonas Bonn <jonas@...rbonn.se> wrote:
>
> Hi Pravin,
>
> I've been thinking a bit about this and find it more and more
> interesting.  Could you post a bit of information about the ip-route
> changes you'll make in order to support GTP LWT encapsulation?  Could
> you provide an example command line?
>
This is done as part of the magma core project
(https://www.magmacore.org/) that needs OVS GTP support.
I have started with OVS integration first, there are unit tests that
validate the GTP support. This is datapath related test, that has the
setup commands:
https://github.com/pshelar/ovs/blob/6ec6a2a86adc56c7c9dcab7b3a7b70bb6dad35c9/tests/system-layer3-tunnels.at#L158
Once OVS patches are upstream I can post patches for ip-route command.

> I understand the advantages here of coupling to BPF and OVS.  How does
> storing the encapsulation parameters via ip-route compare to storing
> them as PDP contexts from the point of view of resource consumption?
> Are there are other advantages/disadvantages?
>
This would allow user to program openflow with OVS or LWT tunnel APIs
to process GTP tunnel packets. As you can see LWT API provides more
fine-grained control over tunnel packet processing. It also integrates
well with the rest of the networking stack. This would bring the same
LWT APIs for GTP tunneling as we have for Geneve, GRE or VxLAN, etc
tunneling in Linux. I do not see much difference in resource
consumption.

> On 12/12/2020 05:40, Pravin B Shelar wrote:
> > Following patch add support for flow based tunneling API
> > to send and recv GTP tunnel packet over tunnel metadata API.
> > This would allow this device integration with OVS or eBPF using
> > flow based tunneling APIs.
> >
> > Signed-off-by: Pravin B Shelar <pbshelar@...com>
> > ---
> > Fixed according to comments from Jonas Bonn
> > ---
> >   drivers/net/gtp.c                  | 514 ++++++++++++++++++++---------
> >   include/uapi/linux/gtp.h           |  12 +
> >   include/uapi/linux/if_link.h       |   1 +
> >   include/uapi/linux/if_tunnel.h     |   1 +
> >   tools/include/uapi/linux/if_link.h |   1 +
> >   5 files changed, 382 insertions(+), 147 deletions(-)
> >
> > diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
> > index 4c04e271f184..0e212a70fe4b 100644
> > --- a/drivers/net/gtp.c
> > +++ b/drivers/net/gtp.c
> > @@ -21,6 +21,7 @@
> >   #include <linux/file.h>
> >   #include <linux/gtp.h>
> >
> > +#include <net/dst_metadata.h>
> >   #include <net/net_namespace.h>
> >   #include <net/protocol.h>
> >   #include <net/ip.h>
> > @@ -73,6 +74,9 @@ struct gtp_dev {
> >       unsigned int            hash_size;
> >       struct hlist_head       *tid_hash;
> >       struct hlist_head       *addr_hash;
> > +     /* Used by flow based tunnel. */
> > +     bool                    collect_md;
> > +     struct socket           *collect_md_sock;
>
> I'm not convinced that you need to special-case LWT in this way.  It
> should be possible to just use the regular sk1u socket.  I know that the
> sk1u socket is created in userspace and might be set up to listen on the
> wrong address, but that's a user error if they try to use that device
> with LWT.  You could easily make the sk1u socket an optional parameter
> and create it (as you do in your patch) if it's not provided.  Then
> ip_tunnel_collect_metadata() would tell you whether to get the
> encapsulaton details from the tunnel itself or whether to look up a PDP
> context.  That should suffice, right?
>
Sounds good. I have added it as part of v3.
Just to be clear, I still need collect_md_sock to keep reference to
the socket that is created as part of the newlink in kernel space.

Thanks,
Pravin.

Powered by blists - more mailing lists