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

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 1 Dec 2003 21:52:39 -0800

Hi Nick,

Comments inline below:

> -----Original Message-----
> From: Nick Petroni [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2003 11:01 AM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine
<snip>
> 
> > 3. Interface to method
> >
> > The interface to the method seems too complicated.
> >
> > First I don't think that intCheck should be a different process. 
> > Integrity checking is done as part of the method processing.  Also 
> > methods aren't required to ingore packets, some methods with ignore 
> > some problems and return errors on others.  I think this behavior 
> > should be incorporated into m.process.
> [npetroni] intCheck is needed because SOMETIMES a method will 
> decide not to use the packet at all. in this case, intCheck 
> is the way the method tells the SM it will not be using that 
> packet. Methods with other ways of dealing with this will 
> just not set intCheck to be true.

[Joe] Int check should be internal to the method.  It should be possible
for the method to signal that a packet should be ignored.  I think
breaking it out like this is misleading.  

> 
> > On a separate but related note it seems that the method state and 
> > decision is very complex. I don't really see the need for the 
> > independent methodState and decision variables.  M.process() should 
> > return one of serverl possible results: IGNORE, CONTINUE, 
> > COND_SUCCESS, SUCCESS, FAILURE.  MethodState should be able 
> to take on 
> > CONTINUE, COND_SUCCESS, SUCCESS, FAILURE.  I don't think a separate 
> > decision variable is necessary.
> [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
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. 

> >
> > 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?
> 
> > 5.  rxSuccess and rxFailure
> >
> > Shouldn't rxSuccess and rxFailure check to see if (reqId == 
> > lastReqID)?
> [npetroni] probably so. I think this should be added.
> 
> 
> 

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 2 Dec 2003 05:32:29 -0500 (EST)

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

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

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

> opaque as possible and use the minimal interface between method and EAP
[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.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Dec 2003 08:49:34 -0800

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

> 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

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 2 Dec 2003 09:13:53 -0800

> Sent: Tuesday, December 02, 2003 2:32 AM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine
> 
> 
> [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.
> > >
> [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.
> 
[Joe] I guess what I am really compaining about is that there seems to
be an overabundance of signals, some of which seem to be internal to the
method.  I would like to see the minimal set of signals used between the
method and the EAP state machine.  Perhaps we already have the minimal
set of signals, but there seems to be a lot (1 boolean and two
tri-states).  I think this can be simplified to 4 different signals from
the method, IGNORE, COND_SUCCESS, SUCCESS, FAILURE.   However the
machine is sufficiently complex that I could be missing something.

---

From: Nick Petroni <[email-masked]>
Date: Tue, 2 Dec 2003 13:20:24 -0500 (EST)

> machine is sufficiently complex that I could be missing something.

No, you understand it perfectly. I guess the difference in opinion is
whether or not there is any value in showing  more detail. I think the
first question would be if there is such value (and I believe Yoshihiro's
point was that there may be). The second question is whether the current
representation provides both the appropriate level of extra information
and the accuracy of that information.

It could very well be that the best state machine has the least amount of
variables and just more text describing what might happen in a method.

nick

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 2 Dec 2003 10:54:21 -0800

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, December 02, 2003 8:50 AM
> To: Nick Petroni
> Cc: Joseph Salowey; [email-masked]
> 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.
> > 
> > > > 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 
> > [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:
> 
[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.
> 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. 

> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
>