Date: Sun, 20 May 2001 18:40:33 -0400 From: Barney Wolff <barney@databus.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <20010520184033.A83645@tp.databus.com> In-Reply-To: <200105202256.aa30752@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, May 20, 2001 at 10:56:34PM %2B0100 References: <200105202256.aa30752@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
1. Multi-homed hosts are in fact very common, especially in
corporate environments. To get the right source addr in
its reply, the server must open separate sockets on each
of its host's addresses - as named and ntpd do. And then
it has to detect changes in the set of addresses. Hard
work for not a lot of gain.
2. Source addr is so easy to spoof that it adds nothing to security.
3. I have not examined the kernel's socket-finding code, but it
is by no means guaranteed that performance with individual
connected sockets will be better, or even as good, as that
with a single unconnected socket. On the other hand, it
would multiply kernel buffering, which can be good or bad.
I have myself used connect on udp sockets, and fought a battle
with the multi-homed server guy. I won but in retrospect it
was a fight that was not necessary. Where an RFC mandates
that the reply source address must be the same as the request
dest addr (as it does for dns, radius, some others) the extra
work on the server's part is mandatory. Is it mandated for rpc?
Barney Wolff
On Sun, May 20, 2001 at 10:56:34PM +0100, Ian Dowse wrote:
>
> The RPC client code in libc performs UDP RPC calls with sendto()
> and recvfrom() using an unconnected socket. When a reply arrives,
> the library code checks only that the XID of the reply matches that
> of the request; it does not check that the reply came from the
> address to which the request was sent.
>
> I assume that this behaviour exists to deal with unusual servers
> that reply from the wrong address or port. However, since RPC is
> used for a number of security-sensitive protocols, this approach
> is not ideal, and its implications for firewall design may be
> surprising to some.
>
> Using sendto/recvfrom also has the disadvantage that the results
> of ICMP errors are not made available to the application. This can
> result in long timeout delays instead of a quick ECONNREFUSED or
> ENETRESET reply.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010520184033.A83645>