19.3. talk
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.
Figure 19-2. 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.
19.3.1. Packet Filtering Characteristics of talk
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[101]
|
[102]
|
External client contacting internal server |
|
Out |
Int |
Ext |
UDP |
517
518[101] |
>1023 |
[102] |
Internal server answering external client |
|
Out |
Int |
Ext |
UDP |
>1023 |
517
518[101] |
[102] |
Internal client contacting external server |
|
In |
Ext |
Int |
UDP |
517
518[101] |
>1023 |
[102] |
External server answering internal client |
|
Out |
Int |
Ext |
TCP |
>1023 |
>1023 |
[103]
|
Internal client communicating with external client |
|
In |
Ext |
Int |
TCP |
>1023 |
>1023 |
[103] |
External client communicating with internal client |
[101]Old versions of talk use
port 517; newer versions use port 518.
19.3.2. Proxying Characteristics of talk
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.
19.3.3. Network Address Translation Characteristics of talk
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.
19.3.4. Summary of Recommendations for talk
- 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.
 |  |  |
| 19.2. ICQ |  | 19.4. Multimedia Protocols |