222

Port 222/tcp is registered with IANA under the service name rsh-spx, described simply as "Berkeley rshd with SPX auth." The entry is dual-registered — an identical row exists for 222/udp with the same service name and description — and every other IANA registry column (Assignee, Contact, Registration Date, Modification Date, Reference, Service Code, Unauthorized Use Reported, Assignment Notes) is blank, so no RFC reference and no registration date can be honestly reported for this port. The name signals a lineage, but not the one an earlier pass attributed to it: 222 sits in a three-port cluster of adjacent IANA registrations — 221/tcp,udp fln-spx ("Berkeley rlogind with SPX auth"), 222/tcp,udp rsh-spx ("Berkeley rshd with SPX auth"), and 223/tcp,udp cdc ("Certificate Distribution Center"), the last assigned to [Kannan_Alagappan]. That assignee co-authored DEC's SPX public-key authentication protocol ("SPX: Global Authentication Using Public Key Certificates," Tardo & Alagappan, IEEE Symposium on Security and Privacy, 1991), whose named Certificate Distribution Center component lines up directly with the adjacent 223 registration — making the "SPX" in rsh-spx DEC's public-key certificate-authentication scheme, not Novell's IPX/SPX sequenced-packet transport. Novell's SPX has no built-in authentication service of its own, and Novell's IPX already holds a separate, unrelated IANA registration at port 213/tcp,udp (assignee [Don_Provan], not [Kannan_Alagappan]) — a different registry row entirely. IANA's blank Reference column for 222 means only that IANA cites no document for this specific assignment; it is not evidence that no RFC exists anywhere for this authentication family — RFC 1507 (DASS), a related public-key network-authentication protocol from the same era, is one example of a sibling RFC that does exist. In modern practice, legitimate rsh-spx deployments are essentially extinct, and TCP/222 is instead most often encountered as a non-standard, manually configured SSH listener — administrators moving sshd off port 22 (or off the also-common 2222) to cut down on automated scan noise, which is obscurity rather than a real hardening control. As a low, easily guessed alternate port, 222/tcp routinely appears in scanner and honeypot sweeps, including brute-force SSH login attempts directed at non-standard low ports. IANA's own "Unauthorized Use Reported" column is blank for 222/tcp, and no primary source substantiates a trojan or malware association with this port.

IANA assignment

