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

[kaushik <kaushik at cisco.com>]

On 1/22/09 2:16 PM, "kaushik" <kaushik at cisco.com> wrote:

> Hi Steve,
> 
> 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