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

From: Stephen Hanna <[email-masked]>
Date: Mon, 9 Feb 2009 09:55:32 -0500

I haven't seen any comments on this topic other than
Kaushik's and mine. I won't say that's WG consensus
but there seems to be no objection to making this change.
Since the state machine in draft-ietf-nea-pb-tnc-02.txt
has a serious known bug, let's make this change.

I think this is the last open issue so I'd like to
ask our editors (including myself) to please prepare
a -03 revision. This should be ready for WG Last Call.

Thanks,

Steve

> -----Original Message-----
> From: Stephen Hanna 
> Sent: Friday, January 23, 2009 7:58 AM
> To: 'kaushik'; [email-masked]
> Subject: RE: [Nea] Proposed PB-TNC state machine changes
> 
> Thanks, Kaushik. I like this idea! I was always troubled
> by the increased complexity of the last proposal.
> 
> 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:[email-masked]] 
> > Sent: Thursday, January 22, 2009 5:34 PM
> > To: Stephen Hanna; [email-masked]
> > 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" <[email-masked]> 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/nea
> > 
> >