Port 102: ISO-TSAP — The Bridge Between Two Protocol Worlds

What Port 102 Does

Port 102 carries ISO Transport Service Access Point (ISO-TSAP) Class 0 traffic over TCP. When a Siemens programmable logic controller talks to the engineering software that programs it, that conversation travels through port 102. When a SCADA system reads sensor data from a factory floor, when a power grid controller checks the status of a substation, when an industrial process needs to report its state to a human operator, port 102 is often the channel.

The protocol running on this port is called TPKT (Transport Packet), defined in RFC 1006.¹ It wraps ISO transport protocol data units inside TCP segments, allowing systems that speak the OSI language to communicate over TCP/IP networks. The service name registered with IANA is iso-tsap.

The Protocol Wars

To understand why port 102 exists, you need to understand the war it was built to survive.

In the 1980s, the networking world was split between two competing visions. On one side: TCP/IP, the scrappy protocol suite born from ARPANET, favored by researchers and hackers who valued working code over committee consensus. On the other: OSI (Open Systems Interconnection), a seven-layer architecture backed by European telecom monopolies, the ISO, the ITU, and most of the world's governments.² The US Department of Commerce mandated OSI compliance. The Department of Defense planned to migrate away from TCP/IP entirely.

This was not a polite academic disagreement. This was the Protocol Wars, and the future of global networking was the prize.

Marshall T. Rose was one of the few engineers who stood in both camps. A protocol engineer at the Northrop Research and Technology Center in Southern California, Rose was simultaneously one of the Internet's most prolific contributors (he would author over 60 RFCs, including the SNMP standard that made TCP/IP networks manageable)³ and arguably the world's leading OSI implementer, having built ISODE, the ISO Development Environment.

Rose saw what others were too tribal to admit: the OSI upper layers (session, presentation, application) had real value, but the lower layers were a mess. Implementations were years behind. Meanwhile TCP/IP's transport layer worked right now, everywhere, reliably. His insight was simple and subversive: take the OSI protocols people want, and run them on the TCP infrastructure that actually exists.

The RFC

In April 1986, Rose and his colleague Dwight E. Cass published RFC 983, "ISO Transport Arrives on Top of the TCP."⁴ The title alone was a provocation. In May 1987, they released the updated RFC 1006, version 3 of the protocol, which reserved TCP port 102 for this purpose.¹

The trick was elegant. ISO Transport Class 0 (TP0) is the simplest ISO transport protocol. When you run it over a reliable connection like TCP, it provides the same guarantees as the much more complex Transport Class 4 (TP4). So Rose and Cass defined a thin wrapper, TPKT, that carries TP0 packets inside TCP connections. Every layer above transport, including all the session, presentation, and application protocols the OSI world had invested years building, runs without modification. They cannot tell the difference.

Port 102 became the meeting point between the two protocol worlds. A TSAP server listens on TCP port 102. When a client connects, the ISO transport protocol begins, and from that moment on, every layer above behaves as if it were running on a pure OSI stack.

The RFC is explicit about its purpose: "The primary motivation for the standard is to facilitate the process of gaining experience with higher-level ISO protocols." Rose and Cass were not trying to end the war. They were building a bridge so the work could continue regardless of who won.

TCP/IP won. But the bridge survived.

The Second Life: Industrial Control

Here is the strange turn in port 102's story. The OSI protocols that Rose and Cass were trying to incubate mostly faded away. X.400 email lost to SMTP. X.500 directories were eclipsed by LDAP. FTAM file transfer never gained traction against FTP. By the mid-1990s, the Protocol Wars were over and TCP/IP had won decisively.

But port 102 did not go quiet. It found an entirely different purpose.

Siemens, the German industrial giant, had built their SIMATIC S7 programmable logic controllers (PLCs) around the S7comm protocol, which communicates over ISO transport on port 102.⁵ These PLCs control factory assembly lines, power plants, water treatment facilities, chemical processing plants, and nuclear centrifuges. The S7-300, S7-400, S7-1200, and S7-1500 series all use port 102 as their primary communication channel.

When an engineer opens Siemens STEP 7 or TIA Portal software and connects to a PLC to upload new logic, that connection runs through port 102. When a SCADA system polls hundreds of PLCs for real-time process data, those queries flow through port 102. The protocol that was meant to be a temporary research bridge became permanent infrastructure for the systems that keep the physical world running.

Other industrial protocols joined it. IEC 61850 MMS (used in electrical substation automation) and ICCP (used for data exchange between utility control centers) also operate over port 102.

Stuxnet: When Port 102 Made History

In 2010, security researchers discovered Stuxnet, a computer worm of unprecedented sophistication. It was the world's first known cyberweapon, widely attributed to a joint operation by the United States and Israel.⁶

Stuxnet's target was Iran's Natanz uranium enrichment facility. Its payload was designed to destroy gas centrifuges by manipulating the Siemens S7-300 PLCs that controlled their variable-frequency drives. The worm first spread through Windows machines via four zero-day exploits, then sought out Siemens STEP 7 software. When it found it, Stuxnet used the S7comm protocol over port 102 to communicate with the PLCs, reprogram their logic, and manipulate centrifuge speeds.

The attack was precisely calibrated. Stuxnet would increase the centrifuge frequency to 1,410 Hz for 15 minutes, restore normal operation at 1,064 Hz for 27 days, then drop the frequency to 2 Hz for 50 minutes. This cycling between extremes caused the centrifuges to tear themselves apart. Meanwhile, the malware reported normal operating conditions to the plant operators. An estimated 1,000 centrifuges were destroyed, setting Iran's nuclear program back by at least two years.⁷

Port 102 carried the commands. The same protocol designed by Marshall Rose to help researchers experiment with OSI applications became the channel through which the first act of cyber-physical warfare was conducted.

Security

Port 102 was designed in 1986 for a research community that largely trusted its members. It has no built-in authentication, no encryption, and no integrity checking. The S7comm protocol layered on top is similarly unprotected: by default, anyone who can reach port 102 on a Siemens PLC can read and write its logic.

The vulnerabilities are severe and ongoing:

• CVE-2016-9159: An attacker with network access to port 102 can steal credentials from S7-300 and S7-400 PLCs.⁸
• CVE-2020-15782: A remote unauthenticated attacker can write arbitrary code to protected memory areas of S7-1200 and S7-1500 PLCs through port 102.
• CVE-2021-37185, CVE-2021-37204, CVE-2021-37205: Specially crafted packets sent to port 102 can crash S7-1200 and S7-1500 PLCs, even when Siemens' access protection and TLS encryption features are enabled.⁹
• CVE-2014-2256: A denial-of-service attack through port 102 can force S7-1200 PLCs into defect mode, requiring a cold restart to recover.

Siemens has introduced TLS-encrypted S7commPlus in newer firmware, but no firewall currently can parse the encrypted S7commPlus_TLS protocol, making deep packet inspection impossible. The recommended defense remains network segmentation: keep port 102 unreachable from anything that should not be programming your PLCs.

If port 102 is exposed to the Internet on an industrial system, that system is in immediate danger. This is not theoretical. Shodan and similar scanning services regularly discover S7 PLCs exposed on the public Internet.

How to Check What Is Listening on Port 102

# Linux
sudo ss -tlnp | grep :102
sudo netstat -tlnp | grep :102

# macOS
sudo lsof -iTCP:102 -sTCP:LISTEN

# Windows
netstat -an | findstr :102

# Scan a remote host
nmap -sV -p 102 <target-ip>

If you find something listening on port 102 and you are not running industrial control software, investigate immediately. On a standard workstation or server, nothing should be using this port.

Related Ports