Subject: [eap] Proposed resolution to Issue 134: EAP transport issues

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

The text of Issue 134 is enclosed below.  The proposed fix is as follows:

In Section 4.1, delete

"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 SHOULD be computed as described in
[RFC2988]. This includes use of Karn's algorithm to filter RTT
estimates resulting from retransmissions. 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 authenticator retransmission timer
SHOULD be set to an infinite value, so that retransmissions do
not occur at the EAP layer. Note that in this case the peer
may still maintain a timeout value so as to avoid waiting
indefinitely for a Request.

Where the authentication process requires user input, the
measured round trip times are largely determined by user
responsiveness rather than network characteristics, so that RTO
estimation is not helpful. Instead, the retransmission timer
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 (see Section 5.6) 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)."

Add Section 4.3:

"4.3 Retransmission Behavior

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 SHOULD be dynamically estimated.
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 authenticator retransmission timer
SHOULD be set to an infinite value, so that retransmissions do
not occur at the EAP layer. The peer may still maintain a
timeout value so as to avoid waiting indefinitely for a Request.

Where the authentication process requires user input, the
measured round trip times may be determined by user
responsiveness rather than network characteristics, so that dynamic
RTO estimation may not be helpful. Instead, the retransmission timer
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 (see Section 5.6) 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).

In order to dynamically estimate the EAP retransmission timer,
the algorithms for estimation of SRTT, RTTVAR and RTO described
in [RFC2988] are RECOMMENDED, including use of Karn's algorithm,
with the following potential modifications:

a) When EAP is transported over a single link (as
opposed to over the Internet), smaller values of RTOinitial,
RTOmin and RTOmax MAY be used. Recommended values are
RTOinitial=1 second, RTOmin=200ms, RTOmax=20 seconds.

b) When EAP is transported over a single link (as opposed
to over the Internet), estimates MAY be done on a
per-authenticator basis, rather than a per-session
basis. This enables the retransmission estimate to make the
most use of information on link-layer behavior

c) An EAP implementation MAY clear SRTT and RTTVAR after
backing off the timer multiple times as it is likely that the
current SRTT and RTTVAR are bogus in this situation. Once SRTT and
RTTVAR are cleared they should be initialized with the next RTT
sample taken as described in [RFC2988] equation 2.2."

-------------------------------------------------------------
Issue 134: EAP transport issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 15, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

RFC 2988 doesn't include support for jittering, and includes a good deal
of material that doesn't relate to EAP. As a result, more specific guidance
is required in order to make it clear how dynamic retransmission timeout
estimation is to be applied.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 29 May 2003 23:27:25 +0300

Looks good, thanks! --Jari

Bernard Aboba wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
>