Re: [sidr] BGPSEC Threat Model ID

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 05 November 2011 04:35 UTC

Return-Path: <brian.peter.dickson@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 7732621F86A1 for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 21:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.617
X-Spam-Level:
X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 VLUiX7yy6YB3 for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 21:35:14 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21E21F86A0 for <sidr@ietf.org>; Fri, 4 Nov 2011 21:35:13 -0700 (PDT)
Received: by faas12 with SMTP id s12so3908205faa.31 for <sidr@ietf.org>; Fri, 04 Nov 2011 21:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Al6Yvf+q0f2rPE7T0c+vGqEBkuB3kQTCwq7YkFBzidk=; b=cBeag9W/NS7loxVVQcTD09eLtKGHD1nNAoMgV1BSj8Ii3kR1FJVO5SUeabTYNOwwy3 RpH4x3rwmpiFGA5ME708R10/kL3+OnIljQZQ2aKorK7O2anP1PMoCWDJOIu6iAzSEU/c iZoOpVyNI695JA3ANuonJEofS6ZlqmoJDnY2s=
MIME-Version: 1.0
Received: by 10.223.6.129 with SMTP id 1mr18521240faz.17.1320467712686; Fri, 04 Nov 2011 21:35:12 -0700 (PDT)
Received: by 10.223.54.15 with HTTP; Fri, 4 Nov 2011 21:35:12 -0700 (PDT)
In-Reply-To: <110BD765-3943-4442-846B-F73C8B632E3B@ericsson.com>
References: <E96517DD-BAC7-4DD8-B345-562F71788C6A@tcb.net> <p06240807cad42f85eb7d@193.0.26.186> <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <p06240801cad6ab773279@193.0.26.186> <D9A38669-883D-4090-9F95-BC5C63220950@tcb.net> <p06240801cad800485596@193.0.26.186> <EEBF68E0-FAD9-4AF3-B81B-78760D200D9B@tcb.net> <p06240808cad85ff73d61@193.0.26.186> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <CAFU7BATC-6DUDNuadakwSa5wj0ryy0=49=XveBXD5Wv=5JL-ag@mail.gmail.com> <m2aa8c489s.wl%randy@psg.com> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <CAL9jLaZj1wcmDnbm1f9=csUv2Uuq_w3rS6UEYmUHAQDPWT9zFg@mail.gmail.com> <CAH1iCiqmRjPTX7RFK+q=CJRWv9qwdMGdRc_G7GhKrV57dM-K3w@mail.gmail.com> <110BD765-3943-4442-846B-F73C8B632E3B@ericsson.com>
Date: Sat, 05 Nov 2011 00:35:12 -0400
Message-ID: <CAH1iCipMDhta4b1NdLks1KtMWGTXWPMjyFnV+vt6VTLu=PsFyQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] BGPSEC Threat Model ID
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: Sat, 05 Nov 2011 04:35:14 -0000

On Sat, Nov 5, 2011 at 12:21 AM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
> On Nov 4, 2011, at 3:41 PM, "Brian Dickson" <brian.peter.dickson@gmail.com> wrote:
>
>> Once a route crosses a peer connection or goes "downhill", it can no
>> longer go "uphill"
>> or cross another peering link.
>
> Why can it not cross a peering link?
>
> --
> Jakob Heitz.

When two networks peer, they agree to exchange routes for their
respective customers.

If A announces a route to B, that route is A's customer and _not_ B's customer.
So, by the nature of the agreements, B cannot announce that route to
another peer, C.

Take the worst case - a tier-1 network. All their routes are either
customer routes, or peer routes.
If they were to send their peers' routes to their peers, they would be
sending all routes to everyone.
They would be providing transit, for free, to their peers. This would
not be good for many reasons.

Put another way - when network B sends routes to peer C, it is
providing transit to those routes.
It generally only wants to do that for customers, especially if that
happens to be its primary business.

Brian