Re: [RPSEC] BGP Security Requirements v08

Stephen Kent <kent@bbn.com> Thu, 19 July 2007 19:13 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 1IBbRS-0004Fo-0d; Thu, 19 Jul 2007 15:13:38 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRQ-0004Cj-Hr for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0004CS-7h for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400
Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRP-0007r8-UO for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1IBbRP-0006za-4l; Thu, 19 Jul 2007 15:13:35 -0400
Mime-Version: 1.0
Message-Id: <p06240505c2c52c906079@[128.89.89.71]>
In-Reply-To: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com>
References: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com>
Date: Thu, 19 Jul 2007 15:06:32 -0400
To: curtis@occnc.com
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: 9182cfff02fae4f1b6e9349e01d62f32
Cc: rpsec@ietf.org, Sandy Murphy <sandy@tislabs.com>, Russ White <riw@cisco.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 4:00 PM -0400 7/18/07, Curtis Villamizar wrote:
>...
>For example, if the AS Path is A X Y Z and I trust my peer A but not X
>and Y, the ROA only tells me that its OK for Z to have originated this
>route and nothing about whether this could have legitimately passed
>through Y and Z.  An authentication would be Z signature, Y signing
>that, X signing that, and A passing along the signatures.  If 128
>bytes are used per signature that is 384 bytes.

We really ought not get into details on specific techniques, as Russ 
noted. For example, if one uses a fancy EEC signature scheme that 
allow signature aggregation, the total for the three signatures is 
about 128 bytes.  (See the PhD work by  Meiyuan Zhao at Dartmouth 2 
years ago.)

>OTOH if some OOB mechanism also addressed whether a peering might be
>legitimate, then requirements would be met.  So maybe its just that
>the current ROA scheme (or schema) is inadequate.

The ROA scheme has a specific purpose, i.e., allowing a resource 
holder to express an globally-verifiable authorization to originate a 
route to the holder's prefix(es). ROAs ought not be criticized for 
not doing something that they are not intended to do.

Steve


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