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

From: Stephen Hanna <[email-masked]>
Date: Fri, 9 Jan 2009 19:12:18 -0500

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

---

From: kaushik <[email-masked]>
Date: Thu, 22 Jan 2009 14:16:51 -0800

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.

---

From: kaushik <[email-masked]>
Date: Thu, 22 Jan 2009 14:19:01 -0800

inadvertently. I will send a complete message in a few minutes.

On 1/22/09 2:16 PM, "kaushik" <[email-masked]> wrote:

> Hi Steve,
> increase the overall complexity of the state machine as you have pointed out.
> Here is an alternate that might be a simpler option
> 
> 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
> either case the PBS will ignore the CRETRY message since it would be either in
> Server Working or Client Working states.

---

From: kaushik <[email-masked]>
Date: Thu, 22 Jan 2009 14:33:45 -0800

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.

                     Receive
                     CRETRY or
                     SRETRY      SRETRY
                      +--+   +----------------+
                      |  |   |                |
                      v  |   v                |
        |              |  | CRETRY                         |

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

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 23 Jan 2009 07:58:26 -0500

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