In TACACS+, what does one session cover, and what transport connection carries it?
answer
- narrower than the connection
- one exchange, not one login
- the network device is the client
- session_id names it, TCP port 49 carries it
- only authentication runs to many packets
basics
~20 sA TACACS+ session is one authentication sequence, one authorization exchange or one accounting exchange, named by session_id in the header. It travels over a TCP connection to port 49 that the network device opens to the device-administration server.
solid answer
~50 sIn TACACS+ the client is the network device itself — the box an engineer is logging in to — and it opens a TCP connection to the device-administration server on `TCP port 49`. A session is narrower than that connection: RFC 8907 defines it as one authentication sequence, one authorization exchange or one accounting exchange, and the 4-octet `session_id` in the 12-byte header names it for its whole life. Because authentication, authorization and accounting are separate exchanges in TACACS+, one engineer's login can produce several sessions, each with its own `session_id`. By default a connection carries exactly one session and the server closes it when that session ends, unless the two ends negotiated single connection mode. Authorization and accounting sessions are always one request and one reply; only an authentication sequence runs to many packets.
go deeper
Recall the shape: the network device is the client, it opens TCP to port 49, and one session is one exchange named by session_id.
Explain why one login produces several sessions, and which of the three kinds can run past two packets. Name the field that groups packets into a session.
Show that you have watched this on a fabric: the default of one session per connection is what makes device-admin AAA a connection-heavy workload, and single connection mode is the protocol's own answer.
Frame the tradeoff the design makes: a disposable transport per exchange is stateless and simple to implement, and it buys that simplicity with connection churn that the estate pays for at scale.
## Three words that are not the same thing On a device running TACACS+, three different things get called "the session", and an interviewer is usually checking whether you can keep them apart. - **The TACACS+ session** — the protocol object. RFC 8907 defines it as *one authentication sequence, one authorization exchange, or one accounting exchange*. It is named by the 4-octet `session_id` field in the 12-byte header, which is chosen when the session starts and does not change while it lives. - **The TCP connection** — the transport underneath. It is opened by the network device to `TCP port 49` on the device-administration server. By default it carries exactly one TACACS+ session; in single connection mode it can carry many, one after another. - **The operator's shell session on the device** — the human-facing thing, the terminal line an engineer is typing on. It has no protocol field at all and may outlive dozens of TACACS+ sessions. A sentence like "the session ended" is ambiguous until you say which of the three closed. ## Who is the client This is the reversal candidates most often get wrong. In TACACS+ the **client is the network device** — RFC 8907 calls it any device that initiates TACACS+ protocol requests. The human at the keyboard is not the client, and neither is any piece of software on a laptop. The device collects what the engineer types, wraps it in TACACS+ packets and asks the device-administration server; the server answers; the device enforces the answer. Everything on the wire is between those two machines. That is why the protocol's vocabulary reads oddly at first: the "client" is a switch, and the "user" appears only as a field inside a body the client sends. ## What one login actually produces Because TACACS+ keeps the three AAA functions in separate exchanges, a single engineer's visit to one device typically produces a run of sessions: 1. An **authentication** session when the engineer logs in. This is the only kind that can run to an arbitrary number of packets, because the server may keep asking for more input. 2. An **authorization** session for what the engineer is allowed to do, and, where the device is configured that way, another one for each command typed. Each is exactly one request and one reply. 3. An **accounting** session that records what happened. Again, exactly one request and one reply. Each of those carries its own `session_id`. Nothing in the protocol ties them together into one "login" object; correlation is done by the server from what the bodies carry. ## Session against connection, side by side | | TACACS+ session | TCP connection | Shell session on the device | |---|---|---|---| | Named by | `session_id` in the header | the TCP four-tuple | nothing on the wire | | Opened by | the network device | the network device | the engineer logging in | | Covers | one authentication sequence, one authorization exchange or one accounting exchange | one session by default, many in single connection mode | the whole visit | | Ends when | the exchange finishes | the session ends, or either end closes it | the engineer logs out | ## Why the default is one session per connection The original design made the transport disposable: open a connection, run one exchange, close it. That is simple and it keeps no state between exchanges, but on a fabric of several hundred devices where every command produces an authorization and an accounting exchange, it means a great many short-lived connections. The protocol's own answer is **single connection mode**, negotiated with a flag in the header of the first packet, which lets the two ends agree to keep the connection open and multiplex later sessions onto it. Without that agreement the server closes the connection at the end of the first session. ## What to say in an interview Lead with the definition — one exchange, not one login — then name the carrier: TCP, port 49, opened by the device. Adding that authorization and accounting are always a single request/reply pair while authentication may run long shows you know the asymmetry rather than a memorised list, and it sets up every follow-up about sequence numbers and connection reuse.
- Does a session_id change while the session runs, and where does its value come from?It does not change: the value is fixed for the life of the session and every packet of that session carries it. RFC 8907 requires it to be generated by a cryptographically strong random method, citing RFC 4086, and a new session gets a freshly generated value rather than the next number in a sequence.
- If a connection carries only one session by default, what ends the connection?The end of that session. Unless single connection mode was established on the first two packets, the server closes the connection when the single session it carried finishes. Either end may also close earlier, and a connection-level ERROR — a mismatched shared secret, for instance — means no further new sessions may be accepted on that connection.
The connection is the phone call and the session is one item of business on it. By default the call ends when the business does, and only by explicit agreement do both parties stay on the line for the next item.
saying these in an interview costs you the question
- Thinking the human operator is the TACACS+ client
- Assuming one login is one session from start to logout
- Believing TACACS+ runs over UDP like its network-access counterpart
- Calling the engineer's shell on the device the TACACS+ session
- Expecting the connection to stay open between commands by default