Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08

[Tomek Mrugalski <[e-mail]>]

Hi Yaron,

Thanks again for your review. I came up with a proposed text for the
security considerations text. There's not much left from the original
text, so here's the whole proposed section:

10.  Security Considerations

   This document explains existing practice with respect to the use of
   Dynamic Host Configuration Protocol [RFC2131] and Dynamic Host
   Configuration Protocol Version 6 [RFC3315].  The security
   considerations for these protocols are described in their
   specifications and in related documents that extend these protocols.

   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 attack, when the DHCP server leaks information about available
   services in networks that 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.

   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.

If you prefer to see the whole document, the unpublished -09 is
available here:
https://github.com/tomaszmrugalski/ietf-topo-conf/blob/master/draft-ietf-dhc-topo-conf-09.txt

Let me know if the text addresses your comments.

Thanks again for your thorough review.

Tomek