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

Merike Kaeo <> Fri, 06 December 2019 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12A3112083C; Fri, 6 Dec 2019 08:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n2WCZ51AHn80; Fri, 6 Dec 2019 08:17:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 076AA12083D; Fri, 6 Dec 2019 08:17:37 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.15.1/8.15.1) with ESMTPSA id xB6GHWMY013249 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Dec 2019 08:17:33 -0800
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E3E63339-8D46-4488-958A-A1B4190F4D66"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Merike Kaeo <>
In-Reply-To: <>
Date: Fri, 6 Dec 2019 08:17:26 -0800
Cc: Tim Chown <>, "" <>, "" <>, "" <>, "" <>
Message-Id: <>
References: <> <>
To: "Eric Vyncke (evyncke)" <>
X-Mailer: Apple Mail (2.3124)
X-Sonic-CAuth: UmFuZG9tSVZUulczE2TeX/QjLAYeq2L7PtTJqBn3FDxqG5Dy+IUYuLt7NeG0J6yaPPf1O9EKf7T/Wa7cg6qM4iJ+0fGN9lyh
X-Sonic-ID: C;rhVm6EMY6hGTQv7Ubmlb6w== M;ZC2x6EMY6hGTQv7Ubmlb6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Dec 2019 16:17:40 -0000

Hi Tim.

You are someone who has over the years made many substantial recommendations to this document so I will echo Eric’s comment that if we did not react to your last review it was a gross oversight.  I will look at my archives since I recall making a concerted effort to make sure we included all the review comments from 2017/2018 in a version around October 2018.

- merike

> On Dec 6, 2019, at 6:19 AM, Eric Vyncke (evyncke) <> wrote:
> Tim
> Thank you for your additional review. And, I feel really bad if we, the authors, have not reacted to your previous review (even if I had in mind that we acted on it -- possibly not changing the text to fit completely your view)
> -éric
> On 06/12/2019, 10:34, "Tim Chown via Datatracker" <> wrote:
>    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
>    threats.
>    I had previously reviewed the draft as an OPS-DIR Early Review in July 2018, as
>    detailed in
>, but I
>    don’t see any evidence of these comments being acted upon, or any response, so
>    as far as I can see, the comments in this review still apply, and I would urge
>    the authors to review these comments.
>    That said, there have been a number of improvements to the draft in the past 18
>    months, and overall it is a much better document for those changes.  The
>    question is at what point the WG should simply ship the draft as “good enough”,
>    rather than try to improve it further.
>    At the moment I think the document is Not Ready, though it’s getting nearer to
>    being Ready with Nits.
>    General comments:
>    There are a number of typos / grammatical errors in the document.  While the
>    RFC Editor will correct, e.g., in the abstract - “mitigations” should be
>    singular, in the intro “with that have been”, in 2.1 “of address space
>    available” (add “is”), “allow” should be “allows”.  Just needs a careful proof
>    read.
>    Specific comments:
>    Abstract:
>    “places” should be “aspects” or similar.
>    2.1.1:
>    Or for internal communication stability in networks where external connectivity
>    may came and go, e.g., many ISPs provide ULAs in home networks.
>    2.1.5:
>    This section muddles privacy addresses with stable per-prefix identifiers.
>    They have different uses, and can be used independently or together.
>    You say “RFC 8064 specifies a way to”, but I think you should cite RFC 7217 as
>    the address generation mechanism, and RFC 8064 as the recommendation to use
>    that, but note that you can still use RFC 4941 addresses alongside RFC RFC 7217
>    addresses.
>    2.1.6
>    As per my previous review I think you should have a section on address
>    accountability / auditing, and discuss that for all address assignment methods,
>    be it DHCPv6 or SLAAC/RFC7217.  You say here DHCPv6 is used for audit purposes,
>    yet later in the doc say there are issues with that approach.
>    Address accountability is the most common question I get asked when speaking to
>    universities about IPv6 deployment when there is (dual-stack) multi-addressing.
>    This can be a place to mention DHCPv6 anonymity profiles, but that would be
>    better in a separate section on address and thus user privacy.
>    2.2.4
>    As per later in the document, emphasise here that IPSec is optional (some still
>    have the original IPv6 marketing message in their head…)
>    2.3.3
>    “his packets” -> “their packets” to be gender neutral.
>    How widely deployed is SAVI in practice?  A comment is rightly made about SeND,
>    but what about SAVI implementation?
>    Can also suggest the /64 per host isolation approach here before the “A drastic
>    technique” paragraph.
>    Address accountability appears again here in the 5th paragraph.  You can get a
>    level of accountability from polling network devices where DHCPv6 is not used;
>    this should be discussed somewhere.
>    2.7.1
>    Should mention RFC 7123 here, and also in Section 3.
>    3.2
>    Given you raise VPNs, you should add a note about RFC 7359.
>    In R&E campus enterprises, eduroam is widely deployed and gives accountability
>    through federated 802.1x based network access.
>    4.3
>    You manage to avoid talking about IPv6 NAT until here.  Then assume there is no
>    IPv6 NAT on a CPE.  Would it be better to not mention IPv6 NAT at all, or dare
>    you open that can of very wriggly worms in this document?  I imagine the IESG
>    reviews may ask, given the widely held industry belief that “NAT is added
>    security” :).  RFC 4864 still has value, but you cite that for a different
>    reason.
> _______________________________________________
> OPSEC mailing list