Re: [Nea] Proposed PB-TNC state machine changes

[kaushik <kaushik at cisco.com>]

The proposed solution addresses the synchronization issues with the PB-TNC
state machine but introduces additional states and state transitions which
increase the overall complexity of the state machine as you have pointed
out. Here is an alternate that might be a simpler option

The fundamental problem is that re-assessment can be initiated by either by
the Posture Broker Client or the Posture Broker Server and the state machine
on the PBS and PBC can get out of synch if the re-assessment messages are
generated at the same time and cross each other in transit. We can make a
simplifying assumption that we won't allow re-assessment to be triggered
during an assessment, i.e. Assessments will run to completion without being
interrupted. This would mean that CRETRY and SRERTY messages can only be
sent from the Decided state and that CRETRY & SRETRY messages sent during an
assessment, i.e. when the state is either Client Working or Server Working,
will be ignored.

The updated State Machine would look like this


                     Receive
                     CRETRY or
                     SRETRY*     SRETRY*
                      +--+   +----------------+
                      |  |   |                |
                      v  |   v                |
                     +---------+  CRETRY  +---------+
           CDATA     | Server  |<---------| Decided | CLOSE
        +----------->| Working |--------->|         |-------+
        |            +---------+  RESULT  +---------+       |
        |                ^ |  |                             v
        |                | |  +---------------------->=======
      ========           | |              CLOSE       " End "
      " Init "      CDATA| |SDATA                     =======
      ========           | |                          ^    ^
        |  |             | v                          |    |
        |  | SDATA   +---------+          CLOSE       |    |
        |  +-------->| Client  |----------------------+    |
        |            | Working |                           |
        |            +---------+                           |
        |              |  ^ Receive                        |
        |              |  | CRETRY*                        |
        |              +--+                                |
        |                       CLOSE                      |
        +--------------------------------------------------+


The changes from the state machine in the -02 version of the draft include

- CRETRY/SRETRY can only be sent from Decided state.
- CRERTY and SRETRY sent from the Decided state move the state machine to
Server Working state.
- CRETRY or SRETRY messages received in Server Working state are ignored
- CRETRY message received in Client Working state is ignored.

Let's apply this state machine to a re-assessment scenario.

1. The state machine is in the Decided state and the Posture Broker Server
decides to initiate a re-assessment and sends a SRERTY and the state machine
on the PBS moves to the Server Working state.

3. The Posture Broker Client may at the exact same time decide to initiate a
re-assessment and send a CRETRY and that would move the state machine on the
PBC to the Server Working state.
4. The PBS can receive the CRETRY from the PBC before or after it sends the
SDATA based on the time taken on the PBS in generating the SDATA message. In
either case the PBS will ignore the CRETRY message since it would be either
in Server Working or Client Working states.
5. The reception of the SDATA message on the PBC would move the PBC state
machine to Client Working and this would result in synchronization of the
state machines between the PBC and PBS.




On 1/9/09 4:12 PM, "Stephen Hanna" <shanna at juniper.net> wrote:

> At IETF 73, I proposed that we change the PB-TNC
> state machine to eliminate a problem. I would like
> to verify that we have WG consensus for the solution
> that I proposed. I think we had consensus in the
> room but consensus on the mailing list is what
> matters. Therefore, I have described the problem
> and my proposed solution in this email. Please
> review and comment on this. Whatever your opinion,
> please respond to this email with an expression
> of your opinion within two weeks (by 5 PM PST
> on Friday, January 23). At that time, I will
> declare consensus if we have it.
> 
> The problem is more easily explained with the aid
> of some diagrams. I suggest that you review the
> slides on this topic that I used at IETF 73. They
> are slides 30-44 in the slide deck available at
> http://www.ietf.org/proceedings/08nov/slides/nea-0/nea-0.htm
> The title of the first relevant slide is "PB-TNC
> State Machine".
> 
> In essence, the problem is that with the state machine
> in draft-ietf-nea-pb-tnc-02.txt, it is possible for the
> PBC and PBS to get stuck in different states, losing
> synchronization. Say that the PBC sends CRETRY. Who
> should send the next message? There's no guidance.
> The PBS and PBC might both send the next message and
> then they will each believe that the message they
> receive from the other is a response to the message
> they sent. It's a bad and messy situation. The easy
> solutions don't work either, as described in the slides.
> 
> At the meeting, I proposed a solution to the problem.
> That was to alter the state machine to this one:
> 
>                                       CLOSE
>                       +--------------------------------------+
>                       |                                      |
>                 +---------+  CRETRY  +---------+ CLOSE       |
>      CDATA      | Server  |<---------| Decided |-----------+ |
>   +------------>| Working |--------->|         |--------+  | |
>   |             +---------+  RESULT  +---------+ SASYNC |  | |
>   |               ^ | | |               |CASYNC         |  v v
>   |               | | | +---------------|-----------+   |  =======
> ========          | | +--------------+  |  SASYNC   v   v  " End "
> " Init "  CDATA or| |         CASYNC |  |     +---------+  =======
> ========  CRETRY  | |SDATA or        v  v     |  Server |   ^ ^
>   |  |            | v SRETRY   +---------+    | Request |   | |
>   |  | SDATA    +---------+    | Client  |    +---------+   | |
>   |  +--------->| Client  |<---| Request |       | ^        | |
>   |             | Working | SOK+---------+       | |        | |
>   |             +---------+      ^      ^        | |        | |
>   |               | | |   CASYNC |      | CASYNC | |        | |
>   |               | | +----------+      +--------+ |        | |
>   |               | |                              |        | |
>   |               | +------------------------------+        | |
>   |               |               SASYNC                    | |
>   |               +-----------------------------------------+ |
>   |                 CLOSE                                     |
>   |  CLOSE                                                    |
>   +-----------------------------------------------------------+
> 
> This revised state machine adds several states to make sure
> that the client and server always agree on whose turn it is
> to send data after a CASYNC or SASYNC is sent.
> 
> The main concern raised at IETF 73 was that this complicates
> the state machine, adding two new states and one new PB-TNC
> message type. That's true. However, I have wracked my brain
> for a simpler solution that works and I haven't found one.
> If someone else has a simpler solution, please speak up!
> If not, I think we'll need to proceed with this one. It's
> not bad. It's fairly simple, really. It just adds a bit
> more complexity and that's never a good thing.
> 
> Thanks,
> 
> Steve
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www.ietf.org/mailman/listinfo/nea

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www.ietf.org/mailman/listinfo/nea