Re: RADEXT Issue 148 Item 6

["Alan DeKok" <aland@ox.org>]

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> 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.

  That's all and good, but where in the RADIUS specifications does it
define which rules should be applied to define this term?

  The suggested definition of "malformed" was due to two reasons:

  1) there is no definition of "malformed" in the RFC's
  2) existing implementations count "malformed" packets in
     implementation-dependent ways (as a result of (1))

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

  The decision as to what is good, or bad, syntax in your examples is
up to the implementation.  The proposed text is intended to say that
the definition of "malformed" is implementation-dependent.

  The text is *not* intended to define that all new implementations
must behave in the way described.  Rather, it is intended to define
that there is no clear definition for the counter, and that the
meaning of the counter is implementation dependent.

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

  Yes.  It's inconsistent, precisely because the definition of
"malformed" is non-existent.

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

  No, it makes the counters implementation dependent.  If you want to
know what the counters mean, ask your RADIUS server vendor.  As was
noted previously, implementations may not implement all of the
counters.

  Implementations may (or may not) implement portions of RADIUS.  If
an implementation does not completely support the protocol, that does
not make it useless, or meaningless.

  Can you suggest text that would address these issues to your
satisfaction?

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