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

[Antony Antony]

On Wed, Feb 18, 2015 at 01:33:23PM -0500, Andrew Cagney wrote:
> 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.

not sure. are you proposing to drop message in process_v2_packet? 
I don't see an issue in calling process_encrypted_informational_ikev2 and dropping the message.

alternatively we could change processing function saying drop the packet.
IMHO, having smc entry is cleaner than using conditional drop in process_v2_packet.