[Swan-dev] ikev2parent_inI1outR1 parsing questions

Paul Wouters paul at nohats.ca
Wed Jan 20 21:59:05 UTC 2016


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.

for example, say one is authby=secret and the other authby=rsasig, then
in IKEv2 we will only know the difference during IKE_AUTH. If we
happened to have taken the initial packet on the conn with
authby=secret, we need to switch.

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)

>> vendorid information might go onto the state, but that assumes there
>> is a state. For NO_PROPOSAL_CHOSEN or INVALID_KE we would not need it,
>> unless later in life we need to do some workaround based on VID.
>
> The current IKEv2 code seems to simply log the values received (but I
> could easily be wrong).

Yes. we are not acting on any kind of VID right now.

> Without the proposal:
>
> - the keying material is the wrong size for the group being proposed;
> this would be a new test lifted from accept_KE

If there is no proposal matching the KE offered I'm fine with only
rejecting it later on when we are going through the proposals. The
client is stupid and so they can wait :P

> - the group isn't in any of the local proposals at all; this is
> stronger than the current code which just checks that lookup_group()
> isn't NULL

But if they have another proposal value that is not the one they picked
for KE, then we can send back INVALID_KE with a value that matches a
mutually agreeable group. If there is no group that is shared between
initiator and responder, NO_PROPOSAL_CHOSEN should be returned instead
of INVALID_KE.

> and with the proposal:
>
> - the KE matches the group in the chosen proposal
>
> In the case where NO_PROPSOAL_CHOSEN and INVALID_KE are both true,
> does it matter which fail we send back?

If there is a potentially matching group, we should send back
INVALID_KE. If there is not, send back NO_PROPSOAL_CHOSEN.

Paul


More information about the Swan-dev mailing list