On Wed, Apr 21, 2021 at 9:41 AM Tim Chown <tim.ch...@jisc.ac.uk> wrote:
> 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? > Actually, it is on tomorrow's telechat. Do you think that this is important enough to hold the document? Keeping in mind that the document has been many years in the making... W > > Tim > > > On 13 Apr 2021, at 21:59, Warren Kumari <war...@kumari.net> 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 <e...@ernw.de> 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 > > > OPSEC@ietf.org > > > 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 > > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
