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

Andrew Chi <> Fri, 06 April 2012 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AC7D21F8422 for <>; Fri, 6 Apr 2012 12:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jevcDwxVTHpq for <>; Fri, 6 Apr 2012 12:21:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E684C21F8418 for <>; Fri, 6 Apr 2012 12:21:41 -0700 (PDT)
Received: from ([]:65188 helo=[]) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1SGEik-000ERl-Jw; Fri, 06 Apr 2012 15:21:18 -0400
Message-ID: <>
Date: Fri, 06 Apr 2012 15:21:31 -0400
From: Andrew Chi <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Murphy, Sandra" <>
References: <> <p06240803cb99d283e548@[]> <> <> <> <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 06 Apr 2012 19:21:43 -0000

On 4/6/2012 2:10 PM, Murphy, Sandra wrote:
> So where's the dos attack?
> (Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

So I think I finally see what Shane's getting at.  Let's say:

- I'm a bad actor (A)
- Bob is my neighbor (B)
- Charlie is Bob's neighbor (C)

A is trying to cause B and C to have different views of the world.  In 
addition, we must assume:

- B's router ignores AS_PATH and just uses BGPSEC_Path_Signature
- C's router checks both AS_PATH and BGPSEC_Path_Signature

As the bad actor, A injects C into the AS_PATH (malicious), but 
processes BGPSEC_Path_Signature normally, and sends the update to B.

- B verifies BGPSEC_Path_Signature only, passes it to C
- C detects a loop in AS_PATH and drops the update

A has just caused B to accept an update while simultaneously causing C 
to drop it silently.  While not a very strong attack (B could always 
filter the route anyway), I could imagine it being a starting point for 
causing confusion.

This is solved by prescribing that AS_PATH/AS4_PATH is ignored when 
BGPSEC is enabled, but Shane has a good point that we might need to 
coordinate with IDR on this.  I defer to the WG chairs on that coordination.