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

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Jun 2009 14:21:50 +0300

During IESG review we identified an issue that the state machine in its 
original form did not deal with the possibility that EAP state machine 
silently discards an EAP message.

This was fixed in -12 along with a small RFC Editors note (diffs at the 
end of this mail). However, Alper has raised an issue that he believes 
there is a better way to deal with this problem. The current draft 
basically bails out of the entire process if a silent discard happens. 
Draft -11 would have stayed in WAIT_EAP_MESSAGE and waited until 
timeout; if the real authenticator would send a message during this 
time, it would not be processed.

An alternative design would treat the silent discard of an EAP message 
as if the PANA message that carried was discarded. This probably means a 
slightly bigger change to the state machine.

I would like to hear from the WG on what to do here. My preference is to 
ship the document as-is; no matter what we do on this, DoS attacks 
disabling the authentication process will be possible.

Jari

Version -12 diffs:

http://tools.ietf.org/wg/pana/draft-ietf-pana-statemachine/draft-ietf-pana-statemachine-12-from-11.diff.html

and the additional RFC Editor note:

  Please add the following text the last paragraph of Section 7.3:

  NEW:
  Note that this specification does not support silently discarding EAP
  messages. They are treated as fatal errors instead. This may have an
  impact on denial-of-service resistance.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 4 Jun 2009 10:33:44 -0400

Jari,

I discussed with Alper and Victor offline about this, and here is my
suggestion:

Add the following state transition entry to WAIT_EAP_MSG state of
the -11 PaC state machine so that the PaC can accept a new PAR and
pass the contained EAP message (which may carry an EAP-Request
retransmitted by EAP authenticator layer) to EAP peer:

"
   Rx:PAR[]                 TxEAP();               WAIT_EAP_MSG
                            EAP_RespTimerStart();
                            if (eap_piggyback())
                              Tx:PAN[];
"

This way, the behavior under message alteration DoS attack will be
robuster than version -11 and -12, and PANA state machines still do
not need to deal with the silent discarding of an EAP message.

On the other hand, some text about eapNoReq and eapNoResp may still
be needed because EAP state machines expect these variables to set to
FALSE in lower layer.

Yoshihiro Ohba

On Wed, Jun 03, 2009 at 02:21:50PM +0300, Jari Arkko wrote:
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Jun 2009 08:17:16 +0300

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.

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

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 8 Jun 2009 09:59:25 -0400

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

> day, other people on the link can get your authentication process

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

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 8 Jun 2009 17:08:50 +0300

Let me inject my thoughts in here....

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

> be good to have if the required change is small and no new problem is

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Jun 2009 19:16:24 +0300

I will again make the observation that we have a working spec in -12.
That has been the case since April. There aren't any Discusses either.

I would really like to push the approve button, but you guys keep
telling me that you want to code the state machine in some other way.
Then I push for you to state what exactly your solution is and after
studying it in detail either me or Pasi sees a problem. Then we start
again from the start. We've already been through this a couple of times,
and every time there's an obviously correct change to the state machine.
And now Pasi tells me that he doesn't want to be involved in the
discussion anymore. Can't say I blame him, its not his job to design the
state machine, its his job to verify that its not broken. And currently,
its not. The latest proposal from Yoshihiro to add queue management to
the state machine does not sound like a trivial change. I could review
it, but I think there would still be a 50% chance that I would miss
something.

So I have a proposal. Unless I hear a strong objection from the entire
WG as opposed to one or two individuals, I will actually press the
approve button on Thursday. If there is a need to incorporate more
advanced functionality, I would suggest that you guys take the time to
work out a bis draft to update the current RFC, I would gladly AD
sponsor it. I do not think it is wise to stall for months on this issue,
and I don't want to do major changes without sending the document back
to the WG.

Jari

---

From: <[email-masked]>
Date: Wed, 10 Jun 2009 21:50:53 +0200

Hi Jari,

I agree that the IESG does not have the time to work on the design of the
state machine I-D.
If the authors are not happy about the current design of the state machine
as submitted to the IESG, we can recall the I-D and work on it until the
authors and the WG is satisfied with the outcome. And I am fine with your
suggestion that the authors can work on a bis version to add extra details
and features to the state machine.

However I do not think that I would want to do that. Hence please go ahead
and approve rev 12 of the I-D.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Sun, 14 Jun 2009 11:12:59 -0400

> Unless I hear a strong objection from the entire
> sponsor it.

I have now done this, i.e., the document has been approved. If Alper or
others are willing to make an improved version, I'll gladly sponsor
another RFC that obsoletes this one.

Jari