[OPSEC] Opsdir early review of draft-ietf-opsec-v6-13

Tim Chown <tim.chown@jisc.ac.uk> Mon, 02 July 2018 17:52 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 CFD3F131160; Mon, 2 Jul 2018 10:52:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Chown <tim.chown@jisc.ac.uk>
To: <ops-dir@ietf.org>
Cc: opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153055392479.16095.569198674604354407@ietfa.amsl.com>
Date: Mon, 02 Jul 2018 10:52:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/6s_YFrXNPwtbQRe62D3_AtXb6as>
Subject: [OPSEC] Opsdir early review of draft-ietf-opsec-v6-13
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 17:52:05 -0000

Reviewer: Tim Chown
Review result: Not Ready


I have reviewed this document 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

The document is Not Ready for publication.

General comments:

The draft is well written, and the authors are clearly experts in the area, but
the evolution of 13 versions of the draft since WG adoption in 2012 means the
draft is somewhat disjoint, and has a number of sections where current best
practices and related RFCs are not included.  A prime example is in the area of
address configuration.

There are seven pages on transition technologies; might that be better homed in
a -bis of RFC 4942?

The sections on control plane and routing (2.4, 2.5) are somewhat generic to
IPv4 and IPv6; there is very little IPv6-specific information in there. While
this isn't bad per se, it pads the length of the document somewhat without much
new material.

There are many typos and grammatical errors throughout the document.

Specific comments:


"subtle differences between IPv4 and IPv6" - I don't think L2 vs L3 resolution,
ND vs ARP, is that subtle?

Do we need to mention NPTv6 here?


Mention 6renum and the gaps draft it produced (RFC 7010)?

The recommendation to use PI for a larger network implicitly means no NPTv6?

Any value in adding a note about the size of prefix an ISP offers?  (6177, etc)
 That affects how the network is configured.

Where is topology discovery / probing mentioned?  Cite RFC 4864?


I think the phrase in para 1 is "security by obscurity".  I would argue that
that can complement other security, but must not be depended upon!

Para 2 - or do both!


Section 2.1.3 - and ND cache exhaustion protection

Section 2.1.4 - "Normal" SLAAC no longer relies on EUI-64 from MAC addresses -
now RFC 8064 recommends the RFC 7217 version of SLAAC.

This whole section is written in a jumbled order.

There should be a separate section on address accountability - whether it's
needed in a given scenario, and where it is, how best to achieve it - there's
bits of this scattered around in many places, but it's independent of privacy

Para 3 - see section 2.1.7.


first line - you can't always control managed vs unmanaged of course; a
university eduroam WiFi is unmanaged, generally, where admin systems probably
are managed.

second para - these are just hints; and for a host not supporting DHCPv6, it
gets no address at all.  Perhaps also mention SAVI here.

Section 2.1.6 - Should mentioned DHCPv6 anonymity profile - RFC 7824 and RFC
7844.  RFC 7934 suggests not using DHCPv6 in certain circumstances as a result.
 Also RFC 7077 recommends to not issue DHCPv6 addresses sequentially from a
small pool.

Section 2.1.7 - note RFC 8273 is designed for shared environments, and
isolation is a primary goal; add reference to RFC 7934.


Perhaps check against text in draft-ietf-6man-rfc6434-bis-08 in section 5.2,
and the excessive EH option processing text in 5.3 there.


Section 2.2.4 - worth adding RFC 8221 and RFC 8247?

Section 2.3 - split out the NS/NA messaging here from ND in general, else you
should include SLAAC.  Given you discuss SLAAC later, focus on NS/NA here in
its own subsection?


Spurious DHCP-Shield wording at end of para 2.

Section 2.3.2 - mention ND cache exhaustion


Rate limit also on ICMP messages?

Perhaps separate out the power drain issue as a threat?  RFC 7772 is relevant

The two drafts cited here by thubert and chakrabarti died in 2012 and 2015
respectively?   Maybe RFC 6775 instead?

Section 2.3.3 - or just supply a 'bad' DNS resolver address


After para 3 emphasise still need RAs in a DHC environment for default router
and on-link prefix(es)


A lot of text on something hardly used?

p.14 - 20
Lots of generic text applicable to IPv4 too?


Replace RFC 2460 with RFC 8200?


There is now draft-ietf-6man-rfc6434-bis-08


What's required to differentiate logging of different IP versions?

Value in mentioning RFC 8096?

Or YANG modules (as per Section 16 of draft-ietf-6man-rfc6434-bis-08)



Windows 7?

At bottom, "was usually done in the IPv4 era" -> "is commonly used in IPv4


"era" again.

Mention DHCPv6 anonymity profiles - RFC 7844


Forensics - that's *one* way - can e.g. use a NMS; one that harvests network
device data via SNMP; many open source options available.


Mostly duplicating RFC 7077.

Section - rfer to RFC 5952, or se Sec


Perhaps be consistent with rather than maintain parity?




Last para is very handwavey!  Device OSes are more secure these days to work in
IPv4 hotspots too?


A campus enterprise is different - BYOD vs managed, esp. wifi/eduroam, or
Science DMZ networks; perhaps mention RFC 7381, esp. sections 2.4, 3.2 and 4.1?


last para - better to omit, I think?