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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Sun, 08 April 2012 16:07 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0963E21F851D for <sidr@ietfa.amsl.com>; Sun, 8 Apr 2012 09:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsu-dpLL0y-j for <sidr@ietfa.amsl.com>; Sun, 8 Apr 2012 09:07:09 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCB21F8518 for <sidr@ietf.org>; Sun, 8 Apr 2012 09:07:08 -0700 (PDT)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 8 Apr 2012 12:07:07 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 8 Apr 2012 12:06:18 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Andrew Chi <achi@bbn.com>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, Shane Amante <shane@castlepoint.net>, Matt Lepinski <mlepinski@bbn.com>
Date: Sun, 8 Apr 2012 12:06:16 -0400
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: AQHNFaDEHY+BQd3OrEu3OCHpXNmb0Q==
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 08 Apr 2012 16:07:10 -0000

Andrew,

There isn't a reason for the problem as you point out to arise.
Your analysis assumes that there a conventional BGP-4 AS_PATH field and then there is
is BGPSEC_Path_Signatures from which AS path info can be inferred separately.
This is not true in the latest BGPSEC update format as Matt presented it in Paris.
Please see slide 8 of the BGPSEC Protocol presentation:
https://datatracker.ietf.org/meeting/83/materials.html 
Matt stated in his presentation that there will soon be an -03 version of the draft
which will include this update format.

What the latest BGPSEC update format has is a field upfront (outside of the BGPSEC_Path_Signatures) 
that provides the sequence of ASNs and their respective pCounts.
Matt has called it the Secure Path (see Slide 8).
Corresponding to each AS in the Secure Path there must be one signature present (in the Sig Block)
in order for the BGPSEC update to be considered well-formed (otherwise it is malformed).
Referring to your example, B is simply not in a position to do what you say he does, namely,
"ignores AS_PATH and just uses BGPSEC_Path_Signatures."
B is required to look at the Secure Path (i.e., ASNs and pCounts) first;
then B expects to see one signature for each AS in the Secure Path;
B finds that this is violated because he sees C's ASN in the Secure Path 
but no signature for it (per your description); 
now B declares that the BGPSEC update from A is malformed.
B would neither verify nor propagate the update any further.
So C does not even get the update.

The good thing about the update format (slide 8) is that
if some AS inserted an AS in the "Secure Path" (without a signature for it),
then the next hop AS knows (even before any signature verification)
that the update is malformed.

I hope this clarification helps.

Sriram
 
> ________________________________________
> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Andrew Chi [achi@bbn.com]
> Sent: Friday, April 06, 2012 3:21 PM
> To: Murphy, Sandra
> Cc: sidr wg list
> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &        lengthening
>
> 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.
>
> -Andrew
>