Subject: [eap] Proposed Resolution to Issue 139: Response to Duplicate Requests

From: [email-masked] (Bernard Aboba)
Date: Thu, 29 May 2003 10:29:57 -0700 (PDT)

The text of Issue 139 is enclosed below. The proposed resolution is as
follows.

In Section 4.1 of RFC 2284bis, change:

"If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response.  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.  An EAP message may be found invalid for a
variety of reasons: failed lower layer CRC or checksum, malformed
EAP packet, EAP method MIC failure, etc."

To:

"If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed
in the order that they are received.

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

---

From: [email-masked] (Jari Arkko)
Date: Thu, 29 May 2003 22:18:34 +0300

> in the order that they are received.

Ok. Maybe add "..., and MUST be processed to their completion
before inspecting the next request" to make it 100% clear
that there are no interrupts?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 29 May 2003 12:02:03 -0700 (PDT)

> Maybe add "..., and MUST be processed to their completion

OK. Will add.