Subject: [eap] Sending new requests before response?

From: [email-masked] ([email-masked])
Date: Tue, 4 Mar 2003 09:54:41 +0200

Is EAP "lock-step" or not?
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: March 4th, 2003
Reference: -
Document: RFC2284bis and RFC 2869bis (and maybe state machine)
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:

I know this issue has been discussed before (e.g. James Carlson's
email on January 6th [1]), but since it has come up in PANA again (and
might cause extra complexity there), I would like to see the issue
explictly clarified in 2284bis and/or 2869bis.

[1] =
http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html

So, the question is: Is the Authenticator/EAP Server allowed to send a
new Request (with different Identifier and contents) before it has
received a Response to the previous outstanding Request? (that is,=20
is EAP "lock-step" protocol or not?)

At least it seems that 2869bis does not support this kind of behavior
(since the authentication server can send an Accept-Challenge only in
response to an Access-Request). So, even if we allow "non-lock-step
behavior" in 2284bis, perhaps it should be explicitly forbidden in
2869bis? (I don't think this is a problem, since 2869bis does not
support all EAP features anyway, like role reversal).

I don't have a strong opinion on this one: allowing such behavior
might increase complexity, but as James said, there was no such
restriction in RFC2284 (or at least so it seems).=20

If we get some kind of consensus on which option should be chosen
(allow non-lock-step behavior in 2284bis but prohibit it in 2869bis,
or prohibit it in both), I can try to propose some text.  (Or, it
might be that the specs already say this, but I can't find it :-)

(BTW, there are some parts in 2284bis which assume lock-step behavior
and need changing if non-lock-step is allowed. For example,
Section 4.1: "In order to avoid confusion between new Requests
and retransmissions, the Identifier value chosen for each new Request
need only be different from the previous Request, but need not be
unique within the conversation.")

Best regards,
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 04 Mar 2003 12:20:47 -0500

--On Tuesday, March 4, 2003 9:54 AM +0200 [email-masked] wrote:

> [1] http://mail.frascone.com/pipermail/public/eap/2003-January/000478.html
>
> received a Response to the previous outstanding Request? (that is,

The state machine at least assumes that lock step is required.  I believe 
this was the consensus on an EAP-design group call, but I am not positive I 
remember correctly, or that all who might disagree were on the call.

I think the alternative is very hard to describe and implement at the 
detail level.  Specifically, if one allows multiple Requests in parallel, 
then each will need to have a separate id.  each id will need to be unique. 
If a Request is retransmitted, the peer may respond to both the original 
and retransmitted request, or to only one of them.  The authenticator will 
not know whether the response is coming or not, so it won't be able to 
reuse the id until a timeout.  The assumption of ordering doesn't help this 
since the authenticator can never be sure the peer won't send a response.

Lock step makes it much simpler and more understandable.  If a response 
comes that is not for the just send id, it can be dropped.

> restriction in RFC2284 (or at least so it seems).
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap