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

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Wed, 22 June 2016 11:37 UTC

Return-Path: <tomasz.mrugalski@gmail.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 D8C0E126D74; Wed, 22 Jun 2016 04:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iDeuVy_KNnQY; Wed, 22 Jun 2016 04:37:40 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93C312D0FE; Wed, 22 Jun 2016 04:37:39 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id q132so72256082lfe.3; Wed, 22 Jun 2016 04:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=8iAX/TIhgzTdU88Et9iR1I26xKeEEFHIKfjiDKKQKFw=; b=n3ZeV5nfeBrEETucMxLMw19wnB9edcZ0NQwLq4tJiqf61fgfVTtZdoaYtTCrEe/hOI N/I+C7lCLWNN8wyCOfI7YDsGcxC100QYcIbbcJnRGNTSL30R+r3IqthP8VGornQIYt/0 6QTHcom+67M2fqh1WRhtgH7+XeUFOvzzpg7yvGn1Uanx64z6ESfcKkZPmPcPxuTT+EIG kbvgBI40fTCHjBZMnwsRuGVw/FCAy7ll0Obih1kHtLf+A09XgIYHKTUzxrYCkaBr7GZn SZ1284SiSryI9rRJr+LHpcGmO1gZwTb6TVlJ1FzVA2zaru1oOP40R5W3lgskexy3i8+E RWBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8iAX/TIhgzTdU88Et9iR1I26xKeEEFHIKfjiDKKQKFw=; b=fA7WIOEFQrrXYTqdDg54yi+W02OaFGJAH1WUeHNtMvrwq8oiIjm2wiioD8tkqXaP6/ /H5XwH5oerayaaTdwwn2gEUfxWsRDS0lM1fxIrkaKeVTLC3ncR7ZFsRQp18LdbGIhlDI aG+Fu8ao4BBiKSf7LQACghTXa1wY7o7ylwEUfhwL0j639MSayCvNd5GYPfBG/nDbI0pv /+D5zNsP6ghEKZQsd2FtThOKbRasx5XQnvz8YwDOA59gkc3c6Bocn60INl0Qw0LKLwFn YYQIrWpyFJeMhCgiHUdp9LC1iCwfixRNA2FlQSbCWZ0IV3MQ+CgMFeUcENQy3h6ftK6a 1mUg==
X-Gm-Message-State: ALyK8tIAOqa7f7QRXpJ//gLnuakeK/ta4x7kAEPF3CP66WfxaZTW/zcUeGF1QDfAqnY6NA==
X-Received: by 10.46.71.206 with SMTP id u197mr7673759lja.16.1466595458034; Wed, 22 Jun 2016 04:37:38 -0700 (PDT)
Received: from voyager2.local (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id z10sm1876809lbr.12.2016.06.22.04.37.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 04:37:37 -0700 (PDT)
To: 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
References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Message-ID: <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com>
Date: Wed, 22 Jun 2016 13:38:56 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <575344A7.30002@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/6lFWToBuCS2AqPi0_ni7sgBlcpk>
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, 22 Jun 2016 11:37:42 -0000

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