RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

Alan DeKok wrote... 

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

The reason that section 2.2 exists at all is because we have a strong
desire for the capability to have an acknowledgement from the NAS, in
particular when it was incapable or unable to apply and attribute (from
this document).   From a security perspective, not knowing explicitly
whether a given policy (i.e. attribute) has been applied is undesirable
to say the least. 

While I do agree that we are setting a precedent that moves away from
the legacy RADIUS behavior, this new behavior would be just applicable
to the attributes described in this document. Perhaps a discussion item
for the RADIUS issues and fixes document is to look at the role explicit
acknowledgement could play for all attributes.  

In relation to specific stop, start/stop accounting behavior that should
occur upon failure, how about the following text to replace the first
paragraph of section 2.2? 

"Unless otherwise noted in the individual description of an attribute
contained herein, a NAS that conforms to this specification and receives
an Access-Accept message that contains an attribute from this document
that it does not recognize or cannot apply MUST interpret this though an
Access-Reject had been sent and MUST terminate the session.  If
accounting is enabled on the NAS, it MUST generate an accounting event
upon session termination." 

MS



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