[secdir] review of draft-ietf-grow-large-communities-usage-06

Klaas Wierenga <klaas@wierenga.net> Fri, 21 April 2017 07:57 UTC

Return-Path: <klaas@wierenga.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DD6129524; Fri, 21 Apr 2017 00:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pcvAV-Cf5WNT; Fri, 21 Apr 2017 00:57:40 -0700 (PDT)
Received: from out63-ams.mf.surf.net (out63-ams.mf.surf.net [145.0.1.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACED0129440; Fri, 21 Apr 2017 00:57:39 -0700 (PDT)
Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v3L7vbcb004018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Apr 2017 09:57:37 +0200
Received: from [2001:610:148:beef:506:6b2d:d4da:3b40] (helo=192-87-30-241.terena.org.mail) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <klaas@wierenga.net>) id 1d1TRV-0005ax-F1; Fri, 21 Apr 2017 09:57:25 +0200
Date: Fri, 21 Apr 2017 09:57:38 +0200
From: Klaas Wierenga <klaas@wierenga.net>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org
Message-ID: <etPan.58f9bb72.55a43bc4.35d@wierenga.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Antivirus: no malware found
X-Bayes-Prob: 0.9986 (Score 4.9, tokens from: p-out:default, p:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0bTaTVBSz - 65f1bb2c0025 - 20170421
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sOBM0Wa9YqFZ7TDlWkgg9XPotXU>
Subject: [secdir] review of draft-ietf-grow-large-communities-usage-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 07:57:42 -0000

 
Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 

This document presents examples of how operators may use BGP large communities to support some typical use-cases.

In general the document is well written and I have no major issues, and I consider it: ready with nits (see below)

My one nit is that even though I think that the statement in the security considerations "Operators should note the recommendations in Section 11(https://tools.ietf.org/html/draft-ietf-grow-large-communities-usage-06#section-11) of BGP
Operations and Security [RFC7454(https://tools.ietf.org/html/rfc7454)]” is largely true, it would be useful if the authors would expand a little on that, not being an expert in this field, I am wondering if the use-cases you describe in one way or the other influence the RFC7454 considerations.

Klaas