[Swan-dev] when to abort retransmits ?

[Andrew Cagney]

On 21 May 2018 at 23:11, Paul Wouters <paul at nohats.ca> wrote:
> On Fri, 18 May 2018, Andrew Cagney 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.
>
>
> All of it, both sides, resend the exact same sized packets. What has
> happened is that both sides are in some state. The initiator did not
> like our IKE_AUTH reply, so it retransmits. We don't even look at the
> content. Since the msgid is the same, we determine this is a retransmit
> and not a "new" or "different" IKE_AUTH (which the RFC doesn't allow
> you to do anyways). And so we just retransmit our reply. Both ends have
> no way of behaving differently until the iphone gives up entirely.

The same packet len, or the same packet?  It doesn't take much for
fragments to all be the same size.

Per earlier post, pluto, looking at send_recorded_v2_ike_msg() should
send all the fragments (unfortunately there's no debug log to confirm
this, just lots of same-sized sends).

However, where pluto is screwing up is by not also checking the
fragment number.  It should only re-transmit on reception of the first
(or last?) fragment.  Sending all fragments back for every fragment
received is excessive.

You're suspecting that the iPhone can't decrypt the fragmented reply,
or never gets one of the fragments?  If the iPhone did receive all the
fragments but didn't like the auth then it should come back with a new
informational(delete) exchange.

Andrew

, pluto sends all
> To me, it just seems a bit excessive
>
> Paul