Re: [RPSEC] BGP Security Requirements v08

Tony Tauber <ttauber@1-4-5.net> Tue, 17 July 2007 16:33 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 1IApyx-00019c-Ss; Tue, 17 Jul 2007 12:33:03 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IApyt-0000pD-3r for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:32:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApys-0000mb-AY for rpsec@ietf.org; Tue, 17 Jul 2007 12:32:58 -0400
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IApyo-0006Jk-V1 for rpsec@ietf.org; Tue, 17 Jul 2007 12:32:58 -0400
Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6HGWhSm024790; Tue, 17 Jul 2007 09:32:43 -0700
Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6HGWhng024789; Tue, 17 Jul 2007 09:32:43 -0700
Date: Tue, 17 Jul 2007 09:32:43 -0700
From: Tony Tauber <ttauber@1-4-5.net>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
Message-ID: <20070717163243.GB1426@1-4-5.net>
References: <20070717155519.EBC053F47D@pecan.tislabs.com> <p06240500c2c29b114c63@[128.89.89.71]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240500c2c29b114c63@[128.89.89.71]>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: rpsec@ietf.org, Sandy Murphy <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

What meaning a receiving AS might assign to a partially authenticated
piece of data is left up to that AS (keeping in the spirit of autonomy).

Certainly one can envision an attack which exposes the authenticated
origin info but which nefariously removes intervening hops to draw in
traffic improperly (e.g., to inspect, alter, or drop).

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

Right, based on the discussion thus far, I was leaning toward keeping
the idea in as a MAY.  One might argue that doing so is effectively the
same as leaving it out altogether, but the intention and information is
retained.  Beyond that, asserting it as a "MAY" explicitly blocks any
interpretation which ends in "... NOT".

Tony


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