[secdir] Secdir review of draft-ietf-grow-ix-bgp-route-server-operations-03
Catherine Meadows <catherine.meadows@nrl.navy.mil> Wed, 17 September 2014 20:09 UTC
Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4D1A0AF6; Wed, 17 Sep 2014 13:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.851
X-Spam-Level:
X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham
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 234bT0ggo-VB; Wed, 17 Sep 2014 13:09:03 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2561A0AF8; Wed, 17 Sep 2014 13:09:03 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s8HK9192007694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Sep 2014 16:09:01 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_622C2FE0-B12A-4FC3-9BED-BE7C8DB86B22"
Date: Wed, 17 Sep 2014 16:09:01 -0400
Message-Id: <9F322527-7D45-4A6C-9928-5F71DB9D948C@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-ix-bgp-route-server-operations.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gJHj8Sy3a7qDLNWMZ_koVOkEnV0
Subject: [secdir] Secdir review of draft-ietf-grow-ix-bgp-route-server-operations-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 17 Sep 2014 20:09:05 -0000
I have reviewed the current version of 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 draft discusses several issues of operational relevance to route server operators and provides recommendations to help them provide a reliable interconnection services. Reliability, not security, is the main focus of this document, but several of the problems that are discussed also have implications for security, mainly because if they are not properly addressed they can be used to implement various attacks, mostly in the form of denial of service. These are summarized in the Security Considerations section, and it is pointed out in that section which countermeasures described in the document defend against these attacks. My only criticism of the Security Considerations section is that the issues are not described in very much detail. It would be helpful to have references to other documents where more information is given. Otherwise I find myself asking questions such as “What are the ‘certain circumstances’ under which the path hiding problem can be exploited” and “How is it trivial for a route server to implement denial of service if prefix leakage mitigation is not implemented?” Also, a nit. I found the summary of path hiding in Section 4.1 a little misleading: "Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to describe the process whereby a route server may mask individual paths by applying conflicting routing policies to its Loc-RIB. This gave me the impression that path hiding is something done deliberately, when actually it appears to be an unintended side effect. The reference draft.ietf-idr-ix-bgp-route-server makes the unintended nature of path hiding more clear. I think it would be better to have something like the following: "Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to describe the process whereby a route server may inadvertently mask individual paths by applying conflicting routing policies to its Loc-RIB. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil
- [secdir] Secdir review of draft-ietf-grow-ix-bgp-… Catherine Meadows
- Re: [secdir] Secdir review of draft-ietf-grow-ix-… Nick Hilliard