Subject: [eap] Issue 14: EAP transport behavior not specified

From: [email-masked] (Bernard Aboba)
Date: Mon, 25 Mar 2002 13:02:37 -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-02
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. It is suggested a
retransmission timer of 1 second with a maximum of 10 retransmissions be
used as default. After each retransmission, the retransmission timer is
doubled. 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. Since it is possible that the Authenticator may retransmit prior to
receiving an EAP-Response from the Peer, the Authenticator MUST be
prepared to detect and silently discard duplicate EAP-Responses."