talk is a text-based real-time two-person conferencing system; it allows two people to establish a "chat" session with each other. Each of their screens gets split into two sections; what one person types appears in one section; what the other person types appears in the other section.
talk is very convoluted in that it uses UDP to negotiate the connections between the two sites and then uses TCP to actually move the data back and forth between the participants. UDP is used between the calling client and the answering server, and again between the answering client and the calling server; TCP is then used between the two clients.
To further complicate matters, there are two incompatible versions of the talk protocol, commonly referred to as either talk and ntalk (for "new talk") or otalk (for "old talk") and talk, depending on who you ask. The earlier version depended on bytes being in a certain order in memory and only worked reliably between machines of the same CPU type. The later version fixes this problem but is incompatible with the earlier version.
The calling client contacts the answering server via UDP to announce the call. The answering server tells the user being called that someone is requesting a talk session and how the user should respond in order to accept the call. While waiting for the user to respond, the calling client also contacts the calling server to say that it's expecting an incoming call and to specify what TCP port it wishes to use for that call (somewhat like calling your secretary to say that you're expecting a call back from someone and that it should be put through to the extension you're currently at). When the answering user accepts, that user's client (the answering client) contacts the calling server via UDP to find out what port the calling client is waiting on; the answering client then contacts the calling client on that TCP port. Figure 19.2 shows how talk works.
Because of the incompatible talk protocols, talk fails relatively often even between sites that do no packet filtering, or between machines of different types within the same site. talk clients and servers are generally provided only on Unix machines.
talk servers (which broker connections between talk clients and then get out of the way) use either UDP port 517 (for old versions of talk) or UDP port 518 (for newer versions). talk clients use UDP ports above 1023 to interact with talk servers. talk clients also use TCP ports above 1023 to interact with each other. This means that, in order to allow talk across your firewall, you'd have to allow TCP connections where both ends are using arbitrary ports above 1023; this isn't safe because of vulnerabilities like X11 servers that use ports above 1023.
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
In | Ext | Int | UDP | >1023 | 517 518[20] | [21] | External client contacting internal server |
Out | Int | Ext | UDP | 517 518[20] | >1023 | [21] | Internal server answering external client |
Out | Int | Ext | UDP | >1023 | 517 518[20] | [21] | Internal client contacting external server |
In | Ext | Int | UDP | 517 518[20] | >1023 | [21] | External server answering internal client |
Out | Int | Ext | TCP | >1023 | >1023 | [28] | Internal client communicating with external client |
In | Ext | Int | TCP | >1023 | >1023 | [28] | External client communicating with internal client |
[20] Old versions of talk use port 517; newer versions use port 518. [21] UDP has no ACK equivalent. [28] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest. | |||||||
No proxies are available for talk. It would theoretically be possible to write one. Because talk involves internal and external clients simultaneously, it would almost have to be a modified-procedure proxy server. (No generic server would handle it, in any case, because it involves both TCP and UDP.) Given the considerable difficulty of writing a talk proxy, and the extreme fragility of the process, it's unlikely that one will become available. talk has been almost altogether abandoned for cross-Internet conversations, in favor of things like IRC and ICQ, described previously.
Because of the way talk negotiates port numbers and opens connections, you would need a network address translation system that was aware of talk in order to make it work. The network address translation system needs to pay attention to the port number negotiation in order to set up the appropriate translation for inbound connections.
It is impossible to safely allow talk through filters or to proxy it, so you can't allow talk between the Internet and your internal machines. If, for some reason, you absolutely must allow talk, you will need to put a victim machine on your perimeter net that is untrusted and has no confidential data, and allow users to log into it and run talk from there.