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

Rob Austein <> Thu, 27 August 2015 17:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80E951B301B for <>; Thu, 27 Aug 2015 10:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g3OHtQ6jix9Z for <>; Thu, 27 Aug 2015 10:58:28 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A0CB1A89C5 for <>; Thu, 27 Aug 2015 10:58:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (verified OK)) by (Postfix) with ESMTPS id 241AB39848 for <>; Thu, 27 Aug 2015 17:58:28 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id A35401AC51E2 for <>; Thu, 27 Aug 2015 13:58:26 -0400 (EDT)
Date: Thu, 27 Aug 2015 13:58:26 -0400
From: Rob Austein <>
In-Reply-To: <>
References: <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
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 17:58:29 -0000

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.