136

Port 136/tcp is registered with IANA under the service name profile, described as "PROFILE Naming System," with both assignee and contact listed as Larry Peterson. The registry entry is dual-registered on TCP and UDP (identical metadata on both transports), and the Registration Date, Modification Date, Reference, Service Code, and Assignment Notes fields are all blank in the IANA CSV — there is no RFC tied to this assignment. PROFILE itself was an experimental, attribute-based ("descriptive") naming service for users and organizations, built as a confederation of attribute-based name servers unified behind a common name-space abstraction and user interface; it was designed and documented by Larry L. Peterson of the University of Arizona and published as "The Profile Naming Service" in ACM Transactions on Computer Systems in 1988, demonstrated on the DARPA/NSF Internet of that era. The service predates and is unrelated to the NetBIOS session-service cluster (137–139) despite the numeric proximity, and it is not part of any Windows-networking suite. PROFILE saw no meaningful production deployment beyond its research context and is treated by contemporary port-reference sources as long retired — third-party listings describe the original assignment as no longer in use. No CVE or named malware family is documented against the port; live scan-visibility data shows only low, sporadic probe traffic with a "green" (low) threat rating and no sustained campaign. A host observed with 136/tcp open today should be treated as running an unidentified or custom service rather than the historical PROFILE service, and investigated on its own merits rather than assumed to be either PROFILE or malicious by default.

IANA assignment

profile — "PROFILE Naming System"; reference (blank — no RFC cited in IANA registry); assignee/contact Larry Peterson; dual-registered 136/tcp + 136/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry (lines 349–350); IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023) [Confirmed] — IANA registry range convention

Related ports

137–139/tcp+udp (NetBIOS session services) are numerically adjacent but functionally and historically unrelated [Confirmed]

Primary use

experimental attribute-based ("descriptive") naming/directory service for users and organizations; confederation of attribute-based name servers behind a unifying name-space abstraction

Protocol background

designed and published by Larry L. Peterson, University of Arizona, demonstrated on the DARPA/NSF Internet of the late 1980s

Common software

no specific modern software or product is documented as defaulting to this port; unrelated to the NetBIOS (137–139) suite despite numeric proximity [Unknown]

Security implications / exposure

SANS ISC live port data (checked 2026-07-09) shows low, sporadic scanning (single source IP generated 124 hits one day, 1 hit the next) with threat level marked green (low); no CVE or named malware family documented; a generic antivirus-style reference site mentions historical Trojan use of the port without naming a family or dated incident (undated, low-confidence secondary claim, not corroborated)

Typically seen on

none confirmed in modern production; an open 136/tcp today is anomalous and should be investigated as a custom/unidentified service [Likely]

Current use

not in active modern deployment; third-party port references describe the original assignment as retired/no longer used; no primary-source evidence of 2020s-era PROFILE deployments found [Likely] — http://www.t1shopper.com/tools/port-number/136/, https://tcp-udp-ports.com/port-136.htm

Analyst note

treat 136/tcp as a retired, low-traffic legacy assignment; its presence open on a host is not evidence of the historical PROFILE service and warrants independent investigation.

Port 136/udp is registered with IANA under the service name profile, described simply as "PROFILE Naming System," with Larry Peterson listed as both assignee and contact. The registry's Registration Date, Modification Date, and Reference/RFC fields are all blank for this entry — there is no RFC anywhere in the IANA record tying the assignment to a published specification, and the same blank fields apply identically to the paired 136/tcp registration, which shares the same service name, description, and assignee. That combination — a bare service name with no protocol document, no reference, and no recorded date — is characteristic of IANA's early port-registry era, when assignments could be reserved administratively without a corresponding standards-track write-up ever being produced. Nothing in the live IANA registry, general web search, or vendor documentation ties port 136/udp to any mainstream operating system feature or actively maintained software package; it does not correspond to a widely deployed service the way ports like NetBIOS or SNMP do. SANS Internet Storm Center's port-136 scanning tracker (which reports on tcp and udp together) shows only low, non-targeted background noise — small single-digit-to-low-triple-digit daily hit counts from individual source IPs — with no listed CVEs and no active-campaign flag. No malware or trojan association is confirmed for UDP 136: no CVE, vendor advisory, or named threat-intelligence source ties a malware family to this port. On balance, port 136/udp reads as an obscure, effectively dormant legacy assignment rather than a protocol in active use, and any traffic seen on it in the wild is more plausibly opportunistic scanning or misconfiguration than a real PROFILE Naming System client.

IANA assignment

profile — "PROFILE Naming System"; reference blank (no RFC cited); assignee/contact Larry Peterson; dual-registered 136/tcp + 136/udp with identical name/description/assignee [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 350; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Registration/Modification Date

blank in the registry for both 136/tcp and 136/udp — left null, no date fabricated [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 350; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Range class

well-known (0–1023) [Confirmed]

Prevalence (scan-frequency data)

nmap-services observed open-frequency 136/udp ≈ 0.051862 — moderate, 29th of 5,615 UDP entries in the dataset: found open on roughly 5 in 100 sampled hosts. The TCP sibling 136/tcp is vanishingly rare by comparison at ≈ 0.000025. The figure measures how often the port answers a scan, not confirmed PROFILE Naming System use — nothing identifies what is listening on those hosts

[Likely] — nmap-services dataset

Related ports

136/tcp (dual registration, identical service name/description/assignee/blank fields) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 349

Primary use / protocol history

legacy naming/directory protocol assigned in IANA's early port-registry era; no RFC or reference document is attached to the assignment

Security implications / exposure

SANS ISC port-136 tracker (covers tcp+udp) shows only low, non-targeted background scan noise, no listed CVEs, no active-campaign flag

Malware associations

none confirmed — no CVE, vendor advisory, or named threat-intelligence source ties a malware family to UDP 136

Common modern software use

none identified; no mainstream OS, application, or standard network service found actively using this port [Unknown] — no confirming source located