Subject: [eap] RE: Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational

From: [email-masked] (Glen Zorn)
Date: Wed, 14 May 2003 20:56:47 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C31A5B.68598830
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

draft-aboba-radius-rfc2869bis-21.txt says in section 2.3:

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

The reasoning behind this modification to the RADIUS retransmission
strategy is that "... 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." (see
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20125).  However,
the TCP RTO algorithms are designed to prevent network congestion, which
(though it may occur) is not the problem we're trying to solve here,
which I think might be better modeled as a server resource contention
problem.  Furthermore, the problem is not specific to EAP-over-RADIUS;
in the situation mentioned above, the same behavior would be observed
regardless of the authentication protocol in use.  This fact suggests
that a solution to the problem (presupposing that a protocol-based
solution is reasonable) should be published as an update to RFC 2865,
rather than RFC 2869.

There are other reasons why the RFC 2998 algorithms are inappropriate
for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4);
others include an initial TMO that is likely to be too short in
situations where one or more RADIUS proxies are traversed, the large
granularity of the timers specified and the deterministic nature of the
algorithms used which in the worst case could result in all the clients
firing repeated salvos of requests in lockstep (not a good way to reduce
instantaneous server loading!).  

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..."

-- Benjamin Franklin, 1759 

I've stopped 24,713 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/

------=_NextPart_000_000C_01C31A5B.68598830
Content-Type: text/x-vcard;
	name="Glen Zorn.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Glen Zorn.vcf"

BEGIN:VCARD
VERSION:2.1
N:Zorn;Glen
FN:Glen Zorn
ORG:Cisco Systems
TITLE:CTO Consulting Engineer
NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D =
E2FC 9769  FB97 FBCF 7DA4 9A2D 1963=3D0D=3D
=3D0A=3D0D=3D0A
TEL;HOME;VOICE:+1 (425) 513-8512
TEL;CELL;VOICE:+1 (425) 344-8113
TEL;WORK;FAX:+1 (425) 740-0168
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue =
N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue =
N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA
URL;WORK:http://www.cisco.com
EMAIL;PREF;INTERNET:[email-masked]
REV:20021107T033833Z
END:VCARD

------=_NextPart_000_000C_01C31A5B.68598830--

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 14 May 2003 21:54:19 -0700 (PDT)

Overall, I agree with Glen's comments and would therefore recommend that
the paragraph in question be removed from RFC 2869bis, and that a separate
document be developed to specify RADIUS retransmission behavior in more detail.

> problem.

The basic principle embodied in the TCP RTO algorithms is "conservation of
packets" -- that a new packet should not enter the network until there is
reason to believe that another packet has left it. Both a server resource
contention problem and congestion manifest themselves in terms of increased
delays and packet loss, and so it seems to me that the principle applies
in both cases -- and can be addressed dynamic timeout estimation, backoff
and jittering.

> Furthermore, the problem is not specific to EAP-over-RADIUS;

I agree with Glen that the problem can occur with any RADIUS
usage (authentication or accounting), and therefore is not specific to
RADIUS/EAP.  It therefore would be best to handle this as a separate
document.

> for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4);

Section 2.4 mentions that TCP is too aggressive in terms of
retransmission.  However in practice we are seeing RADIUS client
implementations that are much *more* aggressive than TCP. For
example, one RADIUS client from a well known vendor has a default RTO of 1
second with no backoff.  Several thousand of these clients recently
caused a service outage on our network after a network-wide password
reset resulted in a RADIUS server overload.  Since the clients did not back off
(or jitter)  the result was extremely high load as clients kept retrying
EAP authentication without success, hammering the servers until we had to
change the network-wide configuration to bring the network online again.

The other thing mentioned in section 2.4 is that faster failover is
desired than what TCP would provide.  It seems to me that RTO
estimation and failover are orthogonal issues so that doing dynamic RTO
estimation and backoff need not adversely affect failover algorithms.

> instantaneous server loading!).

I agree that jitter is required here, and that the initial RTO might be
set to a higher value (say, 5 seconds).