[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADEXT Issue 148 Item 6

Hi,

On Fri, Dec 09, 2005 at 03:21:12PM -0500, Nelson, David wrote:

> The following text is proposed to be added to Section 1. Terminology, to
> resolve RADEXT Issue 148, Item 6 (under General comments):
> 
> <quote>
> 
> This document uses the word "malformed" with respect to RADIUS packets,
> particularly in the context of counters of "malformed packets".  While
> RFC 2865 does not provide an explicit definition of "malformed",
> malformed generally means that the implementation has determined the
> packet does 
> not match the format defined in RFC 2865.  Some implementations may
> determine that packets are malformed when the Vendor Specific Attribute
> (VSA) format does not follow the RFC 2865 recommendations for VSAs.
> Those implementations are used in deployments today, and thus set the
> de-facto definition of "malformed".
> 
> </quote>

I disagree with the issue. 

I would say that "malformed" means that the packet and the rules
governing its format cannot be reconciled. A "syntax error", so to
speak.

If the rules governing the internal contents of the VSA are not known by
the server (eg. by it not knowing about the vendor in question), it
cannot flag the packet as malformed. It has rules governing the outer
structure of the VSA, and those are the only ones it should apply.

If, on the other hand, a server knows eg. that all USR VSAs use
16-bit attribute numbers plus a length field that only covers the value
subfield, and it sees an Ascend VSA that does not follow this format
(eg. the 'internal length' exceeding the 'outer length' of the VSA), the
server can flag a malformed packet.

This keeps the counter meaningful. Otherwise, 'malformed' and thus
ignored attributes from the vendor's point of view would cause the
packet to be counted as well formed, while the inclusion of well formed
attributes from the vendor's point of view, would cause the packet to be
counted as malformed.

If you run an USR NAS, that would make the counter meaningless.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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