Subject: [eap] Issue 125: Retransmission Issue

From: [email-masked] (Bernard Aboba)
Date: Sat, 10 May 2003 20:18:34 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: May 10, 2003
Reference:
Document: RFC2869bis-20
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

RADIUS [RFC2865] does not define retransmission behavior. However we
have seen situations (such as a network-wide reboot) where RADIUS
storms can occur, swamping the RADIUS server(s). In these situations
it would be preferrable for RADIUS clients to support exponential
backoff and a more conservative initial RTO estimate, as in TCP.

Change Section 2.3 from:

"2.3. Retransmission

As noted in [RFC2284], if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible
for retransmission of packets between the RADIUS client and the RADIUS
server.

It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to find
the card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of Session-Timeout
attribute within the Access-Challenge packet.

If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout is used to set
the EAP retransmission timer for that EAP Request, and that Request
alone. Once the EAP-Request has been sent, the NAS sets the
retransmission timer, and if it expires without having received an EAP-
Response corresponding to the Request, then the EAP-Request is
retransmitted."

To:

"2.3. Retransmission

As noted in [RFC2284], if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible
for retransmission of packets between the RADIUS client and the RADIUS
server.

It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to find
the card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of Session-Timeout
attribute within the Access-Challenge packet.

If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout is used to set
the EAP retransmission timer for that EAP Request, and that Request
alone. Once the EAP-Request has been sent, the NAS sets the
retransmission timer, and if it expires without having received an EAP-
Response corresponding to the Request, then the EAP-Request is
retransmitted.

In RADIUS [RFC2865], the RADIUS client is responsible for retransmission
of RADIUS packets. RADIUS/EAP client implementations SHOULD support
dynamic estimation of the RADIUS retransmission timeout, using the algorithms
specified in [RFC2988]. Since RADIUS Access-Requests may be routed the RADIUS server
based on the NAI realm [RFC2486], dynamic retransmission timeout estimates
SHOULD be maintained on a per-realm or per-EAP session basis."

---

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 09:17:05 +0300

> SHOULD be maintained on a per-realm or per-EAP session basis."

Ok.

--Jari