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