Re: [dhcwg] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23 Wed, 17 November 2021 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AC5B3A0B2A; Wed, 17 Nov 2021 02:28:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Sjgq6jHRzgtw; Wed, 17 Nov 2021 02:28:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 936013A05E2; Wed, 17 Nov 2021 02:28:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1637144880; bh=xdOkJ1pVF2PQT1qK6FfWPfm5tbAKu4Jg/+T65d+yAKg=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=jcT44ere/EQOC5dL25M7rc0CDdrPEAm6EAWFRGvp9kRV8tnquMWoyB9bxd/8oPkGF hVRd4kyn8VPt3p3Oi/kfaXBEuAwML6EcLG1t59+EKOwR4r869x8rifFIwPrEqhsaeA 4PT0mSZQiX6+v8nkXirDxeTP5U4dxScJXU0jJ6lg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1Mqb1W-1mINFo1rWa-00mcV2; Wed, 17 Nov 2021 11:28:00 +0100
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE3DFC8-0371-4C4C-8D91-CCF8C786F9F4"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Date: Wed, 17 Nov 2021 11:27:56 +0100
In-Reply-To: <>
Cc:, dhcwg <>,,
To: Vincent Roca <>
References: <>
X-Mailer: Apple Mail (2.3693.
X-Provags-ID: V03:K1:QOY1DUrITUfXVfWEaiGtXyWz+7lOaP8/GLIjhF8QUMIzm0RRM6t EMqgG+M2ukQ5y7qXcStbygTV+7YLeE+Qd4x25jXxj12hDmGenL6NM1gvoncRkyXXEYLebiz 9taGFT/AZtygt3BqPgW1EkD80il75NLgCsS86GN3O5+SgwvPD/qj5zfVUEkINmCaKdfGMZE pBsSavuwUQGRUdqRgwepw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2FFhBuqrtn4=:HVx2Fs7PuTPOAz5yM4AMHg QjL4EjkEj+0LHgf8GjgEOvCXw+Hs1OQC+M1Mkxbt6RLIeopzLVkV4m4dIH8k4UUKPzb6yv8JB fbiHnqkZpWD5IK86e1m2PbwZRX7BQHxOtkTygBYn053h4ymhVF3nS4uuJbVA6mSbbE5nFAqLc k3/l/teNTYC04n+IZrE5xSiNBRR7xlK19jf4UEwRefVmn2cAafk3X8/HI4tL3N3PW0J5M65aK CwcRcpDtYL6bwtX3C817iwuzUCgGnmGSb7Y6/ps9UquLHKjskf6K70kwUyGiutx0kNnRf++Qo 2aIPodvWC9Q8d4Z3nuHmSLJ61utBDHUDeHIs95dlk1xd/crlNL5ce0Nrd0DFnU/hpgfK1vuUe hmxCUD3Ni7QI0h7D47w6IhXnXOWq5e+N6HxF4v+zXu8TN4FeE69JtOCDIYXRpAGLJG1FdXA2i D81TJ0nreHKQ4kt25JIQlqgWMqH/lyG/4sAI6Z+4pKB1cr08F58OmjBM/OEFYav1jkpSiknrc +yV2qB9Tx+0Ax/ZsT/dSZDiCgqeQiRv+UfeYif8d5mldV26J4IwODtSnn1fW4Fc9RMdF1vxrb orhLd4duDuD7UtCscOifomTKNda1rngdQgBjBEATkGjRICY58kwLbq1Jvph5Th2ErehiI4kj+ 8Bl/3A8YXsgE1BX0ByvoiGmQ+QGMTSrvaVuEgD7p8YM8k6bE7fQWZwpAXaKxk3J8/5jb6fL9j 09i1L8QOxeUr2fylsWtQm/mUM0Y75w3u+pMN86AsecJlkmRLbg2jZip/snD7aGMFViWW5/EfE VzFBtUyHgkAc/mHWyCZvrP3d2oMf2NgLerBUXAI38txjOEVZtlat6TD/VrH1/+5MQ+Y/6gMlH RvY1/aFjj4OX+Yuy1xvg68lBtq1pqA2v9FRBdAFNmdQGtlFkAu0fR/vBn9/kNhRWKRjJI+H8z j919PjAVPIkKUPHWMCQiOtTaLQFzZXm13nOvxDL2ifvtatvmO2Q0q3dnhriGVOIyyFG5T5Res WWsrDVCcwIEEEoQ8gvD0hBaeLgU0GfVJiRYf27JSExGDdB64mR7N5+Y6+Z7h7HLppozqa8A9K cBakuO+WHcA5To=
Archived-At: <>
Subject: Re: [dhcwg] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Dynamic Host Configuration <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Nov 2021 10:28:13 -0000

Hi Vincent,

Many thanks for your review. Please see inline below.


> On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker <> wrote:
> Reviewer: Vincent Roca
> Review result: Not Ready
> Hello,
> I have reviewed this document as part of the security directorate’s ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> Summary: Not Ready
> The Security Considerations section is globally well written, with links to
> appropriate documents. However, a few clarifications would be welcome IMHO.
> It is said: "An attacker who is able to access the DHCPv6 server" (resp. relay).
> It's not just a matter of accessing the server (resp. relay).
> As I understand it's more a matter of taking the control of the server (resp.
> relay), which is different. Please clarify.

