Subject: [eap] Re: rfc2284bis issue

From: [email-masked] ([email-masked])
Date: Wed, 12 Mar 2003 16:35:02 +0200

Hello John, and thanks for a thoughtful message!=20

> Thanks for the response and the diagram.  I think we are
> actually quite close and perhaps we should try to come up with
> a common state machine.  There are differences to be talked
> through however.  If you are interested we might want to try
> to have a conversation this week before ietf, or certainly at
> ietf.

Unfortunately, I'm not able to make it to IETF meeting next
week, but let's continue this by e-mail.

I think having a good state machine aligned with 2284bis is
quite important, as aligning it might reveal some problems in
2284bis.  E.g. do the new changes on sequences and "strict
interpretation" really work? And what is really meant when the
spec says MAY or SHOULD?  (Hopefully the state machine will
unambiguously specify what must be done in what circumstances,
and the choice the implementor has to make is to simply
initialize some policy variables according to circumstances).

I ended up doing some reading on state machines (hmm, I didn't
realize that somebody had actually written about them so much),
so please bear with my rather lengthy comment about them :-)

> Our diagrams are in somewhat different styles.  Ours is in 802
> style, in which the actions are all in States, yours is more
> what i would expect, with actions associated with events on
> transitions between states.  While I like yours better, I
> think the group wants to use the 8u2 style.  It certainly
> helps with coordination with 802.1x an 802.11i state machines.

I used the UML notation since I'm more familiar with it, but
coordination with 802.* might be easier if we use the same
notation, so it's OK to me (they are "equivalent enough" for
our purposes, I guess). There are two differences, though.=20
The first is a minor semantic issue and probably won't
matter. The second is more of "style issue", but might be=20
more important?

The semantic issue is the following: In UML you can put
procedures inside states or in transitions (I used only the
latter), but they have different semantics. Procedures in
transitions are called "actions", and they are completed before
the transition has completely happened and next event is
processed. Procedures inside states are called "activities":
they start executing when the state is entered, but it is
possible that new events arrive while the activity is
running. If this results in leaving the state, the activity=20
is aborted.

Quite obviously, the state machine will be much simpler to
understand if we use only actions, and indeed, the procedures
in 802 notation are actions in this sense. (The only possible
candidate for an activity is the processing of EAP request for
method; it might require user interaction.)

The possibly more important issue is related to style.=20
Although the notations are both easy to understand, I had=20
some difficulties in comparing our state diagrams, and I kept
wondering why this was so. Then, it occurred to me (I'm not an
expert in this, so this might be obvious to you): In both
notations, the state of the system is stored by a combination of
the "box we're in" and specific named variables, and they can be
combined in different ways without changing the semantics of the
whole.

It seems that the UML notation prefers boxes to named variables,
and 802 notation does the opposite (though both notations allow
both styles). I feel that we should prefer the boxes, since
changes from one box to another are clearly shown (as arrows),
but the named variables are more like global variables in=20
programming languages: difficult to follow.

To take a concrete example, in my "quick hack" state machine
picture, the two states "MethodCanContinue" and
"MethodContinues" could be replaced by a single state "Method"
and a named variable "canSucceed". Then the transition from
Method->Success would have label "success && canSucceed" instead
of just "success". Using a similar procedure, we could actually
combine all the state boxes to one (except final states), with a
spaghetti of variables.

You can convert a 802 state diagram to UML notation by moving
the procedures to the transitions (and then removing empty
"transition states"). Consider what happens when you do this to
the peer state machine in vollbrech-eap-state-01. All the state
boxes except IDLE (and final states) disappear. (This is as
expected; when the system is not running some procedure or
moving along an arrow, it is always in IDLE state.)

I think the diagram should be refactored into several different
boxes (representing what the system expects or allows to happen
next), removing some of the named variables in the process. This
might lead to a clearer picture of the implications of "strict
interpretation" and other suggested changes (e.g. what specific
transitions are changed). Especially hiding important
information into a "filter" or "policy" variables doesn't=20
sound like a good idea to me...

This refactoring might be easier to do with the UML style,=20
since the style is more aligned with the "common ways
of thinking" about the issue (and it does not generate=20
extra "transition states", and the "real states" and=20
transitions between them are more clearly shown).=20
When it's finished, we can convert it back to 802
notation without loss of information.=20

What do you think? Is refactoring the diagram a good idea?

Then to other issues:

>> But does discarding those messages actually change the DoS
>> situation?  In PPP or plain 802.1X, it seems the answer is
>> "no" (a DoS is possible by sending non-EAP packets
>> anyway). I'm not sure about 802.11i; it might, with certain
>> EAP methods? (does anyone have more information about this?)
>
> I am not certain, but it seems the number of DOS attacks
> possible is large and this will not get rid of all of them.
> However one of the simplest is sending an EAP Failure.

