[Swan-dev] ikev2parent_inI1outR1 parsing questions

[Andrew Cagney]

On 20 January 2016 at 12:20, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 20 Jan 2016, Andrew Cagney wrote:
>
>> I'm looking to move the code dealing with INVALID_KE and
>> NO_PROPOSAL_CHOSEN to before the point where the "state" object is
>> allocated.  in both cases, since the proposal is dropped on the floor,
>> there's no reason to even start allocating state.
>
>
> That does assume there is no connection switching that could make
> things better.

Um, what is "connection switching"?

>> - how critical is the order when it comes to parsing/rejecting
>> packets?  Specifically the vendor ID, my glance at the code suggests
>> it doesn't need state so it too can be moved to before state is
>> created?
>
>
> 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).

If knowing the vendor-id bits proves useful then, I guess it could go
into some local variable short-term, and then the state when it is
constructed.

>> - I suspect I can do a quick cheap KE pre-check (is it in any
>> proposal, is the payload valid) before starting on the proposal, is it
>> worth it though?  It does mean that INVALID_KE can come from two
>> places
>
>
> Why two places? Is there a case where you wouldn't know beforehand
> the KE was wrong, but would find out later?

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

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?

Andrew