Hi, I’ve checked through -26 and compared as best as I can to -25, and submitted the review.
I’m happy enough to put a ‘Ready’ tag on it. It could always be better, but at 50 pages, I fully understand why shipping it is desirable. I can’t see anything specifically wrong in the text :) Tim > On 21 Apr 2021, at 19:36, Eric Vyncke (evyncke) <[email protected]> wrote: > > Tim, Warren, > > Replying with only the author hat (and after consultation with my co-authors) > on this email after having read Warren's and Tim's replies. > > Tim, I do not know whether you remember all the painful journey of this > document but the authors do :-) > > a) the early versions of the I-D included a lot of 'recommendation' wording > but the OPSEC WG requested us to remove them (this is also the reason why it > is not a BCP) > > b) getting a summary would be a nice idea but, again, to reach the WG > consensus, we had to make some recommendation with restrictions and caveats > for special cases (e.g., remember the ULA, RA-guard discussions ?)... hence, > I do not think that this is possibly to make a short summary without > including the restrictions/specifics ... so the summary list will be very > very long and not very useful > > All the other last call comments and the IESG COMMENT points will be > addressed once all feedback is collected, by either updating the text or > explaining our points of view on the comment. > > Thank you again for your review and the discussion > > Regards > > -éric > > -----Original Message----- > From: Tim Chown <[email protected]> > Date: Wednesday, 21 April 2021 at 15:41 > To: Warren Kumari <[email protected]> > Cc: Enno Rey <[email protected]>, ops-dir <[email protected]>, "[email protected]" > <[email protected]>, opsec wg mailing list <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 > Resent-From: <[email protected]> > Resent-To: Eric Vyncke <[email protected]>, Kiran Kumar Chittimaneni > <[email protected]>, Merike Kaeo <[email protected]>, > <[email protected]>, <[email protected]>, Ron Bonica <[email protected]>, > <[email protected]>, <[email protected]>, Gyan Mishra > <[email protected]>, <[email protected]> > Resent-Date: Wednesday, 21 April 2021 at 15:41 > > Hi, > > I’ve not yet seen any comments as proposed by Warren, and the review is > due (the deadline was a shorter than usual one). I can go ahead and look to > determine the changes from the diff view. > > A fairly main point was whether any summary recommendations would be > added, given the document’s length, and the variation in style through the > document, with some sections having recommendations subsections, others not. > There is a lot of good advice in the text, but it’s a long read as is, and > there’s likely a couple of pages of key bullet points that could be added. > > When is the draft coming back to the IESG? > > Tim > >> On 13 Apr 2021, at 21:59, Warren Kumari <[email protected]> wrote: >> >> Just a quick note to say thanks to Tim for the excellent and detailed >> review, and to the authors for addressing it... >> >> I took a quick skim through the diffs, and it was a little tricky for me to >> tel which all of the comments had been addressed -- authors, if you get a >> chance, could you reply noting which comments were folded into -26? >> W >> >> On Sat, Apr 10, 2021 at 2:46 PM Enno Rey <[email protected]> wrote: >> Hi Tim, >> >> thanks so much for another detailed look at the draft. >> Your feeling that it has been in the making for a while is correct (tell me >> about it ;-), still we think that the operational security guidance for IPv6 >> hasn't change much over time, and it might even be more needed than ever >> (given current momentum of IPv6 uptake). >> I went through your below points, and for many of them I've performed >> according clarifications/enhancements of the draft. A new version has then >> been uploaded. >> >> Wish you a great weekend >> >> Enno >> >> >> >> >> On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote: >>> Reviewer: Tim Chown >>> Review result: Has Issues >>> >>> Hi, >>> >>> I have reviewed this document (draft-ietf-opsec-v6-25) 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, >>> and again since then, so am familiar with the document and its history. >>> >>> General comments: >>> >>> The document has evolved over time with many topics added, and has an >>> inevitable ???Frankenstein??? feel to it. The document would be much >>> better for a >>> rewrite, but that would be significant work, and would delay publication >>> further. The material in the document is good, and the advice is valuable, >>> so >>> the focus should be on publishing it sooner rather than later, and thus the >>> issues with structure are probably best overlooked. >>> >>> An example of the historical evolution of the document are the instances >>> where >>> the same topic os covered multiple times. This would ideally be avoided. >>> >>> The section most in need of attention is 2.1, where many aspects of >>> addressing >>> are weaved together: allocations, assignments, assignment to hosts, ULAs, >>> stable and temporary addresses, etc. This might be better presented as a >>> section listing addressing related security issues, such as privacy for >>> users, >>> first hop security, network manageability, implications of multi-addressed >>> hosts, address accountability (which isn???t mentioned here?), avoiding >>> renumbering (if that is security?), etc. >>> >>> There are also some sections which summarise recommendations, or reinforce >>> them, and others that do not. For a document of over 50 pages, which is >>> quite >>> a long read, it would be desirable to have a summary of the key >>> recommendations, either at the end of each 2nd level topic, or as a >>> standalone >>> section at the end of the document where the key points of each 2nd level >>> topic >>> are summarised. >>> >>> Is it worth citing examples of security toolkits readers can explore, like >>> the >>> THC kit, SI6 Networks, etc, maybe Scapy? >>> >>> Specific comments: >>> >>> p.3 >>> I don???t understand why NPTv6 is mentioned here, this early. Just say >>> that some >>> security issues have IPv4 equivalents, like ND attacks and ARP attacks, and >>> some do not, like IPv6 EHs or hop by hop DoS. The NAT discussion should >>> be in >>> a standalone section, and be neutral there. >>> >>> p.4 >>> Why mention the specific example of multi-homed networks? What do you >>> mean by >>> the exception? Is it that multi-homing is out of scope, and so are >>> unmanaged >>> networks? >>> >>> p.4 >>> Again, NPTv6 is mentioned. This section is titled ???addressing >>> architecture??? >>> but this bit of text is about reasons for going PA, PI, or becoming an LIR, >>> which is not architecture. >>> >>> p.4 >>> In the 7934 para, RFC8981 should be mentioned as it???s a significant >>> reason of >>> devices having more addresses. >>> >>> p.5 >>> ULAs are also useful where the prefix changes, for stable internal >>> addressing >>> as the global prefix changes? Typically in residential networks. >>> >>> p.5 >>> Section 2.1.4 is really about choices in address assignment within a >>> network. >>> >>> p.6 >>> Some of these paras should be in a section about IPv6 network >>> reconnaissance, >>> how to best mitigate against scanning, and how to inventory your own network >>> elements. >>> >>> p.6 >>> All mentions of 4941 should be replaced with 8981. >>> >>> p.7 >>> Can use 7721 and 8981 together. >>> >>> p.7 >>> Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so >>> call it >>> that? >>> >>> p.7 >>> ???Even if the use of DHCP??? - this reads badly. Rather 8504 talks about >>> this in >>> 6.5, where RFC7844 is mentioned for example. This should be in a user >>> privacy >>> section (if this document had one). Section 8.4 is also useful advice. >>> >>> p.8 >>> The first para is very muddled. >>> >>> p.8 >>> In 2.1.7 this can also be useful for ACL controls, if one admin / control >>> system sits in a prefix of its own. >>> >>> p.10 >>> This is really about handling of fragmented packets (the topic) not the >>> fragment header itself Also this is covered in 2.3.2.1 as well. >>> >>> p.10 >>> In 2.2, the intro can say these issues have parallels in IPv4. >>> >>> p.11 >>> First line, say the attack can typically happen from a large address scan if >>> permitted into the network? >>> >>> p.11 >>> Bullet 1 - that contradicts the comments on predictable addressing. >>> Bullet 2 - how? Some clues here would be useful. >>> >>> p.12 >>> ???Current??? - really? All current implementations? Delete ???current??? >>> or replace >>> with ???naive??? maybe. >>> >>> p.12 >>> ???Communicate directly??? - at L2? If so, why? >>> >>> p.12 >>> An example of a recommendations section here, where other sections with >>> advice >>> are not titled as such. See the General comment on this. >>> >>> p.13 >>> ???Trivial??? cases - aren???t these common ones, like edge switches in an >>> enterprise? >>> >>> p.13 >>> Why ???hostile???? Delete? >>> >>> p.14 >>> In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work is >>> now >>> on unicast discovery. >>> >>> p.21 >>> Maybe add here 802.1x as an example of the value of RADIUS logs, and add in >>> here as bullets info harvested from switches and (say) router NDP syslog >>> (though that???s I suppose the 4th bullet). These are mentioned in 2.6.1.7 >>> but >>> should be split out at the same level as the other topics here. >>> >>> p.28 >>> The text is 2.6.2.2 repeats earlier text. >>> Similarly text in 2.6.2.3 is repeated form before. >>> >>> p.29 >>> In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator. >>> >>> p.29 >>> In 2.7 point to RFC 4942 >>> >>> p.30 >>> Should RFC 6092 be mentioned here? >>> And that the best defence against IPv6 attacks n ???IPv4 only??? networks >>> is to >>> deploy and manage IPv6? >>> >>> p.31 >>> First bullet on this page - but isn???t this the same as if the traffic is >>> not >>> tunnelled? Why does tunnelling add the requirement? The same applies on >>> the >>> first para on p.32 >>> >>> p.31 >>> Maybe say here the mitigations can also break tunnel brokers (might be >>> desired, >>> but users will notice???)???. Maybe tunnels to specific brokers can be >>> allowed. >>> >>> p.32 >>> ISATAP, in 2021? Same with 6rd. General advice should be deploy native, >>> avoid >>> tunnels. >>> >>> p.33 >>> Same for 6to4. >>> >>> p.34 >>> Teredo though, is that still included in Windows and XBoX, as a MS thing? >>> >>> p.36 >>> Maybe cite Geoff Huston???s blog on this - it???s very good. Maybe >>> there???s a more >>> recent update though - >>> https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is >>> applicable here? (Hence a site should support the 64PREF RA option? >>> RFC8781 >>> >>> p.38 >>> In 2.8, to be fair IPv4 is also hardened a lot of late due to the >>> prevalence of >>> use of devices in WiFi hotspots etc. >>> >>> p.37 >>> Also RFC6092 on section 3.1? >>> >>> p.38 >>> ???Where RFC1918 address are often used??? - add ???often???, the text >>> implies all >>> enterprises use v4 NAT. >>> >>> p.41 >>> Only 2 normative references? >>> >>> Nits: >>> >>> p.1 >>> ???The Internet??? - you probably mean ???an ISP network??? >>> ???Describes the security??? - delete ???the??? >>> >>> p.4 >>> ???Which are the switch??? delete ???which are??? >>> >>> p.8 >>> Varying -> various >>> >>> p.10 >>> ipv6 -> IPv6 >>> >>> p.18 >>> Router processor - add r to ???route??? >>> >>> ??? >>> Tim >>> >>> >>> _______________________________________________ >>> OPSEC mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/opsec >> >> -- >> Enno Rey >> >> Cell: +49 173 6745902 >> Twitter: @Enno_Insinuator >> >> >> -- >> The computing scientist’s main challenge is not to get confused by the >> complexities of his own making. >> -- E. W. Dijkstra > > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
