Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

Randy Bush <randy@psg.com> Fri, 08 July 2011 19:03 UTC

Return-Path: <randy@psg.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 82F1B21F89B6 for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 12:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XBHF5TUiVNp for <sidr@ietfa.amsl.com>; Fri, 8 Jul 2011 12:03:12 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EC53E21F8B0F for <sidr@ietf.org>; Fri, 8 Jul 2011 12:02:22 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <randy@psg.com>) id 1QfGJh-000I9k-Ef; Fri, 08 Jul 2011 19:02:21 +0000
Date: Sat, 09 Jul 2011 04:02:20 +0900
Message-ID: <m2aacolhoj.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Robert Raszuk <raszuk@cisco.com>
In-Reply-To: <4E170E82.60406@cisco.com>
References: <012601cc3d54$8f07c4e0$ad174ea0$@highwayman.com> <m2y609kptw.wl%randy@psg.com> <014001cc3d74$319571c0$94c05540$@highwayman.com> <m2pqlklw3v.wl%randy@psg.com> <4E170E82.60406@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server
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: Fri, 08 Jul 2011 19:03:12 -0000

> IX are used for optimizing local traffic patterns. Only very few 
> applications of IX are about Internet peering broker service (but let's 
> keep those out for the time being).

ixen are used for all sorts of things, including transit.

> So if we assume that A wants to give some of his addresses to B & C via 
> RS why do they need to bother with bgpsec at all ?

because A, B, and C have bgpsec speaking customers who want their
prefixes protected.

> When A advertises it's nets to it's Internet providers yes it will 
> forward sign it properly so they will be announced everywhere according 
> to BGPsec rules.

it's not just A's prefixes, it's also A's customers' prefixes.

> Imagine an IX without RS ... A wants to peer with B and both establish
> a peering relation I really see no need why they should get any of
> additional security on top of their direct route exchange as B will
> not be a transit for A anyway.

first, you have no idea whether they are transit or not.  the business
models across exchanges are quite diverse.

second, both A and B have CUSTOMERS.  A and B received those prefixes as
signed, and A's and B's receiving customers want to receive them via
bgpsec.

no one's customers want to have their security reduced just because an
upstream or more complex business partner uses an exchange point.
weakened security does not sell well.

randy