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

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Wed, 06 July 2016 13:59 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 5A5A412D516; Wed, 6 Jul 2016 06:59:34 -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 tcPbnA3jNiK8; Wed, 6 Jul 2016 06:59:32 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 F04D812D179; Wed, 6 Jul 2016 06:59:31 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id h129so155350649lfh.1; Wed, 06 Jul 2016 06:59:31 -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=8jyqZZ86M4cVA5NSoihzWivuaIuPIdhKnDqftpHz9IE=; b=mr18NM4pi6HXOFhb7TDmjJZGpfSJ7OeUG/fQ5TOgP5AeylxNi/+kkTlihOAeNhLxtW gDIdFTm+lbOI5UALgREXdEG+7twkpU1bsaFFchuuWDW7XYMwxVCmN5akiE2z4l7awh89 7v5TbIHy/sMsIlQqTimg0KhmYpyr3zP0oaAHLjG4JdKILGSWgvNaeTHY6pEnExdMVbDm GDGpGpTPqJKVjK4Gf0W+JjWHVCvAlcYAkkKFCUm5gEeX9lagWu9G2/2QAnyIK6e5JHq3 4bZvKXrCe26Tng/2aoXn+lGFMboVV9XE0c1+g7tNGvPuau73J+i/nIo4wHImBlMj6bSe txNA==
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=8jyqZZ86M4cVA5NSoihzWivuaIuPIdhKnDqftpHz9IE=; b=Ln7z23gREnZP3hYN4oWcFDSrYlOPUbf7gxgjLwNCkfin8aban9WL8aiCtYXK4MM7/S rfv9LBlr62MWTP2djq/GbgerkH3vQLvXLfwle3I1adbvWY8dz39LLKQFlA9MbLNVZh1H Mqqz8Sdxl1QCSz+cqWzyMo9FRDSfOUwyuHele7OjhX0v+z0t86eWKHjnsYN1gx2uX90M eVRErwCSPbiqj8I5VzpgDK0YE0ZFVuDXLerAynmBs7POHNcFNv4lTLEhbcsFEUM8W9K9 6LR4FAqxQ7SYtdPFG/93nIf1DFB3mVWN456Jcp5QkGjDgakPcyWYR/n8rqlIuE0JpKXP OJ1Q==
X-Gm-Message-State: ALyK8tIuPk2EHGSBdeZj3B17jvvxUIYA7S1wtm0VuatqHBgXpWuHLkpC9+slT8Ck3MJpNg==
X-Received: by 10.46.9.215 with SMTP id 206mr5962207ljj.63.1467813570140; Wed, 06 Jul 2016 06:59:30 -0700 (PDT)
Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id l79sm4145052lfi.40.2016.07.06.06.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 06:59:28 -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, "Bernie Volz (volz)" <volz@cisco.com>
References: <5751B895.1070400@gmail.com> <5751D4E6.6000709@gmail.com> <575344A7.30002@gmail.com> <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <577D0EBC.2070800@gmail.com>
Date: Wed, 6 Jul 2016 15:59:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <504107ae-7f75-3ba7-afbd-7ed1f104f0b4@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KwGDJWDFVN8Rl6SCIp_wo9RaBIg>
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, 06 Jul 2016 13:59:34 -0000

Hi Yaron,
I have not heard back from you whether the proposed text is satisfactory
for you. If I don't hear anything back, I'll upload the text as -09 on
Friday (which is the submission deadline).

One other thing pointed out was that the reference to RFC7610 (DHCPv6
guard) was indirect (topo-conf referenced rfc3315bis that references
7610), so I will add a direct reference:

   Many attacks based on rogue DHCPv6 servers can be mitigated by
deploying DHCPv6-Shield mechanism described in RFC7610.

Tomek

On 22.06.2016 13:38, 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
>