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

[Tomek Mrugalski <[e-mail]>]

Hi Yaron,
I have not heard back from you whether the proposed text is satisfactory
for you. If I don't hear anything back, I'll upload the text as -09 on
Friday (which is the submission deadline).

One other thing pointed out was that the reference to RFC7610 (DHCPv6
guard) was indirect (topo-conf referenced rfc3315bis that references
7610), so I will add a direct reference:

   Many attacks based on rogue DHCPv6 servers can be mitigated by
deploying DHCPv6-Shield mechanism described in RFC7610.

Tomek

On 22.06.2016 13:38, 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
>