Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Fri, 09 September 2011 13:44 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 8E0C921F8AB8 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 06:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpPqZIYD7Wzo for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 06:44:55 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id D704121F8AAC for <sidr@ietf.org>; Fri, 9 Sep 2011 06:44:54 -0700 (PDT)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 9 Sep 2011 09:47:31 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Sep 2011 09:46:14 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: "robert@raszuk.net" <robert@raszuk.net>, Jakob Heitz <jakob.heitz@ericsson.com>
Date: Fri, 09 Sep 2011 09:46:14 -0400
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxuaiF/8NedlGWeTnyNz5fL+wOVvQAiV1Oy
Message-ID: <D7A0423E5E193F40BE6E94126930C49308D2CF54CF@MBCLUSTER.xchange.nist.gov>
References: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net> <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <B92913D1-AB82-4D9F-B8A9-F8F4F99713D6@tcb.net> <p06240803ca685bff5443@[128.89.89.43]> <D6D12861-412E-4A65-B626-B627449981B8@tcb.net> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <D7A0423E5E193F40BE6E94126930C49308D36D8383@MBCLUSTER.xchange.nist.gov> <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se>, <4E692C6F.6030104@raszuk.net>
In-Reply-To: <4E692C6F.6030104@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
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, 09 Sep 2011 13:44:55 -0000

-- snip --
>> If we reprioritise BGPSec, we could make it work. Sugestion:
>> during bringup, send routes without the BGPSec attribute.
>
>I think there is a significant risk that this would cause unnecessary
>Internet wide churn.
>
>I would propose and alternative approach. To send the routes with
>whatever attributes sender decides to send then with and do it only once.
>
>Up-on reception if indeed inline CPU processing is an issue on given
>platform store the BGPSec related attributes without any processing then
>when CPU get's idle .. verify them.
>
>Hoping that only small fraction of all routes could be considered
>invalid you may later withdraw them.
>
>Of course this only attempts to fix inbound processing issue. You can
>not do the same when signing the routes outbound.

Jakob:
Robert:

The protocol permits the ideas you are proposing -- see Section 4.2.
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-00#section-4.2

The key wording there is:
.... it is RECOMMENDED that if the BGPSEC speaker 
chooses to propagate the route that it
generate an update message containing the BGPSEC_Path_Signatures
attribute.  However, a BGPSEC speaker MAY propagate a route
advertisement by generating a (non-BGPSEC) update message that does
not contain the BGPSEC_Path_Signatures attribute. 

Also, the optimizations you mention are included/discussed 
in Section 5.4 of the draft-sriram-bgpsec-design-choices document:  
5.4. Temporary Suspension of Attestations and Validations
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-5.4

Robert seems to be asserting that the router must always 
sign and propagate the update (if it selected a signed update for best path). 
However, the current protocol specification allows for dropping BGPSEC_Path_Signatures
attribute (potentially for cases when the route-processor is in overload state). 

Sriram