netdev - [PATCH ipsec/vti 0/2] Fragmentation of IPv4 in VTI

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-next>] [day] [month] [year] [list]

Message-Id: <1552865877-13401-1-git-send-email-bram-yvahk@mail.wizbit.be>
Date:   Sun, 17 Mar 2019 23:37:55 +0000
From:   Bram Yvahk <bram-yvahk@...l.wizbit.be>
To:     steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
        davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: [PATCH ipsec/vti 0/2] Fragmentation of IPv4 in VTI

We've experienced an issue with VTI when the path-mtu is smaller than the size
of the "client" packet.

What happens: IPv4 packet from the client (i.e. another system in the LAN)
attempts to transmit some data; IPv4 header shows that 'DF' bit is not set but
still the client receives ICMPv4 "need-to-frag" message [which the client does
not expect and ignores].

Example: $ ping -s 1300 -M dont -c5 192.168.235.2
    PING 192.168.235.3 (192.168.235.3) 1300(1328) bytes of data.
    From 192.168.236.254 icmp_seq=1 Frag needed and DF set (mtu = 1214)
    From 192.168.236.254 icmp_seq=2 Frag needed and DF set (mtu = 1214)
    From 192.168.236.254 icmp_seq=3 Frag needed and DF set (mtu = 1214)
    From 192.168.236.254 icmp_seq=4 Frag needed and DF set (mtu = 1214)
    From 192.168.236.254 icmp_seq=5 Frag needed and DF set (mtu = 1214)

    --- 192.168.235.3 ping statistics ---
    5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 3999ms

This is addressed in the first patch of this series. (I don't fully like some
parts of this patch but I'll submit my remarks as a reply to the patch)

When testing the changes with an IPv6 tunnel (and with vti6) another issue/edge
case popped up. Assume: client sends a IP packet with a size of 1500 bytes.
After encrypting this packet [and wrapping it in ESP] it obviously is too large
to transmit as a single IPv6 packet and therefor two fragmented IPv6 packets
are transmitted. However: when the packet size is larger then the (not yet
known) path-mtu then a 'ICMPV6_PKT_TOOBIG' is received.
The problem: the ip6_vti error handler ('vti6_err') does not expect that the
original packet was a fragmented IPv6 packet --> it does not process the
'PKT_TOOBIG' and continues in sending packets that are too big.

This is addressed in the second patch.

Bram Yvahk (2):
  vti: fragment IPv4 packets when DF bit is not set
  vti6: process icmp msg when IPv6 is fragmented

 net/ipv4/ip_vti.c  | 43 +++++++++++++++++++---------
 net/ipv6/ip6_vti.c | 83 +++++++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 92 insertions(+), 34 deletions(-)

-- 
2.7.0