| Hi Vincent,
Thanks for your reply. The agreed changes will be in the next version.
Cheers, Ian
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@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." ]
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)
NETCONF - Network Configuration Protocol (NETCONF) RESTCONF - No Expansion ]
VR: okay, forget what I said, I was not aware. Cheers,
Vincent
|
