Summary
- RFC 2012 made
tcpConnStatea read-write object. A management station could set onlydeleteTCB(12), which deleted the selected connection’s Transmission Control Block and immediately terminated the local connection. - The table identified a connection by local and remote IPv4 addresses and ports, while engine counters summarized opens, failures, resets and segments. Neither the row nor the counters recorded a complete chain from operator identity and authorization to application and service outcome.
- RFC 4022 retained the deletion action, separated listeners from connections, added address types and process identifiers, made write support optional for conformance, and explicitly warned that unauthorized writes could terminate arbitrary connections.
The row crossed the line from description to action
Most of RFC 2012 looks like instrumentation. It exposes the retransmission algorithm and timeout bounds, the current number of established or close-wait connections, and counters for opens, failed attempts, resets, received segments, retransmissions, errors and outgoing resets. The connection table then supplies a more exact view: local address and port, remote address and port, and current TCP state.
But tcpConnState was not merely a status cell. Its MAX-ACCESS was read-write. Ordinary state values could not be written by a manager; the only permitted management value was deleteTCB(12). The specified effect was unusually direct: delete the corresponding TCB on the managed node and terminate the connection immediately. The agent could optionally send a reset segment to the peer, but the document warned that resets are not delivered reliably.
That distinction matters. Local deletion is the defined act. Peer notification is optional. Delivery of that notification is uncertain. What the remote application sees, whether it retries, and whether a user-visible service is interrupted are later events. A successful SET response cannot compress them into one fact.
Deleting the TCB removes more than a label
RFC 793 described the Transmission Control Block as the record in which TCP remembers a connection: local and remote socket numbers, security and precedence, pointers to send and receive buffers, the retransmission queue and current segment, and send and receive sequence variables. It called CLOSED a fictional state because, when no TCB exists, no connection exists.
The management operation therefore did not edit a dashboard label. It removed the local protocol state that made this particular connection possible. Yet the row’s identity was still only a four-tuple of IPv4 addresses and ports. The row was transient, and RFC 2012 did not add an action identifier, request reason, ticket, initiating principal, application owner or durable before-and-after receipt.
The mechanism was inherited rather than invented in 1996. RFC 1213 had already changed tcpConnState to read-write in 1991 specifically to support deletion of a connection’s TCB. RFC 2012 carried the same objects into SMIv2. Its introduction said that authentication, authorization, access control and privacy belonged to the administrative framework; its own Security Considerations section simply said that security issues were not discussed.
Counters could show movement without proving cause
After a deletion, an operator might see the current established gauge fall, an established-reset counter rise, or an outgoing-reset counter change. None is a management-action ledger. tcpEstabResets counts particular state transitions to CLOSED, regardless of why they occurred. tcpOutRsts counts segments bearing RST, not reliably delivered notices and not operator intentions. tcpCurrEstab is only a current gauge.
Attribution therefore needs a join that the MIB does not supply: the exact row observed, the authenticated request, the security context and write decision, the agent’s acceptance, the disappearance of local state, the application’s reaction, the peer’s observation, the retry path, the interruption duration and the service consequence. Without that chain, a counter change can be consistent with a management deletion without proving one.
RFC 4022 widened identity and narrowed the promise
The 2005 successor did not remove the switch. tcpConnectionState still accepted deleteTCB(12) and still specified immediate local termination with optional, unreliable RST. It did, however, redraw the surrounding evidence surface.
RFC 4022 deprecated the old table because it was IPv4-only and mixed listeners with connections. The new connection index paired local and remote address types with addresses and ports. A separate listener table distinguished wildcard, one-family and specific-address listeners. Connection and listener rows could report an operating-system process identifier, allowing correlation with host-resource or application MIBs.
Those fields improve the question “which socket and which process?” They do not answer “which human approved this, under which operational reason, and what did customers experience?” A process identifier can be zero, reused or meaningful only inside one host. An address type and zone can disambiguate a row without supplying a durable action history.
RFC 4022 also made an important conformance distinction: write access to tcpConnectionState, and support for deleteTCB(12), were not required. The object model could describe the actuator even when a compliant implementation exposed only observation. Schema, implemented capability, granted authority and executed action must therefore be tested separately.
Its security section finally named the operational risk: unauthorized access to the writable state objects could terminate an arbitrary connection and cause denial of service. It also treated readable connection, listener and process data as potentially sensitive.
Later security models filled only part of the receipt
SNMPv3 supplied stronger pieces. RFC 3414 could authenticate a user on whose behalf a message was sent, protect integrity and timeliness, and optionally protect confidentiality. RFC 3415 could decide access from the security model, security name, security level, context, read-or-write view and exact object instance.
These controls can establish much more than RFC 2012’s row alone. They can separate a reader from a writer and narrow the writer’s view. But RFC 3414 also cautions that it authenticates the user on whose behalf a message originated, not necessarily a specific human originator. Neither security model supplies the change ticket, the business reason, application acknowledgement, peer receipt, user impact or recovery duration.
The historical lesson is not that remote connection deletion was inherently mistaken. Operators may need an emergency actuator. It is that an actuator placed inside an observation table creates a duty to preserve the boundary between seeing, being allowed to act, acting and proving the result. Running code experiences the deletion; a green management response describes only one stage of it.
Sources
- RFC Editor record for RFC 2012
- RFC 2012 — SNMPv2 MIB for TCP
- RFC 2012 errata search
- RFC 1213 — MIB-II
- RFC 793 — Transmission Control Protocol
- RFC 4022 — Management Information Base for TCP
- RFC 4001 — Internet network address conventions
- RFC 3414 — SNMPv3 User-based Security Model
- RFC 3415 — SNMPv3 View-based Access Control Model
- Running-Code Primacy
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- On Why BTW.Media Exists
Evidence limits
The sources establish specification text, document lineage, object syntax, conformance options and security-model semantics. They do not establish that any vendor implemented writable state, that an operator used it, that an outage occurred, how often the feature was deployed, or what any current service-level target requires.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
