Re: Issue 67: Interpretation of Idle-Timeout

[Jari Arkko <jari.arkko@piuha.net>]

Bernard Aboba wrote:

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

> 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."
>  
I wonder if there are in fact two separate issues in the
above text. At least some wireless technology is capable
of sensing the presence and reachability of the client.
(And I think 802.11 belongs to this category too, but I
may be mistaken.)

The presence of a client is different from it being idle.
Of course, if your L2 only gives you an idle indicator,
not presence indicator, you may wish to simulate the
latter with the former. But this is often unsatisfactory
and leads to overly long attachment times for hosts
that have moved on, or too short idle timers.

The presence problem requires a soft process because
we don't want to disconnect anyone just because a truck
passed by and blocked coverage for few seconds. We may
also leave around state so that roaming hosts can come
back and not have to redo full authentication.

> 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.
>  
Right.

> 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.
>  
Yes, but this is problematic too, because it isn't certain
that the client's view of the policy is the same as the
network provider's.  The operators policy may be based
on incorrect assumptions about the software that
people run, for instance.

> 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.
>  
Defining idle traffic is probably a better idea than defining
non-idle traffic. If you define idle lists, no one is going to get
logged out because their favorite protocol was not included
in the list -- they just might stay logged on longer. But if you
define non-idle traffic then what happens if the stuff that
I use is not included in the filter. Say, if I use IPv6:TCP and
the filter said IPv4:TCP...

The other thing that I would recommend is encouraging
L2 to provide "carrier sense" so that we could accurately
track whether particular nodes are still within range or not.

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

--Jari


--
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/>