Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!MONET.BERKELEY.EDU!karels
From: karels@MONET.BERKELEY.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: The multi-home problem again
Message-ID: <8607210614.AA07696@monet.Berkeley.EDU>
Date: Mon, 21-Jul-86 02:14:28 EDT
Article-I.D.: monet.8607210614.AA07696
Posted: Mon Jul 21 02:14:28 1986
Date-Received: Mon, 21-Jul-86 20:12:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 58
Approved: tcp-ip@sri-nic.arpa

The previous answer to Dave Mills' observation on the nameserver
for A.ISI.EDU requires considerable clarification and correction.
Actually, I was going to deny any responsibility on behalf of 4.2
and 4.3BSD UNIX for dealings between a fuzzball and TOPS-20, but a quick
check shows that the server for ISI now runs on a 4.2BSD VAX.
I guess I'm not off the hook so easily.

The previous reply was totally incorrect in its claims about 4.3.
However, 4.2 has a serious problem when it comes to the Principle
of Least Astonishment when it comes to UDP return addresses.
First, a process receiving UDP datagrams (including a server)
receives the datagram "from" address, but not the "to" address.
Thus, a server can take no action to ensure that the source address
of its reply is the same as the destination address of the request
on a multihomed host.  (The preceeding is still true in 4.3.)  Both 4.2
and 4.3 attempt to choose UDP source addresses according to the destination
address, but 4.2 makes a somewhat feeble attempt.  It uses its address
on a network shared with the destination, if any (which is generally correct),
but uses its "primary" address for all other destinations.  The "primary"
address is the address for the first network interface in the system
configuration file.  VAXA.ISI.EDU could apparently be helped considerably
by placing its imp interface first in its kernel configuration table.

4.3 makes a better attempt at choosing source addresses for datagrams
(and client-initiated TCP connections).  It uses its address on the network
through which it routes the packet.  However, for the name-domain system,
this is not sufficient that name solvers may depend on the server's
choice of source address.  In particular, if the server is known by multiple
addresses, the name solver may or may not use the "closest" address for the
server (the address on the network by which the request will arrive).
It seems to be reasonably simple to recognize a reply to one's query,
however, without depending on the source address of the reply.  That is
fortunate, as the predominant servers run on hosts that may not use
the expected source address for all replies.

The comments made by Dave Cohrs about the "UDP bug" concerning inability
to specify the source address of a datagram were incorrect.  It is possible
for the source address to be bound (using the bind system call) before
sending the datagram.  It would be reasonable for a knowledgeable server
to set up one descriptor for each source address in this way.  It is actually
the system interface for reception of datagrams that is limiting.

By the way, the Martian-grams which Dave Mills mentioned (replies from
127.0.0.1) are more difficult to explain.  The last wave of attacks
were ICMP error messages with that source address that came from
a beta 4.3 host.  The code to select the ICMP source address was
unfinished at the time of the beta release, although I had forgotten
that by the time of the attack.  The test release thus used the "primary"
address, which in 4.3 is the first address set.  At one site, the primary
address was thus the one used for the loopback, a configuration error
that I had not imagined.  The error would be much less serious with
the released version of 4.3.  Seismo appears to still be running
the beta test version or a mixture of the two.  With either version,
the loopback address can be set to any value.  To encourage use of
officially-assigned addresses, the release contains an unusable
definition of the loopback address that must be changed.

		Mike