Re: [RPSEC] BGP Security Requirements v08

sandy@tislabs.com (Sandy Murphy) Tue, 10 July 2007 21:50 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 1I8Nbi-00044j-CW; Tue, 10 Jul 2007 17:50:54 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8Nbh-00044Y-9L for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:50:53 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Nbg-00044Q-VJ for rpsec@ietf.org; Tue, 10 Jul 2007 17:50:52 -0400
Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Nbg-0007V2-Nb for rpsec@ietf.org; Tue, 10 Jul 2007 17:50:52 -0400
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6ALl6dc020521; Tue, 10 Jul 2007 17:47:06 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtuaW2N; Tue, 10 Jul 07 17:46:25 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005) id 7AF9F3F421; Tue, 10 Jul 2007 17:44:30 -0400 (EDT)
To: kent@bbn.com, ttauber@1-4-5.net
Subject: Re: [RPSEC] BGP Security Requirements v08
In-Reply-To: <20070710213538.GB27477@1-4-5.net>
Message-Id: <20070710214430.7AF9F3F421@pecan.tislabs.com>
Date: Tue, 10 Jul 2007 17:44:30 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: rpsec@ietf.org
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

> My comment was:  One might interpret this to mean that any extended 
> form of UDATE message MUST be transmitted through ASes that are not
> capable of processing it. This is imposing an unnecessary burden on
> solutions, since an alternative is to just mot send such messages
> through ASes than can't make use of them.

This is a question about use of security information during initial
deployment.  If there are islands of deployment that must communicate
through seas of non-deployment, is it useful for the deployer to
learn that there is a protected route island out there?  When the
information came to them over an unprotected sea?

I'd say that there is a potential for benefit.  Perhaps the unprotected
sea in between is known by other out-of-band means to be reliable,
even if clueless about the new protection mechanisms.  There might
be operational procedures that protect the intermediate sea that
are adequate from the point of view of the recipient on the island.

So I'd say that passing the info along is potentially beneficial,
to some, and should be passed.  The cost to the clueless routers
is storage and bandwidth - processing cost should be minimal.

--Sandy


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