[Swan-dev] when to abort retransmits ?

[Andrew Cagney]

I'm not even sure pluto fragmented its auth reply (I've pushed some
log lines so we can tell).  This is on the re-transmit path:

    /* this should never happen */
    if (st->st_tpacket.len == 0) {
        pexpect(st->st_tpacket.len == 0); /* get noticed */
        libreswan_log("retransmission for message ID: %u exchange %s
failed lastreplied %u - we have no stored packet to retransmit",
            st->st_msgid_lastrecv,
            enum_name(&ikev2_exchange_names, ix),
            st->st_msgid_lastreplied);
        ...

and st->st_tpacket.len==0 when things get fragmented.

Andrew


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