Do not use xform_ipip as decapsulation fallback.

[ae]

Summary

Currently we have two implementation of IP-in-IP encapsulation:
gif(4) and one in the netipsec/ - xform_ipip.

gif(4) is explicitly used by user. xform_ipip used by the
IPSEC code with tunnel mode. Now we redesigned the IPSEC code,
and IPIP encapsulation is called directly from ipsec_output,
IPIP decapsulation is done in the ipsec_input with m_striphdr.

Previously IPIP decapsulation was done from ip_input via ip_encap.
This method had several issues when packets were encapsulated several
times (e.g. one with IPSEC code, other with gif(4)).

Currently xform_ipip used as fallback with low priority for IPIP
encapsulated packets that were decrypted. And in some cases
xform_ipip can decapsulate packets, that it shouldn't decapsulate.
This leads to situations, when wrong configurations are magically working.
Also it can propagate wrong ingress interface and this can break security.

[gnn]

For this change I really want to know how it was tested. I don't think the idea itself is wrong but it's a possibly destabilizing change.

[jmg]

I don't know the IPsec code well enough, but as long as everything has been tested, it looks ok.

[ae]

In D1220#4, @gnn wrote:

For this change I really want to know how it was tested. I don't think the idea itself is wrong but it's a possibly destabilizing change.

I tested tunnel and transport mode with and without using gif(4). If you want to know how reproduce the problem you may use the following configuration:

1. This show how to exploit this problem with "wrong" config

I have two hosts 10.9.8.3 and 10.9.8.11.

[10.9.8.11]# cat /etc/ipsec.conf
#!/sbin/setkey -f

flush;
spdflush;

spdadd 10.9.8.3 10.9.8.11 any -P in ipsec esp/transportdefault;
spdadd 10.9.8.11 10.9.8.3 any -P out ipsec esp/transportdefault;

add 10.9.8.3 10.9.8.11 esp 15701 -m transport -E rijndael-cbc "1111111111111111" ;
add 10.9.8.11 10.9.8.3 esp 24501 -m transport -E rijndael-cbc "1111111111111111" ;

[10.9.8.11]# ifconfig gif1 create inet 192.168.0.11/24 192.168.0.3 tunnel 10.9.8.11 10.9.8.3
[10.9.8.11]# ping 192.168.0.3

---

[10.9.8.3]# cat /etc/ipsec.conf
#!/sbin/setkey -f

flush;
spdflush;

spdadd 10.9.8.3 10.9.8.11 any -P out ipsec esp/transportdefault;
spdadd 10.9.8.11 10.9.8.3 any -P in ipsec esp/transportdefault;

add 10.9.8.3 10.9.8.11 esp 15701 -m transport -E rijndael-cbc "1111111111111111" ;
add 10.9.8.11 10.9.8.3 esp 24501 -m transport -E rijndael-cbc "1111111111111111" ;

[10.9.8.3]# cat ip_input.d
#!/usr/sbin/dtrace -s

fbt::ip_input:entry
{

m = (struct mbuf *)arg0;
ifp = (struct ifnet *)m->M_dat.MH.MH_pkthdr.rcvif;
ip = (struct ip *)m->m_hdr.mh_data;
printf("%s:%16s->%16s %2d %08x",
    ifp->if_xname,
    inet_ntoa(&ip->ip_src.s_addr),
    inet_ntoa(&ip->ip_dst.s_addr),
    ip->ip_p, m->m_hdr.mh_flags);

}

[10.9.8.3]# ./ip_input.d
1 31720 ip_input:entry wlan0: 10.9.8.11-> 10.9.8.3 50 00000003

3  31720                   ip_input:entry wlan0:       10.9.8.11->        10.9.8.3  4 00010003
3  11277            ipe4_encapcheck:entry wlan0:       10.9.8.11->        10.9.8.3  4 00010003
3  11278           ipe4_encapcheck:return 1
3  11274                _ipip_input:entry wlan0:       10.9.8.11->        10.9.8.3  4 00010003
3  31720                   ip_input:entry wlan0:    192.168.0.11->     192.168.0.3  1 00010003

As you may see, xform_ipip has decapsulated this packet (we don't have gif(4) on host 10.9.8.3).

[ae]

We faced with problem when gif(4) didn't handle packets due ingress filtering (LINK2 flag), but xform_ipip did that. Firewall thought that packets were received on wrong interface. And this isn't easy to debug. After this patch packets that weren't decapsulated will be counted in the IP statistic as "packets for unknown/unsupported protocol".

[ae]

Committed in r275133.