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.
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.
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.
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"
- 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.
- intro:
"...which is applicable device's interfaces."
May be: "applicable to ..."
- intro, 1st paragraph:
You should choose to either expand both NETCONF and RESTCONF acronyms,
or none of them.
Cheers,
Vincent
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
