Re: [sidr] Route Leaks and BGP Security

Russ White <russw@riw.us> Tue, 22 November 2011 12:35 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 0D1FF21F8DD4 for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 04:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.564
X-Spam-Level:
X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 D0KKpIWFCgFa for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 04:35:49 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 603E121F8DD0 for <sidr@ietf.org>; Tue, 22 Nov 2011 04:35:49 -0800 (PST)
Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:52363 helo=[192.168.100.52]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RSpZk-0007Qe-Dg for sidr@ietf.org; Tue, 22 Nov 2011 07:35:48 -0500
Message-ID: <4ECB971D.2090501@riw.us>
Date: Tue, 22 Nov 2011 07:35:41 -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> <CAL9jLaZvCe2U6Y=BbZxsfF+BDOqQuV18Ac6N_6Fxxc=Cpms1jg@mail.gmail.com> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> <CAL9jLaY9rNCuLqozgbD7r03U8ZHB_n6MLmFrpVziPM2NNAuqnw@mail.gmail.com>
In-Reply-To: <CAL9jLaY9rNCuLqozgbD7r03U8ZHB_n6MLmFrpVziPM2NNAuqnw@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: Tue, 22 Nov 2011 12:35:50 -0000

> yup... no-export/advertise were taken as 'advisory' communities that
> networks MAY heed, but certainly weren't bound to do so.

>From what's been said on the list in the last several days, however,
isn't it true that even the signatures are "advisory?" There is an
insistence that local policy overrules the signatures --so all the
entire SIDR effort is doing is providing more information on which to act.

Why wouldn't signing communities be providing more information on which
to act, as well? How can we say that providing more information on which
to at is legitimate in the one case (that the receiver isn't bound by
the information provided, but it is good information to have), and yet
in the second case argue that because no-one is bound to act on the
information, we shouldn't provide it?

> I suppose documenting: "One leak scenario is <see id name>" is a fine
> thing, does it help to actually fix the problem though? I think what I
> heard in the meeting and on the thread(s) here was: "Sure leaks are
> important, there's not a way devised so far that distinguishes a
> 'leak' route from a 'normal' route, more than 1 as-hop from the
> 'source' of the leak.
> 
> In the id/draft:
> 
>    isp1   isp2 - me
>        \     /
>         AS1
> 
> I can't tell at 'me' that the route I see is a 'leak', just that I see
> an as-path that is isp1-as1-isp2.

There is a way to tell --you simply have to have ISP1 and ISP2 advertise
through some mechanism that AS1 is not a transit peer. You can either
add this information into BGP itself, through a community or some other
attribute --but note that BGP wasn't designed to do this, and you're
trusting AS1 to pass along the information that's it's not a transit
peer when trying to act as a transit peer (a bit pathological, IMHO), or
you must do so out of band.

There are out of band solutions available, but the insistence that
no-one ever advertise their intent has blocked all such out of band options.

Not everyone might object to advertising their intent --and building a
system that doesn't allow the advertisement of policy to appease the few
that do object appears to be backwards from the way business should be
done. Operators should be given the ability to trade off between
additional security and "privacy."

:-)

Russ