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

[Warren Kumari <[e-mail]>]

[ - last-call for clutter ]

On Thu, Apr 22, 2021 at 7:11 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Thank you Tim for the re-check of the document.
>

Indeed, thank you Tim, both for the review, and for being flexible.

This document has a long and storied history, and, while it certainly could
be better, I think that it's one of those "it's better to ship something
imperfect now, vs never getting around to shipping it" type document.

W



>
> Regards
>
> -éric
>
> -----Original Message-----
> From: Tim Chown <[e-mail]>
> Date: Thursday, 22 April 2021 at 12:55
> To: Eric Vyncke <[e-mail]>
> Cc: Warren Kumari <[e-mail]>, Enno Rey <[e-mail]>, ops-dir <
> [e-mail]>, "[e-mail]" <[e-mail]>, opsec wg
> mailing list <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
> Resent-From: <[e-mail]>
> Resent-To: Eric Vyncke <[e-mail]>, Kiran Kumar Chittimaneni <
> [e-mail]>, Merike Kaeo <[e-mail]>, <
> [e-mail]>, <[e-mail]>, Ron Bonica <[e-mail]>, <
> [e-mail]>, <[e-mail]>, Gyan Mishra <
> [e-mail]>, <[e-mail]>
> Resent-Date: Thursday, 22 April 2021 at 12:55
>
>     Hi,
>
>     I’ve checked through -26 and compared as best as I can to -25, and
> submitted the review.
>
>     I’m happy enough to put a ‘Ready’ tag on it.  It could always be
> better, but at 50 pages, I fully understand why shipping it is desirable.
> I can’t see anything specifically wrong in the text :)
>
>     Tim
>
>     > On 21 Apr 2021, at 19:36, Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>     >
>     > Tim, Warren,
>     >
>     > Replying with only the author hat (and after consultation with my
> co-authors) on this email after having read Warren's and Tim's replies.
>     >
>     > Tim, I do not know whether you remember all the painful journey of
> this document but the authors do :-)
>     >
>     > a) the early versions of the I-D included a lot of 'recommendation'
> wording but the OPSEC WG requested us to remove them (this is also the
> reason why it is not a BCP)
>     >
>     > b) getting a summary would be a nice idea but, again, to reach the
> WG consensus, we had to make some recommendation with restrictions and
> caveats for special cases (e.g., remember the ULA, RA-guard  discussions
> ?)... hence, I do not think that this is possibly to make a short summary
> without including the restrictions/specifics ... so the summary list will
> be very very long and not very useful
>     >
>     > All the other last call comments and the IESG COMMENT points  will
> be addressed once all feedback is collected,   by either updating the text
> or explaining our points of view on the comment.
>     >
>     > Thank you again for your review and the discussion
>     >
>     > Regards
>     >
>     > -éric
>     >
>     > -----Original Message-----
>     > From: Tim Chown <[e-mail]>
>     > Date: Wednesday, 21 April 2021 at 15:41
>     > To: Warren Kumari <[e-mail]>
>     > Cc: Enno Rey <[e-mail]>, ops-dir <[e-mail]>, "
> [e-mail]" <[e-mail]>, opsec wg mailing list <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
>     > Subject: Re: [OPSEC] Opsdir last call review of
> draft-ietf-opsec-v6-25
>     > Resent-From: <[e-mail]>
>     > Resent-To: Eric Vyncke <[e-mail]>, Kiran Kumar
> Chittimaneni <[e-mail]>, Merike Kaeo <
> [e-mail]>, <[e-mail]>, <[e-mail]>, Ron
> Bonica <[e-mail]>, <[e-mail]>, <[e-mail]>,
> Gyan Mishra <[e-mail]>, <[e-mail]>
>     > Resent-Date: Wednesday, 21 April 2021 at 15:41
>     >
>     >    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?
>     >
>     >    Tim
>     >
>     >> On 13 Apr 2021, at 21:59, Warren Kumari <[e-mail]> 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-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
>     >
>     >
>
>
>

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