Wed, Jun 29, 2022 at 03:48:30PM +0000, Joe Clarke (jclarke): > Thanks for taking on this work and to Alan for the initial round of comments. > I've read this draft, and below are my comments as a contributor/individual.
Hey, Thanks for reviewing. I'll make the suggested updates which I've removed from your message. > 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? > 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? > 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. Thanks _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
