Re: [sidr] Route Leaks and BGP Security

Christopher Morrow <morrowc.lists@gmail.com> Tue, 22 November 2011 21:12 UTC

Return-Path: <christopher.morrow@gmail.com>
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 BAD8E1F0C47 for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 13:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.554
X-Spam-Level:
X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 gAERgyoWxCkS for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 13:12:58 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E54571F0C35 for <sidr@ietf.org>; Tue, 22 Nov 2011 13:12:57 -0800 (PST)
Received: by iaeo4 with SMTP id o4so822572iae.31 for <sidr@ietf.org>; Tue, 22 Nov 2011 13:12:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=is9aixeNzqHHudMRi6GEzqUWkBU/Cv0EDxmKJfr1tAk=; b=UDmSnFt+/IVpXbZ6216EKWlSNcdwXMRj+2oKHTsMo5Rbb5DwFcK+DYlMwPIwTIP4Jx ICvjQ23mPHCyROOCtqeq0ZaugSKwiN+HUDY/Q655NvcvQlFlioQWzfSZR+9mHkyMjFVw 1vsc9e60NEIbs9aAGCtasrOaKkU5XatYLGoM4=
MIME-Version: 1.0
Received: by 10.231.27.203 with SMTP id j11mr5718083ibc.10.1321996377509; Tue, 22 Nov 2011 13:12:57 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.231.207.78 with HTTP; Tue, 22 Nov 2011 13:12:57 -0800 (PST)
In-Reply-To: <4ECB971D.2090501@riw.us>
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> <4ECB971D.2090501@riw.us>
Date: Tue, 22 Nov 2011 16:12:57 -0500
X-Google-Sender-Auth: k2Pm1WZFm364fPTmKymtAlvyORU
Message-ID: <CAL9jLaYy0bUEMstJNvayRvpedz9S030QWhtoFg=oVk7NYqu8gw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Russ White <russw@riw.us>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: sidr@ietf.org
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 21:12:58 -0000

On Tue, Nov 22, 2011 at 7:35 AM, Russ White <russw@riw.us> wrote:
>
>> 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

in the end state I think we'd like them to be mandatory. If they
aren't there then the operator of the network in question can decide
to accept/depref/deny the route in question.

> insistence that local policy overrules the signatures --so all the
> entire SIDR effort is doing is providing more information on which to act.

sure.

> 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

If communities were guaranteed to exist along the entire path, maybe?
If people didn't add communities and drop them 'at will' maybe? If we
understood what a community meant, maybe?

I don't see any of the three things there being the case though :(
Communities are really only useful inside a single AS or to the direct
peers (where they signal ala RFC1998 action to be taken on the peer
network).

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

right, this was the focus of at least 2 messages I sent over the last
few days, it's also a focus of Brian Dickson's notes... 'add a bit to
bgp, flip it up/down if customer/peer'. I don't see a practical (and
trustworthy) method to do that though.

-chris

> 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
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>