<at the bottom> Tom Petch
----- Original Message ----- From: "Andrej Ota" <[email protected]> Sent: Thursday, February 11, 2016 12:29 PM > I'll try to answer multiple points from multiple e-mails to try to avoid > fragmented discussion. I do not dispute errors or omissions I made and > which were pointed out. > > On he topic of 1st, 2nd, ... AAA protocol: > My intention was not an ad hominem attack, but I did want to convey my > strong aversion to statement implying TACACS+ is a late arrival when it is > in fact a protocol we have been living with for almost 20 years without it > ever being standardised or agreed upon. A feat I do not wish to be > discounted or ignored, regardless of its origin. Ignoring it serves no > useful purpose and I don't see it as benefiting anyone who wishes to > discuss protocols and standardisation on the merit of usefulness to the > network operator and vendor communities. > > > On the topic of relation to other AAA protocols: > TACACS+ definitely is AAA protocol and as such can be seen and used as a > competitor to RADIUS. At the same time I do not see it as a direct > replacement (to consider it a viable competitor) as it caters to a very > specific niche related to a very specific work. Track record from last 20 > years demonstrates the difference in scopes. Is it competing with RADIUS? I > would rather say that RADIUS is competing with TACACS+ at this niche for > last 20 years and still not doing a stellar job at it. > > Is there a meaningful way to address this difference in scopes? Would it > help if we make it explicitly about network element AAA for management > purposes and avoid chatting about NAS? > > I don't even know what to say about alleged push of vendors *against* > RADIUS. I have to deal with few of vendors that only implement RADIUS and > not TACACS+ while I have yet to bump into a vendor which does the opposite. > > > On the topic of informational vs. standards track: > Authors are aiming for standards track due to two reasons: > 1) In the face of differing implementations, we cannot provide a simple > recap of what works but we feel we have to make a statement on how it > should work in the first place (e.g. removing ambiguities) without > introducing major incompatibilities. > 2) Device management AAA as used in the field today carries security > risks. To address some of them, authors decided to slap some lipstick on a > pig in the form of TLS tunnel. > > Having done this, we cannot honestly call this an informational RFC in the > sense of how RFC 3164 was informational. > > > On the topic of vendor-specific and the message that IETF sends: > I'm sure I'm missing something here, but from what I understand, the main > objection is procedural as in the draft wasn't properly adopted by > workgroup to work on it. As long as that is addressed in accordance with > the procedure, the draft could become IETF draft which WG would discuss and > modify as it sees fit and one which could ultimately be considered for > standards track RFC. I though we were in that process, but if it was > botched, we certainly want to have that addressed. > > I understand and appreciate the sensitivity of IETF even appearing to give > "a seal of approval" to some random vendor stuff. I certainly know how this > work could be misinterpreted if not handled in a very transparent manner. > But instead of a flat out refusal to deal with this protocol as it stands > today, I would like to appeal for suggestions on how to address this in > order to bring value to the community and industry. It's clear that this > was originally a proprietary protocol. I also think it became more than > that over two decades of use in a very specific niche area where AAA is > used in network operations. With multi-vendor adoption and willingness of > original authors to release it to current IETF process (copyrights, IPR and > all included) I think we can accept both negative legacy and its > practically demonstrated usability and viability while not encroaching on > the territories which are undisputedly RADIUS and Diameter dominated. > > > On the topic of slapping anyone in the face: > Continued long-term existence of non-IETF and non-RFC AAA protocol, its > widespread adoption in a single niche area and impact it has on the day to > day network operations cannot be ignored or discounted. As much as RADIUS > can be used in the same niche (as any other AAA protocol and other stuff > like LDAP can be used for the same purpose), it did not supplant the > non-standard solution for the last 20 years. I do not see how TACACS+ RFC > (if it ever comes to it) would change this. > > While IETF is and should be forward-looking in defining how things could > and should be done better, this doesn't mean that it should avoid dealing > with sometimes ugly issues at hand as long as the work helps the community > of users and vendors to do their work more efficiently. > > > On the topic of technical benefits: > There must be something that TACACS+ is doing at least good enough while > RADIUS isn't doing it so much better to replace it. > > My personal opinion is that TACACS+ is simple and dumb enough protocol to > be cheap to implement and still fit for the purpose. This two properties > combined make it an attractive choice for both users and vendors. > > My personal experience is that TACACS+ appears to work more consistently > over a range of different vendors than I can say for devices which provide > RADIUS exclusively. I also find it easier to diagnose and debug as it uses > reliable transport. RFC6613 was supposed to change the latter, but after 3+ > years I still don't see it adopted for the purpose of network management > AAA. > > > On the topic of proprietary and vendor lock-in: > I don't see any evidence of vendor lock-in after 20 years of use, but I do > see a risk because there is no authoritative and standard definition of > what is TACACS+. The IETF process is aimed to address this and I don't > think calling out current proprietary status is an argument against > considering the proposal, but rather an argument to work on a proposal. > > The IETF process should ensure that proprietary monicker is removed after > all conditions are met. Proprietary protocol probably isn't evil by itself, > but is made evil by the fact that even the original author cannot be held > accountable if it changes it or ignores it. This effort aims to address > that as well and is an argument to work on the proposal, not throwing it > out. > > Current state of IPR for any TACACS+ implementor is unknown. The IETF > process must and will ensure that all IPR will be ultimately disclosed > which will take away a lot of stress an unknowns from both vendors and > users. How can this ever be a wrong thing to do and how could it be bad if > IETF is the one forcing the issue? I again see this as an argument to work > on this within IETF and not reject all work on it. The IETF process is that each contributor must disclose any known IPR - "all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion." [BCP0079] except that I know that US legal liability makes companies there keep their staff in ignorance of such IPR so what I expect, and do not yet see, is a disclosure from the company in question. That can and does make a difference to the decisions of the IETF. Tom Petch > > -- > -- > Andrej Ota > > Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland > Registered in Dublin, Ireland - Registration # 368047 > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
