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

"Borchert, Oliver" <> Thu, 27 August 2015 19:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 18B361B3B67 for <>; Thu, 27 Aug 2015 12:15:58 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KkTVYyKpeVwD for <>; Thu, 27 Aug 2015 12:15:55 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67F821B3B50 for <>; Thu, 27 Aug 2015 12:15:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 27 Aug 2015 19:15:52 +0000
Received: from ([]) by ([]) with mapi id 15.01.0243.020; Thu, 27 Aug 2015 19:15:52 +0000
From: "Borchert, Oliver" <>
To: "" <>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ4EXk8vgV73xBckONsKYcP4tTrp4f/liAgAAlDQD//9KSAA==
Date: Thu, 27 Aug 2015 19:15:52 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BN3PR09MB0356; 5:7jatvv9pKI6ozuRt9lwdue+m3PLUz9IWSAxB9dyeeKmkfiQD2NI9KuAt8py0Bai6AyvtCZQ2UM8ghFDIoapea8g3d+2RJPROwfopq4KE7X7hCoZhhirX9MzhGmsBktddBO5v4VzcenNHDBnCiHVd0w==; 24:dzfyzvQAIDerHt7voZKoFDhL0sCo8eKSNyx0WAhTuvIbkzndm89YK58tMNgvawq21lnDCLvsns3h0dlfRwDnrBG0liN/9SWMl0m3tT+Gqrw=; 20:+R4MPAB1lBgIJRWPPDEB00W/vZp+aOuppJc7KjXYhVJjx4AosL+42dy64BQ/DqlBnVoBebKB8cpEz7OZbDIn8Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0356;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN3PR09MB0356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0356;
x-forefront-prvs: 06818431B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(76104003)(377454003)(189002)(199003)(479174004)(101416001)(50986999)(122556002)(76176999)(2351001)(36756003)(2501003)(97736004)(106116001)(230783001)(66066001)(83506001)(64706001)(5001830100001)(99286002)(4001350100001)(189998001)(110136002)(5001860100001)(107886002)(4001540100001)(105586002)(40100003)(54356999)(5007970100001)(5004730100002)(81156007)(2656002)(86362001)(5001960100002)(450100001)(15975445007)(2900100001)(77096005)(5002640100001)(92566002)(87936001)(68736005)(102836002)(77156002)(62966003)(19580395003)(106356001)(10400500002)(19580405001)(2950100001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0356;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 19:15:52.7722 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR09MB0356
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: Thu, 27 Aug 2015 19:15:58 -0000

If I understand David¹s attack vector correct than the attack would look
as follows:

For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C
only signing but not validating:

A signs the path to D and not to B but sends it to B. Because B and C
don¹t validate, just sign they forward the path to D.
D removed B and C from the path and forwards the path as ‹> A ‹> D  to E.
Now E verifies the path as valid and moves on.

If this is what David had in mind then I agree that the security guarantee
in 7.1 does not hold up.


On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein"
< on behalf of> wrote:

>At Thu, 27 Aug 2015 15:45:49 +0000, Sriram, Kotikalapudi wrote:
>> What do you think of the following two-update collusion scenario?
>> -- > A --> B --> C --> D --> E
>> A and D are colluding. B and C are signing without verifying.
>> First update at time= t0:
>> A signs and forwards an update normally (without any corruption).
>> The update propagates via B and C to D.
>> D receives it and stores it, but does not forward to E (or anyone).
>> Second update at time= t1 (= t0 + delta):
>> A sends an intentionally corrupted version of the update (signed),
>> while keeping the same NLRI as before.
>> B and C are still signing but not verifying.
>> The update propagates via B and C to D. Now D replaces
>> this corrupted update with the earlier clean one (received at t0),
>> and propagates to E. The resulting update from D to E is valid.
>> One can argue that there is violation of the guarantee (in Section 7.1)
>> at time t1. The valid route propagated from D to E does not
>> agree with the route that B or C forwarded (at time t1)
>> for the NLRI in consideration.
>If I understand your scenario correctly, as far as folks further along
>the path are concerned, this is a replay attack by D.  That D is doing
>this to cover up something bad that A is doing to B and C is almost
>irrelevant, as is the specific nature of whatever bad thing A is doing
>to B and C.
>So, yeah, OK, it's a form of collusion, but it's not one that relies
>on a weakness in the signature semantics, it's one that relies on lack
>of protection against replay attacks, something the WG discussed and
>rejected.  Can't speak for anybody else, but I'm not particularly
>interested in exhuming the replay horse at this late date.
>sidr mailing list