Port 153: SGMP — The Protocol That Was Never Meant to Last

Port 153 carries the Simple Gateway Monitoring Protocol (SGMP), a network management protocol published in November 1987. SGMP lets a management station ask a gateway (router) what it knows: how many packets have passed through, which interfaces are up, what errors have occurred. It is one of the earliest standardized attempts to give humans visibility into what machines are doing.

SGMP is obsolete. It has been for decades. But what it became is not.

What SGMP Does

SGMP operates on a simple manager-agent model. A management station sends requests to an agent process running on a gateway. The agent responds. Four message types, and that is the entire protocol¹:

• Get Request: Ask for the value of a variable (interface status, packet counts, uptime)
• Get Response: The agent answers
• Set Request: Change a configuration parameter on the gateway (optional, and rarely implemented)
• Trap: The agent sends an unsolicited alert when something happens (a link goes down, authentication fails, a neighbor disappears)

The protocol runs over UDP. No sessions. No guaranteed delivery. No encryption. Every password transmitted in plaintext. The authors knew all of this. They designed it this way on purpose, because the routers of 1987 had kilobytes of RAM, not megabytes, and simplicity was the only thing that would actually get deployed.

All management functions are modeled as reading or writing variables. There are no imperative commands, no "reboot" or "flush cache" operations. If you want a gateway to do something, you change a variable that makes it do the thing. This design choice, controversial at the time, became the philosophical foundation of SNMP.

The Story Behind Port 153

In the mid-1980s, the Internet was growing fast enough to become unmanageable but not fast enough for anyone to have proper tools. Network engineers at regional networks like NYSERNET (New York) and SURAnet (Southeastern Universities) were flying blind. When a router went down, the first indication was often a phone call from an angry user. Diagnosing problems meant logging into individual machines one at a time, if you could reach them at all.

Four people decided this was unacceptable: James Davin at Proteon, Jeffrey Case at the University of Tennessee, Mark Fedor at Cornell, and Martin Schoffstall at Rensselaer Polytechnic Institute¹. They wrote SGMP not as a grand vision for network management but as a practical tool they needed right now, today, to keep their networks running.

RFC 1028 is remarkably honest about its own limitations. The authors explicitly state that SGMP is "only an interim response to immediate gateway monitoring needs" and that "long term use of the mechanisms described here should be seriously questioned."¹ They were building a bridge, and they labeled it as one.

The San Diego Decision

By the end of 1987, three competing network management proposals had gained enough traction that the Internet community had to choose, or face a future of incompatible tools²:

1. HEMS (High-Level Entity Management System), technically superior, with experimental implementations and backing from Cisco
2. SGMP, simple and already running on production networks
3. CMIS/CMIP, the ISO standard, voluminously documented but with almost no implementations

On February 29, 1988, at the San Diego Supercomputer Center, the Internet Activities Board convened to decide². Craig Partridge, one of the HEMS architects, made what RFC 1052 calls "a dramatic act of statesmanship": he volunteered to withdraw HEMS entirely if it would end the deadlock.

The committee chose a two-track approach. In the short term, SGMP (renamed to SNMP, the Simple Network Management Protocol) would be adopted immediately because it was already working. In the long term, the community would develop CMIS/CMIP as the "real" solution².

The long term never arrived. SNMP won completely. CMIS/CMIP, despite the backing of ISO and government mandates, could not overcome SNMP's head start of simplicity and actual deployment. By 1988, Cisco, ACC, and Proteon had SNMP products shipping³. The protocol that was supposed to be temporary became permanent. The protocol that was supposed to be permanent was forgotten.

The Same Four Authors

Here is the part that matters most: the four people who wrote SGMP on port 153 are the same four people who wrote SNMP³. Case, Davin, Fedor, and Schoffstall took everything they learned from their "interim" protocol and built its successor. SNMP kept SGMP's core philosophy (manage by variables, not commands; keep it simple enough to actually implement) but added a structured Management Information Base, extensible data types, and broader vendor support.

SNMP now manages virtually every networked device on Earth. Every router, every switch, every server with a management agent. When your ISP's network operations center sees a red dot on a map, that is SNMP. When a monitoring system pages an engineer at 3 AM because a link went down, that notification chain started with SNMP.

And SNMP started here, on port 153, as SGMP.

Protocol Details

Security

SGMP has no security to speak of. Community strings (effectively passwords) are transmitted in cleartext. There is no encryption, no integrity checking, no access control beyond the community string. This was a known limitation in 1987 and remains one of the reasons SGMP should never be used on any production network today.

Even SNMP struggled with security for decades. SNMPv1 and v2c inherited the community string model directly from SGMP. It was not until SNMPv3 that proper authentication and encryption arrived, and adoption of v3 has been painfully slow.

If you see traffic on port 153, investigate. No legitimate modern system should be using SGMP.

How to Check What Is Listening on Port 153

# macOS / Linux
sudo lsof -i :153
netstat -an | grep 153

# Windows
netstat -an | findstr 153

# Scan a remote host
nmap -p 153 <host>

Related Ports