See below.
> Section 3.2 > > You make reference to the proper "TACACS+ Session", but there is no reference > either in your terminology section or to the T+ RFC. I feel a reference is > needed here. This is defined in rfc8907 S3.5 and S2 of the draft refers to 8907 S3. Is this not an acceptable way to do this? [JC] It struck me as warranting a 2.x sub-section. > Section 4 > > "The TACACS+ server or client receiving TACACS+ Packets MUST process > the packet as if TAC_PLUS_UNENCRYPTED_FLAG was set. The actual value > of TAC_PLUS_UNENCRYPTED_FLAG flag in the TACACS+ header MUST be > ignored." > > But what if the flag isn’t set and obfuscation is used? That’s an error, and > MUST result in the termination of the Session (at least that’s what I would > think). This should be clarified, The sections says that the flag MUST be ignored on receipt and SHOULD set on transmission. I will attempt to make it clearer. This seems like a common way to deprecate a flag. Do you still think that the unset flag on receipt should be an error? [JC] I personally do as it could be that obfuscation is being done and this will ultimately lead to the inability to process the PDU. That said, I’m more in favor of a strong obsolescence of the obfuscation. > Overall, I think this document warrants an Operators Considerations section > to describe interoperability with legacy T+. That is, thoughts around > configuring a fallback legacy T+ server along side a tacacss server (or > servers); thoughts on migrating from a shared key to certificate-based > validation; etc. > > You address some of this in different parts of the document where you talk > about PSKs, mixing legacy and tacacss on a single server, and the need to > provide some port flexibility, but I think a centralized section might help > bring focus to those migrating to this. Sure, completely reasonable. But I don't want to expend that effort unless this will be adopted. Seems like that could lead to quite a bit of rearrangement. > Additionally, if there are working or PoC implementations of this, some > lessons learned (perhaps in an appendix) could be useful. There are none that I know of. I would not make that effort unless there is adoption or at least a commitment to adopt the draft. [JC] As chair, I will call for adoption of this work by the WG. I read Alan’s recent reply and understand how he feels concerning this approach to more of a straight TLS encap around T+. I would like to hear what others in the WG think.</chair> Joe
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
