Hi Eric, > On 8 Feb 2021, at 18:02, Eric Vyncke (evyncke) <[email protected]> wrote: > > [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.
Thanks, I have a feeling I’ll be looking at the new new version soon too. Everything you say below looks fine, thanks. Tim > 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
