[Swan-dev] IKEv2 nhelpers == 0 failures

D. Hugh Redelmeier hugh at mimosa.com
Fri May 30 10:34:34 EEST 2014


I think that I know what is going on.

Totally incompetent event setting in IKEv2 state handling.

- the default event is EVENT_SO_DISCARD, in 0 seconds, to clean up any 
  state transition that didn't properly set an event (this is OK)

- The initiator state transitions set EVENT_v2_RETRANSMIT
  to handle retransmission, if needed.  This is OK.

- the responder state transitions don't bother to set an event and thus 
  will be blown away by the default EVENT_SO_DISCARD,  THIS IS A BAD BUG.

- the crypto helper code saves the day for responder states that use a 
  real helper: they set EVENT_CRYPTO_FAILED for some time in the future in 
  case they don't manage to do the crypto fast enough.  This is OK.  BUT 
  they never cancel/replace this timer.  This would be OK if the state 
  transition replaced it.

  a) As described above, the initiator state transitions will replace
  the event (with EVENT_v2_RETRANSMIT)

  b) Responder state transitions with nhelpers!=0: We don't bother to
  set the event.  So the EVENT_CRYPTO_FAILED event keeps on ticking,
  usually long enough for the other side to reply and everything
  appears to work.  But if the other side is slow, we will act as if a
  crypto helper failed.

  c) Responder state transitions with nhelpers==0:  We didn't use a
  crypto helper and the EVENT_CRYPTO_FAILED won't be set and the
  left-over EVENT_SO_DISCARD will immediately fire, deleting the
  state.

The fix should be that responder state transitions set an event at the 
limit of their patience for the next Initiator message.  What event?  
Probably a new one so that an appropriate message is logged "v2 responder 
got tired of waiting for the next message and will declare failure".

Wow.  How did any of this happen to work?  What luck. (bad? good?)

Of course I could be wrong.  Nothing is proven yet.


More information about the Swan-dev mailing list