eap Mailing List: RE: [Issue 203] Comments on EAP-Peer state machine

[Nick Petroni (npetroni]

Thanks for the comments Joe.  I have some comments as well.

> [Joe] Int check should be internal to the method.  It should be possible
intCheck IS set by an internal method, m.integrityCheck().

> for the method to signal that a packet should be ignored.  I think
> breaking it out like this is misleading.
[npetroni] I would say it IS possible for the method to signal that a
packet should be ignored just by setting intCheck. Perhaps it's the name
you just don't like? I don't see how this is any different from how it
works now.

> > [npetroni] This is meant to show that a method really has its
> > own state machine and that these states are separate from the
> > final decision. I think it provides nice way of separating
> > the two, but I am willing to discuss this alternative notation.
> >
> [Joe] I agree that a method has its own state machine, however I think
> exposing it here creates some problems.  First it complicates the EAP
[npetroni] This is not exposing the ACTUAL method state machine (IMHO),
just a minimal set of signals that need to be exported. There could be
more.

> state machine and second the internal state machine of the method will
> vary from method to method.  I think it would be best to make the method
> opaque as possible and use the minimal interface between method and EAP
> state machines.
[npetroni] Perhaps the notation is confusing to some, I don't think it is
overly complex. Author's bias perhaps? I am open to changing it, but I
guess I still don't understand the argument completely. I would love to
get additional input- any consensus from the group would be great.


> > > 4. Idle timer
> > >
> > > It seems that there is a problem with the idle timer.  It would be
> > > possible for the peer to never time out if it keeps on receiving
> > > packets that it discards.  This is not so good.
> > [npetroni] hmm, that seems like a trivial DoS, no? Send
> > enough bad packets to the Peer and it goes away for a while?
[npetroni] I guess I am responding to my own comment here, but I went back
and read your original thoughts on this and I think I see your point now.
I misread where you thought the timer should be set. I think there could
be a good argument for moving the idleWhile setting to INITIALIZE and
SEND_RESPONE. I don't think it should be in METHOD just for abstraction.
Besides, you would have to do it conditionally in METHOD anyway. Are
there other opinions on this? The problem comes down to bad packets
resetting the client timeout such that the peer can still go
ClientTimeout without receiving a good packet and yet not timeout. I
guess the question is does the timeout go between GOOD packets or just
packets? I see no reason why this is explicitly a peer problem. Wouldn't
the authenticator work the same?

Thanks for the feedback- anything that helps make the document more
understandable (and more correct :) ) is a good thing.

Regards,
nick