Subject: Unauthorized DHCP servers

From: [email-masked]
Date: Wed, 16 Aug 2000 09:51:43 -0500

I'm a little confused as for how a dhcp client decides to accept a reply
from legal and illegal servers. It seems to me, in a case of an
unauthorized dhcp server on a local segment as the client, the client
always pick the NAK from the unauthorized server.   Is it simply because of
distance/hops since the unauthorized server is on the same wire as the
client, while the authorized server is one or two hops away from the
client?  If so, why the delta time shows that the client actually receives
the reply packets from the legal server first when I do a sniffer trace?

Here is some background.  Let's say, an unauthorized dhcp server is sitting
on the same segment as the dhcp client, whereas the authorized servers
sites on a different segment as the client. The client has to go through
the router/relay agent to get to the legal server.  When the client sends
broadcast messages out, both the legal and illegal servers will receive the
broadcast message and try to reply back to the client.

Question:
In the case of the illegal server, since it's local to the client, would it
send unicast pack to the client or would it flood the reply message on to
the wire and let the client decide?

In the case of the legal server, since it's on a separate segment as the
client, it will unicast it's reply packet to the relay agent, the relay
agent then either unicast  or broadcast to the client.  Now how the relay
agent decide whether to unicast or broadcast the packet to the client?

thanks for your help!
Hannah

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 18 Aug 2000 10:27:19 -0700

> -----Original Message-----
> From: [email-masked]
> Sent: Wednesday, August 16, 2000 7:52 AM
>
> always pick the NAK from the unauthorized server.   Is it simply
> because of distance/hops since the unauthorized server is on the same
> wire as the client, while the authorized server is one or two hops away
> from the client?  If so, why the delta time shows that the client actually
> receives the reply packets from the legal server first when I do a sniffer
> trace?
>
...there really are no hard and fast rules governing the mechanism by which
a DHCP client selects which IP address lease offer it will accept when
soliciting lease offers in an environment with multiple servers.

Forgetting about DHCP Authentication for the moment, the client is free to
accept or decline any offered lease.  If the client has no prior experience
(that is, has not previously been connected to any network segment) it will
generally attempt to use the first address lease offered it.  The client
sends a gratuitous ARP request packet and waits for a reply.  If a reply is
received, the client should decline the address, as it obviously is already
in use.  The absence of a reply, unfortunately, does not guarantee that the
address is available, especially in those environments utilizing switches
and routers whose ARP caches may not be fully initialized.  It is possible
for a client (though I know of none that do this) to issue multiple
gratuitous ARP requests to circumvent timing problems with ARP cache
initialization.

Clients may use any criteria they wish to select an offered IP address
lease, including server address and any other information that can be
gleaned from the DHCPOFFER packet, so it is quite possible to select an
offered lease from a bogus or rogue DHCP server.

Many clients remember the server from which it last accepted an offer, so
those clients will be biased towards selecting offers from that server on
subsequent discover-offer-request-ack cycles.  Using the Microsoft client as
an example, the user may be required to issue the two commands, "ipconfig
/release" and "ipconfig /renew" to eliminate the bias.  This is why a
"closer" server is sometimes ignored by a client.

> Here is some background.  Let's say, an unauthorized dhcp server
> is sitting on the same segment as the dhcp client, whereas the
> authorized servers sites on a different segment as the client. The
> client has to go through the router/relay agent to get to the legal
> server.  When the client sends broadcast messages out, both the
> legal and illegal servers will receive the broadcast message and
> try to reply back to the client.
>
> Question:
> In the case of the illegal server, since it's local to the client,
> would it send unicast pack to the client or would it flood the
> reply message on to the wire and let the client decide?
>
...because the client does not yet have an IP address, unicasts are not
possible, but, as most servers can determine the source (local or gatewayed)
it would be possible for the server to choose between an "all-nets"
broadcast or a subnet broadcast, but usually the DHCP server leaves that
decision to the underlying IP stack installed on the server host.

In answer to your question, the client always decides.

> agent decide whether to unicast or broadcast the packet to the client?
...Again, a relay agent can't unicast to a host lacking an IP address, and
probably doesn't make the choice of an all-nets versus subnet broadcast,
leaving that to the underlying IP stack.

for an example of a relay agent implementation, check out the Internet
Software Consortium's DHCPD distribution.

Hope that helps....

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Fri, 18 Aug 2000 15:11:26 -0700

At 09:51 AM 8/16/00 -0500, [email-masked] wrote:
>from legal and illegal servers.

The protocol spec in RFC 2131/2132 does not provide for any authentication 
through which a client can differentiate between authorized and 
unauthorized servers.  There is an authentication option that is very close 
to acceptance as a standard; see draft-ietf-dhc-authentication-14.txt for 
details.

>  It seems to me, in a case of an

Typically, a DHCP client will select the server whose response arrives 
first at the client.  The response from a server on the same network 
segment will typically get back to the client before the response forwarded 
by a relay agent from a server on a different network.

>the wire and let the client decide?

An RFC2131-compliant server or relay agent will unicast the DHCPOFFER, 
using the client's link-layer address and the IP address offered by the 
server, unless the BROADCAST bit is set or the server or relay agent is 
unable to use unicast.

>agent decide whether to unicast or broadcast the packet to the client?

The relay agent uses the same rules described above for deciding between 
unicast and broadcast.

When you use a network analyzer to grab the DHCP messages, are you seeing 
responses from both the authorized and unauthorized servers?  Are those 
messages broadcast or unicast?

- Ralph Droms