Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
"Borchert, Oliver" <oliver.borchert@nist.gov> Thu, 27 August 2015 19:23 UTC
Return-Path: <oliver.borchert@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652411ACEBE for <sidr@ietfa.amsl.com>; Thu, 27 Aug 2015 12:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nssBzApgCkZF for <sidr@ietfa.amsl.com>; Thu, 27 Aug 2015 12:23:47 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324371AD0C0 for <sidr@ietf.org>; Thu, 27 Aug 2015 12:23:47 -0700 (PDT)
Received: from BN3PR09MB0355.namprd09.prod.outlook.com (10.160.115.152) by BN3PR09MB0356.namprd09.prod.outlook.com (10.160.115.153) with Microsoft SMTP Server (TLS) id 15.1.243.23; Thu, 27 Aug 2015 19:23:45 +0000
Received: from BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) by BN3PR09MB0355.namprd09.prod.outlook.com ([10.160.115.152]) with mapi id 15.01.0243.020; Thu, 27 Aug 2015 19:23:45 +0000
From: "Borchert, Oliver" <oliver.borchert@nist.gov>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ4EXk8vgV73xBckONsKYcP4tTrp4f/liAgAAlDQD//9KSAIAAAjMA
Date: Thu, 27 Aug 2015 19:23:45 +0000
Message-ID: <D204DB7C.387BC%oliver.borchert@nist.gov>
References: <f12cf36b3ee80798852c3fa13485b50d@mail.mandelberg.org> <CY1PR09MB0793AAC5E6D10477A6351A96846F0@CY1PR09MB0793.namprd09.prod.outlook.com> <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> <D204D873.387AB%oliver.borchert@nist.gov>
In-Reply-To: <D204D873.387AB%oliver.borchert@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.4.150722
authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.140.59]
x-microsoft-exchange-diagnostics: 1; BN3PR09MB0356; 5:P8cu+5npLS9VouDzyftofC14XrP22kepPOozqJu/efIhIcostidrMtK3VxL516aqOrjhrsabMXKgrrtZUr77Xqu4aHxEzUL669OrBsOuxi9JmHzNtgidkxIAqFbA1vpUvBuExtFvUjiHvH5PSY/CEw==; 24:joU9bUXrQ5RViXR83Gv8nYBYDlmPoTlosqHmsAXAvBNQTkaHrZkObPH8h3i6uLoXRE/ljFWJuHwu+sSyP1l7vVLBZ8HygNdoy3mEBxaFs2M=; 20:wLNFAnErBdDhFFg3KZOtqPt4dHmwBPrz4wv8whO1b/VBPOHPu5gh6JtQwlkFCfMPZtJKR1cCVdxXoMSCEuZ7kg==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR09MB0356;
x-microsoft-antispam-prvs: <BN3PR09MB0356CBA9A48913D712E42030986F0@BN3PR09MB0356.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN3PR09MB0356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR09MB0356;
x-forefront-prvs: 06818431B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(199003)(377454003)(76104003)(24454002)(2900100001)(77096005)(5001960100002)(86362001)(2656002)(15975445007)(450100001)(19580395003)(62966003)(106356001)(2950100001)(46102003)(10400500002)(19580405001)(68736005)(87936001)(102836002)(92566002)(5002640100001)(77156002)(230783001)(66066001)(83506001)(2501003)(106116001)(97736004)(64706001)(122556002)(76176999)(2351001)(50986999)(101416001)(36756003)(105586002)(40100003)(54356999)(4001540100001)(5001920100001)(5004730100002)(81156007)(5007970100001)(93886004)(4001350100001)(99286002)(5001830100001)(107886002)(189998001)(110136002)(5001860100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR09MB0356; H:BN3PR09MB0355.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CAAD194F1A92A04C8176FE8B56F287C4@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 19:23:45.4761 (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: <http://mailarchive.ietf.org/arch/msg/sidr/Ne9aGIKfImlOe8HOsZmYo7V8TuY>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 27 Aug 2015 19:23:49 -0000
I noticed Outlook changed some characters so here again: If I understand Davids 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 do not 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. Oliver On 8/27/15, 3:15 PM, "sidr on behalf of Borchert, Oliver" <sidr-bounces@ietf.org on behalf of oliver.borchert@nist.gov> wrote: >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. > > >Oliver > > > >On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein" ><sidr-bounces@ietf.org on behalf of sra@hactrn.net> 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 >>sidr@ietf.org >>https://www.ietf.org/mailman/listinfo/sidr > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr
- [sidr] draft-ietf-sidr-bgpsec-protocol-13's secur… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Randy Bush
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Rob Austein
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sriram, Kotikalapudi
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Rob Austein
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Borchert, Oliver
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Borchert, Oliver
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sandra Murphy
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Randy Bush
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sriram, Kotikalapudi
- [sidr] replay threats (was: draft-ietf-sidr-bgpse… Randy Bush
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sandra Murphy
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sriram, Kotikalapudi
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Rob Austein
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Rob Austein
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Stephen Kent
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… David Mandelberg
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sriram, Kotikalapudi
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Randy Bush
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Sandra Murphy
- Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's s… Matthew Lepinski
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Sriram, Kotikalapudi
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Sandra Murphy
- Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pro… Sriram, Kotikalapudi