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

[Antony Antony]

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. 

> - 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)
> 
> - 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.

-antony