rsh-spx — "Berkeley rshd with SPX auth"; reference blank; assignee blank; dual-registered 222/tcp + 222/udp, identical fields [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry-547; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=222

Registration date / modification date / reference RFC

blank in the IANA registry — left blank, not fabricated [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023) [Confirmed]

Prevalence (nmap-services open-frequency)

nmap-services observed open-frequency 222/tcp ≈ 0.000941 — very low (roughly 9 in 10,000 scanned hosts in the nmap-services sample); the paired 222/udp row is slightly lower at ≈ 0.000774, so the TCP side is the marginally more commonly observed of the two — consistent with the alternate-SSH-listener reuse described above, which cannot occur over UDP [Confirmed for the figures; Likely for the SSH-reuse reading] — nmap-services dataset

Protocol lineage — cluster adjacency

221/tcp,udp fln-spx, 222/tcp,udp rsh-spx, 223/tcp,udp cdc (assignee [Kannan_Alagappan]) form three consecutive rows in the same registry block

Protocol lineage — DEC SPX identification

the SPX in fln-spx/rsh-spx is DEC's public-key certificate authentication protocol (Tardo & Alagappan, "SPX: Global Authentication Using Public Key Certificates," IEEE Symposium on Security and Privacy, 1991), whose Certificate Distribution Center component matches the adjacent 223 cdc row assigned to the paper's co-author — not Novell's IPX/SPX transport, which has no authentication service and holds its own unrelated registration at port 213 [Likely] — bibliographic citation (Tardo & Alagappan, IEEE S&P 1991); no live URL independently verified in this pass; corroborated by the IANA Service Name and Transport Protocol Port Number Registry-529 (Novell IPX at 213, different assignee) and :548-549 (cdc/223, [Kannan_Alagappan])

Common software

OpenSSH or another SSH daemon reconfigured to listen on 222; no other widely standardized modern service commonly uses this port

Exposure/scanning

routine inclusion in scanner and honeypot sweeps; documented pattern of brute-force SSH login attempts against non-standard low ports

Malware/trojan association

confirmed negative — IANA's "Unauthorized Use Reported" column is blank for 222/tcp, and no primary source substantiates a trojan or malware association with this port

RFC-existence framing

IANA's blank Reference column means IANA cites no document for this assignment; it is not proof no RFC exists for the wider authentication family — RFC 1507 (DASS) is a sibling public-key auth protocol from the same era with its own RFC [Confirmed for the blank-field fact; Likely for the "not proof of nonexistence" framing] — the IANA Service Name and Transport Protocol Port Number Registry

Modern/de-facto use

legitimate rsh-spx deployments are effectively extinct; the port is now most often seen as a non-standard, manually configured SSH listener (moved off 22/2222 to reduce automated scan noise) [Likely] — https://internet-security.com/ports/port-222-TCP.html

Port 222/udp is registered with IANA under the service name rsh-spx, described as "Berkeley rshd with SPX auth" — the same name and description as the companion 222/tcp row, with every other registry column (Assignee, Contact, Registration Date, Modification Date, Reference, Service Code, Unauthorized Use Reported, Assignment Notes) left blank, so no RFC and no registration date can be honestly reported. The name signals a lineage, but not the one an earlier pass attributed to it: 222 sits in a three-port cluster of adjacent IANA registrations — 221/tcp,udp fln-spx ("Berkeley rlogind with SPX auth"), 222/tcp,udp rsh-spx ("Berkeley rshd with SPX auth"), and 223/tcp,udp cdc ("Certificate Distribution Center"), the last assigned to [Kannan_Alagappan]. That assignee co-authored DEC's SPX public-key authentication protocol ("SPX: Global Authentication Using Public Key Certificates," Tardo & Alagappan, IEEE Symposium on Security and Privacy, 1991), whose named Certificate Distribution Center component lines up directly with the adjacent 223 registration — making the "SPX" in rsh-spx DEC's public-key certificate-authentication scheme, not Novell's IPX/SPX sequenced-packet transport. Novell's SPX has no built-in authentication service of its own, and Novell's IPX already holds a separate, unrelated IANA registration at port 213/tcp,udp (assignee [Don_Provan], not [Kannan_Alagappan]) — a different registry row entirely. What sets the UDP row apart from its TCP twin is a genuine protocol-fit question: Berkeley rsh/rshd is an interactive, stream-oriented remote-command protocol historically built on TCP, and no RFC or primary source describes an actual DEC SPX-authenticated rshd session running connectionless over UDP. The far more plausible explanation is that IANA registered the name on both transport rows for administrative completeness rather than because a distinct UDP protocol was ever implemented. Unlike 222/tcp, which sometimes sees reuse as a manually reconfigured alternate SSH listener, that reuse pattern does not carry over to UDP because SSH itself runs exclusively over TCP. No primary source was found confirming current legitimate use, udp-specific scan volume, or malware association for this exact port/transport pairing; those gaps are reported honestly as unverified rather than guessed.

IANA assignment

rsh-spx — "Berkeley rshd with SPX auth"; reference blank; assignee blank; dual-registered 222/tcp + 222/udp, identical fields [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Registration date / modification date / reference RFC

blank in the IANA registry — left blank, not fabricated [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023) [Confirmed]

Prevalence (nmap-services open-frequency)

nmap-services observed open-frequency 222/udp ≈ 0.000774 — very low (roughly 8 in 10,000 scanned hosts in the nmap-services sample); the paired 222/tcp row is slightly higher at ≈ 0.000941. The two figures are close, which argues against reading the UDP number as evidence of a real deployed UDP service — a sub-1024 port sits inside every generic mass-UDP sweep range, so a low nonzero open-frequency here is consistent with scan artifacts and open|filtered ambiguity rather than live rsh-spx [Confirmed for the figures; Likely for the reading] — nmap-services dataset

Protocol lineage — cluster adjacency

221/tcp,udp fln-spx, 222/tcp,udp rsh-spx, 223/tcp,udp cdc (assignee [Kannan_Alagappan]) form three consecutive rows in the same registry block

Protocol lineage — DEC SPX identification

the SPX in fln-spx/rsh-spx is DEC's public-key certificate authentication protocol (Tardo & Alagappan, "SPX: Global Authentication Using Public Key Certificates," IEEE Symposium on Security and Privacy, 1991), whose Certificate Distribution Center component matches the adjacent 223 cdc row assigned to the paper's co-author — not Novell's IPX/SPX transport, which has no authentication service and holds its own unrelated registration at port 213 [Likely] — bibliographic citation (Tardo & Alagappan, IEEE S&P 1991); no live URL independently verified in this pass; corroborated by the IANA Service Name and Transport Protocol Port Number Registry-529 (Novell IPX at 213, different assignee) and :548-549 (cdc/223, [Kannan_Alagappan])

Protocol fit caveat

Berkeley rsh/rshd is an interactive, stream-oriented protocol historically defined over TCP; no RFC or primary source describes a genuine connectionless DEC SPX-authenticated rshd session running over UDP — the udp registry row most plausibly reflects administrative pairing with the tcp row rather than a distinct implemented protocol

Common software

no modern software identified that binds to UDP/222 by default or convention

Exposure/scanning notes

SANS ISC's port-222 activity page shows scanning traffic against the port generically, but does not clearly separate tcp from udp counts in what was retrievable; DShield's dedicated port-222 page could not be fetched (HTTP 403)

Malware/trojan association

secondary aggregator auditmypc.com reports "No" virus/trojan association specifically for UDP port 222, with a general disclaimer that historical flags don't necessarily apply today; no primary-source association found

Modern/de-facto use

no evidence found of current legitimate use of 222/udp specifically; the alternate-SSH-listener reuse seen on 222/tcp does not apply here because SSH runs over TCP, not UDP [Likely] — https://internet-security.com/ports/port-222-TCP.html