Re: [sidr] [Idr] No BGPSEC intradomain ?

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 11 April 2012 16:41 UTC

Return-Path: <brian.peter.dickson@gmail.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 7C47D11E809A; Wed, 11 Apr 2012 09:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
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 ZvweNEz+lYTy; Wed, 11 Apr 2012 09:41:00 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42911E8089; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so727435wgb.13 for <multiple recipients>; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ic4sarfmTwxzIqasiM4WyQ3ROK/JqUSaHXk1gq1/I2g=; b=YT+cMSaCx/7E7YKalpUIAOdJ5pirfaTQ9tVcfLS7WjQ2GFmYAHlXEapK27hQD/FxEW 1YjPYRg2kfCCGrZEpMapIT85+6fFL4vSLmvyLFKDIjmcuczFUwKam+ZO0/pSQbdWBHe8 mc5hGcu0tigs4zMVpWuE3Sq2BJlTbz7tZPAdNeGFkyxmiepaO5vyW8VXr1zcRvNuDAYN LLU+5FOfYxQpMq34lXeJtXgmKZoBv+mUHuz0g4lZBPLt6dsDisBbjzP9WcjPocH9pwwc XAjgWVmrtYKwckNqRMrtTAumS2gZkeJRANKCQMIgRO432bOGpUz0x1ZnDBkhDgWHHdle yXsw==
MIME-Version: 1.0
Received: by 10.216.132.6 with SMTP id n6mr9578669wei.26.1334162459060; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Wed, 11 Apr 2012 09:40:58 -0700 (PDT)
In-Reply-To: <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <4F846736.2060604@raszuk.net> <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
Date: Wed, 11 Apr 2012 12:40:58 -0400
Message-ID: <CAH1iCirzcsbaLihcogSNJJHLi-1fsx3PX9-gp=O94=U6w9z5Vw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6d784fd71e86704bd69e7f5"
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
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, 11 Apr 2012 16:41:01 -0000

On Tue, Apr 10, 2012 at 1:47 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <robert@raszuk.net> wrote:
>


> > All BGP monitoring tools need to be upgraded to now understand BGPSEC
> > attribute too. And surprise .. here BMP will not convert it like it will
> to
> > "legacy" speakers.
>
> sure, they'd have to do that anyway, or they just are
> 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
> other words, tomorrow for them is the same as today, the world keeps
> on going round.
>
> > You may think that if we stuff all "data" in the new attribute and drop
> the
> > other one everything else will work. This may be so in theory, but it is
> > clearly not a case in practice.
>
> maybe? so far you've not convinced me... you can feel free to keep
> trying though? email is cheap.
>
>
Okay, I'll bite...

Suppose someone wants to take an existing tool which speaks BGP, and writes
out full tables and updates to files. Call it "bgpmon". :-)

The obvious thing to do for that tool, would be for it to advertise that it
speaks BGPSEC, and record the updates that come from BGPSEC speakers.

Clearly, this tool is not a router, nor does it need to do validation. In
fact, you *don't* want to validate, since you want to record all updates,
*including* invalid updates.

The ability to do quick-and-dirty comparisons between BGP-vanilla and
BGPSEC data, from archived data, would be significantly hampered if the
AS_PATH had to be reconstructed from this data.

Duplicate bits should really not be a huge deal.

Perhaps, at minimum, there should be a negotiated option on whether or not
the AS_PATH is included in updates, on a per-neighbor basis?

That would allow both sides to win, and even better, provide some measure
of interoperability testing, including possibly passing the opaque
attribute through non-believers to far-end systems that want to see *all*
the BGPSEC data, even when it has crossed outside of the BGPSEC bubble.

In particular, this would be very helpful during the incremental deployment
phases, where there are *multiple* islands of BGPSEC.

Brian