Port 136: PROFILE — The Internet's First People Search

Port 136 carries the Profile Naming Service, a pioneering system designed in 1988 to solve a problem that seems almost quaint today: how do you find someone's email address when you don't already know where they are?

The Port at a Glance

What the Profile Naming Service Does

Profile is a descriptive naming service used to identify users and organizations¹. Unlike traditional naming systems that require you to know exactly what you're looking for, Profile lets you search by describing attributes of the person you want to find.

Want to find a computer scientist at the University of Arizona who works on distributed systems? Profile could help. You didn't need to know their email address. You described them, and the system searched.

The system has three components¹:

1. A confederation of attribute-based name servers — independent authorities that store information about users and organizations using multiple descriptive attributes
2. A name space abstraction — a client program that searches across multiple name servers in sequence
3. A user interface — tools that let users build customized commands and integrate Profile with existing systems

The Problem Profile Solved

In 1988, the DARPA/NSF Internet was growing rapidly, but finding people on it was remarkably difficult. The network had around 60,000 hosts², spread across universities, research labs, and government facilities. If you wanted to email someone, you needed their exact address.

The tools that existed were primitive:

• WHOIS could tell you about domain registrations, but not about people
• Finger (port 79) could tell you who was logged into a specific machine, but only if you already knew which machine to query³
• DNS could resolve hostnames to IP addresses, but knew nothing about human beings

What the Internet lacked was a white pages service: a way to look up people the way you looked up phone numbers. You should be able to search for "John Smith at MIT" and find his email address without knowing that his username was "jsmith" on the machine "athena.mit.edu".

This was the problem Larry Peterson set out to solve.

The History

Larry Peterson and the University of Arizona

Larry L. Peterson received his Ph.D. from Purdue University in 1985 and joined the University of Arizona, where he established himself as a leader in computer networks and distributed computing⁴. He would later become a renowned figure in networking: co-author of the classic textbook "Computer Networks: A Systems Approach," member of the National Academy of Engineering, Fellow of both ACM and IEEE, and recipient of the ACM SIGCOMM Award⁴.

In the late 1980s, Peterson was working on fundamental problems in distributed systems. Naming was one of the hardest.

The 1988 Paper

Peterson published "The Profile Naming Service" in the ACM Transactions on Computer Systems in November 1988¹. The paper described a working implementation that had been tested on the DARPA/NSF Internet.

The key insight was attribute-based naming. Instead of requiring users to navigate a rigid hierarchy (country → organization → department → person), Profile let users describe what they knew:

"Each name server is an independent authority that allows clients to describe users and organizations with a multiplicity of attributes."¹

This was revolutionary. You could search for someone by their role, their affiliation, their research interests, or any combination of attributes the servers knew about.

The Port Assignment

Port 136 was assigned to the Profile Naming Service by IANA, with Larry Peterson (llp@arizona.edu) listed as the contact⁵. The assignment appears in RFC 1340, the "Assigned Numbers" document published by Joyce Reynolds and Jon Postel in July 1992⁵.

The port sits in interesting company:

• Port 135: Location Service
• Port 136: PROFILE Naming System
• Ports 137-139: NetBIOS services

How Profile Worked

Profile's architecture was elegant in its simplicity:

Federated name servers: Rather than requiring a single authoritative database, Profile allowed multiple independent name servers to coexist. Each server was an authority for its own domain (a university, a company, a research lab), but clients could search across all of them.

Attribute queries: Users described what they knew about the person they were seeking. "Name contains 'Peterson'" and "organization contains 'Arizona'" would find Larry Peterson. The system combined these attributes to narrow down results.

Sequential searching: The client program implemented a discipline for searching name servers in sequence, starting with the most likely and expanding outward until it found a match.

Integration with existing systems: Profile didn't try to replace finger or WHOIS. Instead, it provided a unified interface that could query those systems and integrate the results.

Why Profile Didn't Survive

Profile was technically successful. Peterson's paper concluded:

"Experience with an implementation in the DARPA/NSF Internet demonstrates that Profile is a feasible and effective mechanism for naming users and organizations in a large Internet."¹

But technical success doesn't guarantee adoption. Profile faced several challenges:

X.500 emerged as a standard: In 1988, the international standards bodies were developing X.500, a directory service that would become the basis for LDAP⁶. Major vendors and governments backed X.500, which made Profile look like a research project competing against an industrial standard.

The Web changed everything: By 1993, the World Wide Web was exploding. Search engines like AltaVista would soon let you find people by searching web pages. The problem Profile solved was being solved differently.

Email directories went commercial: Services like Four11 (later acquired by Yahoo) built email directories as commercial products. The grassroots, federated model of Profile gave way to centralized databases.

Social networks arrived: By the 2000s, LinkedIn, Facebook, and other services made finding people trivially easy. You didn't need attribute-based queries when everyone had a profile page.

Port 136 was never formally deprecated, but traffic on it effectively ceased. Today, it sits silent in the IANA registry, a reminder of a problem that was once pressing and is now invisible.

Security Considerations

Profile was designed in an era of implicit trust. The early Internet was small, its users were mostly academics and researchers, and security was not a primary concern.

The system had no authentication mechanism for queries or responses. Anyone could query for information about anyone else. Name servers could be spoofed. Results could be fabricated.

These weren't seen as major problems in 1988. They would be unacceptable today.

If you see traffic on port 136 on a modern network, treat it as suspicious. Legitimate Profile traffic is essentially nonexistent. Any activity on this port is more likely to be:

• Misconfigured legacy systems
• Port scanning by attackers
• Malware using an obscure port to avoid detection

Related Ports

The Legacy

Profile didn't become the Internet's white pages. But the ideas it pioneered lived on.

Attribute-based search is now everywhere. When you search LinkedIn for "software engineer in San Francisco," you're using the same conceptual model Peterson described in 1988.

Federated identity remains an active area of research. The idea that multiple independent authorities can cooperate to provide naming services influenced later work on federated authentication and identity management.

The problem is still hard. Despite decades of progress, finding someone's email address when you only know their name and employer remains surprisingly difficult. Profile was an honest attempt at a problem that still isn't fully solved.

Larry Peterson went on to make major contributions to networking, including the TCP Vegas congestion control algorithm, the PlanetLab distributed systems research platform, and foundational work on software-defined networking⁴. His textbook, "Computer Networks: A Systems Approach," remains a standard reference.

Port 136 is a memorial to a moment when the Internet was small enough that finding people felt like a tractable problem, and one researcher in Arizona thought he could solve it.