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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
