[Swan-dev] ikev2parent_inI1outR1 parsing questions

[Andrew Cagney]

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.  For instance, from:

- other checks
- create state
- vendor ID processing
- half check KE
- compute KE
and then
- check proposal
- discover KE was wrong all along

to something like:

- other checks
- vendor ID processing???
- [pre-check KE] (INVALID_KE#1)
- check proposal (NO_PROPOSAL_CHOSEN)
- check proposal KE matches payload (INVALID_KE#2)
- create state
- start computing KE
and so on

But it raises some questions:

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

- 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

Andrew