Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

"Sriram, Kotikalapudi" <> Fri, 04 September 2015 17:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E21C51A8AA4 for <>; Fri, 4 Sep 2015 10:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id afqu9YJh9L9t for <>; Fri, 4 Sep 2015 10:08:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFC3A1A8A8C for <>; Fri, 4 Sep 2015 10:08:37 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 4 Sep 2015 17:08:35 +0000
Received: from ([]) by ([]) with mapi id 15.01.0262.011; Fri, 4 Sep 2015 17:08:35 +0000
From: "Sriram, Kotikalapudi" <>
To: "sidr wg list (" <>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ5zRVYND+nmLqz0SZcM1xIM4p8g==
Date: Fri, 04 Sep 2015 17:08:34 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BN1PR09MB012; 5:X/HrB2Z/BiQHCdUw/gH4PWSVjTUvH/oyiICMMEKQCS3QyIc132tiujIqT4b1Nw3ckePPjjQHwvT1rlOZHjm0lLTo2YB11bQrn6elyKNWtzwTdqqT6kGtdKK9SR9Iyv2ILxqO8/phPZfHa4XSazcuxw==; 24:woMCLx3UfRpTcbtRLpaIQsv2zFMvYz0M06qWPPOtyC1YpdRpIM238cf5Q+z0yoVk0WuRTF740npoq2wcygD8dzGA4WXJn2EA5OPZIXeA7SY=; 20:KHQgmTNDp3az7q/VW3EjSkLJwSZVb9g42k+oTkLZbrC9Hfk1Muo+wqqwccdzyK7e0w06ODpKEyNNi4F3O8Z74Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB012;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN1PR09MB012; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB012;
x-forefront-prvs: 06891E23FB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5001860100001)(230783001)(105586002)(74316001)(66066001)(40100003)(2420400006)(68736005)(64706001)(81156007)(97736004)(450100001)(77156002)(106116001)(5002640100001)(19580395003)(102836002)(77096005)(106356001)(62966003)(46102003)(5003600100002)(122556002)(110136002)(50986999)(107886002)(87936001)(99286002)(5007970100001)(76176999)(5001830100001)(33656002)(5004730100002)(54356999)(15975445007)(92566002)(189998001)(10400500002)(86362001)(93886004)(5001960100002)(2900100001)(4001540100001)(2950100001)(101416001)(76576001)(7110500001)(10710500003)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB012;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2015 17:08:34.9952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB012
Archived-At: <>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Sep 2015 17:08:43 -0000

Doug and I have discussed the issues raised in this thread in some detail.
We feel that the following considerations (with corresponding changes in the document) 
would help resolve the issue(s) we are dealing with:

1.  As mentioned already, signature should cover more data so that 
the collusion vulnerability that David pointed out can be addressed.

2.  It was a conscious design decision to not require (MUST) validation before
path selection and signing in all cases. Lazy (or deferred) evaluation 
(e.g., the ability to select and sign a path before validation) adds 
performance / robustness options to implementations that address 
real operational concerns (e.g., convergence time on table dumps, bootstrap, etc.) 
that were identified early in the BGPsec design process.

3.  In consideration of the above (#2), the document should instead 
strongly recommend that “if an AS signs an update without verifying first, 
it SHOULD return to the update at its earliest and verify, and forward 
a new signed update, if necessary." Make this a strong BCP recommendation.

4. If this recommendation (#3) is followed, then other collusion/replay effects 
that have been identified on the list will be short lived 
(e.g. Oliver’s:  ). 
Adverse effects would be short lived, if the duration of deferment of 
verification (if any) is short.