[Text copied from https://datatracker.ietf.org/doc/review-ietf-opsec-v6-21-opsdir-lc-chown-2019-12-06/ ]
Tim, The 2nd batch of your comments, this time on the previous version -21. Look for EV> Again, thank you for having spent valuable time to review our document. Regards -éric -------- Start of OPS-DIR review ------ I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft analyses operational security issues related to the deployment of IPv6, and describes appropriate mechanisms and practices to mitigate potential threats. I had previously reviewed the draft as an OPS-DIR Early Review in July 2018, as detailed in https://mailarchive.ietf.org/arch/msg/opsec/6s_YFrXNPwtbQRe62D3_AtXb6as, but I don’t see any evidence of these comments being acted upon, or any response, so as far as I can see, the comments in this review still apply, and I would urge the authors to review these comments. EV> we clearly forgot about this… review analyzed and acted upon earlier today That said, there have been a number of improvements to the draft in the past 18 months, and overall it is a much better document for those changes. The question is at what point the WG should simply ship the draft as “good enough”, rather than try to improve it further. At the moment I think the document is Not Ready, though it’s getting nearer to being Ready with Nits. General comments: There are a number of typos / grammatical errors in the document. While the RFC Editor will correct, e.g., in the abstract - “mitigations” should be singular, in the intro “with that have been”, in 2.1 “of address space available” (add “is”), “allow” should be “allows”. Just needs a careful proof read. EV> hopefully done (with the assistance of MS-Word...) Specific comments: Abstract: “places” should be “aspects” or similar. EV> done 2.1.1: Or for internal communication stability in networks where external connectivity may came and go, e.g., many ISPs provide ULAs in home networks. EV> indeed, text added 2.1.5: This section muddles privacy addresses with stable per-prefix identifiers. They have different uses, and can be used independently or together. EV> text has been updated to avoid this mix. You say “RFC 8064 specifies a way to”, but I think you should cite RFC 7217 as the address generation mechanism, and RFC 8064 as the recommendation to use that, but note that you can still use RFC 4941 addresses alongside RFC RFC 7217 addresses. EV> text has been updated 2.1.6 As per my previous review I think you should have a section on address accountability / auditing, and discuss that for all address assignment methods, be it DHCPv6 or SLAAC/RFC7217. You say here DHCPv6 is used for audit purposes, yet later in the doc say there are issues with that approach. Address accountability is the most common question I get asked when speaking to universities about IPv6 deployment when there is (dual-stack) multi-addressing. This can be a place to mention DHCPv6 anonymity profiles, but that would be better in a separate section on address and thus user privacy. EV> text now implements all the previous comments of yours 2.2.4 As per later in the document, emphasise here that IPSec is optional (some still have the original IPv6 marketing message in their head…) EV> good suggestion, implemented 2.3.3 “his packets” -> “their packets” to be gender neutral. EV> done How widely deployed is SAVI in practice? A comment is rightly made about SeND, but what about SAVI implementation? EV> based on my own Cisco experience, « first hop security” is as deployed as “dhcp snooping/dynamic ARP inspection” => in a lot of places (also default behavior of Cisco AP). I can only assume that other vendors do the same. Can also suggest the /64 per host isolation approach here before the “A drastic technique” paragraph. EV> good suggestion 2.6.1.5 Address accountability appears again here in the 5th paragraph. You can get a level of accountability from polling network devices where DHCPv6 is not used; this should be discussed somewhere. EV> added some text in 2.6 2.7.1 Should mention RFC 7123 here, and also in Section 3. EV> indeed, done 3.2 Given you raise VPNs, you should add a note about RFC 7359. EV> added In R&E campus enterprises, eduroam is widely deployed and gives accountability through federated 802.1x based network access. EV> not limited to eduroam of course but covered in section 2.6.1.6 IMHO 4.3 You manage to avoid talking about IPv6 NAT until here. Then assume there is no IPv6 NAT on a CPE. Would it be better to not mention IPv6 NAT at all, or dare you open that can of very wriggly worms in this document? I imagine the IESG reviews may ask, given the widely held industry belief that “NAT is added security” :). RFC 4864 still has value, but you cite that for a different reason. EV> do not get me started on NAT for security please ;-) Basically, this I-D has been lingered for IPv6 NAT and use of ULA (in addition to PI vs. PA)...
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
