[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue 67: Interpretation of Idle-Timeout



Issue 67: Interpretation of Idle-Timeout
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: February 27, 2005
Reference:
Document: ISSUES, IEEE 802
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Here is what RFC 2865, Section 5.28 says about Idle-Timeout:

"This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge."

Here is what RFC 3580, Section 3.12 says about Idle-Timeout:

"The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802
media other than 802.11 the media are always on. As a result the
Idle-Timeout attribute is typically only used with wireless media
such as IEEE 802.11. It is possible for a wireless device to wander
out of range of all Access Points. In this case, the Idle-Timeout
attribute indicates the maximum time that a wireless device may
remain idle."

However, there is no definition of "idle". Does this really mean
"no traffic"? In practice, a connected host will send broadcast
traffic, including ARP, NetBIOS, IPX, AppleTalk, SSDP, etc. So
if idle = "no traffic" then the idle timeout might never trigger.

In practice, devices often provide support for access lists
that define what types of traffic are used to bring
connections up and down.  So that filter defines what "idle" is.
If not provided, local policy makes the determination.

The suggested resolution is to look at defining "idle" conditions more
explicitly within RADIUS, such as defining the maximum traffic over a
defined period that qualifies as "idle" and possibly defining a filter
that would indicate what traffic is *not* to be counted.

Within the Issues and Fixes document, it would be stated that "Idle"
is defined by local policy in the absence of these other attributes.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>