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

"Sriram, Kotikalapudi" <> Tue, 15 September 2015 00:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6B171B3B8E for <>; Mon, 14 Sep 2015 17:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ObQE1xsX5wdi for <>; Mon, 14 Sep 2015 17:54:43 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DCC31B3B6E for <>; Mon, 14 Sep 2015 17:54:42 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 15 Sep 2015 00:54:39 +0000
Received: from ([]) by ([]) with mapi id 15.01.0268.017; Tue, 15 Sep 2015 00:54:39 +0000
From: "Sriram, Kotikalapudi" <>
To: David Mandelberg <>, "" <>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ5zRVYND+nmLqz0SZcM1xIM4p8p4zZROAgAlrFm4=
Date: Tue, 15 Sep 2015 00:54:39 +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; CY1PR09MB0796; 5:PVaX2w6ApFTVQpjxiuZvdlJQXtcdS9Yay3F1lw47wFsm9yI4MH4xP8ewE/kw3O/oL4UI8idGNxzL2k+3iiNtNmXustDDflx2yo0PEBV+hrAXMPR9DcoFoX3xX1qY3pO9OwCUuwOPFI56Ijo+hMDKZA==; 24:8H8dAbZ8X2llMokcn4yJRvUz9YwH6ETSEulY2e0+ahB7Zz1Uj/Ah8xlrevVRX31X4WMeI71w7cor1blVBsHv4gjzTCSawe7IDySTMbhY81E=; 20:8dt7FtnT5QCPucH4iOG1mOqiru5C854V4X4S1rKnIvifhB+pekpIowqlSryQ7ZOb4Oqytzdri44pvmk8QZg28Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520075)(8121501046)(520078)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796;
x-forefront-prvs: 070092A9D3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(77156002)(66066001)(81156007)(4001540100001)(64706001)(76576001)(2900100001)(5001830100001)(2501003)(10400500002)(40100003)(11100500001)(5004730100002)(5007970100001)(122556002)(74316001)(92566002)(2950100001)(68736005)(86362001)(189998001)(77096005)(46102003)(102836002)(5002640100001)(5001860100001)(230783001)(97736004)(5001960100002)(106116001)(50986999)(107886002)(54356999)(33656002)(5001770100001)(101416001)(76176999)(93886004)(105586002)(106356001)(62966003)(99286002)(87936001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796;; 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: 15 Sep 2015 00:54:39.1725 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796
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: Tue, 15 Sep 2015 00:54:46 -0000

>> 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.
>Without replay protection, I don't see how this recommendation would
>help. I.e., the old signed update would still be valid.

In the example with   -- > A --> B --> C --> D -->, if B and C 
(the ones that were signing but not verifying) return to the update to verify, 
then they will realize that the update they last signed (for the prefix) was invalid,
and will propagate an alternate valid signed announcement or 
send a withdrawal message to D.
At this point, B and C have taken their corrective action.
Their well-behaving neighbors (others besides D) will act on 
the new valid announcement or the withdrawal.
But if D is still malicious and suppresses the new valid announcement
or the withdraw, then that would be 
a classic withdraw suppression / replay attack.
(B and C are not contributing to collusion anymore at this point.)
And the solution at that point is whatever remedy 
draft-ietf-sidr-bgpsec-rollover-04 offers.