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

[[e-mail]]

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

[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