Re: [RPSEC] BGP Security Requirements v08

Stephen Kent <kent@bbn.com> Tue, 17 July 2007 16:18 UTC

Return-path: <rpsec-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAplG-0004XW-6a; Tue, 17 Jul 2007 12:18:54 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAplE-0004XM-R6 for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:18:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAplE-0004XE-Gx for rpsec@ietf.org; Tue, 17 Jul 2007 12:18:52 -0400
Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAplD-0006LV-7y for rpsec@ietf.org; Tue, 17 Jul 2007 12:18:52 -0400
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1IAplC-0003uW-5H; Tue, 17 Jul 2007 12:18:50 -0400
Mime-Version: 1.0
Message-Id: <p06240500c2c29b114c63@[128.89.89.71]>
In-Reply-To: <20070717155519.EBC053F47D@pecan.tislabs.com>
References: <20070717155519.EBC053F47D@pecan.tislabs.com>
Date: Tue, 17 Jul 2007 12:19:00 -0400
To: sandy@tislabs.com (Sandy Murphy)
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: rpsec@ietf.org, sandy@tislabs.com
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Errors-To: rpsec-bounces@ietf.org

At 11:55 AM -0400 7/17/07, Sandy Murphy wrote:
>...
>Steve, I strongly believe that incremental deployment scenarios WILL
>include cases where non-upgradable ASs will be provided with other,
>operational or algorithmic, protections, so that ISPs in the know will
>trust paths that come to them from those ASs.  I am less strongly
>convinced that incremental deployment scenarios MUST include such cases.
>But I see no way to provide benefit in incremental deployment otherwise.

Incremental deployment in ASes that are adjacent to one another 
offers  advantages, and I think one cannot rule out scenarios in 
which adjacent ASes deploy an enhanced version of BGP.

>I do not think that you are saying that solutions COULD NOT provide
>benefit when island hopping.  The work being done in the sidr wg
>(to provide an infrastructure that would provide authorization for
>prefix origination) would be an example of protections that would
>still provide benefit when island hopping, as the origin authorization
>check is of value no matter how many clueless ASs touch the UPDATE.

True, the SIDR work will make origin AS authorization data available 
to every ISP by virtue of publishing ROAs. However, it does so 
without passing ROA data via BGP, so the non-adjacency issue does not 
apply in this case.

>I believe that you are arguing whether solutions should be REQUIRED
>to provide benefit when island hopping.  And Curtis is arguing that
>they should, because otherwise incremental deployment will be very
>very unattractive.
>
>The choices seem to boil down to MUST or SHOULD.

Or a MUST/SHOULD vs. MAY.

Steve


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec