Subject: Re: [Pana] AD review of draft-ietf-pana-statemachine

From: Victor Fajardo <[email-masked]>
Date: Thu, 02 Apr 2009 11:59:16 -0400

Hi Jari,

I've uploaded a new rev of the pana statemachine draft that addresses 
your comments.

regards,
victor

> 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
>> [email-masked]
>> 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 
> ______________________________________________________________________
>
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Apr 2009 16:11:00 +0300

I'm happy with the new version. I'm moving the draft forward. Thanks for 
the quick update!

Jari

Victor Fajardo wrote:
>>> 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 
>>> 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.
>>
>> 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:
>>
>> 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.
>>
>>>
>> 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".
>>
>>>
>>> machine is created. What if it disagrees with the contents of the 
>>> PAN that you receive from the network?
>>
>> 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
>>>