Subject: [eap] Issue 139: Response to duplicate requests

From: [email-masked] (Bernard Aboba)
Date: Wed, 28 May 2003 06:42:21 -0700 (PDT)

I think this language was put there because of token cards. The
peer checks the validity of the EAP layer header (Code, Identifier,
Length) as well as EAP method header (Type, Type-Data), and so a packet
is silently discarded is if these validity checks fail.  But here let's
assume that both the initial Request and the retransmitted Request are
valid.

If the authenticator is retransmitting a Request before a Response has
been sent, that must be because the authenticator has not estimated the
RTO timer well.  While we do have some language relating to dynamic RTO
estimation, it could be that the EAP method requires user
input (e.g. punching in a token value) and that the RADIUS server did
not provide a good "hint" as to how long this should take (e.g.
Session-Time attribute wasn't included). In this case the authenticator
could use an RTOinit = 3 seconds, but the user might take longer than that
to respond. So the authenticator will retransmit the Request.

Off the top of my head, I don't see anything wrong with sending a Response
to the initial Request, or sending a duplicate Response to the
subsequent Request.  The question is really about the processing of the
duplicate Request.  Does this result in an automatic resending of the
Response, or is there a requirement for additional user action -- the
user just typed in her token, and now we're asking for it again? That is
what needs to be avoided.

The current text attempts to handle this by discarding a Request which
arrives before a Response is sent.

An alternative to this would be to resend the Response -- but make it
clear that this is automatic (occurs in the EAP layer) and does not
require any user action.  So the user wouldn't have to type in their token
again until they get a *new* Request.

----------------------------------------------------
Issue 139: Response to duplicate requests
Submitter name: Nick Petroni
Submitter email address: [email-masked]
Date first submitted: May 14, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

"If a peer receives a duplicate Request before it has
sent a Response, but after it has determined the initial Request
to be valid (i.e. it is waiting for user input), it MUST silently
discard the duplicate Request. "

Seems like the peer should
be able to send as many responses as it gets requests for the same
id.  It may not send a response for prior id after it has sent a
response to current id.  This is how the state machine works, and
hopefully the wording in 2284bis will be modified to match.