[if - I propose:

An attacker who is able to access the DHCPv6 server can undertake
   various attacks, such as:

An attacker with read/write access the DHCPv6 server can undertake
   various attacks, such as:

Same change for the relay text."

> Then, the current text only mentions "denial of services" among the possible
> consequences. DoS are rapidly identified and fixed, and anyway, an attacker
> having full control on the DHCP server has other options to launch a DoS. I'd
> be more concerned by subtle attacks that could be used to exfiltrate sensitive
> information (maybe by redirecting to a rogue server?), or to create excessive
> traffic (maybe by changing the valid-lifetime?), or to create subtle
> dysfunctions (e.g., assigning the same IP to different clients), etc.

[if - The subtle attacks are properties of the DHCPv6 protocol and the elements which provide it,
rather than specifically associated with NETCONF/YANG or other methods by which those elements are configured
and managed. The text currently has:

"Security considerations related to DHCPv6 are discussed in [RFC8415].”

Do you think this covers it?]

> Another example: an attacker may gather information about clients, network
> topology and network devices (e.g., by looking at the OUI part of the MAC
> address). Such information can be highly helpful when preparing an orchestrated
> attack towards a target company. If this is simplified by the YANG based
> configuration in some way (I think so but you have a better understanding than
> me), then it's worth mentioning.

[if - The current Security Considerations text contains the following:

"   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  Therefore, it
   is important to control read access (e.g., only permitting get, get-
   config, or notifications) to these data nodes.  These subtrees and
   data nodes can be misused to track the activity of a host:

   *  Information the server holds about clients with active leases:

   *  Information the relay holds about clients with active leases:

MAC address/Client DUIDs and other client state information is held as part of these sub-trees.

RFC7824 specfically covers DHCPv6 Privacy Considerations in some detail, so I can add
The following text:

“[RFC7824] covers privacy considerations for DHCPv6 and is applicable here."

> To summarize, I have the feeling the current text could better illustrate some
> of the consequences of attacks, beyond DoS attacks.
> Minor comments:
> - Section 5: remove "a" or "the" in:
>        "changing the address of a the DNS server"

[if - done]

> - Section 5: "re-configuring messages" is ambiguous.
>        I think "forwarding messages to a rogue server after modifying the
>        'server-address'" (I think this is what is meant) would be more
>        appropriate.

[if - I’ve changed to the following:

Modifying the relay's "destination-address" to send               
          messages to a rogue DHCPv6 server. 

> - intro:
>        "...which is applicable device's interfaces."
>        May be: "applicable to ..."

[if - done]

> - intro, 1st paragraph:
>        You should choose to either expand both NETCONF and RESTCONF acronyms,
>        or none of them.

[if - AFAIK, RESTCONF does not have an expanded acronym (there isn’t one given in RFC8040)
The RFC Editor’s list of acronyms ( <>) has the following:

NETCONF    - Network Configuration Protocol (NETCONF) 
RESTCONF   - No Expansion 

> Cheers,
>   Vincent