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

Re: RADEXT Issue 148 Item 6

I agree with Emile on this. During the discussion of "malformed" in the original RADEXT WG, the intent was to catch syntax errors, not unknown attributes. RFC 2865 does not require a particular VSA format, and in AAA WG, we've had an extensive discussion about the problems that can occur when it is assumed that all VSAs obey the suggested format. Going down this road could therefore set a precedent that could affect the interoperability of RADIUS in other contexts as well.
In cases where there are interoperability problems, it is not possible to establish precedent based on the existing behavior, since by definition the text has been interpretted differently by different implementers. So the logic behind the proposed text is flawed. To fix the issue, you've got to choose one interpretation or the other. This may require some implementations to change their code -- but shying away from this will only sacrifice interoperability, which isn't a good tradeoff. 



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




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