Port 163: CMIP/TCP Manager — The Protocol That Was Supposed to Win

Port 163 is assigned to CMIP/TCP Manager, the manager-side endpoint for the Common Management Information Protocol running over TCP/IP. Its sibling, port 164, handles the agent side. Together they were supposed to become the standard way every device on the Internet reported its health, accepted commands, and communicated its state to the humans watching over it.

That never happened. Port 163 is one of the quietest well-known ports on the Internet, a door that was built, numbered, and labeled, but that almost no one ever walked through.

What CMIP Was Supposed to Do

Network management is the art of watching machines. Knowing when a router is overloaded, when a link is failing, when a disk is full. In the late 1980s, two protocols were being designed to solve this problem: SNMP (Simple Network Management Protocol), built by the Internet community, and CMIP (Common Management Information Protocol), built by the OSI committees.¹

CMIP was the ambitious one. Where SNMP could only GET a value, SET a value, or receive a TRAP notification, CMIP could do all of that plus CREATE managed objects, DELETE them, and define arbitrary ACTIONS.² It had built-in security with authorization, access control, and audit logs. It could scope and filter operations across entire subtrees of managed objects in a single command. It modeled the network as a rich object hierarchy using GDMO (Guidelines for the Definition of Managed Objects), where objects could inherit properties from parent classes.

On paper, CMIP was superior in every way that mattered.

How It Works

CMIP operates on a manager-agent model. The manager (port 163) sends requests. The agent (port 164) responds with information about the devices it oversees.

The protocol runs on top of two OSI application-layer protocols: ACSE (Association Control Service Element) for managing connections between manager and agent, and ROSE (Remote Operations Service Element) for the actual data exchange.³ This is already a hint at why CMIP struggled: it assumed the full seven-layer OSI stack was available underneath it.

To make CMIP work in a TCP/IP world, the IETF's OSI Internet Management working group created CMOT (CMIP Over TCP/IP), first specified in RFC 1095 in April 1989.⁴ CMOT introduced a Lightweight Presentation Protocol (LPP) to provide the presentation services that CMIP expected, wedged on top of TCP and UDP. RFC 1189 revised the specification in October 1990, updating it to align with the final International Standards for CMIS/CMIP rather than the earlier drafts.⁵

Port 163 was assigned for CMOT's manager role. Port 164 for its agent role. The infrastructure was ready.

The Protocol Wars

The story of port 163 is inseparable from the Protocol Wars, the decades-long conflict between the OSI model and the TCP/IP Internet over which architecture would run the world's networks.⁶

The OSI community, backed by European telephone monopolies, most governments, and the ITU, believed protocols should be designed by committee to be comprehensive from the start. The Internet community believed in shipping something simple that worked and iterating from there. These weren't just technical disagreements. They were philosophical ones about how systems should be built.

SNMP and CMIP embodied this split perfectly. SNMP was intentionally simple. Its creators at the IETF designed it to run on devices with limited memory and processing power, the actual routers and switches that were building the early Internet. CMIP required significantly more resources from every device that implemented it: more memory, more CPU, more network bandwidth.

Here is the part that stings: SNMP was designed as a temporary solution. The Internet Activities Board explicitly stated that both SNMP and CMOT had equal status as "Draft Standard" and "Recommended."⁴ The plan was to use SNMP in the short term while CMIP matured, then transition the Internet to CMIP for the long term.

The transition never came.

Why CMIP Lost

TCP/IP vendors implemented SNMP because it was easy. Once SNMP was on every device, every network management system had to support SNMP. Once every management system supported SNMP, there was no reason for vendors to also implement CMIP. The network effect locked in the simpler protocol.⁷

CMIP's technical superiority became irrelevant. It didn't matter that CMIP could create and delete managed objects remotely, or that its security model was years ahead of SNMPv1's nonexistent authentication. What mattered was that SNMP agents could run on a router with 64KB of RAM, and CMIP agents could not.

CMIP found a home in telecommunications, where the Telecommunications Management Network (TMN) adopted it for managing telephone infrastructure.¹ Telecom operators had the resources and the need for CMIP's power. But on the broader Internet, port 163 went quiet.

Security

Port 163 is not a significant security concern on modern networks because almost nothing listens on it. If you find port 163 open on a machine, it warrants investigation, not because of CMIP vulnerabilities, but because anything unexpected listening on a well-known port deserves attention.

Ironically, CMIP itself had better security than the protocol that replaced it. SNMPv1 transmitted its "community strings" (effectively passwords) in plaintext. It took until SNMPv3, published in 2004, for SNMP to get authentication and encryption capabilities that CMIP had specified from the beginning.²

How to Check What Is Listening on Port 163

On most systems, you can check whether anything is bound to port 163:

# Linux
sudo ss -tlnp | grep :163

# macOS
sudo lsof -i :163

# Windows
netstat -an | findstr :163

On virtually every machine you will check, nothing will be there.

Related Ports