[Swan-dev] ikev2parent_inI1outR1 parsing questions

[Andrew Cagney]

On 20 January 2016 at 22:59, Paul Wouters <paul at nohats.ca> wrote:
> 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.

That, fortunately, is beyond the scope of what I'm changing.

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

Yes.  For instance, given:

- initiator proposes KE=1500 MODP=1500 2000
- responder has MODP=4000,2000

then if tje responder sends back INVALID_KE(4000) (its default),
instead of INVALID_KE(2000) (from matching proposal), then the
initiator is going to drop that response on the floor and an interop
that should work won't.


> You cannot really send INVALID_KE back in IKE_AUTH.
>
> Paul