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

[Vincent Roca <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 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.


>> 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