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

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Mar 2009 16:17:16 -0700

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

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

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.

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.

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

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?

Jari

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 23 Mar 2009 14:55:59 -0400

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

Ok. This seems reasonable.

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

Good catch. It would be best to split the states to avoid this case.

> supposed to be set until you are in OPEN... or you could do some more 

yes additional text is needed to restrict the firing of these event 
variables. I'll add them accordingly.

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

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

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