Hi Jari,
Apologies for taking some time to do this. I have reviewed the draft
and I think it is in very good shape. There are one or two technical
problems that require the draft to be revised, unless I missed
something. Please discuss this with me and, if needed, revise the
draft accordingly.
Here are my comments:
7.2. Constants
FAILED_SESS_TIMEOUT
Configurable value ...
Small editorial problem: Something is inconsistent here.... maybe
call the section "7.2. Configurable Values"?
Ok. This seems reasonable.
State: WAIT_PNA
Three technical problems:
1. You enter this state in two ways, either because you sent a PING,
or because you wanted to re-authenticate. However, coming back from
the state you go to re-authentication or ping processing depending
on the flag in the answer message. So, if the peer responds with the
wrong flag value, you might accidentally go into, say, OPEN state
even if you really were going to do re-authentication...
The fix is is to either note the limitation or split WAIT_PNA into
two different states.
Good catch. It would be best to split the states to avoid this case.
2. What happens if you want to initiate re-auth while waiting for
ping response? Perhaps you could state that the relevant variables
are not supposed to be set until you are in OPEN... or you could do
some more radical change.
yes additional text is needed to restrict the firing of these event
variables. I'll add them accordingly.
3. More seriously, I think you need to support the case that you are
doing ping on one side while the other guy initiates
re-authentication. WAIT_PNA does not support reception of the
relevant messages. This needs to be fixed somehow.
Generalizing the last point a little bit, what do you do when
there's termination / ping / re-authentication / initialization in
parallel with something else that the other peer is doing? At the
very least, you need to explicitly decide to discard undesired
events in states (and show that its still according to the RFC). Or,
some other type of a change is needed in the draft.
I agree. race conditions of such kind are not really handled in the
fsm (and should be handled). The options of a) discarding un-expected
events or b) making assumptions of which events takes precedence in a
given state .. are not explicitly/implicitly stated in the rfc.
Option a) is not so good from basic the operations and vulnerability
point-of-view. Option b) needs some event precedence assumptions
which can be:
* Waiting for re-auth reply (pac only)
- on ping, reply to ping and continue waiting
- on terminate, give up on re-auth and continue with terminate
* Waiting for re-auth reply (paa only)
- on ping, ignore ping and continue waiting
- on terminate, give up on re-auth and continue with terminate
* Waiting for ping reply (pac and paa)
- on re-auth, give up on ping and continue with re-auth
- on terminate, give up on ping and continue with terminate
* Waiting for terminate (pac and paa)
- ingore everything and continue waiting
re-auth for paa and pac is separated so as to conform to the rfc;
ping sent only in the access phase. if these assumptions are
reasonable (??) then I can introduce event handlers for them.
------------------------------
State: INITIAL (Initial State)
------------------------------
Initialization Action:
OPTIMIZED_INIT=Set|Unset;
NONCE_SENT=Unset;
RTX_COUNTER=0;
RtxTimerStop();
...
- - - - - - - - - - - - - - (PAN Handling) - - - - - - - - - -
Rx:PAN[S] && if (PAN.exist_avp WAIT_EAP_MSG
((OPTIMIZED_INIT == ("EAP-Payload"))
Unset) || TxEAP();
PAN.exist_avp else {
("EAP-Payload")) EAP_Restart();
SessionTimerReStart
(FAILED_SESS_TIMEOUT);
}
Rx:PAN[S] && None(); WAIT_PAN_OR_PAR
(OPTIMIZED_INIT ==
Set) &&
! PAN.exist_avp
("EAP-Payload")
Observation: the two actions do not cover all possible combinations,
e.g., not Rx:PAN[S] && OPTIMIZED_INIT == Unset &&
!PAN.exist_avp("EAP-Payload").
The 1st and 2nd event condition (PAN handling shown above) is suppose
to handle all relevant combinations. In the example you mentioned,
the 1st event condition will be triggered (by OPTIMIZED_INIT ==
Unset) and the action takes care of checking "EAP-Payload".
You are setting OPTIMIZED_INIT to a value at the time that the state
machine is created. What if it disagrees with the contents of the
PAN that you receive from the network?
The current PAA event conditions was intended to handle both cases
where the PAN agrees (w/ EAP-Payload) or disagress (w/o EAP-Payload)
with OPTIMIZED_INIT. This is why the 1st event condition for PAN
handling is an OR (||); to handle most of the combinations. The 2nd
condition for PAN handling covers the case where there is
disagreement and optimized inits will not take place. In all cases,
it proceeds accordingly.
regards,
victor
Jari
_______________________________________________
Pana mailing list
Pana at ietf.org
https://www.ietf.org/mailman/listinfo/pana
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
