Re: [OPSEC] WGLC for draft-ietf-opsec-v6

Merike Kaeo <merike@doubleshotsecurity.com> Thu, 20 April 2017 04:55 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 DD910126DDF for <opsec@ietfa.amsl.com>; Wed, 19 Apr 2017 21:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 PNloNHngtaYq for <opsec@ietfa.amsl.com>; Wed, 19 Apr 2017 21:55:37 -0700 (PDT)
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 60E61126CF6 for <opsec@ietf.org>; Wed, 19 Apr 2017 21:55:37 -0700 (PDT)
Received: from [10.178.3.115] (4.239.214.82.in-addr.arpa [82.214.239.4] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v3K4tQRU022571 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Apr 2017 21:55:31 -0700
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3560835E-A906-4B31-A819-E4FB2FEC06F6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Merike Kaeo <merike@doubleshotsecurity.com>
In-Reply-To: <alpine.DEB.2.02.1704191654320.5591@uplift.swm.pp.se>
Date: Wed, 19 Apr 2017 21:55:19 -0700
Cc: opsec@ietf.org
Message-Id: <D7E5871C-2D2B-49E5-BE2B-6066E23BFAB5@doubleshotsecurity.com>
References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <alpine.DEB.2.02.1704191654320.5591@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.3124)
X-Sonic-CAuth: UmFuZG9tSVZ8RkbHH4y7b8UU7/L+M374EixRY1GZdhzT9wBgiBeyNGkDRwSR8ULDNxxXtdWOrWTATk7WOB1ji8qVnT6709lH
X-Sonic-ID: C;LEyZkYUl5xGxbSzL7bdh1w== M;wLwFlIUl5xGxbSzL7bdh1w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/BXGsYQ44tRWZCJ7FnjLr6raBzqk>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Apr 2017 04:55:39 -0000

Thank you (!)  Mikael for the thorough review.  The intent is to have it be as complete a document with ‘rough concensus’ to overall security considerations so your comments below are exactly what we are looking for.  Even during a last call.

For group overall - I have privately sent the last call info to 6 operational folks I know who don’t typically follow IETF lists and asked for a thorough review.  I know, shocking :)  I had sent the list to co-authors so they were aware.

I’ll work with co-authors to also see how best to capture all comments and get them resolved with ‘group concensus’.

- merike

> On Apr 19, 2017, at 8:26 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Wed, 12 Apr 2017, Gunter Van De Velde wrote:
> 
>> This is to open a two week WGLC for https://tools.ietf.org/html/draft-ietf-opsec-v6.
>> If you have not read it, please do so now. You may send nits to the author, but substantive discussion should go to the list.
>> 
>> I will close the call on 26 April 2017
> 
> Hi,
> 
> I went through -11. Reading it and commenting as if I never read it before (which I don't remember doing, but since I am mentioned in the acknowledgement section I must have :) )
> 
> 2.1.2. I would like to see the last paragraph moved to first in this section, ie have the IETF recommendation start this off, not finish it.
> 
> Somewhere in 2.1.x, can we have a note about the /64 per host as a means of tracking devices instead of having to track individual addresses?
> 
> 2.3.1. I keep hearing people talk about SeND. The paragraph rightly ends with with "SeND isn't widely available in implementations". Can we start off with that? Also potentially move the whole SeND section to later in 2.3.x so that the actually useful protocols come first?
> 
> 2.4.x. Should this document have all this text on router security? Does this text say anything in opposition to RFC6192 that it starts off with a reference to?
> 
> 2.6.x. This document has 0 mentions of the word "YANG" or "NETCONF". I think it should contain more such references. For instance, 2.6.1.4 mentions using CLI tools to dump ND table. There is a YANG model for that.
> 
> 2.6.1.4. Here is one example where /64 per host and only tracking that, would be useful approach.
> 
> 2.6.1.5. Option 37 would be one way to keep track of DHCPv6 IA_NA and where they are. I don't think if that's implied in the 6221 5.3.2 reference?
> 
> 2.6.2.3 This is one of a few "..." in there. Is that really what we want in a finished RFC?
> 
> 2.7. "Some text"?
> 
> 2.7.2. Blocking all tunnels? What's the recommendation here? "...it could be helpful to block all default configuration tunnels"?
> 
> 2.7.2.x. I've seen advice that if you can, disable ISATAP, 6to4 and TEREDO on all your enterprise machines (where you can, this was specifically for enterprise Windows deployments). Shouldn't we mention this here? Unless you know that you need it, turn it off? Or if there is a document somewhere talking about this, reference it?
> 
> 2.7.2.4. I'd like to start this with the fact that anycast 6to4 has been deprecated.
> 
> 
> This document is a nice overview of a lot of topics, it contains lots of good links to documents that are good for reader to know. I actually think this is the best feature of this document, ie that it overviews a lot of different topics and gives the reader ideas for further reading. However, reading the document it felt a bit like there was a bit more work needed. It's 95% there, but I think there are more things that needs discussion. I also think this document needs wider review. Notifying 6man and v6ops was a good thing. It seems there have been more discussion there than here in OPSEC, but I think the authors follow those groups as well.
> 
> So my comment for this in WGLC is that I would like to have more people look at the document and I think we need a few more revisions before it's ready for publication. Overall, I think this document contains valuable information and after some more review and discussion I definitely would like to see it published.
> 
> 
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se_______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec