Re: [Nea] Proposed PB-TNC state machine changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nea] Proposed PB-TNC state machine changes
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'; nea at ietf.org
> 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: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
> >
> >
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
