netdev - Re: [PATCH net-next 1/2] UDP tunnel encapsulation module for tunnelling different protocols like MPLS,IP,NSH etc.

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, 21 Oct 2019 19:18:44 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Martin Varghese <martinvarghesenokia@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jonathan Corbet <corbet@....net>, scott.drennan@...ia.com,
        martin.varghese@...ia.com
Subject: Re: [PATCH net-next 1/2] UDP tunnel encapsulation module for
 tunnelling different protocols like MPLS,IP,NSH etc.

On Fri, 18 Oct 2019 13:03:56 -0700, Tom Herbert wrote:
> More specifically fou allows encapsulation of anything that has an IP
> protocol number. That includes an L3 protocols that have been assigned
> a number (e.g. MPLS, GRE, IPv6, IPv4, EtherIP). So the only need for
> an alternate method to do L3 encapsulation would be for those
> protocols that don't have an IP protocol number assignment.
> Presumably, those just have an EtherType. In that case, it seems
> simple enough to just extend fou to processed an encapsulated
> EtherType. This should be little more than modifying the "struct fou"
> to hold 16 bit EtherType (union with protocol), adding
> FOU_ENCAP_ETHER, corresponding attribute, and then populate
> appropriate receive functions for the socket.

How do you suggest to plug that in? We need the received inner packets
to be "encapsulated" in an Ethernet header; the current approach of
"ip link add type ipip|sit encap fou" does not work here. Are you
suggesting to add another rtnl link type? How would it look like?
"ip link add type ethernet encap fou" does not sound appealing,
especially since "type ethernet" would have no meaning without the
"encap fou".

Thanks,

 Jiri