[tac_plus] Should optional A/V pair be sent?

Daniel Schmidt daniel.schmidt at wyo.gov
Wed Jan 25 15:20:50 UTC 2012


This I why I added the "av_pair kluging" to do_auth.  Users with Nexus,
Brocade, Cisco, XR & whatever can all play nice together on one tac_plus
server.  And, network operators can all have appropriate read-only
accounts, despite vendor differences.  It's not to fix the limitations of
tac_plus, it's to fix the limitations (bugs) of the vendors.  Well, that
and multiple groups per user.

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Jathan McCollum
Sent: Wednesday, January 25, 2012 7:42 AM
To: heasley
Cc: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Should optional A/V pair be sent?

On the server side, that makes sense. Thanks for confirming! :) I will
take this back to Brocade to request that they send the attribute they are
requiring for successful authorization.

As for devices that freak out when they receive optional AVP, if anyone
can think of any that would be helpful! I have a large environment with
many and varied devices that are so ancient there is no hope of getting
some kind of firmware bug corrected. :)

On Tue, Jan 24, 2012 at 8:23 PM, heasley <heas at shrubbery.net> wrote:

> handling of optional AVs is coded as 'if the nas didnt send it (as
> mandatory or optional), then the daemon does not send it'.
>
> the ancient ietf draft does not make this necessary.  its only
> assertion is that both sides must ignore optional AVs if they do not
support them:
>
>   The arguments in both a REQUEST and a RESPONSE can be specified as
>   either mandatory or optional. An optional argument is one that may or
>   may not be used, modified or even understood by the recipient.
>
> ISTR someone mentioning on this list that some device of theirs threw
> a fit if it received an optional AVP that it didnt understand.
> Perhaps daniel?
>



--
Jathan.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.shrubbery.net/pipermail/tac_plus/attachments/20120125/aec67250
/attachment.html>
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
E-Mail to and from me, in connection with the transaction 
of public business,is subject to the Wyoming Public Records 
Act, and may be disclosed to third parties.



More information about the tac_plus mailing list