Security of Messages Exchanged between Servers and Relay Agents
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
United States of America
volz@cisco.com
Cisco Systems
Cessna Business Park
Varthur Hobli, Outer Ring Road
Bangalore
Karnataka
560103
India
yogpal@cisco.com
Internet
Network Working Group
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has
no guidance for how to secure messages exchanged between servers
and relay agents. The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) states that IPsec should be used to secure
messages exchanged between servers and relay agents but does not
require encryption. With recent concerns about
pervasive monitoring and other attacks, it is appropriate to
require securing relay-to-relay and relay-to-server communication
for DHCPv6 and relay-to-server communication for DHCPv4.
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4)
and the Bootstrap Protocol have
no guidance for how to secure messages exchanged between servers
and relay agents. The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) states that IPsec should
be used to secure messages exchanged between servers and relay agents
but does not recommend encryption. With recent concerns about
pervasive monitoring , it is appropriate
to require use of IPsec with encryption for relay-to-server communication
for DHCPv4 and require use of IPsec with encryption for relay-to-relay and
relay-to-server communication for DHCPv6.
This document specifies the optional requirements for relay agent and
server implementations to support IPsec authentication and encryption
and recommends that operators enable this IPsec support.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
This document uses terminology from ,
, and .
For DHCPv6 , this specification REQUIRES relay and
server implementations to support IPsec encryption of relay-to-relay and
relay-to-server communication as documented below. The remainder of this section replaces
the text in Section 21.1 of when this specification
is followed.
For DHCPv4 , this specification REQUIRES relay and
server implementations to support IPsec encryption of relay-to-server
communication as documented below.
This specification RECOMMENDS that operators enable IPsec for this
communication.
By using IPsec with encryption for this communication, potentially sensitive
client message and relay included information, such as the DHCPv4 Relay Agent
Information option (82) , vendor-specific information
(for example, the options defined in ), and
Access-Network-Identifier
option(s) , are protected from pervasive monitoring
and other attacks.
Relay agents and servers MUST be able to exchange messages using the
IPsec mechanisms described in with the
conditions below. If a client message is relayed through multiple relay
agents (relay chain), each of the relay agents MUST have established
independent, pairwise trust relationships. That is, if
messages from client C will be relayed by relay agent A to relay
agent B and then to the server, relay agents A and B MUST be
configured to use IPsec for the messages they exchange, and relay
agent B and the server MUST be configured to use IPsec for the
messages they exchange.
Relay agents and servers use IPsec with the following conditions:
Relay agents are manually configured with the addresses
of the relay agent or server to which DHCP messages are to be
forwarded. Each relay agent and server that will be using IPsec for
securing DHCP messages MUST also be configured with a list of the
relay agents to which messages will be returned. The selectors for the
relay agents and servers will be the pairs of addresses defining relay
agents and servers and the direction of DHCP message exchange on DHCPv4
UDP port 67 or DHCPv6 UDP port 547.
Relay agents and servers MUST use IPsec in
transport mode and use Encapsulating Security Payload (ESP).
This document
REQUIRES combined mode algorithms for ESP authenticated encryption,
ESP encryption algorithms, and ESP authentication algorithms as per
Sections 2.1, 2.2, and 2.3 of , respectively.
Encryption is required as relay agents may forward unencrypted
client messages as well as include additional sensitive information,
such as vendor-specific information (for example,
the options defined in ) and the
Access-Network-Identifier Option defined in
.
Because both relay agents and servers
tend to be managed by a single organizational entity, public key
schemes MAY be optional. Manually configured key management MAY
suffice but does not provide defense against replayed messages.
Accordingly, Internet Key Exchange Protocol Version 2 (IKEv2) with pre-shared secrets SHOULD be
supported. IKEv2 with public keys MAY be supported. Additional
information on manual vs. automated key management and when one
should be used over the other can be found in
.
DHCP messages between relay agents and
servers MUST only be accepted from DHCP peers as identified in the local
configuration.
Shared keys, indexed to the source IP
address of the received DHCP message, are adequate in this application.
Note: As using IPsec with multicast has additional complexities (see
), relay agents SHOULD be configured to forward
DHCP messages to unicast addresses.
The security model specified in this document is hop by hop. For DHCPv6, there
could be multiple relay agents between a client and server, and each of these
hops needs to be secured. For DHCPv4, there is no support for multiple relays.
As this document only mandates securing messages exchanged between relay agents
and servers, the message exchanges between clients and the first-hop relay
agent or server are not secured. Clients may follow the recommendations in
to minimize what information they expose or make
use of secure DHCPv6 to secure communication
between the client and server.
As mentioned in Section 14 of , the following
are known limitations of the usage of manual keys:
As the sequence numbers cannot be negotiated, replay
protection cannot be provided. This leaves DHCP insecure against
all the attacks that can be performed by replaying DHCP packets.
Manual keys are usually long lived (changing them
often is a tedious task). This gives an attacker enough time to
discover the keys.
It should be noted that if the requirements in this document are followed,
while the DHCP traffic on the wire between relays and servers is encrypted,
the unencrypted data may still be available through other attacks on the
DHCP servers, relays, and related systems.
Securing these systems and the
data in databases and logs also needs to be considered on both the systems
themselves and when transferred over a network (i.e., to network attached
storage for backups or to operational support systems).
Use of IPsec as described herein is also applicable to Lightweight DHCPv6
Relay Agents , as they have a link-local
address that can be used to secure communication with their next-hop
relay(s).
This document makes no request of IANA.
Secure DHCPv6
CableLabs' DHCP Options Registry
CableLabs
The motivation for this document was several IESG DISCUSSes on recent
DHCP relay agent options.
Thanks to Kim Kinnear, Jinmei Tatuya, Francis Dupont, and Tomek
Mrugalski for reviewing and helping to improve the document.
Thanks to the authors of for the original
Section 21.1 text.