Bug#1053550: IKEv2 regression when IP address changes behind NAT-T

2024-03-11 Thread Daniel Kahn Gillmor
Control: forwarded 1053550 https://github.com/libreswan/libreswan/issues/1645

On Fri 2023-10-06 15:31:40 +0800, Herbert Xu wrote:
> When the IP address of a host behind NAT changes, libreswan fails
> to respond correctly when IKEv2 is used.  This is a regression from
> IKEv1 as libreswan will correctly shut down the existing connection
> and initiate a new one when DPD kicks in.

Thanks for this report, Herbert.  I don't know how to resolve this at
the debian packaging layer, but i've forwarded it upstream.

--dkg


signature.asc
Description: PGP signature


Bug#1053550: IKEv2 regression when IP address changes behind NAT-T

2023-10-06 Thread Herbert Xu
Package: libreswan
Version: 4.10-2+deb12u1

When the IP address of a host behind NAT changes, libreswan fails
to respond correctly when IKEv2 is used.  This is a regression from
IKEv1 as libreswan will correctly shut down the existing connection
and initiate a new one when DPD kicks in.

Let the host behind NAT be A, and the server be B.  When A's IP
address changes, its data connection to B will be broken.  However,
B continues to respond to A's liveliness messages thus preventing
A from tearing the broken connection down.  This will only resolve
itself when A's SA eventually times out and is rekeyed.

Here is a packet dump on B's side showing this:

A's old address: XXX.XXX.107.30.15410
A's new address: XXX.XXX.212.186.25610
B: XXX.XXX.189.96.4502

07:17:42.939963 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 140

Packet is sent from A's new address.  It is correctly processed
by the kernel (Linux ignores the source address on inbound packets).

07:17:42.940182 IP XXX.XXX.189.96.4502 > XXX.XXX.107.30.15410: UDP-encap: 
ESP(spi=0xd4b2be8b,seq=0x1), length 140

Packet is sent back to A's old address, because libreswan has
not updated the outbound SA to use the new address.  This is
suboptimal but not a regression as libreswan never had code to
deal with this case.  With IKEv1, DPD would eventually kick in
and reestablish the connection.  However, with IKEv2 we instead
see this:

07:18:02.690370 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 1
07:18:22.687887 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 1
07:18:26.793134 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 61
07:18:26.793398 IP XXX.XXX.189.96.4502 > XXX.XXX.212.186.25610: UDP, length 61
07:18:26.793439 IP XXX.XXX.189.96.4502 > XXX.XXX.212.186.25610: UDP, length 61

As you can see from this, libreswan on B responds to A's new IP
address, making A think that the connection is still alive.  This
does not happen with IKEv1.  B should either not respond to the
packet from the new address, or it should tear down the old SAs
and create new ones with the new address.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt