On Sun, Dec 28, 2014 at 6:02 PM, Robert Drake <rdr...@direcpath.com> wrote: > Picking back up where this left off last year, because I apparently only > work on TACACS during the holidays :)
avoiding relatives? :) > > > On 12/30/2013 7:28 PM, Jimmy Hess wrote: >> >> Even 5 seconds extra for each command may hinder operators, to the extent >> it would be intolerable; shell commands should run almost >> instantaneously.... this is not a GUI, with an hourglass. Real-time >> responsiveness in a shell is crucial --- which remote auth should not >> change. Sometimes operators paste a buffer with a fair number of >> commands, not expecting a second delay between each command --- a >> repeated delay, may also break a pasted sequence. >> >> It is very possible for two of three auth servers to be unreachable, in >> case of a network break, but that isn't necessary. The "response >> timeout" might be 5 seconds, but in reality, there are cases where you >> would wait longer, and that is tragic, since there are some obvious >> alternative approaches that would have had results that would be more >> 'friendly' to the interactive user. >> >> (Like remembering which server is working for a while, or remembering >> that all servers are down -- for a while, and having a 50ms timeout, >> with all servers queried in parallel, instead of a 5 seconds timeout) > > I think this needs to be part of the specification. > > I'm sure the reason they didn't do parallel queries was because of both > network and CPU load back when the protocol was drafted. But it might be > good to have local caching of authentication so that can happen even when > servers are down or slow. Authorization could be updated to send the > permissions to the router for local handling. Then if the server dies while > a session is open only accounting would be affected. Juniper, at least, does the authorization cache on the device trick... (or really scoping of commands/areas a user is permitted via a local cache file in /var/tmp) > > That does increase the vendors/implementors work but it might be doable in > phases and with partial support with the clients and servers negotiating > what is possible. The biggest drawback to making things like this better is > you don't gain much except during outages and if you increase complexity too > much you make it wide open for bugs. and I wonder what percentage of 'users' a vendor has actually USE tac+ (or even radius). I bet it's shockingly low... > 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? :) > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or MinimaLT > would address these problems too. It's possible that if we did the > transport with BEEP it would also provide this, but I'm reading the docs and > I don't think it goes that far in terms of connection assurance. > > So, here is my TACACS RFC christmas list: > > 1. underlying crypto juniper, cisco, arista, sun, linux, freebsd still can't get TCP-AO working... they don't all have ssl libraries in their "os" either... 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. -chris > 2. ssh host key authentication - having the router ask tacacs for an > authorized_keys list for rdrake. I'm willing to let this go because many > vendors are finding ways to do key distribution, but I'd still like to have > a standard (https://code.google.com/p/openssh-lpk/ for how to do this over > LDAP in UNIX) > 3. authentication and authorization caching and/or something else
