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

Merike Kaeo <merike@doubleshotsecurity.com> Fri, 06 December 2019 16:17 UTC

Return-Path: <merike@doubleshotsecurity.com>
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 12A3112083C; Fri, 6 Dec 2019 08:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2WCZ51AHn80; Fri, 6 Dec 2019 08:17:38 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 076AA12083D; Fri, 6 Dec 2019 08:17:37 -0800 (PST)
Received: from [192.168.9.116] ([216.243.59.39]) (authenticated bits=0) by c.mail.sonic.net (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 <merike@doubleshotsecurity.com>
In-Reply-To: <3E6971B4-D213-4F63-A09D-7AEAFE69A2CD@cisco.com>
Date: Fri, 6 Dec 2019 08:17:26 -0800
Cc: Tim Chown <tim.chown@jisc.ac.uk>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org" <draft-ietf-opsec-v6.all@ietf.org>
Message-Id: <12F11732-63CB-4A39-BA22-C2A24EB40B85@doubleshotsecurity.com>
References: <157562487044.21086.3344278098662647264@ietfa.amsl.com> <3E6971B4-D213-4F63-A09D-7AEAFE69A2CD@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
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: <https://mailarchive.ietf.org/arch/msg/opsec/S3aM4mzVO8KswbIw_G0EZwoW1GY>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-21
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: 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) <evyncke@cisco.com> 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" <noreply@ietf.org> 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
>    https://mailarchive.ietf.org/arch/msg/opsec/6s_YFrXNPwtbQRe62D3_AtXb6as, 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.
> 
>    2.6.1.5
> 
>    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
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>