[secdir] Security review of draft-ietf-grow-diverse-bgp-path-dist-07

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 16 July 2012 19:32 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B70AC21F892D; Mon, 16 Jul 2012 12:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lT8M7Bc4uEgO; Mon, 16 Jul 2012 12:32:55 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by ietfa.amsl.com (Postfix) with ESMTP id EB44B21F8929; Mon, 16 Jul 2012 12:32:54 -0700 (PDT)
Received: from mx01.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1Sqr33-0006LC-GT; Mon, 16 Jul 2012 13:33:37 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=sylvester.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1Sqr30-0001jn-AV; Mon, 16 Jul 2012 13:33:37 -0600
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6GJUsvm014864; Mon, 16 Jul 2012 13:30:54 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q6GJUr6Z014862; Mon, 16 Jul 2012 13:30:53 -0600
Date: Mon, 16 Jul 2012 13:30:53 -0600
Message-Id: <201207161930.q6GJUr6Z014862@sylvester.rhmr.com>
From: Hilarie Orman <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: draft-ietf-grow-diverse-bgp-path-dist.all@tools.ietf.org, robert@raszuk.net
Subject: [secdir] Security review of draft-ietf-grow-diverse-bgp-path-dist-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Mon, 16 Jul 2012 19:32:55 -0000

Security review of draft-ietf-grow-diverse-bgp-path-dist-07
Distribution of diverse BGP paths.

Do not be alarmed.  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

This document presents a mechanism for distributing redundant BGP
paths based on the concept of parallel route reflector planes.  It
does not need any changes to the BGP protocol definition.

The general notion is that different groups of route reflectors would
be assigned find the "nth best route" where n varies from 1 to a small
number.  All n routes would be presented to devices connected to the
route reflectors.  This in turn would enable a multitude of benefits:
quick routing restoration, load balancing, and churn reduction.

The point of making this an IETF document is odd.  Its fundamental
message is "instead of using extensions to BGP for additional paths,
you could use route reflectors configured for nth best path."  And, as
it turns out, Cisco makes such a product.

The draft is sketchy on how route reflectors actually work, and the
writing is a testament to the complexity and redundancy of English, a
notoriously user unfriendly language.  The text is very difficult to
read, but eventually some non-ambiguous meaning emerges from each
sentence, despite the irregular grammar and run-on sentences.  Oddly
enough, Cisco's documentation about its route reflectors is
well-written.  I would refer interested readers there.

Still, we do not get to know if route reflectors put additional,
proprietary, information on the wire, how a listener could inquire
about their configuration, or what the stability and failure
properties might be.

All of this makes for difficulties in doing a security analysis.  The
document asserts that all security problems are subsumed by prior work
in analyzing BGP security.  This might be true, but BGP has a number
of documented vulnerabilities, and the new paths might multiply them.

Should BGP listeners trust the additional paths?  Are opportunities
for spoofing increased because listeners should expect more paths?
What are the interactions between spoofed failures and switching to
one of the diverse paths?  Could route reflectors be tricked into
permuting the path ordering so fast that paths never stabilize?

I think that the security considerations should address potential
problems in the context of the previous analyses of BGP security, if
this is indeed a protocol document in the ordinary IETF sense.
Perhaps it is not, maybe it is an infrastructure configuration guide
or an argument against BGP add-paths extensions.  I can't tell.


NB: "Hilarie Orman" is my actual name and not a pseudonym for any
other person with similar knowledge or interests.