On 20 January 2016 at 12:20, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
