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

Suresh Krishnan <> Wed, 29 June 2016 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EEF312D961; Wed, 29 Jun 2016 16:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LnSDjgi4bmcn; Wed, 29 Jun 2016 16:55:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18B1912DEF8; Wed, 29 Jun 2016 16:54:53 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-b6-57745f8ca336
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 70.05.03614.C8F54775; Thu, 30 Jun 2016 01:53:48 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 19:54:51 -0400
From: Suresh Krishnan <>
To: Tomek Mrugalski <>, Yaron Sheffer <>, IETF Security Directorate <>, The IESG <>, "" <>
Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08
Thread-Index: AQHRvboHXmaXobDEYkKp6QMo3tFpbA==
Date: Wed, 29 Jun 2016 23:54:51 +0000
Message-ID: <>
References: <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoG5PfEm4wc8XBhZ7u08xW8z4M5HZ 4sPChywW+68tYLJYdX8GuwOrx85Zd9k9liz5yeTx5fJntgDmKC6blNSczLLUIn27BK6Mr39N Cm4qVHw5tY+xgfGuZBcjJ4eEgIlEz5Q2FghbTOLCvfVsXYxcHEICRxklLkz/wwjhLGeUeL9u LlgVG1DHhp2fmUASIgLNTBJPFnUzgSSEBSwl3kxcxg5iiwhYSfSdngJl60l8/N4I1swioCrx eeEzMJtXwFeisXE3C8SGyYwSP2efBGtgBLrj+6k1YEOZBcQlbj2ZzwRxn4DEkj3nmSFsUYmX j/+xQthKEh9/z2eHqNeRWLD7ExuErS2xbOFrZohlghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUB I8sqRo7S4oKc3HQjw02MwAg5JsHmuINxb6/nIUYBDkYlHt4FPCXhQqyJZcWVuYcYJTiYlUR4 j8cBhXhTEiurUovy44tKc1KLDzFKc7AoifPqv1QMFxJITyxJzU5NLUgtgskycXBKNTCuOn3U oFFQveBXRVfXs9XK75ilVjf+O3rB3UTosb9YwfmdKeXeL+XFPEXcXrAecyrls3NzY+Bs5N6o bqS+44dARCo/izr/xJIv33e93/fFeuIHpl156VrPOiKylhwKWuKjWHfiW8Cyn5dvFT5IOyg9 cerVigtTTpi+2lFYcaNk494Ka7cGlblKLMUZiYZazEXFiQC2Ehq8jAIAAA==
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: Wed, 29 Jun 2016 23:55:36 -0000

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