[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