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@NONE: <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 (local)