[Swan-dev] ikev2parent_inI1outR1 parsing questions

[Paul Wouters]

On Wed, 20 Jan 2016, Andrew Cagney wrote:

>>> Um, what is "connection switching"?
>>
>> We answer IKE_INIT, they come back with IKE_AUTH. We then check if there
>> is a better matching connection to switch to.
>
> In IKEv2, the only way the initiator is going to encrypt and the
> responder decrypt that IKE_AUTH packet is by using the KE and proposal
> agreed to during IKE_INIT.

All of that information is stored on the state, not the connection. So
it can still switch connection and update st->st_connection

>> This is why later in the IKE negotiation we can find out the KE payload
>> we had is actually not valid (because we had to switch connection)
>
> I suspect there's something else I'm missing.

conn one
     also=base
     authby=secret
     ike=aes-sha1;modp2048

conn two
     also=base
     authby=rsasig
     ike=aes-sha1;modp1536

When we receive IKE_INIT, both connections can match. Say it picks "one"
and the KE payload is modp2048. Then it replies and received IKE_AUTH.
Now the AUTH payload has RSASIG as method. It means we need to switch to
conn "two". But now suddenly our replied modp2048 group is invalid and
we need to return NO_PROPOSAL_CHOSEN.

> Ah, you'd like to play nice :-)

It's hard enough to get an idea of what's going wrong to begin with :)

> I believe:
>
> - sends back INVALID_KE(default)
>
> causing remote end to come back with a KE we might consider, and then either:
>
> - sends-back (I hope) INVALID_KE(correct ke); causing the remote end
> to come back with KE we'll hopefully agree to
> - or, no proposal chosen

It is tricky to return the right KE based on only information in
IKE_INIT. Administrators are encourages to use the same modp groups
where possible :P

You cannot really send INVALID_KE back in IKE_AUTH.

Paul