From owner-freebsd-security Wed Feb 3 09:39:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16887 for freebsd-security-outgoing; Wed, 3 Feb 1999 09:39:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16881 for ; Wed, 3 Feb 1999 09:39:50 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA28673; Wed, 3 Feb 1999 12:39:43 -0500 (EST) Date: Wed, 3 Feb 1999 12:39:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Garrett Wollman cc: security@FreeBSD.ORG Subject: Re: tcpdump In-Reply-To: <199902031549.KAA24669@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 3 Feb 1999, Garrett Wollman wrote: > > Bpfilter is a useful piece of functionality required for dhcp, a service > > that is increasingly popular. > > Actually, it is not required for DHCP. However, the implementational > requirements of DHCP currently run afoul of bugs (or misfeatures) in > the IP stack which currently require DHCP programs to circumvent IP in > order to operate. So, I forget--it has been a while since I attended the DHCP working group (I worked on DHCPsec for a while, hence my being there). Here's RFC 2131's take on the whole thing: (stolen from RFC 2131) 1. The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet. 2. Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). Servers need not reserve the offered network address, although the protocol will work more efficiently if the server avoids allocating the offered network address to another client. When allocating a new address, servers SHOULD check that the offered network address is not already in use; e.g., the server may probe the offered address with an ICMP Echo Request. Servers SHOULD be implemented so that network administrators MAY choose to disable probes of newly allocated addresses. The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary. 3. The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents. To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. The client times out and retransmits the DHCPDISCOVER message if the client receives no DHCPOFFER messages. 4. ... DHCPACK or DHCPNAK (see RFC for more and pretty diagrams) So the phase currently requiring BPF is presumably the bit where the client picks up the broadcast response as it doesn't have an IP address yet. The DHCP client also requires that it can set the source IP address for the outgoing requests. What changes to the protocol stack do you recommend to allow the reception of messages for the 0.0.0.0 (or whatever) address, and sending of appropriate packets? Could one use the existing ifconfig alias technique to add reception of those messages? For sending, presumably a raw IP socket would work? Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message