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

Warren Kumari <warren@kumari.net> Fri, 23 April 2021 18:03 UTC

Return-Path: <warren@kumari.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07FE3A18C3 for <opsec@ietfa.amsl.com>; Fri, 23 Apr 2021 11:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeGcpkvvf4nX for <opsec@ietfa.amsl.com>; Fri, 23 Apr 2021 11:03:25 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2653A18C0 for <opsec@ietf.org>; Fri, 23 Apr 2021 11:03:24 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id u20so56617250lja.13 for <opsec@ietf.org>; Fri, 23 Apr 2021 11:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9uQRhGQWSkS4l5ttE+8R2cud3lgeNv5bArF2K7HOXDM=; b=vstcsMH2rjYiJt/KMiD7fa1eQTxB71Ny5t8GO9JxK+rxrXzHWFTAIvqojwbb2yowfj G/mBi0uh42p+C73paFXZrXxIrGLbKNRE5EDEkRYTqN5zKky3qiOY/t/QJW8oX1eHDfvy rjb1yX9vF3ByCx6+lUk9WAtKCtJhh95hlGBRgtysTC6Kl54Sw+l4o4QDK5olywCLyytj asYWTUhsaGn7IKlFY3Exo7PhawJeJfUg/CCCMqyp8OqSY4oJeespsPTrTFM9xz6j5nso Q0/Nc0t75UKfLgEzJCpEdc8oPVIhXA5J3nZseubQ7YNPf9wM+KPmTFNi9nMMKGzogvZ+ 2rpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9uQRhGQWSkS4l5ttE+8R2cud3lgeNv5bArF2K7HOXDM=; b=HRT77GnpQc5hzKxkfgJkx2HS/ftzqwVUCFM5sPx4iODD/yclD/6zmZRIBz/FUNpizc phXu2NP74qxy9VPDST+ErBZ1C1eMv+iEvOg4iIq4t8e7vgMYpYQ1FU0myZ8mAf7U0MnF ObCvo0iDZ5ZMZ1/yjahoxvumcnXxXRG2j8CA6qe7jNhLkU0KgOdaBna2v1hYw/WlIXZ0 3REcgvDIUyf6JwhmhnPAufTIkB42e89Kny7y/jjkbdm33pt79se+gwm+Jw2lcxPgNsz6 w65veprCfvw3oi/XbFG21o/rxOZrl5Ui1uejUMLw2Um4OHFPXtGdEzRcvuATlYzfYBIu myOw==
X-Gm-Message-State: AOAM531ASB7Kkg0DnAbXwGfBnTZdqF4guVR6oQCBWa7dmVslNHAnAeSG InsFUYTCUTJnDvyMPPNw6jPVBqs+8ljPAYbqss35Hw==
X-Google-Smtp-Source: ABdhPJyn3cROGjQVY3NaJNC7O6ft+gEJCUa3464VdLQB19z9CvIWasTslQwO6d0zMMzzLvrE+8wMMg6ztn2YR66VmQw=
X-Received: by 2002:a2e:9256:: with SMTP id v22mr3626953ljg.409.1619201000986; Fri, 23 Apr 2021 11:03:20 -0700 (PDT)
MIME-Version: 1.0
References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> <CAHw9_iKuhQrbmzprYVuN7c1GSrugHX-HwbrUR4HXoVDcU8kp4w@mail.gmail.com> <B3212703-618A-474B-835A-B1FDC7BE6ACD@jisc.ac.uk> <D8DD5268-E942-426C-9459-96F639CE8481@cisco.com> <A1444977-B106-4C32-A66A-F5E2BBA8C5E5@jisc.ac.uk> <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com>
In-Reply-To: <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 23 Apr 2021 14:02:44 -0400
Message-ID: <CAHw9_iKq0D7OyrdCsG_Q1xuTZN3MNdbBNHGjJdzdRSQjoN1Jag@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, Enno Rey <erey@ernw.de>, ops-dir <ops-dir@ietf.org>, opsec wg mailing list <opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org" <draft-ietf-opsec-v6.all@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007bec7205c0a79cbc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/wOkirG5vuSN4LQ0POyLRj0kCfNM>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Apr 2021 18:03:31 -0000

[ - last-call for clutter ]

On Thu, Apr 22, 2021 at 7:11 AM Eric Vyncke (evyncke) <evyncke@cisco.com>
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 <Tim.Chown@jisc.ac.uk>
> Date: Thursday, 22 April 2021 at 12:55
> To: Eric Vyncke <evyncke@cisco.com>
> Cc: Warren Kumari <warren@kumari.net>et>, Enno Rey <erey@ernw.de>de>, ops-dir <
> ops-dir@ietf.org>gt;, "last-call@ietf.org" <last-call@ietf.org>rg>, opsec wg
> mailing list <opsec@ietf.org>rg>, "draft-ietf-opsec-v6.all@ietf.org" <
> draft-ietf-opsec-v6.all@ietf.org>
> Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: Eric Vyncke <evyncke@cisco.com>om>, Kiran Kumar Chittimaneni <
> kk.chittimaneni@gmail.com>gt;, Merike Kaeo <merike@doubleshotsecurity.com>om>, <
> erey@ernw.de>gt;, <furry13@gmail.com>om>, Ron Bonica <rbonica@juniper.net>et>, <
> warren@kumari.net>gt;, <rwilton@cisco.com>om>, Gyan Mishra <
> hayabusagsm@gmail.com>gt;, <hayabusagsm@gmail.com>
> 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) <evyncke@cisco.com>
> 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 <Tim.Chown@jisc.ac.uk>
>     > Date: Wednesday, 21 April 2021 at 15:41
>     > To: Warren Kumari <warren@kumari.net>
>     > Cc: Enno Rey <erey@ernw.de>de>, ops-dir <ops-dir@ietf.org>rg>, "
> last-call@ietf.org" <last-call@ietf.org>rg>, opsec wg mailing list <
> opsec@ietf.org>gt;, "draft-ietf-opsec-v6.all@ietf.org" <
> draft-ietf-opsec-v6.all@ietf.org>
>     > Subject: Re: [OPSEC] Opsdir last call review of
> draft-ietf-opsec-v6-25
>     > Resent-From: <alias-bounces@ietf.org>
>     > Resent-To: Eric Vyncke <evyncke@cisco.com>om>, Kiran Kumar
> Chittimaneni <kk.chittimaneni@gmail.com>om>, Merike Kaeo <
> merike@doubleshotsecurity.com>gt;, <erey@ernw.de>de>, <furry13@gmail.com>om>, Ron
> Bonica <rbonica@juniper.net>et>, <rwilton@cisco.com>om>, <warren@kumari.net>et>,
> Gyan Mishra <hayabusagsm@gmail.com>om>, <hayabusagsm@gmail.com>
>     > 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 <warren@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 <erey@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