Re: [Pana] draft-ietf-pana-statemachine issue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Jun 05, 2009 at 08:17:16AM +0300, Jari Arkko wrote:
> Yoshihiro,
> 
> 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).
> >   
> 
> 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.

Thanks,
Yoshihiro Ohba




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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.