[Swan-dev] encrypted informational message when in state R1?

[Andrew Cagney]

On 18 February 2015 at 13:16, Antony Antony <antony at phenome.org> wrote:
> Here is my recollection of an experience and the patch.
>
> On Mon, Feb 16, 2015 at 03:32:51PM -0500, Andrew Cagney wrote:
>> Hi,
>>
>> I'm trying to understand this:
>>
>>     /* Informational Exchange */
>>     { .story      = "R1: process INFORMATIONAL",
>>       .state      = STATE_PARENT_R1,
>>       .next_state = STATE_PARENT_R1,
>>       .flags      = SMF2_STATENEEDED,
>>       .req_clear_payloads = P(SK),
>>       .opt_enc_payloads = P(N) | P(D) | P(CP),
>>       .processor  = process_encrypted_informational_ikev2,
>>       .recv_type  = ISAKMP_v2_INFORMATIONAL,
>>       .timeout_event = EVENT_RETAIN, },
>>
>> from ikev2.c.
>>
>> Several things make me think this transition won't happen or the
>> message will be ignored:
>
> yes the message will be dropped by libreswan.
> In past there were reports, log files, of cisco sending such message and libreswan crash inside NSS. The current behavior is drop the message silently. A better one would finish the DH computation and decode the informational message. For that libreswan need another _continue _tail function to complete DH.

> Later I also herd CISCO was possibly misconfigured.

Given ...

>> - to me, rfc7296 makes it really clear that during the INIT and AUTH
>> exchanges the only valid messages are of type INIT and AUTH and not
>> INFORMATIONAL - a packet of this type just isn't allowed at this point
>> (there's an edge case at the end of AUTH, but by then the responder
>> had better be in state R2
>> http://tools.ietf.org/html/rfc7296#section-2.21.2)

I'm thinking that dropping the packet like a hot potato is the best solution.

>> - when the responder is in state R1, while it has all the DH material,
>> it hasn't done the DH calculation (pluto delays that until the R1->R2
>> transition), consequently, if such a packet were to be received it
>> would be rejected anyway with STF_FAIL because
>> !st->hidden_variables.st_skeyid_calculated (see ikev2_decrypt_msg).
>
> I belive this was added after we discovered cisco could send such message. I think that check is reasonable.

(I've nothing against the sanity check)

It sounds like the above transition can be removed.

Andrew