Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
Enno Rey <erey@ernw.de> Sat, 10 April 2021 18:46 UTC
Return-Path: <erey@ernw.de>
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 9CBB23A0E62; Sat, 10 Apr 2021 11:46:05 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 VgkeCGAwZanm; Sat, 10 Apr 2021 11:46:01 -0700 (PDT)
Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95E3A0E60; Sat, 10 Apr 2021 11:45:57 -0700 (PDT)
Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 9DE1227309; Sat, 10 Apr 2021 20:45:55 +0200 (CEST)
Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8566D452D7C; Sat, 10 Apr 2021 20:45:55 +0200 (CEST)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 7B3FDE5C1; Sat, 10 Apr 2021 20:45:55 +0200 (CEST)
Date: Sat, 10 Apr 2021 20:45:55 +0200
From: Enno Rey <erey@ernw.de>
To: Tim Chown <tim.chown@jisc.ac.uk>
Cc: ops-dir@ietf.org, last-call@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org
Message-ID: <20210410184555.GE91991@ernw.de>
References: <161778675730.8077.2835666586607648895@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <161778675730.8077.2835666586607648895@ietfa.amsl.com>
User-Agent: Mutt/1.11.3 (2019-02-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/Fimk_iwY0wMAkr-yyhrzm3Ob1SM>
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: Sat, 10 Apr 2021 18:46:06 -0000
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
- [OPSEC] Opsdir last call review of draft-ietf-ops… Tim Chown via Datatracker
- Re: [OPSEC] Opsdir last call review of draft-ietf… Enno Rey
- Re: [OPSEC] Opsdir last call review of draft-ietf… Warren Kumari
- Re: [OPSEC] Opsdir last call review of draft-ietf… Tim Chown
- Re: [OPSEC] Opsdir last call review of draft-ietf… Warren Kumari
- Re: [OPSEC] Opsdir last call review of draft-ietf… Tim Chown
- Re: [OPSEC] Opsdir last call review of draft-ietf… Eric Vyncke (evyncke)
- Re: [OPSEC] Opsdir last call review of draft-ietf… Tim Chown
- Re: [OPSEC] Opsdir last call review of draft-ietf… Eric Vyncke (evyncke)
- Re: [OPSEC] Opsdir last call review of draft-ietf… Warren Kumari
- Re: [OPSEC] Opsdir last call review of draft-ietf… Tim Chown
- Re: [OPSEC] Opsdir last call review of draft-ietf… Enno Rey
- Re: [OPSEC] Opsdir last call review of draft-ietf… Tim Chown