Date: Wed, 3 Feb 1999 12:39:43 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: security@FreeBSD.ORG Subject: Re: tcpdump Message-ID: <Pine.BSF.3.96.990203121931.28547B-100000@fledge.watson.org> In-Reply-To: <199902031549.KAA24669@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990203121931.28547B-100000>