On Wed, Apr 21, 2021 at 9:41 AM Tim Chown <Tim.Chown@xxxxxxxxxx> 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 <warren@xxxxxxxxxx> 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 <erey@xxxxxxx> 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@xxxxxxxx
> > 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
complexities of his own making.
-- E. W. Dijkstra
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
