[Swan-dev] get rid of "V2 microcode entry (I3: INFORMATIONAL) has unspecified timeout_event"

[Antony Antony]

On Sat, Nov 08, 2014 at 11:10:03AM -0500, D. Hugh Redelmeier wrote:
> | From: Antony Antony <antony at phenome.org>
> 
> [Sorry for the slow response.  I still haven't studied this well but
> I don't want to hold you up any longer.]
> 
> | It is probably time to remove IKEv2 debug log line in function 
> | success_v2_state_transition, case EVENT_NULL, Any objections?
> 
> No objection.
> 
> My idea was that setting of timeouts should be centralized since there
> is a more-or-less common logic.  That certainly was true in V1.
> 
> It was one of many things on my to-do list but I ignored it since you
> had taken that task over (but perhaps with a different goal).

same goal as you. There is once case in AUTH exchange where 
we set timeout event outside of success_v2_state_transition.  I am not sure how to move that.
The timeout event for child is set by success_v2_state_transition.

> 
> | And the proposed change and related ones are in a new branch 
> | ikev2-smc-timeout, waiting for review and testing.
> | 
> | Hugh, please take a look when time permits.
> 
> Sorry, I haven't done that yet.
> 
> What is the semantics of EVENT_NULL in this table?  I presume: don't
> change the event that is already scheduled.  In that case, we should
> check that there is actually an event scheduled.  If so, perhaps we
> should add and use "EVENT_RETAIN" to make that clear -- after all,
> EVENT_NULL already has a different meaning elsewhere (I guess).  If
> there is not other use, then it should just be renamed.
> 
> 0 (the value of EVENT_NULL) might be useful as a reserved value to
> catch accidents.  For example, uninitialized struct member.
> 
> | EVENT_NULL is ok for many smc entries, such as,
> | 	- when responding to an IKEv2 informational exchange, such as dpd/liveness , or delete 
> 
> When responding to an IKEv2 informational exchange, I would expect
> EVENT_RETAIN would make sense.
> 
> DPD/Liveness: would that not change the next DPD/Liveness event timing
> (at least in some cases)?
> 
> I don't know what "delete" is.  If it is "I just sent a delete
> notification", I think a new event would be appropriate (when to
> retransmit or to just go ahead and delete).  If it is "I just received
> a delete, but not for myself", I imagine that
> - dpd timeout (if any) should be reset
> - the old rekey-or-whatever event ought to be retained.
> 
> | 	- "Initiator: process anti-spoofing cookie" 
>

EVENT_RETAIN is a good idea. I have committed the change to #ikev2-smc-timeout

-antony