Port 120: CFDPTKT — The Ticket Window for a Forgotten Broadcast

Port 120 carries a service called CFDPTKT. If you've never heard of it, that's expected. Most people haven't. But behind this obscure five-letter abbreviation is a genuinely clever idea from the early 1990s, a protocol designed to solve a very specific problem that most of us will never face again.

What Runs on Port 120

Port 120 is assigned to the CFDPTKT service, which stands for CFDP Ticket Server. It is the ticket-granting component of the Coherent File Distribution Protocol (CFDP), defined in RFC 1235¹ and published in June 1991.

The ticket server doesn't transfer files. It answers a simpler question: "I need this file. Where do I get it, and how big is it?" The server responds with a 32-bit ticket, the file's size, the block size for transfer, and the IP address and port of the actual CFDP file server. That's it. A handshake. A receipt. A pointer to where the real action happens.

Port 120 is a well-known port, meaning it falls within the 0-1023 range reserved by IANA for system-level services. These ports require elevated privileges to bind to on most operating systems, a convention that dates back to the earliest days of Unix networking.

How the Protocol Works

CFDP was built around one insight: if ten machines all need the same file at the same time, sending it ten times is wasteful. Send it once, over broadcast, and let everyone listen.²

Here's the sequence:

1. A client contacts the ticket server on UDP port 120 with a REQTKT (Request Ticket) packet containing a filename
2. The ticket server responds with a TIYT (This Is Your Ticket) packet: a ticket ID, file size, block size, and the address of the CFDP file server
3. The client contacts the CFDP server and requests the file using the ticket
4. The server broadcasts the file over the network
5. Any other client that needs the same file eavesdrops on the broadcast and grabs the data as it flies by
6. When the broadcast ends, any client that missed blocks sends a PARREQ (partial request) for just the missing pieces

The elegance is in step 5. If twenty machines boot at 8:00 AM and all need the same kernel image, the server sends it once. Every machine listens. The network load is the same whether one machine needs the file or a hundred.

The Story Behind It

John Ioannidis and Gerald Q. Maguire Jr. built CFDP at Columbia University's Department of Computer Science.³ Their original problem was very concrete: they had an experimental packet-radio network and a cluster of diskless workstations that needed to boot over that network every time they powered on.

Diskless workstations were common in the late 1980s and early 1990s. These machines had no local storage. Everything, the operating system, the applications, the configuration, came from the network at boot time. In a lab with dozens of these machines, morning boot was a traffic storm. Every machine would individually request the same files from the same server, flooding the network with redundant copies of identical data.

Ioannidis and Maguire recognized that the broadcast nature of their network (whether Ethernet, fiber, or packet radio) meant that every byte sent was already reaching every machine. The protocol just needed to be smart enough to let machines take advantage of that. Rather than each client having a private conversation with the server, they designed a system where the server announces files to the entire network and clients grab what they need from the broadcast.

The ticket server on port 120 was the front door of this system, a lightweight name-resolution and handshake service that could run on a different machine than the file server itself.

RFC 1235 was published as an Experimental protocol. It was never promoted to a standard. The problem it solved, booting diskless workstations over broadcast networks, faded as hard drives became cheap and ubiquitous. By the mid-1990s, most workstations had local storage, and the desperate need for coherent broadcast file transfer quietly disappeared.

Security Considerations

CFDP has no authentication, no encryption, and no access control beyond whatever the ticket server chooses to enforce. RFC 1235 explicitly acknowledges this, noting that the protocol was designed as a "back-end protocol" and that "a separate front-end is needed to handle naming and security issues."¹

Anyone on the broadcast network could eavesdrop on file transfers by design. That was the whole point. In a trusted lab environment at Columbia University in 1991, this was fine. On a modern network, this would be a significant security concern.

If you find something listening on port 120 today, investigate it carefully. No mainstream software uses this port. Unexpected listeners on well-known ports with no assigned modern service are worth scrutiny.

How to Check What's Listening on Port 120

On Linux:

sudo ss -tulnp | grep :120
sudo lsof -i :120

On macOS:

sudo lsof -i :120
netstat -an | grep '\.120 '

On Windows:

netstat -ano | findstr :120

If something is listening on port 120 and you didn't put it there, find out what process owns it. This port sees virtually no legitimate traffic in modern networks.

Why Unassigned Ports Still Matter

Port 120 isn't truly unassigned. It has an IANA registration. But the protocol it serves is effectively extinct. This is a common pattern in the well-known port range: names from the late 1980s and early 1990s that solved real problems for real people, then quietly went dormant as the problems themselves disappeared.

These ports still matter because they're reserved. The IANA registration means no new protocol will claim port 120 without going through a formal process. The reservation is a kind of historical marker, a record that someone once needed this number for something specific. The well-known port range is finite (only 1,024 ports), and every assignment, active or dormant, represents a moment when someone said "this problem is important enough to deserve a permanent address."