[Swan-dev] when to abort retransmits ?

Paul Wouters paul at nohats.ca
Fri May 18 03:00:33 UTC 2018


I'm looking at a case where IKE_AUTH is fragmented, with iOS as
initiator and libreswan as responder. Something is wrong and
both ends seem to be just retransmiting the same packet:

[root at euk-88957 ~]# grep "sending 340 bytes for
ikev2-responder-retransmit through" /var/log/pluto.log 
May 17 20:34:26.548937: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:26.970419: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:26.972670: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:26.974875: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:29.546602: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:29.970454: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:29.972705: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:29.975048: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:32.555937: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:32.978128: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 17 20:34:32.980411: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:54690 (using #7)
May 18 01:49:49.959394: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:49.961646: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:49.967761: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:52.555534: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:52.978057: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:52.980392: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:52.982603: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:55.563520: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:55.981792: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)
May 18 01:49:55.984003: | sending 340 bytes for ikev2-responder-retransmit through eth0:4500 to 5.31.204.40:10100 (using #33)

12 retransmits in 6 seconds. This seems a bit much to me.

But according to RFC 7296, we MUST answer. So arguably this is the
iphone's fault. But should we limit the number to something more sane
in this case?

I don't know yet what's going on. It seems the iphone didn't like our
IKE_AUTH, but retransmiting it won't change the outcome. One possibility
is that things are getting mangled (by accident or on purpose?) and
it just hasn't yet gathered all our fragments successfully ? The only
other case would be that it did receive all fragments, and either
the resulting cleartext is mangled or or it didn't like some validly
formatted content. But in that case, I don't think it should blindly
retransmit the IKE_AUTH in the hope that things will get better?


Paul


More information about the Swan-dev mailing list