Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

Jeffrey Haas <jhaas@pfrc.org> Wed, 14 May 2014 13:58 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB41A009C; Wed, 14 May 2014 06:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 uYwj17qs-Lbg; Wed, 14 May 2014 06:58:10 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB71A0099; Wed, 14 May 2014 06:58:10 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4262AC26A; Wed, 14 May 2014 09:58:04 -0400 (EDT)
Date: Wed, 14 May 2014 09:58:04 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "George, Wes" <wesley.george@twcable.com>
Message-ID: <20140514135804.GJ16861@pfrc>
References: <CAL9jLabRKA2gezfRdzND1TSYMJO+a_4mVV+M302cLBFTUwYmTQ@mail.gmail.com> <CF96AEDB.1B684%wesley.george@twcable.com> <CAL9jLaZ9J52Dt5n1Wk2KYTqwzmefGxvq-bRcfMfhWBNwf_6ZGg@mail.gmail.com> <CF978B01.1B737%wesley.george@twcable.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CF978B01.1B737%wesley.george@twcable.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/jKkqOjmLIRJ9j1YEDIPIgJ50_nc
Cc: "grow-chairs@ietf.org" <grow-chairs@ietf.org>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 13:58:12 -0000

[picking on this message to base my comments]

On Tue, May 13, 2014 at 09:48:32AM -0400, George, Wes wrote:
> If I were to define a route leak succinctly, I???d say something like:
> 
> A route leak occurs when a valid (in this document???s case, valid=
> validated by RPKI Origin Validation and BGPSec) route announcement is
> propagated beyond its intended AS boundary. The AS boundary can be one, or
> an arbitrary number of ASNs away, and may be different for different BGP
> Peer ASNs. These leaks can occur due to either misconfigurations or
> malicious intent (I.e. An attempt to perform a MITM attack), (and any
> solution should provide means to prevent both types of leak).

This to a large extent identifies the problem: BGP *as a protocol* has no
idea what these boundaries are.  Thus, "intent" is up to the perception of
the involved parties.

This thread has looped a few iterations with "this is a problem!" and SIDR
basically saying "there's nothing in BGP here to secure".  Both things are
still true.

I think documenting route-leaks and their potential negative (or malicious)
consequences is worth GROW doing.

I think this issue exists even without bgpsec being involved.  While it's
correct that bgpsec doesn't add anything here, until the underlying base
protocol has some idea of what we can do, picking on bgpsec doesn't help.
If anything, I'd probably take the route-leak document and say "here's the
problem" with a one or two sentence note that bgpsec doesn't do much. 

In it's current form, I don't think the document is ready to progress.  I'd
even suggest it needs to be rescoped.

The interesting work is resurrecting the thread on injecting routing policy
intent into some system we can secure. :-)

-- Jeff