22. Security Considerations
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
22. Security Considerations
This section discusses security considerations that are not related
to privacy. See Section 23 for a discussion dedicated to privacy.
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCP ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
DHCP lacks end-to-end encryption between clients and servers; thus,
hijacking, tampering, and eavesdropping attacks are all possible as a
result. Some network environments (discussed below) can be secured
through various means to minimize these attacks.
The threat common to both the client and the server is the "resource-
exhaustion" DoS attack. Typically, these attacks involve the
exhaustion of available assigned addresses or delegatable prefixes or
the exhaustion of CPU or network bandwidth, and they are present any
time there is a shared resource. Some forms of these exhaustion
attacks can be partially mitigated by appropriate server policy,
e.g., limiting the maximum number of leases any one client can get,
limiting the number of leases one client can decline, and limiting
the number of messages a single client can transmit in a period of
time.
22.1. Client Security Considerations
One attack specific to a DHCP client is the establishment of a
malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to
mount a "man-in-the-middle" attack that causes the client to
communicate with a malicious server instead of a valid server for
some service (such as DNS or NTP). The malicious server may also
mount a DoS attack through misconfiguration of the client; this
attack would cause all network communication from the client to fail.
A malicious DHCP server might cause a client to set its SOL_MAX_RT
and INF_MAX_RT parameters to an unreasonably high value with the
SOL_MAX_RT (see Section 21.24) and INF_MAX_RT (see Section 21.25)
options; this may cause an undue delay in a client completing its
DHCP protocol transaction in the case where no other valid response
is received. Assuming that the client also receives a response from
a valid DHCP server, large values for SOL_MAX_RT and INF_MAX_RT will
not have any effect.
Another threat to DHCP clients originates from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
If a client implementation supports the reconfigure mechanism, see
Section 22.3.
22.2. Server Security Considerations
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
theft of service or to circumvent auditing for any number of
nefarious purposes.
The messages exchanged between relay agents and servers may be used
to mount a man-in-the-middle or DoS attack. Communication between a
server and a relay agent, and communication between relay agents, can
be authenticated and encrypted through the use of IPsec, as described
in [RFC8213].
However, the use of manually configured pre-shared keys for IPsec
between relay agents and servers does not defend against replayed
DHCP messages. Replayed messages can represent a DoS attack through
exhaustion of processing resources but not through misconfiguration
or exhaustion of other resources such as assignable addresses and
delegatable prefixes.
If a server implementation supports the reconfigure mechanism, see
Section 22.3.
22.3. Reconfigure Security Considerations
RKAP, described in Section 20.4, provides protection against the use
of a Reconfigure message by a malicious DHCP server to mount a DoS or
man-in-the-middle attack on a client. This protocol can be
compromised by an attacker that can intercept the initial message in
which the DHCP server sends the key as plain text to the client.
Because of the opportunity for attack through the Reconfigure
message, a DHCP client MUST discard any Reconfigure message that does
not include authentication or that does not pass the validation
process for the authentication protocol.
A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server. Note
that although a client sends its response (Renew, Rebind, or
Information-request message) through a relay agent and, therefore,
that response will only be received by servers to which DHCP messages
are relayed, a malicious server could send a Reconfigure message to a
client, followed (after an appropriate delay) by a Reply message that
would be accepted by the client. Thus, a malicious server that is
not on the network path between the client and the server may still
be able to mount a Reconfigure attack on a client. The use of
transaction IDs that are cryptographically sound and cannot easily be
predicted will also reduce the probability that such an attack will
be successful.
22.4. Mitigation Considerations
Various network environments also offer levels of security if
deployed as described below.
* In enterprise and factory networks, use of authentication per
[IEEE8802.1x] can prevent unknown or untrusted clients from
connecting to the network. However, this does not necessarily
assure that the connected client will be a good DHCP or network
actor.
* For wired networks where clients typically are connected to a
switch port, snooping DHCP multicast (or unicast) traffic becomes
difficult, as the switches limit the traffic delivered to a port.
The client's DHCP messages (multicast to
All_DHCP_Relay_Agents_and_Servers) are only forwarded to the DHCP
server's (or relay's) switch port -- not all ports. Also, the
server's (or relay's) unicast replies are only delivered to the
target client's port -- not all ports.
* In public networks (such as a Wi-Fi network in a coffee shop or
airport), it is possible for others within radio range to snoop
DHCP and other traffic. But in these environments, there is very
little if anything that can be learned from the DHCP traffic
itself (either from client to server or from server to client) if
the privacy considerations provided in Section 23 are followed.
Even for devices that do not follow the privacy considerations,
there is little that can be learned that would not be available
from subsequent communications anyway (such as the device's Media
Access Control (MAC) address). Also, because all clients will
typically receive similar configuration details, a bad actor that
initiates a DHCP request itself can learn much of such
information. As mentioned above, one threat is that the RKAP key
for a client can be learned (if the initial
Solicit/Advertise/Request/Reply exchange is monitored) and trigger
a premature reconfiguration, but this is relatively easily
prevented by disallowing direct client-to-client communication on
these networks or using [RFC7610] and [RFC7513].
Many of the attacks by rogue servers can be mitigated by making use
of the mechanisms described in [RFC7610] and [RFC7513].