[Swan-dev] ikev2parent_inI1outR1 parsing questions

Paul Wouters paul at nohats.ca
Wed Jan 20 17:20:39 UTC 2016

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.

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

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


More information about the Swan-dev mailing list