The state of TACACS+

Robert Drake rdrake at
Mon Dec 29 17:00:48 UTC 2014

On 12/28/2014 10:21 PM, Christopher Morrow wrote:
> and I wonder what percentage of 'users' a vendor has actually USE tac+
> (or even radius). I bet it's shockingly low...
true.. even in large-ish environments centralized authentication 
presents problems and can have a limited merit.  Up to some arbitrary 
size, nobody really can be bothered unless some business case comes up 
like splitting responsibilities between groups. Accounting is probably 
the best early reason to turn it on in small networks.  Being able to 
see who made a change makes it easier to figure out why.

>> Maybe there is a simpler solution that keeps you happy about redundancy but
>> doesn't increase complexity that much (possibly anycast tacacs, but the
>> session basis of the protocol has always made that not feasible).  It's
> does it really? :)
Well, the chance of two geographically close servers getting 
load-balanced made it not feasible for us to do.  Not to mention the 
fact that we had only two tacacs servers and the use-case for anycasting 
wasn't worth the hassle of implementation.

> juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working...
> they don't all have ssl libraries in their "os" either...
With it being a TCP extension, my guess is that it's harder to find 
someone at those companies willing to change things inside the kernel 
because it's used by too many people, and if nobody is asking for it 
then they don't want to build it just to advertise they're first to market.

Even the ISP's who probably asked for it ultimately don't put money on 
getting it done because the engineer who says they need it still doesn't 
turn down the new chassis that lacks support.  The money is all flowing 
through the hardware guys now and if it's not directly related to moving 
packets quickly then they don't care.

> Getting to some answer other than: "F-it, put it i clear text" for new
> protocols on routers really is a bit painful... not to mention ITARs
> sorts of problems that arise.
Now you're making me depressed.   :)

The question is should we be trying to move things along or just leave 
it as it is?  There are certainly more important things on everyone's 
TODO list right now, but I'd rather the vendors have an open ticket in 
their queue saying "secure-tacacs+-rfc unimplemented" rather than 
letting them off the hook.

> -chris


More information about the NANOG mailing list