Re: [Pana] draft-ietf-pana-statemachine issue

["Alper Yegin" <alper.yegin at yegin.org>]

Let me inject my thoughts in here....

> > I talked to Pasi about this, and he said:
> >
> > > Doesn't quite work -- EAP state machine processes one request
> > > at a time. Once you've given it a request to process by setting
> > > eapReq, you can't set eapReq again before the request has
> > > been processed and eapReq has been cleared (well, in theory you
> > > could set eapReq again, but it doesn't do what you'd expect).

I wonder what is the expected behavior from the lower layer for such a case?
Should the lower-layer queue the requests, or drop the requests while EAP
layer is busy?


> > Which is true as far as I can tell. I'm sure you could fix this, and
> > then we'd have to see what the next problem is, if any.
> 
> As a fix, we could add description that the PaC state machine
> internally maintains a queue for received EAP messages, eapReq is set
> when each queued message appears at the queue head, and all queued
> messages are discarded when the PaC state machine exits from
> WAIT_EAP_MSG state.  If more changes than this additional fix are
> needed, I will have to agree that the proposed alternative is complex
> and I will withdraw my suggestion and will be ok with -12 in that case.
> 
> >
> > But I have a higher level question. Do we really want to do this? We
> > knew from the start that making the PANA state machine deal with the
> > loss of EAP message in an integrated manner is going to take a
> > relatively large change to the state machine, and getting this right
> > could take time. The other alternative is simpler, and I'm not sure
> the
> > end result is really that different. (In any case, at the end of the
> > day, other people on the link can get your authentication process
> > stopped, if they want.)
> 
> The end result would be improved for a particular type of DoS attack
> of altering EAP request or response messages.  Although other types of
> DoS attacks would be still possible, this specific improvement would
> be good to have if the required change is small and no new problem is
> found.

I agree.
If all PANA does is to transport EAP payload, it does not have to take part
in a DoS attack that specifically plays with the EAP (which is just an
opaque payload to PANA).  

Alper





> 
> Thanks,
> Yoshihiro Ohba
> 
> 
> 
> 
> >
> > Jari
> >
> > _______________________________________________
> > Pana mailing list
> > Pana at ietf.org
> > https://www.ietf.org/mailman/listinfo/pana
> >
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www.ietf.org/mailman/listinfo/pana