in vs. out
hecker at wave-storm.com
Thu Oct 4 09:40:33 CEST 2007
Just one word on it: you are citing a RADIUS specific RFC. Thus, Acct-
Input-Octets is the value perceived by RADIUS instances. RADIUS RFCs
cannot possibly specify how terminals, wireless cards, GSM phones
etc. should or should not count packets, traffic, connections, etc.
It can and it does specify how NAS (radius-client) should communicate
with the AS (radius-server). Thus, the situation here is from the NAS
point of view(*) and the INPUT means INPUT to the NAS from the
service port, i.e. e.g. from the user as Alan explained.
Any other interpretation would be imho very strange, no?
PS or from server's point of view if you prefer. Since RADIUS is a
distributed AAA system, it's whole sense us to establish the same
view after a while through protocol exchanges. (ah)
On 4 Oct 2007, at 09:17, Alan DeKok wrote:
> wlan at mac.com wrote:
>> It is curious, then, why the RFC isn't as definitive in the
>> definition... I suppose it is intentionally left open for vendor
> <sigh> No. The RFC *is* definitive. It just may not be overly
> 10 years after the original text was written. It is NOT left open for
> vendor interpretation. If it was, then Acct-Input-Octets would be
> *useless*, as you could never tell what it meant.
>> As such, portmaster being more specific as it relates to
>> their products isn't surprising. But, is that the 'standard', a 'best
>> practice', or just one vendor's (albeit, a very in-the-know vendor's)
>> implementation? I do agree with the point of view (of the port), in
>> theory. However, in practice, I guess the best answer is that it is
>> vendor specific.. hmm.
> No. The standard is the RFC. The portmaster text is just
> text from the people building RADIUS systems.
> It is NOT vendor specific. Do NOT say it is vendor specific.
>>> Follow the standards. Do not follow broken vendors.
>> It actually isn't just that one vendor... in fact, if not
>> mistaken, much
>> of the commercial wlan gear I've worked with used the above
>> meaning. It
>> would be curious to see a list of vendors and how they implemented
>> accounting... if we all checked the manuals of the devices we
>> use, we
>> could all help build that list in the freeradius wiki!
> Feel free to start this effort.
> There are many other vendor products that are very broken with
> to RADIUS. Do NOT follow any individual vendor, or even groups of
> vendors. Follow the standards. If the standards aren't clear, ask on
> the IETF RADEXT mailing list. The people there should be able to give
> conclusive answers.
> Also see my 2 documents in that working group. They clarify many
> issues and problems with the previous RADIUS RFC's.
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
More information about the Freeradius-Users