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

[ianfarrer@xxxxxxx]

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@xxxxxxxx> 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) has the following:

NETCONF    - Network Configuration Protocol (NETCONF) 

RESTCONF   - No Expansion 

]

Cheers,

  Vincent

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call