"Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote: > I've been thinking about that, and I'm not sure about that. For > example, Lucington PM3 boxes have l2tp tunneling support, but I > don't think the PM3 supports tagged attributes. Yet you need to > send it the Tunnel attributes.
That's why the RFC's are ambiguous: to work around problems where NAS vendors can't, or won't fix their software. So the PM3 supports tunnel attributes which have no tag. The code to handle these attributes is just like the code to handle normal RADIUS encoded strings. But could they have added *proper* tag support to the RADIUS client code, while they were adding handlers for the tunnel attributes? Noo... that would make too much sense. > But I have read the RFC and I'm still not sure what, if anything, > is being said about this. It's ambigious. That's because the RFC's give you choices as to how the attributes are encoded. That's bad, as it promotes confusion and non-interoperability. As an example: http://www.freeradius.org/rfc/rfc2865.html Page 15: Administrative Note ... The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. This text was NOT in earlier RADIUS RFC's. It was put in because I told the authors about a RADIUS client implementation which had NO place to put a shared secret, and had documentation saying that the server shared secret must be set to an empty string. It's hard to design good protocols. Adding multiple ways of doing the same thing makes life harder for everyone. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
