Subject: [eap] Proposed resolution of Issue 14: Accept

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 12:02:31 -0800 (PST)

Issue 14: EAP transport behavior not specified
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 25, 2002
Reference:
Document: RFC2284bis
Comment type: T
Priority: 1
Section: 4.1
Rationale/Explanation of issue:

RFC 2284 does not adequately specify EAP's transport behavior. The EAP
implementation survey results indicate that implementations do not use the
default retransmission timer of 6 seconds as specified in RFC 2284. In
fact, much lower values are often used, sometimes so low that the
EAP-Request can be retransmitted prior to arrival of the EAP-Response.
This causes problems if the NAS sends a duplicate AAA Request as a result.
Similarly, when EAP is run over reliable transport (such as within PIC,
which can run over ISKAMP/TCP), it is possible for retransmissions to
occur at multiple layers of the stack.

Change:

"Implementation Note: Because the authentication process will often
involve user input, some care must be taken when deciding upon
retransmission strategies and authentication timeouts. For use in
PPP, it is suggested a retransmission timer of 6 seconds with a
maximum of 10 retransmissions be used as default. One may wish to
make these timeouts longer in certain cases (e.g. where Token
Cards are involved). Additionally, the Peer must be prepared to
silently discard received retransmissions while waiting for user
input."

To:

"Implementation Note: Because the authentication process will often
involve user input, some care must be taken when deciding upon
retransmission strategies and authentication timeouts.

By default, where EAP is run over an unreliable lower layer,
the EAP retransmission timer (EAP_RTO) SHOULD be computed as
described in [RFC2988]. A maximum of 3-5 retransmissions is suggested.

When run over a reliable lower layer
(e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP retransmission timer
SHOULD be set to an infinite value, so that retransmissions do not occur
at the EAP layer.

Where the authentication process requires user input,
the measured round trip times are largely be determined by user
responsiveness rather than network characteristics,
so that RTO estimation is not helpful.
Instead, the retransmission timers SHOULD be set so as to provide
sufficient time for the user to respond, with longer timeouts
required in certain cases, such as where Token Cards are involved.

In order to provide the EAP authenticator with guidance as to the
appropriate timeout value, a hint can be communicated to the
Authenticator by the backend authentication server (such as via the
RADIUS Session-Timeout attribute).

Additionally, the Peer MUST be prepared to
silently discard received retransmissions while waiting for user input,
so as to mitigate the ill effects of a too small retransmission timer."