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

"Bernie Volz (volz)" <> Fri, 08 July 2016 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D23BD12D620; Fri, 8 Jul 2016 11:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbEn9EvMCCc7; Fri, 8 Jul 2016 11:57:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AF5812D59E; Fri, 8 Jul 2016 11:57:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4454; q=dns/txt; s=iport; t=1468004254; x=1469213854; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KpUdb+BLHtNLpnYYJICcPzyYl476vLfQqzndjwmjeww=; b=fmlX1zUNvzb2sLJJX88qcqzadeAM4Wq8oxr1NeFn7JRRxJCBgdsxdXdy R8KTLtDf9oO1+JyIhhcKCcWoW5kQ9JYbPcR2KRLxDdfCeheoKWwDOqYNQ vEfle4DZgiUOMvdxK764PD3nUvavRtPXjkViU/F/TcrHmSr8oSiKZ3luE A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,331,1464652800"; d="scan'208";a="294607502"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 18:57:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u68IvXIL017312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 18:57:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 13:57:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 13:57:32 -0500
From: "Bernie Volz (volz)" <>
To: Suresh Krishnan <>, Tomek Mrugalski <>, Yaron Sheffer <>, IETF Security Directorate <>, The IESG <>, "" <>
Thread-Topic: SecDir review of draft-ietf-dhc-topo-conf-08
Thread-Index: AQHRvqYM69lblI6d7UyJqU61VCq4X6APF5Xw
Date: Fri, 08 Jul 2016 18:57:32 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 18:57:37 -0000

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