[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Alan DeKok writes...
> Inserting *other* attributes in between a fragemented attribute
> is annoying and pointless. It's better to forbid this, and to
> declare that packets failing this test are malformed, and SHOULD
> be silently discarded.
I think this would introduce a new, non-backwards-compatible requirement.
Today, RADIUS requires that attributes of the same type not be re-ordered in
the PDU, e.g. by proxies. There is no such requirement for attributes of
> What does "Foo(0,4)" mean?
I suppose it means the TLV with Type Code 4, assigned within the IETF
allocation, i.e. Attribute 26, Vendor-ID 0.
Why not just refer to it as "Foo"?
There is a long-standing typographical tradition of listing attributes as
> Consider the following structure:
> Integer a;
> String b;
> Integer c;
> What syntax is this?
Pseudo-code? Maybe actually using ANSI C would be more universal. I think
the RADIUS data types are not a good way to express this concept, as
witnessed by confusion in various drafts over the years.
> Reading the rest of the example, I find the b(4,5) syntax very
I think that's part of Glen's [potential] issue.
> 7. Security Considerations
> I suggest adding a note that a new attribute encoding is an
> opportunity for buffer overflows, inadequate checks, etc.
> Implementors SHOULD take care to validate the lengths, etc.
> before decoding the contents of the attributes.
How is that different from good coding guidelines for *any* implementation
of *any* protocol? What about the on-the-wire protocol involved raises
> 9. Open Issues
> What is the numbering scheme for attributes that will be used by RFC
> writers going forward? For example today we write user-name(1).
> Uh... We do?
Yes, we do. I can cite numerous examples.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.