draft-ietf-radext-fixes-06.txt   draft-ietf-radext-fixes-07.txt 
Network Working Group David Nelson Network Working Group David Nelson
INTERNET-DRAFT Elbrys Networks, Inc INTERNET-DRAFT Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579 Alan DeKok Updates: 2865, 2866, 2869, 3579 Alan DeKok
Category: Proposed Standard FreeRADIUS Category: Proposed Standard FreeRADIUS
<draft-ietf-radext-fixes-06.txt> <draft-ietf-radext-fixes-07.txt>
Expires: February 27, 2007 Expires: March 1, 2007
27 August 2007 4 September 2007
Common Remote Authentication Dial In User Service (RADIUS) Common Remote Authentication Dial In User Service (RADIUS)
Implementation Issues and Suggested Fixes Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 8, line 14 skipping to change at page 8, line 14
second. This is sufficient to overwhelm most RADIUS servers. second. This is sufficient to overwhelm most RADIUS servers.
Suggested solutions include: Suggested solutions include:
[a] Jitter. To avoid synchronization, a RADIUS client SHOULD [a] Jitter. To avoid synchronization, a RADIUS client SHOULD
incorporate induced jitter within its retransmission algorithm, as incorporate induced jitter within its retransmission algorithm, as
specified below. specified below.
[b] Congestive backoff. While it is not necessary for RADIUS client [b] Congestive backoff. While it is not necessary for RADIUS client
implementations to implement complex retransmission algorithms, implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits implementations SHOULD support congestive backoff.
suggested by [RFC2865] Section 2.4.
RADIUS retransmission timers are based on the model used in DHCPv6 RADIUS retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this [RFC3315]. Variables used here are also borrowed from this
specification. RADIUS is a request/response-based protocol. The specification. RADIUS is a request/response-based protocol. The
message exchange terminates when the requester successfully receives message exchange terminates when the requester successfully receives
the answer or the message exchange is considered to have failed the answer or the message exchange is considered to have failed
according to the RECOMMENDED retransmission mechanism described according to the RECOMMENDED retransmission mechanism described
below. Other retransmission mechanisms are possible, so long as they below. Other retransmission mechanisms are possible, so long as they
satisfy the requirements on jitter and congestive backoff. satisfy the requirements on jitter and congestive backoff.
skipping to change at page 10, line 46 skipping to change at page 10, line 45
Access-Request packets, as described in Section 3 of [RFC2865]. Access-Request packets, as described in Section 3 of [RFC2865].
Implementations MUST also cache the Responses (Access-Accept, Access- Implementations MUST also cache the Responses (Access-Accept, Access-
Challenge, or Access-Reject) that they send in response to Access- Challenge, or Access-Reject) that they send in response to Access-
Request packets. If a server receives a valid duplicate Access- Request packets. If a server receives a valid duplicate Access-
Request for which is already has sent a Response, it MUST resend its Request for which is already has sent a Response, it MUST resend its
original Response without reprocessing the request. The server MUST original Response without reprocessing the request. The server MUST
silently discard any duplicate Access-Requests for which a Response silently discard any duplicate Access-Requests for which a Response
has not been sent yet. has not been sent yet.
Each cache entry SHOULD be purged after a period of time. This time Each cache entry SHOULD be purged after a period of time. This time
SHOULD be no less than 5 seconds, and no more than 30 seconds. SHOULD be no less than 5 seconds, and no more than 30 seconds. After
about 30 seconds, most RADIUS clients and end users will have given
up on the authentication request. Therefore, there is little value
in having a larger cache timeout.
Cache entries MUST also be purged if the server receives a valid Cache entries MUST also be purged if the server receives a valid
Access-Request packet that matches a cached Access-Request packet in Access-Request packet that matches a cached Access-Request packet in
source address, source port, RADIUS Identifier, and receiving socket, source address, source port, RADIUS Identifier, and receiving socket,
but where the Request Authenticator field is different from the one but where the Request Authenticator field is different from the one
in the cached packet. If the request contains a Message- in the cached packet. If the request contains a Message-
Authenticator attribute, the request MUST be processed as described Authenticator attribute, the request MUST be processed as described
in [RFC3580] Section 3.2. Packets with invalid Message- in [RFC3580] Section 3.2. Packets with invalid Message-
Authenticators MUST NOT affect the cache in any way. Authenticators MUST NOT affect the cache in any way.
skipping to change at page 11, line 29 skipping to change at page 11, line 31
When sending requests, RADIUS clients MUST NOT re-use Identifiers for When sending requests, RADIUS clients MUST NOT re-use Identifiers for
a source IP address and source UDP port until either a valid response a source IP address and source UDP port until either a valid response
has been received, or the request has timed out. Clients SHOULD has been received, or the request has timed out. Clients SHOULD
allocate Identifiers via a least-recently-used (LRU) method for a allocate Identifiers via a least-recently-used (LRU) method for a
particular source IP address and source UDP port particular source IP address and source UDP port
RADIUS clients do not have to perform duplicate detection. When a RADIUS clients do not have to perform duplicate detection. When a
client sends a request, it processes the first response that has a client sends a request, it processes the first response that has a
valid Response Authenticator as defined in [RFC2865] Section 3. Any valid Response Authenticator as defined in [RFC2865] Section 3. Any
later responses MUST be silently discarded. later responses MUST be silently discarded, as they do not match a
pending request. That is, later responses are treated exactly the
same as unsolicited responses, and are silently discarded.
2.2.3. Server Response to Overload 2.2.3. Server Response to Overload
Some RADIUS server implementations are not robust in response to Some RADIUS server implementations are not robust in response to
overload, dropping packets with even probability across multiple overload, dropping packets with even probability across multiple
sessions. In an overload situation, this results in a high failure sessions. In an overload situation, this results in a high failure
rate for multi-round authentication protocols such as EAP [RFC3579]. rate for multi-round authentication protocols such as EAP [RFC3579].
Typically, users will continually retry in an attempt to gain access, Typically, users will continually retry in an attempt to gain access,
increasing the load even further. increasing the load even further.
 End of changes. 4 change blocks. 
7 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/