Re: [dhcwg] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23

ianfarrer@gmx.com Wed, 17 November 2021 16:01 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7459C3A0794; Wed, 17 Nov 2021 08:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 gMSVCNt6ecCI; Wed, 17 Nov 2021 08:01:28 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87CC3A0799; Wed, 17 Nov 2021 08:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637164884; bh=BtSxbisDo27os5NymNC7GcjNg9pdJ6THDQaTr4ss9mI=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=OvABiB53txgS8ZUW33lULxO4JSsps4jKHr/6oP0A9ERQqGAnMYJFhq/1Pkx+MN7tz NtDn5RqdCNi6ahYv7in0cSRI5TXJ+4CrrJM6vuB4cguVMu3FIK44JviuB8/bhqbA25 b+clsadPrSGJBvVBASb2ZgJujrMtnw0ac5Xrusgk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from smtpclient.apple ([87.78.165.90]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N5GE1-1mdMuc3fkr-0118UQ; Wed, 17 Nov 2021 17:01:23 +0100
From: ianfarrer@gmx.com
Message-Id: <2F867726-7AB5-4959-B9B1-124D05B8CBDC@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_582B3F25-47BB-43B8-B7D7-90DA573FF527"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
Date: Wed, 17 Nov 2021 17:01:22 +0100
In-Reply-To: <66A97B88-777B-43D5-A0B2-02ACB8297378@inria.fr>
Cc: secdir@ietf.org, dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org
To: Vincent Roca <vincent.roca@inria.fr>
References: <163713848820.18649.9224727643938761782@ietfa.amsl.com> <83B0FF38-8180-4B5D-AE41-48E8AB7DA4A6@gmx.com> <66A97B88-777B-43D5-A0B2-02ACB8297378@inria.fr>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
X-Provags-ID: V03:K1:9MjSuzEidHD15qMoW2OKIFtrCoLB+w49t1R6P7TVkAn3N53H+yi yP8IMdM/dtG3JPCQiLt4xmCEa9FuQDcXl1KiIB/Xw+jxJkZfWVUw1vuXQOmdB5+Arv+USP7 SpTH7APtpoNPRh3lpWlMEKMKubsNA4eC/dCCqop4w0sJ6c1toLC170ewPgCjC9Jk9uaJBXc PSZIrsBt3zL7JJ3uYKt9w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:L8itNGKl9qc=:59cq76BSTnCyF5Lkk5sbrB T+XCS0lSPzaROv1KdJsP4x6g046B75c7dabAP1TkhsBVZ5R+S/wk8cey69Eglj+qekzr8KDLE TkIQmJCf5ZjS1jrIZ8EQmHfYPjHr6MTc9QPL9GE9fHyycs7IAgAba9jIYn3eCiK30nJiyfEXS fynJsUtoxTCOJECEcLJOzzmIoHYFoIl1iIah3DCn0mjmi1C1kfh5zpORQW/XW6Zs2amixmVMB 71RhpzW1nZ0AY5U9/DeMsDUqLXr7J0wT843GkrRHaPn5yleszHDlJWYuN336qIK02u6Yvo4hH nz7syXGohjs4mXQh64WXVyA42gi7VesEYMIuxxYsDjVjZxj4ZN8549YJDOBflJg25hx7lK6TH z8F1s7Z/oeKwZDTea3uPS7PRWml/7+ns1YoHC8C1ARFBvQII9eQOl0kr2DWAM+POCq0PuB26i iv/kjVhKhNXDQxmYS/AlUQLdxGLhrLqEF1tW10NiRvxKM/97+nPVvrtPn8iMkqGtR2FDVph/d /UU43l+GWiJB3cn0ptkpxzYBZGx8PM+XLNwrm1bRtyd/OR2JaBWHAbepQRdXFHETT8jpzSbY2 V6WPeIkHzo1luea0vQ23edcSrX3kpYaIgj/+I1gwbgZkjqtTwu5QgMWDgNIIMRVvIJXbggWuL ItXcoepDPhHr9XcgLabUHvEXZE4ULgV7ddttzu2Be9bzcwnxJIp97t7jIbflzjkdfZZ/TNbmo WUMTw2WckJZHu24EpIKaNHusnzYMk83ru0ZgV7NIVuNjzQHlqbhHHyIxgE1BI2MipAMoiWPYN yNGBSx46kJwSdxrhdoKKUkDEDEUp0aPIvbSS4G+5FOGK5OOoKQSwMZm3XRO30CTsDx3Nidiga tV+j9R2AG+BtIUvoA44aPQvmQfYT1szR3FRc7BwJXhHA5mgFXNY1kPLoVC/l5bEeR6/JwpZWi M+peMkDSCJdJ7vksEI55fciJwOrB2gEqVkrLlr62YegWee7oNhGTbtcwhNrs6nCM8brd6EY/j N2G75yNCTtuZS71LEdWbooYZp42wjb7t0PTjuH5117WWHP8LQJXFRupYlfbO84NvMzFHAwHtt T9VK9gZuSk24us=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/e8fh5ws8kzvNAwrxGz1zpXKJpgc>
Subject: Re: [dhcwg] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 16:01:34 -0000

Hi Vincent,

Thanks for your reply. The agreed changes will be in the next version.

Cheers,
Ian

> On 17. Nov 2021, at 14:38, Vincent Roca <vincent.roca@inria.fr> wrote:
> 
> Thank you for your quick answer Ian.
> 
> 
>> Hi Vincent,
>> 
>> Many thanks for your review. Please see inline below.
>> 
>> Cheers,
>> Ian
>> 
>>> On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> 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:
>> 
>> Old:
>> An attacker who is able to access the DHCPv6 server can undertake
>>    various attacks, such as:
>> 
>> New:
>> An attacker with read/write access the DHCPv6 server can undertake
>>    various attacks, such as:
>> 
>> Same change for the relay text."
>> ]
> 
> VR: yes, I now understand what you meant. 
> 
> 
>>> 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?]
> 
> VR: if I follow your logic and if I correctly understand, DoS attacks are already discussed
> in RFC 8415 and could be removed from this document since there’s nothing specific to YANG.
> My point is to highlight that risks are not limited to DoS, unlike what is currently suggested. 
> 
> Maybe:
> 
> Old:
>    *  Various attacks based on re-configuring the contents of DHCPv6
>       options.  For example, changing the address of a the DNS server
>       supplied in a DHCP option to point to a rogue server.
> 
> New:
>    *  Various attacks based on re-configuring the contents of DHCPv6
>       options, leading to several types of security or privacy threats.  
>       For example, changing the address of a the DNS server
>       supplied in a DHCP option to point to a rogue server.

[if - Done]

> 
> 
>>> 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:
>>       (dhc6-srv/allocation-ranges/allocation-range/address-pools/
>>       address-pool/active-leases)
>> 
>>    *  Information the relay holds about clients with active leases:
>>       (dhc6-rly/relay-if/prefix-delegation/)
>> 
>> 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."
>> ]
> 
> VR: indeed, RFC 7824 is a key reference and must be referenced by your document.
> 	Thanks for adding it.
> 
> 
>>> 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. 
>> ]
> 
> VR: yes.
> 
>> 
>>> - 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 (https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>) has the following:
>> 
>> NETCONF    - Network Configuration Protocol (NETCONF) 
>> RESTCONF   - No Expansion 
>> ]
> 
> VR: okay, forget what I said, I was not aware.
> 
> Cheers,
> 
>    Vincent