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

D. Hugh Redelmeier hugh at mimosa.com
Sat Nov 8 18:10:03 EET 2014


| 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).

| 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" 

There should be a new timeout set here, I would think.


More information about the Swan mailing list