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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
