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

Tim Chown via Datatracker <noreply@ietf.org> Wed, 07 April 2021 09:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 572E13A1310; Wed, 7 Apr 2021 02:12:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tim Chown via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-opsec-v6.all@ietf.org, last-call@ietf.org, opsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <161778675730.8077.2835666586607648895@ietfa.amsl.com>
Reply-To: Tim Chown <tim.chown@jisc.ac.uk>
Date: Wed, 07 Apr 2021 02:12:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/R5gGr3IYe3r-IiF9ns2A2Ir5N44>
Subject: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Apr 2021 09:12:38 -0000

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