[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap
"Nelson, David" <dnelson@enterasys.com> wrote:
> <quote>
>
> [pc] I believe that this should not cause any problem, but to be honest,
> we could use some input from others. I'm aware of some implementations
> that send a start and then immediately follow with a stop, but this
> could be more resource intensive than needed. The stop without a start
> would either be ignored by the server or appropriately acknowledge the
> termination of the session that didn't start. This could be useful for
> diagnostic purposes. I'd love to hear from other Radius vendors as to
> whether this would be a problem or not. Again, my assumption is that it
> isn't.
>
> </quote>
Multiple NAS implementations already send STOP without START. The
use appears to be that when a session is rejected, a stop may be sent
with zero session time. I've seen this for at least the last five
years, so it is a fairly wide-spread and common behavior.
> I haven't seen much comment one way or the other. My conservative
> nature tells me to be cautious about assuming that adding heretofore
> un-described behavior in a long-standing protocol based on the
> assumption that nothing will break is fairly risky.
FreeRADIUS doesn't much care one way or the other. A search on
google for "stop packet with zero session length" yeilds a number of
email questions about SQL queries, but SQL is just one accounting
store out of many available.
I don't see how any RADIUS vendor could avoid seeing stop packets
without a start, especially because of UDP packet loss and lack of
ordering.
So I don't see it as much of an issue for existing implementation,
but I'm not sure that codifying it in a new standard is a good idea.
My belief is that if a "session termination" does NOT happen when an
Access-Reject is sent to the NAS. Rather, the session was proposed,
but never established. As a result, no session existed, so no stop or
start packet should be sent.
In general, stop should always be preceded by starts.
Alan DeKok.
--
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/>