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

Suresh Krishnan <> Fri, 08 July 2016 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D131127058; Fri, 8 Jul 2016 12:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nuHmV08n_39C; Fri, 8 Jul 2016 12:41:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EDFE12D0BD; Fri, 8 Jul 2016 12:41:27 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-ed-578001a36fbd
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 36.A9.03614.3A100875; Fri, 8 Jul 2016 21:40:19 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Fri, 8 Jul 2016 15:41:25 -0400
From: Suresh Krishnan <>
To: "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08
Thread-Index: AQHRvboHXmaXobDEYkKp6QMo3tFpbKAPXMMA///JNcM=
Date: Fri, 08 Jul 2016 19:41:24 +0000
Message-ID: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF643D59BFFeusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyuXRPlO5ixoZwg1m3tCz2dp9itpjxZyKz xYeFD1ks9l9bwGSxfIamxar7M9gd2Dym/N7I6rFz1l12jyVLfjJ5fLn8mS2AJYrLJiU1J7Ms tUjfLoErY+PK62wFl9Iq9i75z9jAuDKsi5GTQ0LAROLPxhnMELaYxIV769m6GLk4hASOMkrM O/CeCcJZxiix72QPI0gVG1DHhp2fwRIiAnuYJK7d/wfkcHAIC1hKPJ6QB1IjImAl0Xd6CjuM Pf3bASYQm0VARWL/o0Vgc3gFfCW+zv7IDLFgApPEq4ndrCAJTgFXifl7V4I1MAKd9P3UGjCb WUBc4taT+UwQpwpILNlzHupsUYmXj/+xQtTkS5za9o4NYoGgxMmZT1gmMArPQtI+C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxQU5uupHhJkZgjB2TYHPcwbi31/MQ owAHoxIPr8Kr+nAh1sSy4srcQ4wSHMxKIrwf/gGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+q/ VAwXEkhPLEnNTk0tSC2CyTJxcEo1MGqnZjO4rFXc/umWvLHZPe77y5n2vvraV6CzedWNs613 71r+CLie9lSmbtX97LU/g8QV43qOn2VS1bpcYVT1LeadLwub/7TOLxfdp+6XEWd3r5vec1dO rHqnTud2zXvRFkvPKadrz+m/vtKl8HZjOnvqMcaWOfd9FQzl5/7yC5jyokUt6ftjAyWW4oxE Qy3mouJEAA/A65utAgAA
Archived-At: <>
Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 19:41:31 -0000

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


-----Original Message-----
From: Bernie Volz (volz) []
Received: Friday, 08 Jul 2016, 2:57PM
To: Suresh Krishnan []; Tomek Mrugalski []; Yaron Sheffer []; IETF Security Directorate []; The IESG []; []
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 []
Sent: Wednesday, June 29, 2016 7:55 PM
To: Tomek Mrugalski <>; Yaron Sheffer <>; IETF Security Directorate <>; The IESG <>;
Subject: Re: SecDir review of draft-ietf-dhc-topo-conf-08

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


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:
> Let me know if the text addresses your comments.
> Thanks again for your thorough review.
> Tomek