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

[Yoshihiro Ohba (yohba]

On Tue, Dec 02, 2003 at 05:32:29AM -0500, Nick Petroni wrote:
> 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.

I agree with Joe that from implementation point of view, it is better
to reduce the number of variables needed for the interface between
method and EAP state machines.

On the other hand, the other role of the EAP state machines document
is to help implementers understand how RFC2284bis works.  I think
describing the peer state machine by using the two variables (i.e.,
methodState and decision) helps us understand Implementation Note in
Section 4.2 of RFC2284bis pretty well.

So, I would suggest keeping the currnet state machine as it is (i.e.,
use methodState and decision variables), but adding the following
statement in "Implementation Consideration" section:

  "In the peer state machine, implementations may integrate
  methodState and decision variables into a single variable that 
  may be obtained as a return value of m.process() method procedure."

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

I agree that in both peer and authenticator state machines it is not
good to reset the timer value when the received message is discarded.

On the other hand, the peer idle timer should be set only once in
INITIALIZE state and should not be reset anywhere else.  This is
because (correct me if I am wrong) the idle timer for authenticator
and the idle timer for peer are used for different purposes.  The
former timer is message retranmission timer and the latter timer is
authentication session timeout timer.

Yoshihiro Ohba

> 
> Thanks for the feedback- anything that helps make the document more
> understandable (and more correct :) ) is a good thing.
> 
> Regards,
> nick
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap