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