Message-ID: <fd41d544-31f0-8e60-a301-eb4f4e323a5b@6wind.com>
Date:   Thu, 26 Aug 2021 17:33:51 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Justin Iurman <justin.iurman@...ege.be>, netdev@...r.kernel.org
Cc:     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

Le 26/08/2021 à 16:01, Justin Iurman a écrit :
> Nowadays, there are more and more private domains where a lot of ingresses and
> egresses must be linked altogether. Configuring each possible tunnel explicitly
> could quickly become a nightmare in such use case. Therefore, introducing
> support for ip6ip6 decapsulation without an explicit tunnel configuration looks
> like the best solution (e.g., for IOAM). For now, this patch only adds support
> for ip6ip6 decap, but ip6ip4 could probably be added too if needed.
> 
> Last year, we had an interesting discussion [1] with Tom about this topic, and
> especially on how such solution could be implemented in a more generic way. Here
> is the summary of the thread.
> 
> Tom said:
> "This is just IP in IP encapsulation that happens to be terminated at
> an egress node of the IOAM domain. The fact that it's IOAM isn't
> germaine, this IP in IP is done in a variety of ways. We should be
> using the normal protocol handler for NEXTHDR_IPV6  instead of special
> case code."
> 
> He also said:
> "The current implementation might not be what you're looking for since
> ip6ip6 wants a tunnel configured. What we really want is more like
> anonymous decapsulation, that is just decap the ip6ip6 packet and
> resubmit the packet into the stack (this is what you patch is doing).
> The idea has been kicked around before, especially in the use case
> where we're tunneling across a domain and there could be hundreds of
> such tunnels to some device. I think it's generally okay to do this,
> although someone might raise security concerns since it sort of
> obfuscates the "real packet". Probably makes sense to have a sysctl to
> enable this and probably could default to on. Of course, if we do this
> the next question is should we also implement anonymous decapsulation
> for 44,64,46 tunnels."
> 
> 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.
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?


Regards,
Nicolas

> 
> Some feedback would be really appreciated, specifically on these points:
>  - Should the anonymous decapsulation happen before (as it is right now) or
>    after tunnel6 handlers? "Before" looks like the most logical solution as,
>    even if you configure a tunnel and enable anonymous decap, the latter will
>    take precedence.
>  - Any comments on the choice of the sysctl name ("tunnel66_decap_enabled")?
>  - Any comments on the patch in general?
> 
> [1] https://lore.kernel.org/netdev/CALx6S374PQ7GGA_ey6wCwc55hUzOx+2kWT=96TzyF0=g=8T=WA@mail.gmail.com

Powered by blists - more mailing lists