Subject: [eap] Re: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Wed, 26 Mar 2003 15:44:18 +0200

Hi,

I took a look at the latest (V7) peer state diagram, and it
actually looks much better. The way the "strict interpretation"
is handled actually seems to work reasonably well. I'm still
wondering if we could "promote" some of methodState to a box of
its own (splitting the IDLE state), but I guess it's not
absolutely necessary.

Some comments about the current version:

- The methodState descriptions in -01 draft are not in sync
  with the diagram. For instance, SUCC is really "succeeds or
  continues or fails", because methods like GTC are always in
  SUCC state (because the client doesn't know if the conversation=20
  will continue or not).

- The FAIL and CONT methodStates are equivalent (same
  transitions occur for both), which probably means that either
  there's a problem in the diagram, or they need to be renamed
  (I can't find any serious problem there, so maybe it's the
  latter?).

- How and where are Identity requests handled? Is
  Policy.allow(Identity) always true? (If necessary, this could
  be put to a box of its own, like Notifications)

- How does the "handshake procedure" between EAP and lower
  layer actually work? More specifically, what happens if
  another request (or response on server side) arrives while
  processing the previous one? I guess it's either discarded, or
  put into a queue.
 =20
  A straight-forward event-loop implementation (e.g. with
  select() and recvmsg() system calls) would queue it. But then
  we can't model the requirement "If a peer receives a duplicate
  Request before it has sent a Response, but after it has
  determined the initial Request to be valid (i.e. it is waiting
  for user input), it MUST silently discard the duplicate
  Request." (2284bis-01, section 4.1)
 =20
Some suggestions what refactoring could be done to make
the diagram more understandable and precise:

- Another problem with the current handshake procedure is that
  it won't work if the lower layer is also specified using a
  similar state machine. This is because e.g. eapResp is set to
  FALSE immediately after it's set to TRUE. If the lower layer
  state machine is doing something else (than sitting in "idle"
  state), this trigger will be lost. So, perhaps these variables
  should be replaced with procedures (e.g. change "eapResp=3DTRUE"
  to "sendResponse()", and "eapIgnore=3DTRUE" to "ignore()").

- I think we should make some of the data changes more
  visible.  For example, currently lastId is never set
  anywhere. Also, the response packet data is somehow handled
  "behind the scenes". Proposal how this could be done:
=20
  - Create a SEND_RESPONSE box with contents "lastRespData=3DrespData;=20
   lastId=3DcurrentId; send(respData)".=20
  - Rename ACTIVE to RETRANSMIT, and change contents to=20
    "respData=3DlastRespData;"
  - Change UCT transitions from NAK/NOTIFY/ACTIVE(RETRANSMIT) to IDLE
    to go via this box.
  - in METHOD state, set respData=3DbuildMethodResp(). I think this=20
    is the logical place, instead of making the response in a separate=20
    step. (change intCheck transition directly to SEND_RESPONSE state).
    Also, add "if (intCheck) {" after the first line, and "}" to end.
  - Minor adjustments in other states: in NOTIFY do=20
    "eapRespData=3DbuildNotify()"; in NAK "respData=3DbuildNak(..)";
    and also remove "eapResp=3DTRUE" from NAK/NOTIFY/ACTIVE(RETRANSMIT).
  - in DIALOG state, explicitly state which variables are set. =20
    E.g. (rxMethodReq, rxSuccess, rxFailure, rxNotify, currentId,=20
    currentMethod)=3DparseReceivedMessage()"

- I think the discCount variable is unnecessary. It's not used
  anywhere, and there are many other statistics an implementation
  might want to collect, and events it might want to put in a log; we
  don't include those either.

- Timeout is handled differently than in 802.1X (which has explicit=20
  timer variables which are set and decremented; the "timeout=3DFALSE" =
in=20
  IDLE state =EDs quite different).

Here's a version that incorporates some/most of these refactoring ideas:
http://www.cs.hut.fi/~peronen/eap_state_machine_26032003.gif

(No behavior changes were intended, so this does not address the
issues at the beginning of the message)

Best regards,
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 26 Mar 2003 11:05:27 -0500

I haven't been able to go over this completely, but here are some quick=20
reactions.  we should talk during the conf call or later.  Thanks for the=20
thoughtful comments.

--On Wednesday, March 26, 2003 3:44 PM +0200 [email-masked] wrote:

>   SUCC state (because the client doesn't know if the conversation
>   will continue or not).
true
>   (I can't find any serious problem there, so maybe it's the
good point.  I think that what is now STRICT was
CONT.  We need to decide how to deal with this.  My suggestion is to rename =

STRICT to CONT.

>   be put to a box of its own, like Notifications)
Identity requests are treated as any other req.  Identity is not allowed=20
within STRICT methods.
>   processing the previous one? I guess it's either discarded, or
there is a 802.1x diagram that shows how 802.1x state machine deals with=20
this.  see http://www-personal.umich.edu/~jrv/eap.htm and look at 802.1x=20
update at IEEE in Dallas.

>   to "sendResponse()", and "eapIgnore=3DTRUE" to "ignore()").
I have to look at this - eapResp and eapIgnore are signals to the lower=20
layer.  we may be wrong to reset them.

>   "behind the scenes". Proposal how this could be done:
lastid should be fixed.    I am not sure I understand the rest of this.  I=20
think it would be useful to show where the response data is created and=20
have a variable that holds it.  We should talk this through.

>   - Create a SEND_RESPONSE box with contents "lastRespData=3DrespData;
>    lastId=3DcurrentId; send(respData)".
>   - Rename ACTIVE to RETRANSMIT, and change contents to
>   - in METHOD state, set respData=3DbuildMethodResp(). I think this
>     is the logical place, instead of making the response in a separate
>   - Minor adjustments in other states: in NOTIFY do
>   - in DIALOG state, explicitly state which variables are set.
>     E.g. (rxMethodReq, rxSuccess, rxFailure, rxNotify, currentId,
> - Timeout is handled differently than in 802.1X (which has explicit
>   timer variables which are set and decremented; the "timeout=3DFALSE" in
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap