[Swan-dev] when to abort retransmits ?

[Andrew Cagney]

On 18 May 2018 at 10:07, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> 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.

Looking at the code I was half right..

The code doesn't know how to deal with re-transmitted fragments so
triggers a call to process_recent_rtransmit() for all fragments (It
should only trigger on the last fragment?).  However, the code sending
out the re-transmits does seem to do the right thing - send all
fragments (alas logging to confirm this is lacking).

Depressingly, I suspect the best way to test this is with the packet
filter / firewall.

Andrew


>
>> [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