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

"Sriram, Kotikalapudi" <> Thu, 27 August 2015 15:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 469C71B2E01 for <>; Thu, 27 Aug 2015 08:45:53 -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 llT6nkjiAQ8q for <>; Thu, 27 Aug 2015 08:45:51 -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 CB5E21B2DFC for <>; Thu, 27 Aug 2015 08:45:50 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 27 Aug 2015 15:45:49 +0000
Received: from ([]) by ([]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 15:45:49 +0000
From: "Sriram, Kotikalapudi" <>
To: David Mandelberg <>, "" <>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ4EXjUWOu4xHMLkqEedR7+Q4tdZ4f9sSQ
Date: Thu, 27 Aug 2015 15:45:49 +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; CY1PR09MB0794; 5:6hvZN4410RsBDjRR8ZfJcz+JQ5D0kNo1rpsS5/h/+c0RT/Sl2kaGTWlT3nO2MyLmk6O4E/DoWRv3uo3+UNibs6Hh3RJdlWYWr+NLWFp/pkU8zJgUEo6B/f07oz8jfDE+OfYUvYOBV69//Aw96F6dMA==; 24:2x9y/teem3GtT0RDvogwQ9vo3pUaMdOPG1oSoY42cve9UZnxY3q4ucTUqS7nlcuz5jSLLahRIWWTGDU/Eu1rhNWjWZDd2Jx+6yP+S6MN0pE=; 20:zdEcYMpTiJ0Wwm81D9E+cbzHu+K0ZWxsl/HRBubz2L5HcG55YLJIaP58jDSe+0ZJkdAv1artkQ/Mn0iIEdqzWg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0794;
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:CY1PR09MB0794; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0794;
x-forefront-prvs: 06818431B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(76104003)(46102003)(54356999)(99286002)(77156002)(62966003)(2900100001)(2950100001)(68736005)(101416001)(50986999)(5007970100001)(5004730100002)(122556002)(106356001)(76176999)(64706001)(66066001)(5003600100002)(40100003)(76576001)(5001920100001)(5002640100001)(5001770100001)(77096005)(10400500002)(5001830100001)(189998001)(2656002)(230783001)(97736004)(5001860100001)(4001540100001)(105586002)(86362001)(2501003)(87936001)(107886002)(102836002)(106116001)(92566002)(33656002)(74316001)(5001960100002)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0794;; 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 15:45:49.2680 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0794
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 15:45:53 -0000

>It appears that this guarantee will not always hold. Specifically, if
>two non-adjacent ASes conspire, and they are separated by a sequence of
>ASes that sign path data that they have not verified, then the
>conspiring ASes can violate the guarantee. 

Agree with that. 
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.

>I think this problem might be fixed if we modify the protocol to sign
>all of the preceding signed data (rather than just the immediate,
>previous signature).

If we agree that the above two-update collusion scenario 
is something we care about, then it should be noted that
this fix does not prevent it.