skip to content

A TACACS+ authentication session reaches seq_no 255 — what must happen, and why can the number not wrap?

level: seniorimportance: nice to knowfreq 20%

answer

  1. one octet, so 255 is the ceiling
  2. terminate rather than roll over
  3. restart at 1 with a new name
  4. nothing else orders the packets
  5. only an authentication sequence gets near it

basics

~20 s

The session must terminate and be restarted with a sequence number of 1. seq_no is a single octet and the specification forbids it from wrapping, because the number and its parity are the only things that place a packet in its session.

solid answer

~50 s

`seq_no` is one octet of the 12-byte header. The first packet of a session is 1, the client sends only odd values and the server only even ones, and the number must never wrap: if `2^8-1` is reached, that session must terminate and be restarted with a sequence number of 1 — a fresh session, with a freshly generated `session_id`. The rule exists because nothing else orders a session's packets. There is no second counter and no epoch field, so a value of 3 after a wrap would be indistinguishable from the real third packet and the parity rule that identifies the sender would still hold, making the confusion silent. In practice only an authentication sequence can approach the limit, because authorization and accounting exchanges are a single request and reply and never go past 2.

code

pseudocode · 14 lines
pseudocode
on sending a packet in session S:

  if S has sent nothing yet
     then next := 1              # the first packet of a session is always 1
     else next := S.last_sent + 2  # each end steps its own value by two

  if next >= 255                 # 2^8-1 reached: seq_no must never wrap
     then terminate S
          open a new session with a freshly generated session_id
          send its first packet with seq_no := 1
     else send packet with seq_no := next

# parity follows from the rule above:
#   the client's values are odd, the server's are even

go deeper

for a junior

Know that seq_no is one octet, starts at 1 in every session, and that the client's values are odd while the server's are even.

for a middle

Explain the no-wrap rule and what a restart actually means: the session ends and a new one begins at 1 with a new session_id.

for a senior

Read it as a symptom. A session climbing towards the limit means a loop, and a capture can show it from the header alone, sorted by session_id with the highest seq_no per session.

for a principal

Note the design choice: rather than adding an epoch field to survive a wrap, the protocol forbids the wrap and pays with a terminated session, keeping receivers trivial at the cost of an abrupt failure mode.

## The field, and the two rules on it `seq_no` is the third octet of the TACACS+ header. Two rules govern it and they are easy to state: - **The first packet of a session is 1**, the client's packets carry odd numbers and the server's carry even ones. Each end therefore steps its own value by two. - **The number must never wrap.** If `2^8-1` — 255 — is reached, that session must terminate and be restarted with a sequence number of 1. Restarting means a genuinely new session: a freshly generated `session_id` and a new first packet numbered 1. It does not mean the counter rolls over inside the same session. ## Why wrapping is forbidden rather than handled A one-octet counter that wrapped would be perfectly parseable, which is the problem. Consider what the receiver would have to do with it: - Nothing else in the header orders packets. There is no epoch, no generation counter and no second sequence field to disambiguate a repeat. - The parity rule would still hold after a wrap, so a wrapped packet from the client would still look like a legitimate client packet. - `session_id` does not change during a session, so it cannot be used to distinguish the first pass from the second. The failure would therefore be **silent**: a receiver could not tell packet 3 from packet 259, and neither end could prove which one it was answering. Terminating the session is the cheap alternative — the exchange has already gone badly wrong by that point, and forcing a restart is unambiguous for both ends. ## Only one kind of session can get there | Session kind | Packets in a normal exchange | Can it approach 255? | |---|---|---| | Authentication sequence | as many as the exchange needs | yes, in a pathological case | | Authorization exchange | one request, one reply | no — it ends at 2 | | Accounting exchange | one request, one reply | no — it ends at 2 | This is the asymmetry that makes the rule almost invisible in practice. Authorization and accounting are defined as single request/reply pairs, so their sequence numbers are 1 and 2 and that is the whole session. Only an authentication sequence, where the server may keep coming back for more input, has any route to a long packet count at all — and even there, a real exchange takes a handful of round trips, not a hundred and twenty-seven. ## What it means when you actually see it A session that approaches the limit is a symptom, not a design point. Something is looping: two ends that keep re-asking and re-answering without converging. Because the header is unprotected, this is one of the diagnoses a capture can make on its own — sort by `session_id`, look at the highest `seq_no` reached, and a session in the tens or hundreds of packets is visible immediately even though the bodies are not readable. The healthy signature is the opposite: very many sessions, each with a highest `seq_no` of 2, occasionally a handful more for a login. A single session climbing steadily is the outlier worth chasing. ## The related numbers, and getting them right Several small numbers cluster here and it is worth keeping them apart: - `seq_no` is **one octet**, so its ceiling is 255 and the rule is stated as `2^8-1`. - `session_id` is **four octets**, generated by a cryptographically strong random method rather than counted up, and constant for the session. - `length` is **four octets** and counts the body only, with RFC 8907 recommending a maximum packet size of 2^16 and requiring that a server's maximum accepted size be controllable. A candidate who says the session restarts "when the counter overflows" has the mechanism nearly right but the rule backwards: the specification's point is that overflow never happens, because the session ends first.

  • Why is the restart a new session rather than the same session continuing at 1?
    Because a session is named by its `session_id`, and reusing that name with a sequence number that has already been seen would be exactly the ambiguity the no-wrap rule exists to prevent. A restart generates a new `session_id`, so the old and new packet streams are distinguishable even if both are in a capture.
  • Could an authorization exchange ever reach a high sequence number?
    No. An authorization exchange is defined as a single request and a single reply, so its sequence numbers are 1 and 2. The same holds for accounting. Seeing either type carry a higher `seq_no` in a capture means an implementation is not following the specification, which is itself a finding.

saying these in an interview costs you the question

  • Saying the counter simply wraps back to zero and continues
  • Thinking sequence numbers are per connection rather than per session
  • Expecting an authorization exchange to run past two packets
  • Assuming the restarted session keeps its old session_id
  • Treating a session at high sequence numbers as normal behaviour