[Swan-dev] ikev2parent_inI1outR1 parsing questions
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
> - 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
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
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