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

"Hilarie Orman" <hilarie@purplestreak.com> Thu, 19 July 2012 18:22 UTC

Return-Path: <hilarie@purplestreak.com>
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 5A55A21F86BD; Thu, 19 Jul 2012 11:22:42 -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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjWgGBRMobFW; Thu, 19 Jul 2012 11:22:41 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD9D21F86B6; Thu, 19 Jul 2012 11:22:41 -0700 (PDT)
Received: from mx02.mta.xmission.com ([166.70.13.212]) 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 1SrvNs-000602-7c; Thu, 19 Jul 2012 12:23:32 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1SrvNo-0007GT-TC; Thu, 19 Jul 2012 12:23:32 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6JIKiKC026715; Thu, 19 Jul 2012 12:20:44 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q6JIKhGv026714; Thu, 19 Jul 2012 12:20:43 -0600
Date: Thu, 19 Jul 2012 12:20:43 -0600
Message-Id: <201207191820.q6JIKhGv026714@sylvester.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: robert@raszuk.net
In-reply-to: Yourmessage <500738E6.9070902@raszuk.net>
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ***;robert@raszuk.net
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Cc: draft-ietf-grow-diverse-bgp-path-dist.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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: Thu, 19 Jul 2012 18:22:42 -0000

Thanks for explaining the GROW WG, I apologize for not reading its
charter before writing my review.  Other comments inline.

>  Date: Thu, 19 Jul 2012 00:29:58 +0200
>  From: Robert Raszuk <robert@raszuk.net>
>  MIME-Version: 1.0
>  To: Hilarie Orman <hilarie@purplestreak.com>
>  CC: iesg@ietf.org, secdir@ietf.org,
>	   draft-ietf-grow-diverse-bgp-path-dist.all@tools.ietf.org
>  Subject: Re: Security review of draft-ietf-grow-diverse-bgp-path-dist-07
>  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>  Content-Transfer-Encoding: 7bit

>  Dear Hilarie,

>  Many thx for your comments and apologies for delayed reply. Let me 
>  attempt to clarify some of the points you raised hoping that they may 
>  shed some more light on the topic.

>  > 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.

>  Correct.

>  > 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.

>  I am perhaps missing the background of the above comment, but please 
>  keep in mind that this document is worked on in GROW WG. This working 
>  group is not tasked to define new protocol extensions, but to document 
>  operational solutions to existing problems. GROW WG also provides best 
>  common practices documentation. IMHO the more solutions GROW or any 
>  other working group in IETF defines which do not require new protocol 
>  extension the faster velocity of improvement to Internet and other IP 
>  based services can be accomplished.

>  > The draft is sketchy on how route reflectors actually work,

>  True. But this is very well documented in RFC4456 and this draft does 
>  not intend to update that RFC. In fact the draft does not changes any 
>  route reflection protocol assumptions.

>  > Still, we do not get to know if route reflectors put additional,
>  > proprietary, information on the wire,

>  They do not otherwise the specification would be a protocol extension 
>  which you correctly already observed it is not.

>From the draft, it was not apparent to me that RR communication was
specified in RFC4456.  I should have read the RFC, but shouldn't that
be a normative reference?  Also, as an editorial issue, it would help
to have some specific references to it in the descriptions of the
various routing plane scenarios.

>  > how a listener could inquire about their configuration,

>  I am not sure what do you mean by that in the light of regular IBGP 
>  session between route reflector and it's client.

A nit --- "its".

>  > or what the stability and failure properties might be.

>  The stability and failure property is identical to any other iBGP 
>  session today.

>  > 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.

>  While I understand your point it is extremely broad. One way of possible 
>  comparison would be to compare it with full mesh IBGP peering as in this 
>  case all clients would see all paths in the domain (assuming best 
>  external is enabled).

My only point is that the burden of this should be on the writers of
the drafts.  I gather that it is common practice to keep saying
"no additional security concerns" without looking at what the base
security concerns are.  Surely it is worth some "consideration"?

>  > Should BGP listeners trust the additional paths?

>  Yes. Remember those are intra-domain paths. Would BGP speaker trust any 
>  other iBGP peer ?

>  > 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 am not clear what spoofing risk you are referring to above.

RFC4272 refers to several kinds of attacks that compromise the
authentication.  You might reference that in the security consideration
section.

>  > 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.

>  This document is to provide very easy solution for BGP speaker to 
>  receive more then best path. In most applications two paths is sufficient.

>  So the main objective of this document is to observe that by simply 
>  adding new session between RR and it's client RR can be instructed to 
>  send a 2nd best/backup path on such session.

>  Both above described functions are already very commonly available in 
>  number of BGP implementations. Authors just combine both to achieve easy 
>  deployable solution which does not require massive network wide upgrades 
>  which as I am sure we all realize may take years.

All well and good.  I'd like to note that your text is much clearer
than anything in the draft; you might use it in the abstract.  You might
use that style (short, simple sentences) as a guide to revising the
draft.

Nonetheless, any new usage of a protocol may have security
implications, and it is worthwhile asking if known security issues
might lead to some new form of compromised functionality.

Hilarie