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

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba [at] tari.toshiba.com] 
> Sent: Tuesday, December 02, 2003 8:50 AM
> To: Nick Petroni
> Cc: Joseph Salowey; eap [at] frascone.com
> Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine
> 
> 
> 
> 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.
> 
[Joe] I find it more confusing than enlightening.  I think the two
variables introduce a lot of complexity.  If you want to describe the
internal workings of the EAP-Method you should have a different state
machine for that.  



> 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."
> 
[Joe] I would rather see the EAP state machine simple and have text
describe how a method may implement its internal state machine.  I also
think m.intCheck should be integrated into m.process() as well.  

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

[Joe] I think I agree, I haven't had a chance to take a close look at
the authenticator side of the state machine, but I think you are
correct. 

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