[Nea] Proposed PB-TNC state machine changes

[Stephen Hanna <shanna at juniper.net>]

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