netdev - Re: [ipsec/xfrm] IPv6 fragmentation/path-mtu

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

Date:   Wed, 20 Mar 2019 22:06:23 +0100
From:   Bram Yvahk <bram-yvahk@...l.wizbit.be>
To:     netdev@...r.kernel.org
CC:     steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
        davem@...emloft.net
Subject: Re: [ipsec/xfrm] IPv6 fragmentation/path-mtu

>
> What I would've expected to happen is that 'Gateway A' would send out
> two fragmented IPv6 packets containing the encrypted data. 'Gateway A'
> is the originator of the IPv6 ESP packet so it can fragment these.
> This similar to how it's done for IPv4. When the ESP is fragmented
> then the IPv6 packet from 'client A' is left intact/not fragmented.
>
> With my - limited - understanding of the IPv6 RFC I think this would
> be allowed.

Parts from the IPv6 RFC that I think are relevant:

5. Packet Size Issues

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.  On any link that cannot convey a 1280-octet
   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPv6.

+

   link      - a communication facility or medium over which nodes can
               communicate at the link layer, i.e., the layer
               immediately below IPv6.  Examples are Ethernets (simple
               or bridged); PPP links; X.25, Frame Relay, or ATM
               networks; and internet (or higher) layer "tunnels",
               such as tunnels over IPv4 or IPv6 itself.

*My* interpretation from this: an IPv6 IPsec tunnel is considered a "link"
in the IPv6 RFC.

This means that the mtu inside an IPsec tunnel - which tunnels IPv6
traffic - must be at least 1280 octets.

What this technically means for IPsec: when the path-mtu between the
two IPsec Gateways is 1280 then the IPsec tunnel should still provide
a 1280 octets mtu inside the IPsec tunnel.

The way it can do this is by transmitting fragmented IPv6 ESP packets.
[Data inside the tunnel is *not* fragmented]

Before continuing: is my understanding correct? and/or does everyone
agree with the above?

Is it reasonable to expect tunneling to work when path-mtu between
the IPsec gateways is 1280?

(In case it is reasonable then one can discuss what the mtu inside
 the tunnel should be when path-mtu is 1280 (or better put when
 path-mtu - ESP overhead < 1280) - but let's leave that discussion
 for later)