[Swan-dev] race causing lost packet when IKEv1 AH KLIPS(IKE initiator)->KLIPS(IKE responder)

Andrew Cagney andrew.cagney at gmail.com
Wed Jul 24 18:10:42 UTC 2019


For instance, in the below, once the SA is established a single packet is
sent from west->east, but it is lost vis:

004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established tunnel mode {AH=>0xAHAH <0xAHAH xfrm=HMAC_MD5_96 NATOA=none
NATD=none DPD=passive}
+
004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established tunnel mode {AH=>0xd405e4fd <0x7d11a0b5 xfrm=HMAC_MD5_96
NATOA=none NATD=none DPD=passive}
+
==== cut ====
ping -q -n -c 1 -i 6 -w 5 -I 192.0.1.254 192.0.2.254
==== tuc ====
[   38.119182] IN=eth1 OUT= MAC=12:00:00:64:64:45:12:00:00:64:64:23:08:00
SRC=192.0.2.254 DST=192.0.1.254 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=51594
PROTO=ICMP TYPE=0 CODE=0 ID=1481 SEQ=1
==== cut ====
PING 192.0.2.254 (192.0.2.254) from 192.0.1.254 : 56(84) bytes of data.

--- 192.0.2.254 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
==== tuc ====
down UNEXPECTED

however if I tweak the test to first sleep for a second vis:

...
004 "authenticate-ikev1-md5" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established tunnel mode {AH=>0xf3e4d1b2 <0xcd040343 xfrm=HMAC_MD5_96
NATOA=none NATD=none DPD=passive}
+
sleep 1
==== cut ====
ping -q -n -c 1 -i 6 -w 5 -I 192.0.1.254 192.0.2.254
==== tuc ====
==== cut ====
PING 192.0.2.254 (192.0.2.254) from 192.0.1.254 : 56(84) bytes of data.

--- 192.0.2.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.537/0.537/0.537/0.000 ms
==== tuc ====
up

that first packet gets through.

I find this worrying - from my POV this should be 100% deterministic - the
initiator wack only exits when it's both received the SA response
(confirming that the other end's kernel is ready) and it too has configured
its kernel.
If things are set up as KLIPS(IKE initiator)->NETKEY(IKE responder) then
the problem doesn't seem to occure - suggesting the the responder (east)
returned early - even more worrying.
(I've also looked at old variants of this test - where 4 packets were sent
- and they two can loose the packet)

anyone?

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20190724/bfb62cce/attachment.html>


More information about the Swan-dev mailing list