Re: [sidr] Route Leaks and BGP Security

Christopher Morrow <morrowc.lists@gmail.com> Mon, 21 November 2011 05:35 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 DC9E311E8096 for <sidr@ietfa.amsl.com>; Sun, 20 Nov 2011 21:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.556
X-Spam-Level:
X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 hDk+-TVIsStH for <sidr@ietfa.amsl.com>; Sun, 20 Nov 2011 21:35:54 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AD11E808D for <sidr@ietf.org>; Sun, 20 Nov 2011 21:35:54 -0800 (PST)
Received: by ggeq3 with SMTP id q3so3326150gge.31 for <sidr@ietf.org>; Sun, 20 Nov 2011 21:35:53 -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=4X6Zphh48ZiSoYBhSJy4B8ejuAb86xJ+CrdC6OKxDms=; b=cnh5xF6s2ewzI/UmD27gA/3cy1qH/K3vFtyGycose6nUh1itsk78Kr6kakOe4k8Mxq 9Oa0myWmNN/oq5fI5knrmXmgf+WfnTZVcFurTlU/Cueo1eu/zcc95RGlSqk3GI3UyuCD 9OQpXsBOMPbNh4ZEaLspCVGN+pDzwtbdUsTWg=
MIME-Version: 1.0
Received: by 10.50.88.199 with SMTP id bi7mr13061669igb.45.1321853753556; Sun, 20 Nov 2011 21:35:53 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.231.202.142 with HTTP; Sun, 20 Nov 2011 21:35:53 -0800 (PST)
In-Reply-To: <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net>
References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net>
Date: Mon, 21 Nov 2011 00:35:53 -0500
X-Google-Sender-Auth: Df3ubcfQy9sodQhrSxdzrpHO7ow
Message-ID: <CAL9jLaZvCe2U6Y=BbZxsfF+BDOqQuV18Ac6N_6Fxxc=Cpms1jg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <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: Mon, 21 Nov 2011 05:35:55 -0000

On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson <danny@tcb.net> wrote:
>
> Team,
> I've updated this draft based on some feedback received already.  Given
> the discussion at the WG session, and the list discussion as of late, I'd like
> to ask that it become a WG item and used to inform the BGP Threat Model
> document -- particularly with regards to what's an acceptable residual risk and
> what is not.  Once that's comprehensive it can be used to inform secure routing
> requirements documents in the working group, and then we can begin assessing
> the feasibility of reducing various risks.

"The authors believe the capability to prevent leaks should be a	
  first-order engineering objective in any secure routing architecture."

So, in the simple scenario laid out, the customer is filtered by the
isp's, no? and the filter data is built with something like:  take irr
data, meld with rpki data, create filter-lists.

The rpki data gives the isps an ability to filter the customer
announcements, which would stop the leaks. Is the thing you really
want to outline in a draft the process to link the
resource-certification data with the existing IRR data and create
better prefix/as-path filters?

I think one item that was asked for on the list (or perhaps in the
meeting) was: How can you know a route you see is a leak?

Taken another way, in the case of your example:

victim - isp2 - attacker - isp1

how is the victim to know that this path isn't proper?
what in the update says that?
is there other data that could be used (outside of bgp) to tell the
victim that the path is improper?

-chris