[Swan-dev] state m/c 2of3: State machine cleanups

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

(I didn't write the centralized V2 code driven by the microcode but it
was kind of copied from what I did in V1.)

| - I earlier posted questions related to ikev2_process_payloads() - it
| is, to me, doing more than it should.
| By moving its search logic into the main search-for-state-transition
| loop things get more transparent, and SMF2_CONTINUE_MATCH (which
| scares me) can also be deleted.
| In addition to checking the clear payload, SMF2_UNPACK_SK indicates
| that the SK (encrypted) payload can be checked - less stuff for my
| rekey states to deal with

The following is based on my imperfect memory.  With no checking.
Beware.

I hacked in the SMF2_CONTINUE_MATCH code.  Why?

- decryption was not done by the central routine: the per-transition
  routines do it.

- in some cases, decryption exposes information that affects microcode
  selection.  So a second go at matching was required 
  (SMF2_CONTINUE_MATCH).

Some thoughts:

- I think that it would be better to have the centralized routine do
  the decryption before calling the appropriate per-transition
  routine.

- I think that there are some cases where a bit of transition-specific
  code is needed before the keying material for decryption is
  available.  (So it was easier to hack in what I did rather than
  making larger changes.)

- ikev2_process_payloads gets called twice on an encrypted message:
  the first gobbles just the single E payload; the second gobbles the many
  payloads within the decrypted E payload.

- I think that it would be clearer if the E payload were special-cased
  and that ikev2_process_payload were only called once
  and that the payload checking only be done once
  and only then would the per-transition function be called.
  But the proof would be if the code were  simplified by this.

My feeling is that a significant amount of code that is replicated in
several per-transition functions could be moved into a central routine
and gated by microcode.  That was the motivation for the microcode
construct in V1.

An example of centralizing code is moving the timeout-setting logic out of 
the per-transition functions.  I think that Antony has done (most of?
all of?) this.