Hopefully there will be some discussion at IETF about this
question (does silently discarding some messages give
*non-insignificant* protection against DoS? And even if
it's non-insignificant, is it worth the certainly=20
non-insignificant extra complexity?).

> 1. the diagram you present seems to deal only with strict
> interpretation. Is that your intent or am i missing something?
>
> 2. I am not clear how Requests and other messages that don't
> match policy.type are handled - are they silently discarded?
> I thought Requests would be NAK'd?

No, the diagram is intended to work with all EAP methods, not
just ones using "strict interpretation". It just takes the
approach "silently discard whenever possible; i.e. discarding
won't change the outcome". This applies to e.g. requests for
other types once the supported type has been started. (Though
since it was just a "quick hack", I haven't checked carefully
that messages which could lead to success are never discarded.)

The method-specific part of "strict interpretation" is embedded
the indications: continues/can_continue, and probably_succeeded/
succeeded.  For instance, the methods specified in RFC2284 don't
support the strict interpretation, so they never send the
"continues" indication. This means the state machine never ends
up in the MethodContinues state, where Success packets are
silently discarded.

Ok, I'm not sure if this is the best way to handle this, but at
least it makes the differences between methods visible in the
state machine. Each method has to choose only when to send which
indication. In a state machine supporting sequences, we might
need even more different indications, like most_definitely_continues,=20
can_continue_or_succeed, can_continue_or_fail, and
can_continue_or_succeed_or_fail. (All this is relevant,=20
of course, only if we see that silently discarding some=20
messages is worth the extra complexity).

> 3. Are you using link-enabled and link-disabled as two
> separate signals. I assume these are meant to be "alternate
> indications"?

Yes (and I should have called them that, instead of
link-enabled/disabled).

> 4. I think your "PROBABLE SUCCESS" and our "IDLE" states are
> pretty close, except that we allow another method to start if
> allowed by policy rather than only allowing success or
> failure.

Not really, since the "IDLE" state is the only "real" state box
there is (see the comment about refactoring them earlier).  But
some refactoring might bring them to alignment.

I hope you have some good discussions next week at IETF (I'm
sorry I won't be there)! But let's continue this via e-mail..

Best regards,=20
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 19 Mar 2003 12:11:15 -0500

Pasi -- I apologize for taking so long to reply.  I have been thinking 
about your note, and there is much for me to try to put together.  I would 
like to pursue this, and will have more time next week.

A couple notes inline, more next week.

-- John

--On Wednesday, March 12, 2003 4:35 PM +0200 [email-masked] wrote:

> Hello John, and thanks for a thoughtful message!
>
yes- for sure
> our purposes, I guess). There are two differences, though.
> matter. The second is more of "style issue", but might be
> more important?
>
> running. If this results in leaving the state, the activity
> is aborted.
>
thanks for the tutorial.  this is helpful for me - I didn't know this, so 
it is helpful

> method; it might require user interaction.)
ok -
> The possibly more important issue is related to style.
> Although the notations are both easy to understand, I had
this has occurred to me, but I haven't done the analysis you have.

> but the named variables are more like global variables in
this is true - there are global variables, and they imply interactions 
between states and state machines.  this seems to be true throughout 802.1 
state machines
> combine all the state boxes to one (except final states), with a
I am thinking this thru and am not yet convinced.  It seems that the 
setting of an internal variable can cause a transition to a state, but the 
state is something else because in the state I do activities (and actions 
in 802 sense).    I see where you are going - I can have a state that has 
lots of transitions with actions that goes back to itself.  I am not sure 
why this doesn't work, so it is too bad we don't have a whiteboard and a 
meeting to talk it through.

> information into a "filter" or "policy" variables doesn't
I would be interested in seeing what you have in mind.

> This refactoring might be easier to do with the UML style,
> of thinking" about the issue (and it does not generate
> extra "transition states", and the "real states" and
> transitions between them are more clearly shown).
> notation without loss of information.
>
It is an interesting idea.  I do think it is important to keep the diagram 
in a form usable by 802.1aa, as they are hoping to include it as an 
addendum to their document.
> it's non-insignificant, is it worth the certainly
We had some discussion yesterday.  I think the issue was that we should do 
what is logical in the flow.  I am still thinking this through and hope to 
address it tomorrow when I present the state machine doc.

> that messages which could lead to success are never discarded.)
this is the approach more or less approved yesterday

> need even more different indications, like most_definitely_continues,
> can_continue_or_succeed_or_fail. (All this is relevant,
> of course, only if we see that silently discarding some
you're right - they aren't that close when I think about it.  the 
refactoring is definitely interesting.
> sorry I won't be there)! But let's continue this via e-mail..

yes - I am very interested in seeeing how the refactoring would look.

- John