Date: Sun, 20 May 2001 22:56:34 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-net@freebsd.org Subject: Using connect() on UDP RPC client sockets. Message-ID: <200105202256.aa30752@salmon.maths.tcd.ie>
next in thread | raw e-mail | index | archive | help
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. I would like to change the RPC client code to use connect() for UDP sockets. I think this would be a more modern behaviour; it is more secure, and ICMP errors get reported back to the application. This does not require any API changes, and for most applications there will be no noticable difference in behaviour. However, I don't claim to have a lot of experience in the area of RPC, so I'd be grateful for any suggestions or comments related to taking this approach. Specifically: * Is there anything I am missing? e.g. are there any reasons that accepting a reply from any address simply must be allowed? * Should this behaviour be optional? If so should it be controllable in some system-wide fashion, or just by the application? The clnt_control() mechanism would be suitable for application-level control. * Are the issues caused by multi-homed hosts common enough that we should ensure all our RPC servers have a facility for listening on multiple UDP sockets, or implement the reverse of IP_RECVDSTADDR or whatever before changing the default RPC behaviour? Ian 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? <200105202256.aa30752>