netdev - Re: [RFC net-next] ipv6: Support for anonymous tunnel decapsulation

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: <1977792481.53611744.1629994989620.JavaMail.zimbra@uliege.be>
Date:   Thu, 26 Aug 2021 18:23:09 +0200 (CEST)
From:   Justin Iurman <justin.iurman@...ege.be>
To:     nicolas dichtel <nicolas.dichtel@...nd.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        yoshfuji@...ux-ipv6.org, dsahern@...nel.org, tom@...bertland.com,
        edumazet@...gle.com
Subject: Re: [RFC net-next] ipv6: Support for anonymous tunnel decapsulation

Nicolas,

>> Based on the above, here is a generic solution to introduce anonymous tunnels
>> for IPv6. We know that the tunnel6 module is, when loaded, already responsible
>> for handling IPPROTO_IPV6 from an IPv6 context (= ip6ip6). Therefore, when
>> tunnel6 is loaded, it handles ip6ip6 with its tunnel6_rcv handler. Inside the
>> handler, we add a check for anonymous tunnel decapsulation and, if enabled,
>> perform the decap. When tunnel6 is unloaded, it gives the responsability back to
>> tunnel6_anonymous and its own handler. Note that the introduced sysctl to
>> enable anonymous decapsulation is equal to 0 (= disabled) by default. Indeed,
>> as opposed to what Tom suggested, I think it should be disabled by default in
>> order to make sure that users won't have it enabled without knowing it (for
>> security reasons, obviously).
>> 
>> Thoughts?
> I'm not sure to understand why the current code isn't enough. The fallback
> tunnels created by legacy IP tunnels drivers are able to receive and decapsulate
> any encapsulated packets.

Because, right now, you need to use the ip6_tunnel module and explicitly configure a tunnel, as you described below. The goal of this patch is to provide a way to apply an ip6ip6 decapsulation *without* having to configure a tunnel.

> I made a quick try with an ip6 tunnel and it works perfectly:
> 
> host1 -- router1 -- router2 -- host2
> 
> A ping is done from host1 to host2. router1 is configured with a standard ip6
> tunnel and screenshots are done on router2:
> 
> $ modprobe ip6_tunnel
> $ ip l s ip6tnl0 up
> $ tcpdump -ni ip6tnl0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ip6tnl0, link-type LINUX_SLL (Linux cooked), capture size 262144
> bytes
> 17:22:22.749246 IP6 fd00:100::1 > fd00:200::1: ICMP6, echo request, seq 0,
> length 64
> 
> And a tcpdump on the link interface:
> $ tcpdump -ni ntfp2
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ntfp2, link-type EN10MB (Ethernet), capture size 262144 bytes
> 17:23:41.587252 IP6 fd00:125::1 > fd00:125::2: IP6 fd00:100::1 > fd00:200::1:
> ICMP6, echo request, seq 0, length 64
> 17:23:41.589291 IP6 fd00:200::1 > fd00:100::1: ICMP6, echo reply, seq 0, length
> 64
> 
> $ ip -d a l dev ip6tnl0
> 6: ip6tnl0@...E: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group
> default qlen 1000
>    link/tunnel6 :: brd :: promiscuity 0 minmtu 68 maxmtu 65407
>    ip6tnl ip6ip6 remote any local any hoplimit inherit encaplimit 0 tclass 0x00
> flowlabel 0x00000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs
> 65535
>    inet6 fe80::b47d:abff:feac:ec09/64 scope link
>       valid_lft forever preferred_lft forever
> 
> Am I missing something?