skip to content

What does an '=' separator in a TACACS+ authorization argument oblige the network device to do that '*' does not?

level: seniorimportance: should knowfreq 33%

answer

  1. one character decides the contract
  2. equals is a condition, star is advice
  3. first separator wins, rest is value
  4. unknown mandatory name means deny
  5. mixed software ages turn this into outages

basics

~20 s

'=' marks the pair mandatory and '*' marks it optional. A device that receives a mandatory argument it cannot handle MUST evaluate the whole response as though the status were FAIL, so one unrecognised mandatory name turns an approval into a denial.

solid answer

~40 s

Each argument is a single string holding a name and a value joined by one separator: `=` (0x3D) makes the pair **mandatory**, `*` (0x2A) makes it **optional**, and an optional pair may be disregarded by either side. The obligation is the interesting half: if a device receives a mandatory argument it cannot handle, it MUST evaluate the response as though it were `TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10` — a pass carrying one unknown mandatory name becomes a refusal. That is the price of the protocol's extensibility: both ends must already agree on the meaning of every name they exchange, so introducing a new mandatory argument across a mixed fleet denies commands on whatever cannot parse it.

code

pseudocode · 9 lines
pseudocode
function split_argument(s):
  for each index i in s:
    if s[i] == '=' : return (name = s[0..i-1], value = s[i+1..], mandatory = true)
    if s[i] == '*' : return (name = s[0..i-1], value = s[i+1..], mandatory = false)
  reject s                       # no separator: not a well-formed argument

# "cmd="          -> name "cmd",      value "",       mandatory
# "idletime*10"   -> name "idletime", value "10",     optional
# "autocmd=a*b"   -> name "autocmd",  value "a*b",    mandatory

go deeper

for a junior

Remember that the separator carries meaning: = mandatory, * optional, and the name is everything before the first one.

for a middle

Explain the parsing rule and the length bounds, and why a value may contain a separator while a name may not.

for a senior

Show the operational consequence: a mandatory argument the device cannot handle forces the whole response to be treated as FAIL, and a mixed-software fleet feels that as selective denials.

for a principal

Treat every mandatory argument as a fleet-wide vocabulary commitment, and stage its introduction as optional before it becomes a condition.

## One string, one separator An authorization argument is not a structure. It is a single text string in which the name comes first, then one separator character, then the value: - **`=` (0x3D)** — the argument is **mandatory**. - **`*` (0x2A)** — the argument is **optional**, and may be disregarded by either the device or the server. The parsing rule is strict and worth stating exactly: **parsing stops at the first occurrence of either separator**. An argument **name MUST NOT contain either separator character**; a **value MAY** contain them. So `idletime*10` is the optional argument `idletime` with value `10`, and a string whose value happens to contain a `*` after an earlier `=` is still a mandatory argument whose value carries a literal asterisk. Read the first separator and stop; everything after it is value. ## Lengths and empty values - The **maximum** length of one argument-value string is **255 characters**; the **minimum** is two. - The strings are **not null-terminated** — the packet's length fields say where each one ends. - A value **may be empty**. The argument `cmd` with no value travels as the four characters `cmd=`, which is a well-formed mandatory argument and a meaningful request rather than a malformed one. ## The obligation that makes '=' expensive Mandatory does not mean *important*; it means **both sides must understand it or the answer collapses**. A device that receives a mandatory argument it cannot handle MUST evaluate the response as though it were `TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10`. The status the server actually sent is irrelevant at that point — a PASS_ADD carrying one unrecognised mandatory name denies the command just as firmly as an explicit refusal. This is a deliberate fail-closed choice. A device that quietly dropped a mandatory argument would be running a command under conditions the policy did not sanction, and the specification would rather the command not run. The cost is that a mandatory argument is a contract, not a hint. ## What this means for an estate The failure mode is a slow one, and it is the reason the rule is a senior question. Consider a broadcaster's contribution-circuit routers, bought over several years and running a range of device software: 1. Someone adds a new mandatory argument to the device-admin server's shell policy — a parameter the newest boxes understand. 2. The newest routers apply it and nothing looks wrong. 3. The older routers cannot handle the name, so each one evaluates every affected reply as FAIL. 4. What the operators report is not "a parse error" but "I am denied on the older circuits", and the server's own view is that it passed them. The diagnosis is to compare a reply the device accepted with one it refused and look for a name the older software does not know. The fix is either to send the argument optionally, with `*`, so a device that does not know it may disregard it, or to hold the change until every device understands the name. ## Why optional is not simply weaker Optional is the right marking whenever the argument is advice rather than a condition — something the sender would like applied but will accept being dropped. Because **either** side may disregard an optional pair, an argument sent optionally cannot be relied on to have taken effect, which is exactly the trade. Mandatory buys certainty about what the other end did and pays for it with a hard dependency on shared vocabulary; optional buys interoperability across mixed software and pays for it with a parameter that may simply not be in force. ## The line to say out loud "The separator is not punctuation, it is a contract term." One character decides whether an unknown name is ignored or turns the whole reply into a denial, and that is the whole extensibility story of the argument-value scheme in a sentence.

  • How is the argument string `autocmd=a*b` parsed?
    As the mandatory argument `autocmd` with the value `a*b`. Parsing stops at the first separator, which is the `=`, and the `*` after it is an ordinary character in the value. A name may never contain a separator, but a value may.
  • A server sends PASS_ADD with one mandatory argument the device does not know. What runs?
    Nothing. The device MUST evaluate the response as though the status had been `TAC_PLUS_AUTHOR_STATUS_FAIL := 0x10`, so the command is refused despite the server having passed it. The device's log will show a denial the server's log will not.
  • How do you introduce a new argument across a fleet of mixed device software?
    Send it optionally, with `*`, so any device that cannot handle the name may disregard it and the reply still passes. Accept that it may not be in force everywhere, and only move it to `=` once every device understands it.

saying these in an interview costs you the question

  • Treats '=' and '*' as interchangeable punctuation
  • Says parsing splits on the last separator in the string
  • Claims an argument name may contain a separator character
  • Thinks an unknown mandatory argument is simply skipped
  • Says an empty argument value makes the packet malformed