draft-ietf-dhc-topo-conf-08.txt   draft-ietf-dhc-topo-conf-09.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Intended status: Informational T. Mrugalski Intended status: Informational T. Mrugalski
Expires: November 7, 2016 ISC Expires: January 9, 2017 ISC
May 6, 2016 July 8, 2016
Customizing DHCP Configuration on the Basis of Network Topology Customizing DHCP Configuration on the Basis of Network Topology
draft-ietf-dhc-topo-conf-08 draft-ietf-dhc-topo-conf-09
Abstract Abstract
DHCP servers have evolved over the years to provide significant DHCP servers have evolved over the years to provide significant
functionality beyond that which is described in the DHCP base functionality beyond that which is described in the DHCP base
specifications. One aspect of this functionality is support for specifications. One aspect of this functionality is support for
context-specific configuration information. This memo describes some context-specific configuration information. This memo describes some
such features and explains their operation. such features and explains their operation.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. Identifying Client's Location by DHCP Servers . . . . . . . . 3 3. Identifying Client's Location by DHCP Servers . . . . . . . . 3
3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7 3.1. DHCPv4 Specific Behavior . . . . . . . . . . . . . . . . 7
3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7 3.2. DHCPv6 Specific Behavior . . . . . . . . . . . . . . . . 7
4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9 4. Simple Subnetted Network . . . . . . . . . . . . . . . . . . 9
5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 11 5. Relay Agent Running on a Host . . . . . . . . . . . . . . . . 11
6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 11 6. Cascaded Relays . . . . . . . . . . . . . . . . . . . . . . . 11
7. Regional Configuration Example . . . . . . . . . . . . . . . 12 7. Regional Configuration Example . . . . . . . . . . . . . . . 12
8. Multiple subnets on the same link . . . . . . . . . . . . . . 14 8. Multiple subnets on the same link . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications The DHCPv4 [RFC2131] and DHCPv6 [RFC3315] protocol specifications
describe how addresses can be allocated to clients based on network describe how addresses can be allocated to clients based on network
topology information provided by the DHCP relay infrastructure. topology information provided by the DHCP relay infrastructure.
Address allocation decisions are integral to the allocation of Address allocation decisions are integral to the allocation of
addresses and prefixes in DHCP. addresses and prefixes in DHCP.
The DHCP protocol also describes mechanisms for provisioning devices The DHCP protocol also describes mechanisms for provisioning devices
skipping to change at page 15, line 30 skipping to change at page 15, line 30
DHCPv4 or DHCPv6 protocols and is implementation dependent. DHCPv4 or DHCPv6 protocols and is implementation dependent.
9. Acknowledgments 9. Acknowledgments
Thanks to Dave Thaler for suggesting that even though "everybody Thanks to Dave Thaler for suggesting that even though "everybody
knows" how DHCP servers are deployed in the real world, it might be knows" how DHCP servers are deployed in the real world, it might be
worthwhile to have an IETF document that explains what everybody worthwhile to have an IETF document that explains what everybody
knows, because in reality not everybody is an expert in how DHCP knows, because in reality not everybody is an expert in how DHCP
servers are administered. Thanks to Andre Kostur, Carsten Strotmann, servers are administered. Thanks to Andre Kostur, Carsten Strotmann,
Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean- Simon Perreault, Jinmei Tatuya, Suresh Krishnan, Qi Sun, Jean-
Francois Tremblay, Marcin Siodelski and Bernie Volz for their Francois Tremblay, Marcin Siodelski, Bernie Volz and Yaron Sheffer
reviews, comments and feedback. for their reviews, comments and feedback.
10. Security Considerations 10. Security Considerations
This document explains existing practice with respect to the use of This document explains existing practice with respect to the use of
Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
Configuration Protocol Version 6 [RFC3315]. The security Configuration Protocol Version 6 [RFC3315]. The security
considerations for these protocols are described in their considerations for these protocols are described in their
specifications and in related documents that extend these protocols. specifications and in related documents that extend these protocols.
This document introduces no new functionality, and hence no new
security considerations. The mechanisms described in this document could possibly be exploited
by an attacker to misrepresent its point of attachment in the
network. This would cause the server to assign addresses, prefixes
and other configuration options, which can be considered a leak of
information. In particular, this could be used a preliminary stage
of an attack, when the DHCP server leaks information about available
services in parts of the network the attacker does not have access
to.
There are several ways how such an attack can be prevented. First,
it seems to be a common practice to filter out DHCP traffic coming in
from outside of the network and one that is directed to clients
outside of the network. Second, the DHCP servers can be configured
to not respond to traffic that is coming from unknown (i.e. those
subnets the server is not configured to serve) subnets. Third, some
relays provide the ability to reject messages that do not fit
expected characteristics. For example CMTS (Cable Modem Termination
System) acting as a DHCP relay detects if the MAC address specified
in chaddr in incoming DHCP messages matches the MAC address of the
cable modem it came from and can alter its behavior accordingly.
Also, relay agents and servers that are connected to clients directly
can reject traffic that looks as if it has passed a relay (this could
indicate the client is attempting to spoof a relay, possibly to
inject forged relay options).
There are a number of general DHCP recommendations that should be
considered in all DHCP deployments. While not strictly related to
the mechanisms described in this document, they may be useful in
certain deployment scenarios. [RFC7819] and [RFC7824] provide an
analysis of privacy problems in DHCPv4 and DHCPv6, respectively. If
those are of concern, [RFC7844] offers mitigation steps.
Current DHCPv4 and DHCPv6 standards lack strong cryptographic
protection. There is an ongoing effort in DHC working group to
address this. [I-D.ietf-dhc-sedhcpv6] attempts to provide mechanism
for strong authentication and encryption between DHCPv6 clients and
servers. [I-D.volz-dhc-relay-server-security] attempts to improve
security of exchanges between DHCP relay agents and servers.
Another possible attack vector is to set up a rogue DHCP server and
provide clients with false information, either as a denial of service
or to execute man in the middle type of attack. This can be
mitigated by deplyoing DHCPv6-shield [RFC7610].
Finally, there is an ongoing effort to update DHCPv6 specification,
that is currently 13 years old. Sections 23 (Security
Considerations) and 24 (Privacy Considerations) of
[I-D.ietf-dhc-rfc3315bis] contain more recent analysis of the
security and privacy considerations.
11. IANA Considerations 11. IANA Considerations
The IANA is hereby absolved of any requirement to take any action in The IANA is hereby absolved of any requirement to take any action in
relation to this document. relation to this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
bis", draft-ietf-dhc-rfc3315bis-05 (work in progress),
June 2016.
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-12 (work
in progress), April 2016.
[I-D.volz-dhc-relay-server-security]
Volz, B. and Y. Pal, "Security of Messages Exchanged
Between Servers and Relay Agents", draft-volz-dhc-relay-
server-security-01 (work in progress), June 2016.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, DOI 10.17487/RFC3011, November 2000, RFC 3011, DOI 10.17487/RFC3011, November 2000,
<http://www.rfc-editor.org/info/rfc3011>. <http://www.rfc-editor.org/info/rfc3011>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, DOI 10.17487/RFC3046, January 2001, RFC 3046, DOI 10.17487/RFC3046, January 2001,
skipping to change at page 17, line 14 skipping to change at page 18, line 33
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>. <http://www.rfc-editor.org/info/rfc7227>.
[RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting against Rogue DHCPv6 Servers", BCP 199,
RFC 7610, DOI 10.17487/RFC7610, August 2015,
<http://www.rfc-editor.org/info/rfc7610>.
[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
April 2016, <http://www.rfc-editor.org/info/rfc7819>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016,
<http://www.rfc-editor.org/info/rfc7824>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2000 Seaport Blvd 2000 Seaport Blvd
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1-650-381-6000 Phone: +1-650-381-6000
Email: Ted.Lemon@nominum.com Email: Ted.Lemon@nominum.com
 End of changes. 8 change blocks. 
13 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/