[Swan-dev] when to abort retransmits ?

Andrew Cagney andrew.cagney at gmail.com
Fri May 18 14:07:14 UTC 2018


On 17 May 2018 at 23:00, Paul Wouters <paul at nohats.ca> wrote:
>
> 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:

Grep for, and look carefully at, the incoming packet size.  My (I
should probably read the source code) guess is that iOS re-sent the
the entire packet as 12 fragments but our end, not knowing how to deal
with fragmented re-transmits, is responding immediately with the first
packet each time.

> [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
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev


More information about the Swan-dev mailing list