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

[Warren Kumari <[e-mail]>]

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-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsec
>
> --
> Enno Rey
>
> Cell: [phone]
> Twitter: @Enno_Insinuator
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra