Re: [Last-Call] [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25

[Enno Rey <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec

-- 
Enno Rey

Cell: [phone]
Twitter: @Enno_Insinuator