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

[Stephen Hanna <shanna at juniper.net>]

Since this is a substantial change from the previous
proposal, let's extend the discussion and consensus
check for another two weeks (until February 6).

Folks, please review and comment on this proposal.
As Kaushik points out, this does reduce the flexibility
of the NEA system somewhat (requiring assessments
to proceed to completion before they can be restarted).
However, the benefits in simplicity are substantial.
Greater simplicity generally leads to better security,
reliability, and ease of implementation and adoption
so it's definitely a good thing! So please comment on
this proposal and whether you are comfortable with it.

Thanks,

Steve

> -----Original Message-----
> From: kaushik [mailto:kaushik at cisco.com] 
> Sent: Thursday, January 22, 2009 5:34 PM
> To: Stephen Hanna; nea at ietf.org
> Subject: Re: [Nea] Proposed PB-TNC state machine changes
> 
> 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
> received 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 
> where there could
> be potential synchronization issues.
> 
> 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.
> 2. 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.
> 3. The PBS can decide to send a SDATA immediately which would 
> move the state
> machine on the PBS to  the Client Working state.
> 4. The PBC will receive the SRETRY message which it will 
> ignore since it is
> in the Server Working state.
> 5. 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.
> 6. 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.
> 
> This proposal seems to address most use cases that may result in an
> out-of-synch state machine between the PBC and PBS. We 
> probably need closer
> scrutiny to ensure that this addresses all scenarios in question.
> 
> Regards,
>  kaushik
> 
> 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