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

[[e-mail]]

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]> 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."
]

> 
> 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:
      (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."
]

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

> 
> Cheers,
> 
>   Vincent
> 
>