On Aug 30, 2022, at 3:48 PM, John Heasly <[email protected]> wrote: > It is not a new format, it is the format currently used in the > authorization and accounting parts of tacacs, except with no fixed > fields. AVPs are its own version of TLVs that have existed since the > beginning of tacacs, so that code has existed as long.
It's changing the existing format for authentication packets. So it's a change.. but to something which likely already has code support in TACACS+ implementations. > We are not eager to remove the fixed fields that exist or make any > drastic changes. Douglas assembled an example to ensure that we > understood by example what Alan's comment was about - existence of fixed > fields at all or that we'd originally proposed adding a fixed field (to > make Authen consistent with Author/Acct) or something else entirely. My concern was with adding a new header which was different from existing ones, and which used yet more fixed fields, >> Please consider RFC8949: CBOR. > > If you want the authentication part changed to CBOR or whatever the > flavour of the month is, then you also want authorization and accounting > to change? IE: you want a complete restructure of all of the packet > formats used in tacacs. > > I do not see how that is less likely to result in bugs in areas unrelated > to (de)serialization and will impede implementation. There is no good solution here. There are strong reasons to just "patch" existing implementations with minimal changes. That enables quick implementation and deployment. There are also strong reasons to use a modern format which has extensive implementations: https://cbor.io/impls.html If we stick with the current TACACS+ format, then we still need to serialize / deserialize the data. There are likely issues related to encoding binary data in textual format. And perhaps multiple representation formats of the same data. If there is an argument against CBOR, it would be "CBOR doesn't match what we need to do in TACACS+". As reference, the CBOR data types are: • an integer in the range -264..264-1 inclusive • a simple value, identified by a number between 0 and 255, but distinct from that number itself • a floating-point value, distinct from an integer, out of the set representable by IEEE 754 binary64 (including non-finites) [IEEE754] • a sequence of zero or more bytes ("byte string") • a sequence of zero or more Unicode code points ("text string") • a sequence of zero or more data items ("array") • a mapping (mathematical function) from zero or more data items ("keys") each to a data item ("values"), ("map") • a tagged data item ("tag"), comprising a tag number (an integer in the range 0..264-1) and the tag content (a data item) Does this meet the expected use-case? As an implementor, I can sympathize with the approach of "minimal changes". But 15 years of minimal changes can result in a horrible mess. There's also a good argument for saying "Look, we're going to do a bunch of stuff with TACACS+, so we might as well fix it now". Using a standard format such as CBOR means that the initial cost to implementations is large. But any further extensions are likely to be trivial. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
