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

Warren Kumari <warren@kumari.net> Wed, 21 April 2021 15:51 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 CDE713A2D47 for <opsec@ietfa.amsl.com>; Wed, 21 Apr 2021 08:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 W6vr7emGuWNi for <opsec@ietfa.amsl.com>; Wed, 21 Apr 2021 08:51:48 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 E2EDD3A2D19 for <opsec@ietf.org>; Wed, 21 Apr 2021 08:51:42 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id u25so9957357ljg.7 for <opsec@ietf.org>; Wed, 21 Apr 2021 08:51:42 -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=hCsFLwoggKeFuwuqvlVbf76obDqjwP5P9dwQuvp6Xvw=; b=FQg0sW/6pKCO0FSieHMDTb1/3U02bt9IOWRcz/+qqVlmJZtm/pfziE/vXBbNYaUI2G DzOD7VcW4NkafI2xWI0HItP8FdfspgGnJF6S6DJEuqU8aL3bY9nFgf4jMo5pK9h1C5Pn 93hrKB0vYYoRLbgzIV+KRCnfWuCqYQjSVu+adkdQUQgLvoXuAWJV7G7j6aaiOJRvgEb2 SSw9Fvy1pSDEVAqjycx+6jWJM9jH0u2fbRdhYUfO5QDkHZh8RlacJGxLgbOsh9gYwM67 9Nh89NlTo81l3I1XidOZ0Uaff5/YuCLvo0sDq5fqbhCA1cdV+2ATk+yziF0OhGuXzmki OKqA==
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=hCsFLwoggKeFuwuqvlVbf76obDqjwP5P9dwQuvp6Xvw=; b=gvlYI7CC7H7CvPaRvZB8Qt/YjhffZC0LDcLk+eCjIiGqivoPfHHAQPA/3+c17dRqp5 1aZcIfKbv3tSvlNh5fnHRJDMb+wwESRNtPJLxhbgfJJRHUWYtPXPwo/qN0G32eaFsT0a WQKQlXHcxdetgtts/s7/vP+W3dN6hT0DrDIB7ypvxO3TUDscbhBAtgEEpUtbkjQ500wy 7cmUbtRaN4cvxKG9szZ8t3bD4o43PW9SLE19SwG285/5whxvfPCs5hkSruPCDVNQKoHO egVmMXR7k0ze/Hg0ykVG7HyBMalVccvQSHAU4wdHtYWxhF3IhYvF3esKZtn3XmEikexQ 6VJQ==
X-Gm-Message-State: AOAM531G1MjAWTi5azjGuJk2TiKWL7SZ/QrFE5pGyADvlb5v5VmiEw2b LCaNv+EVuncgPH5qz7oXr89YhUPPwER60Mh1XkO9Qw==
X-Google-Smtp-Source: ABdhPJyMi0SH4T2rM8HLIHXsUAniobnB7QNgzIuIM6a+ikkbvpbe5bYBO68PFUfFVpfDGSl+DZYMANWbn8T19fMalSQ=
X-Received: by 2002:a2e:bc0c:: with SMTP id b12mr19081496ljf.502.1619020295619; Wed, 21 Apr 2021 08:51:35 -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>
In-Reply-To: <B3212703-618A-474B-835A-B1FDC7BE6ACD@jisc.ac.uk>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 21 Apr 2021 11:50:59 -0400
Message-ID: <CAHw9_iL9j4EjadQ13gwouNAcBtOzL=yV75bdjPOZjrA9UCHRLA@mail.gmail.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: Enno Rey <erey@ernw.de>, ops-dir <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@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="0000000000009ada6e05c07d898f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/e9VE7QlffXr5U16RQx3aVBM-Puo>
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: Wed, 21 Apr 2021 15:51:57 -0000

On Wed, Apr 21, 2021 at 9:41 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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@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