From owner-freebsd-net Sun May 20 15:40:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id ACFC637B424 for ; Sun, 20 May 2001 15:40:54 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f4KMeXm83714; Sun, 20 May 2001 18:40:33 -0400 (EDT) (envelope-from barney) Date: Sun, 20 May 2001 18:40:33 -0400 From: Barney Wolff To: Ian Dowse Cc: freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <20010520184033.A83645@tp.databus.com> References: <200105202256.aa30752@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105202256.aa30752@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, May 20, 2001 at 10:56:34PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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