Re: [sidr] Route Leaks and BGP Security

Russ White <russw@riw.us> Mon, 21 November 2011 12:32 UTC

Return-Path: <russw@riw.us>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8021F8C0F for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 04:32:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 RVwKxQCjBcpH for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 04:32:44 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1D221F8C0E for <sidr@ietf.org>; Mon, 21 Nov 2011 04:32:44 -0800 (PST)
Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:54639 helo=[192.168.100.52]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RST3D-0002ej-5S for sidr@ietf.org; Mon, 21 Nov 2011 07:32:43 -0500
Message-ID: <4ECA44E2.1050402@riw.us>
Date: Mon, 21 Nov 2011 07:32:34 -0500
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: sidr@ietf.org
References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLabbHVauBYUkXCxdpWW90Vt+fMRzATr-aOrdU912ibxJeQ@mail.gmail.com>
In-Reply-To: <CAL9jLabbHVauBYUkXCxdpWW90Vt+fMRzATr-aOrdU912ibxJeQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Subject: Re: [sidr] Route Leaks and BGP Security
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2011 12:32:44 -0000

> danny's draft actually does a decent job of saying what a leak is (one
> instance of a leak at least, which is fine), it just doesn't say how
> you'd know that from 2 as-hops away... (today, with out bgp changes
> and/or external knowledge about the ASes in the AS-Path)

I came to the conclusion long ago that BGP doesn't carry the information
needed to "secure" the AS Path... Maybe this is why BGPsec can't provide
the information needed to make intelligent decisions in so many places
--because BGP itself doesn't provide that information, and BGPsec only
attempts to "secure the semantics of BGP" (and that only in a rather
incomplete way).

The solution isn't to rule out such problems because they're
"unsolvable." There are, in fact, at least two systems that can solve
this problem.

>> When S sends a packet to D, that packet should traverse
>> only ASs that S trusts OR that D trusts. If the packet
>> traverses an AS that NEITHER S NOR D trusts, then a route
>> leak has occurred.

I would generally avoid using packet flow models as a way to describe
BGP security issues... BGP, like all routing protocols, is a distributed
real time database combined with a set of rules about using the data
within the database.

By signing the updates, you're attempting to show that the each node
participating in the database has followed the rules correctly. The
problem is that many of the rules are implicit, rather than explicit,
and implicit rules don't lend themselves to being signed. Danny's route
leak problem, or needing "beacons," to take routes out of the system,
etc., are instances of implicit rules.

You have to start with a good model and good requirements, and then work
from there. The model the WG has chosen --"we're going to secure BGP
semantics," doesn't lead to a good result, simply because not all the
semantics are on the table to be secured.

:-)

Russ