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

Tomek Mrugalski <> Wed, 06 July 2016 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A5A412D516; Wed, 6 Jul 2016 06:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tcPbnA3jNiK8; Wed, 6 Jul 2016 06:59:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F04D812D179; Wed, 6 Jul 2016 06:59:31 -0700 (PDT)
Received: by with SMTP id h129so155350649lfh.1; Wed, 06 Jul 2016 06:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 206mr5962207ljj.63.1467813570140; Wed, 06 Jul 2016 06:59:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id l79sm4145052lfi.40.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 06:59:28 -0700 (PDT)
To: Yaron Sheffer <>, IETF Security Directorate <>, The IESG <>,, "Bernie Volz (volz)" <>
References: <> <> <> <>
From: Tomek Mrugalski <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 06 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: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
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, 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.


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:
> Let me know if the text addresses your comments.
> Thanks again for your thorough review.
> Tomek