Date: Mon, 21 May 2001 14:43:09 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Barney Wolff <barney@databus.com> Cc: Ian Dowse <iedowse@maths.tcd.ie>, freebsd-net@FreeBSD.ORG Subject: Re: Using connect() on UDP RPC client sockets. Message-ID: <200105211443.aa07793@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sun, 20 May 2001 18:40:33 EDT." <20010520184033.A83645@tp.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20010520184033.A83645@tp.databus.com>, Barney Wolff writes: >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. An alternative to this approach on the server side, which has been discussed before, is a mechanism to set the source address of individual outgoing UDP datagrams. There is already the IP_RECVDSTADDR socket option which can be used to determine the source address of the incoming packet: If the IP_RECVDSTADDR option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return the destination IP address for a UDP datagram. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by the IP address. The cmsghdr fields have the following values: cmsg_len = sizeof(struct in_addr) cmsg_level = IPPROTO_IP cmsg_type = IP_RECVDSTADDR If an IP_SENDSRCADDR control message was implemented, servers could use it to reply from the address to which the request was sent. This would not require opening additional sockets, and it would not need to detect interface address changes. Another alternative would be to make IP_HDRINCL work with UDP sockets, so that the server could construct a UDP header at the start of the datagram containing the required source address. I would prefer to see the server-side issue being fixed so that the clients can use the simple, secure approach. Then for interoperating with `broken' servers, there needs to be a way to revert to the old client behaviour. >2. Source addr is so easy to spoof that it adds nothing to security. True, but internal networks can be trivially protected from spoofed packets coming in from less secure networks, and this is one of the most basic levels of filtering employed by most firewalls. Also, local unpriviledged accounts on unix servers cannot be used to spoof source addresses. However in both of these cases, it may still be possible to get a bogus reply accepted by an RPC client. Incoming packets do not need to spoof any addresses - they just require that the firewall lets in packets to UDP ports (i.e. many stateless firewalls). Local unpriviledged users can also send bogus replies simply by opening a UDP socket and sending a datagram to the RPC client port. It is this behaviour that I think is undesirable, and may be surprising to many people. 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? <200105211443.aa07793>