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

[Suresh Krishnan <[e-mail]>]

Hi Bernie,
Yep. I saw the 09 draft got published this afternoon and I will be moving it along the process.

Thanks
Suresh

-----Original Message-----
From: Bernie Volz (volz) [[e-mail]]
Received: Friday, 08 Jul 2016, 2:57PM
To: Suresh Krishnan [[e-mail]]; Tomek Mrugalski [[e-mail]]; Yaron Sheffer [[e-mail]]; IETF Security Directorate [[e-mail]]; The IESG [[e-mail]]; [e-mail] [[e-mail]]
Subject: RE: SecDir review of draft-ietf-dhc-topo-conf-08

Hi Suresh:

In case you missed it (perhaps Tomek sent you email), but Tomek did publish the 09 with the revised security considerations text ... So if you can move this document forward, would be great!

- Bernie

-----Original Message-----
From: Suresh Krishnan [mailto:[e-mail]]
Sent: Wednesday, June 29, 2016 7:55 PM
To: Tomek Mrugalski <[e-mail]>; Yaron Sheffer <[e-mail]>; IETF Security Directorate <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: Re: SecDir review of draft-ietf-dhc-topo-conf-08

Hi Yaron,
   Any thoughts on this new text? Does this address your concerns?

Thanks
Suresh

On 06/22/2016 07:37 AM, Tomek Mrugalski wrote:
> 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
>
>