Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

Stephen Kent <> Tue, 10 April 2012 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A562021F8681 for <>; Mon, 9 Apr 2012 19:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.534
X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fC19mvp1-uPQ for <>; Mon, 9 Apr 2012 19:23:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F82221F8671 for <>; Mon, 9 Apr 2012 19:23:05 -0700 (PDT)
Received: from ([]:46358 helo=[]) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1SHQjH-0009cX-3t; Mon, 09 Apr 2012 22:22:47 -0400
Mime-Version: 1.0
Message-Id: <p06240809cba947b7d040@[]>
In-Reply-To: <>
References: <> <p06240803cb99d283e548@[]> <>
Date: Mon, 9 Apr 2012 22:20:37 -0400
To: Shane Amante <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: sidr wg list <>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 02:23:05 -0000

At 3:04 PM +0200 3/29/12, Shane Amante wrote:
>Thanks for the response.  First, a high-level comment before more 
>specific responses below.

Shane,  sorry to be so late in replying.  I think you and Andrew have 
already discussed a number of the issues you raised below, so I'll 
just make a few, brief comments.

First, as Sriram noted, BGPSEC carries only the secure AS path info, 
not the old
As path attribute. So there cannot be a mismatch between the two, and 
loop detection should work. Because of the signature requirements, no 
bogus ASN's can appear in the secured path, no hops can be stripped, 
etc. It's an implementation decision as to whether a router checks 
the secured path data before validating the sigs to detect a loop. 
One might do this to avoid wasting cycles on crypto.

>There is text about MITM threat in Section 4.2; however, that seems 
>to relate to crypto security between two adjacent routers over, say, 
>a directly connected link.  However, what about MITM attacks that 
>create what appear to be valid BGPSEC_Path_Signature attribute that 
>would pass verification by downstream parties?

I still do not understand. Unless a MITM has access to the private 
keys for the BGP routers in question, it cannot generate sigs that 
will validate when checked by downstream parties.'