Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

Randy Bush <randy@psg.com> Wed, 30 May 2012 00:52 UTC

Return-Path: <randy@psg.com>
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 480B721F86B7; Tue, 29 May 2012 17:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level:
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599]
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 94F1mtelqgFE; Tue, 29 May 2012 17:52:06 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BA17F21F86B6; Tue, 29 May 2012 17:52:06 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SZX8w-000D4r-Fj; Wed, 30 May 2012 00:52:06 +0000
Date: Wed, 30 May 2012 09:52:05 +0900
Message-ID: <m2likasd6y.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se>
References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <CE876529-6CDB-44ED-9184-CA73DFD2D048@juniper.net> <C37AE148-0873-4D9A-B1B2-1959A427435D@bgp.nu> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> <m2sjeise8s.wl%randy@psg.com> <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Wanderlust/2.15.9 (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"
Cc: idr wg <idr@ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]
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: Wed, 30 May 2012 00:52:07 -0000

>> and here i thought that detecting that they differ, as an attack, is
>> the core goal of as-path validation.
> I thought it was to prevent an AS from announcing an update that it
> was not authorised to.

nope.  that is rpki-based origin validation.  we are now talking about
as-path validation.

from a note to some gov folk:

To be clear, as people keep calling BGP security 'RPKI'

In the current taxonomy, there are three pieces, the RPKI, RPKI-based
origin validation, and then path validation.

RPKI is the X.509 based hierarchy with is congruent with the internet IP
address allocation administration, the IANA, RIRS, ISPs, ...  It is the
substrate on which the next two are based.  It is currently deployed in
four of the five administrative regions, ARIN in North America being the
sad and embarrassing exception.

RPKI-based origin validation uses some of the RPKI data to allow a
router to verify that the autonomous system announcing an IP address
prefix is in fact authorized to do so.  This is not crypto checked so
can be violated.  But it prevents the vast majority of accidental
'hijackings' on the internet today, e.g. the famous Pakastani accidental
announcement of YouTube's address space.  RPKI-based origin validation
is in shipping code from Cisco, and will be shipping by Juniper soon.

Path validation uses the full crypto information of the RPKI to make up
for the embarrassing mistake that, like much of the internet BGP was
designed with no thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to formally
cryptographically validate that the originating autonomous system was
truely authorized to announce the IP address prefix, and that the
systems through which the announcement passed were indeed those which
the sender/forwarder at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

randy