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

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 29 June 2016 23:55 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEF312D961; Wed, 29 Jun 2016 16:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnSDjgi4bmcn; Wed, 29 Jun 2016 16:55:34 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B1912DEF8; Wed, 29 Jun 2016 16:54:53 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-b6-57745f8ca336
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.05.03614.C8F54775; Thu, 30 Jun 2016 01:53:48 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Wed, 29 Jun 2016 19:54:51 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-dhc-topo-conf.all@tools.ietf.org" <draft-ietf-dhc-topo-conf.all@tools.ietf.org>
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: <E87B771635882B4BA20096B589152EF643D48090@eusaamb107.ericsson.se>
References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com> <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
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: <https://mailarchive.ietf.org/arch/msg/secdir/AU4e0Hmcnt0CeL40UQABDoQYJns>
Subject: Re: [secdir] SecDir review of draft-ietf-dhc-topo-conf-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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?

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
>
>