Internet DRAFT - draft-ietf-dhc-dhcpinform-clarify
draft-ietf-dhc-dhcpinform-clarify
Dynamic Host Configuration Working D. Hankins
Group Google
Internet-Draft October 1, 2011
Updates: 2131 (if approved)
Intended status: Standards Track
Expires: April 3, 2012
Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications
draft-ietf-dhc-dhcpinform-clarify-06
Abstract
The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the current defined standard. This
document seeks to provide clarification of actual behaviour and
guidance for some situations that were previously omitted.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Hankins Expires April 3, 2012 [Page 1]
Internet-Draft DHCPINFORM Clarify October 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 4
4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hankins Expires April 3, 2012 [Page 2]
Internet-Draft DHCPINFORM Clarify October 2011
1. Introduction
The most recent DHCPv4 Standard [RFC2131] added a new DHCPv4 message:
DHCPINFORM. The intent of the DHCPINFORM message was for clients
that used manually entered fixed IPv4 addresses to still be able to
get some configuration state dynamically. Since that time, however,
we have seen this message used by normal DHCPv4 dynamically addressed
clients; clients that have previously succeeded in receiving
configuration through DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and
finally DHCPACK messages.
These clients are attempting DHCPINFORM messages in order to obtain
additional configuration state that was not present in their lease
binding. The discovery is that DHCPINFORM can be used to reach extra
DHCP servers, other than the one that gave an address, which may have
more configuration options available but aren't in a position to give
addresses. This extra configuration state is often required by
applications that were not running at system startup, when the DHCP
client was initialized, and supplied by servers or services bundled
with a product that cannot easily be integrated with the network's
existing DHCP infrastructure and so are provided separately.
Some of these DHCPINFORM clients have surfaced which run with
stripped down user priveleges, but still perform some network related
functions. This software does not have the capacity to determine its
IPv4 address(es), nor does it know what interface(s) are present on
the system, or their hardware addresses. But it can send and receive
DHCP packets. Consequently, the 'ciaddr' and 'chaddr' fields have
been witnessed to be empty, even though they appear to be required to
be filled by RFC 2131. Clarification is sought for server behaviour
when ciaddr is zero.
Another set of DHCP clients set the 'chaddr' field to a fixed magic
value, rather than the client's hardware address, identifying them as
part of a vendor's product. Although the 'chaddr' contents were
never defined by any IETF RFC to be a valid place to store 'Vendor
Identifying Information', their implementors believed this field was
unused by the DHCP protocol in specific regards to DHCPINFORM because
a server would determine the client's hardware address through normal
UDP unicast methods; IP forwarding leading to ARP [RFC0826]
processing or similar.
We also wish to clarify a DHCPv4 server's behaviour when it receives
a DHCPINFORM via a relay (when 'giaddr' is non-zero). Section 4.1 of
the DHCPv4 specification [RFC2131] seems to include
DHCPINFORM->DHCPACK exchanges by describing generic behaviour for all
DHCPOFFER and DHCPACK replies, and it requires that if 'giaddr' is
non-zero that it "MUST" be used. But this advice does not work in
Hankins Expires April 3, 2012 [Page 3]
Internet-Draft DHCPINFORM Clarify October 2011
practice (due to BOOTP Relay Agent [RFC1542] requirements to use
'yiaddr' field contents, which MUST be zero as also per [RFC2131]).
Furthermore, this guidance conflicts with [RFC2131] Section 4.3.5,
which directs that the server replies directly to the 'ciaddr'
contents when responding to DHCPINFORM, and makes no other directions
for other header fields. As a result, it also does not adequately
describe current operational deployments of the DHCPINFORM message
exchange which definitely direct replies directly to 'ciaddr' and may
(it has not been concretely determined) direct replies to the
'giaddr' first.
2. Requirements Language
In this document, the key words "MAY", "MUST", "SHALL", "MUST NOT",
"SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP
14, RFC 2119 [RFC2119].
3. Client Behaviour
Clients are still required to fulfill the DHCPv4 requirements for
DHCPINFORM messages ([RFC2131], Sections 4.4.1 and 4.4.3). But the
following are clarified as in addition, or to overlay those
requirements:
o Clients MUST set 'ciaddr' to a working IPv4 address which they can
use to receive replies. This address SHOULD be an address that is
currently assigned to the interface upon which the client is
transmitting its DHCPINFORM, except in the condition where the
DHCP client is unable to determine a valid IP address for its
host, in which case the client MUST set 'ciaddr' to all-zero.
o Clients MUST set 'chaddr', 'htype', and 'hlen' to the hardware
address of the interface upon which the DHCPINFORM message is
being transmitted, except in the condition where the DHCP client
is unable to determine this address, in which case all three
fields MUST be set all-zero.
o Clients MUST set the 'flags' field to zero. This means that the
client MUST NOT set the 'BROADCAST' flag, and MUST be capable of
receiving IP unicasts.
o Clients SHOULD direct their DHCPINFORM via unicast UDP to the IPv4
address contained in the Server Identifier [RFC2132] option, if
they have a currently active binding from previous DHCPREQUEST
message exchanges. It MAY be unicast to a known DHCP server, or
otherwise broadcast to the appropriate IPv4 broadcast address on
Hankins Expires April 3, 2012 [Page 4]
Internet-Draft DHCPINFORM Clarify October 2011
the interface being configured.
4. Server Behaviour
DHCPv4 server behaviour in processing DHCPINFORM messages is a more
difficult question to answer, due to inconsistent client behaviour
and conflicting directions in RFC 2131. The following is intended to
be a more complete reference.
First, upon receiving a DHCPINFORM, a DHCPv4 Server MUST determine
the client's "relevant IPv4 address" according to the following in
order of priority:
1. The Subnet Selection Option [RFC3011], if it is present.
2. The 'ciaddr' field, if it is non-zero.
3. The Relay Agent Link Selection Sub-Option [RFC3527], if it is
present in a Relay Agent Information Option [RFC3046].
4. The 'giaddr' field, if it is non-zero.
5. The IPv4 source address field, if it is non-zero.
6. The DHCPv4 Server's address on the interface on which the
DHCPINFORM was received.
The DHCPv4 server checks to see if the "relevant IPv4 address" is
within a range or subnet over which it holds authority, or if it is
configured to respond. It will manufacture a DHCPACK response with
configuration values appropriate for the "relevant IPv4 address". If
the "relevant IPv4 address" is from the 'ciaddr' field (because the
Subnet Selection Option was not provided, and the 'ciaddr' field is
non-zero), the server MAY also inspect that address's current lease
in order to source configuration specific to the host, but MUST NOT
modify the lease in any way.
In the DHCPACK reply:
o The 'htype', 'hlen', 'chaddr', 'ciaddr', 'xid', 'flags' (with the
exception noted below), and 'giaddr' fields MUST be copied from
the client's DHCPINFORM.
o The 'hops' field MUST be zero.
o The 'secs' field MUST be zero.
Hankins Expires April 3, 2012 [Page 5]
Internet-Draft DHCPINFORM Clarify October 2011
o The 'yiaddr' field MUST be zero.
o The 'siaddr' field MUST be zero.
o The 'sname' and 'file' fields MAY be used exclusively for 'option
overloading', but MUST be all-zero otherwise.
o The 'options' field MUST be filled as described in RFC 2131
Section 4.3.1.
Next, the DHCPv4 server MUST determine the "reply address and port"
according to the first of the following conditions it finds a valid
reply address for, in order:
1. If the 'ciaddr' field is non-zero, the server selects its
contents as an IPv4 address and port 68 ('DHCP client').
2. If the 'giaddr' field is non-zero, the server selects its
contents as an IPv4 address and port 67 ('DHCP server').
3. If the IPv4 source address field is non-zero, the server selects
its contents as an IPv4 address and port 68 ('DHCP client')
4. The server selects the limited broadcast address (all-ones) and
port 68 ('DHCP client').
At this point, the DHCPv4 server verifies that it holds configuration
authority over the reply address (or link in case of limited
broadcast address) it has selected to transmit the reply to. If the
server has not been configured to hold authority over this address,
it MUST NOT reply. It SHOULD increment a counter visible to the
operator but SHOULD NOT log an error (unless a mechanism is used to
suppress repeated log messages). See the Security section
(Section 5) for the rationale behind this direction.
Note very carefully that a DHCPv4 server will send replies directly
to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message
was relayed. Note that this means DHCPINFORM processing is
intentionally broken in deployments where the client's address space
is unreachable by the DHCPv4 server. In such cases, the server
should probably be configured not to reply to DHCPINFORMs.
Now, the server performs an exception to assist relay agents. If it
selected the 'giaddr' as the destination address and port, then it
MUST set the 'BROADCAST' bit in the flags field true, no matter what
its value was in the client's DHCPINFORM message, without altering
the other bits of the flag field. Otherwise, the response could not
be delivered; a BOOTP Relay Agent [RFC1542] is required to direct
Hankins Expires April 3, 2012 [Page 6]
Internet-Draft DHCPINFORM Clarify October 2011
unicast server replies to the 'chaddr' and 'yiaddr' field contents,
but 'chaddr' is not reliably filled, and 'yiaddr' is required to be
all-zero. Setting the broadcast flag assists the relay agent in
locating the client by informing it to perform a local limited
broadcast.
Having selected a destination IPv4 address and port number, the last
step is to select a destination link layer address.
For the all-ones limited broadcast address, the DHCPv4 server MUST
use the all-ones broadcast hardware address.
For all other (unicast) destination selections, the DHCPv4 server
MUST use its host operating system's usual methods to determine
hardware addressing, as by IP forwarding and subsequent address
resolution (such as through ARP [RFC0826]). Note that the DHCPv4
server MAY have seeded its ARP cache from a previous stateful
exchange with the client (from 'chaddr' contents while processing a
DHCPREQUEST message, due to the requirement of DHCPv4 servers to
unicast some replies before clients will process ARP), and some
DHCPv4 software MAY still use 'chaddr' contents to direct replies to
directly connected clients. Consequently, DHCPINFORM can not be
reasonably expected to instigate an immediate ARP broadcast, nor can
'chaddr' contents be used for any purpose other than to carry the
unicast hardware address with which a client might reasonably be
reached.
5. Security Considerations
As with all DHCP messages, DHCPINFORM and DHCPACK replies contain no
capacity for encryption, and all packet contents must be presumed
readable in the clear. In particular, and as outlined above, in some
circumstances the packets may be broadcast and so more easily
intercepted than most other messages.
Authentication for DHCPv4 Messages [RFC3118] does exist, but is not
well deployed. Care should be taken in the degree to which
configuration parameters provided by DHCPv4 are trusted, as the
replies can be easily spoofed by any eavesdropper. Again noting that
packets may be broadcast under some circumstances, the BOOTP header
Transaction Id field ("XID") is insufficient protection from man-in-
the-middle attacks.
A relay agent receives replies via unicast UDP messages from a DHCP
server, and may broadcast these packets on the inside-facing network.
If an outside attacker was aware of this relay agent and its unicast
address, this facility could be used to produce broadcast storms on
Hankins Expires April 3, 2012 [Page 7]
Internet-Draft DHCPINFORM Clarify October 2011
the network. Care should be taken to ensure that the relay agent is
not open to this kind of attack, possibly making use of Relay Agent
Authentication [RFC4030] to ensure that a DHCPv4 server can not be
induced to sending bogus replies to the relay.
This protocol uses the 'ciaddr' field contents to direct replies,
which may be set blindly by the client to any value, regardless of IP
source address validation or related filter restrictions. If an
attacker were to identify a number of DHCPv4 servers which reply to
addresses not under their authority to configure, and those servers
had enough large DHCPv4 options in configuration to request, it could
represent a significant amplification vector in straight packet-load
Denial-of-Service attacks. For this reason, servers MUST NOT make
replies to addresses not explicitly configured under their authority
to configure.
6. IANA Considerations
This document has no action for IANA.
7. Acknowledgements
This document has been reviewed and improved by the comments of
several people, but the author would like to take a moment to thank
Alfred Hoenes, who has submitted revised text for this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
Hankins Expires April 3, 2012 [Page 8]
Internet-Draft DHCPINFORM Clarify October 2011
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
8.2. Informative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
the Dynamic Host Configuration Protocol (DHCP) Relay Agent
Option", RFC 4030, March 2005.
Author's Address
David W. Hankins
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA
Email: dhankins@google.com
Hankins Expires April 3, 2012 [Page 9]