The IP-in-IP encapsulation is 'in the clear' tunnel protocol between two hosts. When the module is loaded, the system will be in an 'any-to-any' routing state. It will accept any "IP in IP" packets and forward them through the system routing chains.
No authentication, encryption or restrictions is created between endpoints by the kernel module. Until a configuration rule is set, any system that can send "IP in IP" packets to an unconfigured system with the ipip kernel module loaded will be unwrapped and forwarded. There is an area of opportunity between module loading and configuration that may allow for an attacker to abuse this flaw.
When a tunnel device is created this will restrict the source and destination of the tunnelled packets. The content of the tunnelled data remains unencrypted and unauthenticated.
Red Hat Product Security strongly recommends using authenticated and encrypted tunnels such as IPSec, VPN or libreswan if tunnelling between networks is required.
Multiple products that implement the IP Encapsulation within IP standard (RFC 2003, STD 1) decapsulate and route IP-in-IP traffic without any validation, which could allow an unauthenticated remote attacker to route arbitrary traffic via an exposed network interface and lead to spoofing, access control bypass, and other unexpected network behaviors.
A flaw was found in the IP-in-IP protocol. An unauthenticated attacker can use the IP-in-IP protocol to route network traffic through a vulnerable device, which can lead to spoofing, access control bypasses, and other unexpected network behaviors.