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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 10 April 2012 21:04 UTC

Return-Path: <christopher.morrow@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 485A311E8154; Tue, 10 Apr 2012 14:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.239
X-Spam-Level:
X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 6b1EXNzWDUZd; Tue, 10 Apr 2012 14:04:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D606C11E8149; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so299308obb.31 for <multiple recipients>; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XyCcvNNjWVn0i12Aadq51jNhmVDwqGmlC960LF2KPMo=; b=HAPzioIanN0ippIjbqRpAlYnOuVWVK8XMdjd8mvLHVgtU/J/Rq1i6sH0nHmGX8nMYg x564Ssx67swdiFcFKTUu+BBhVpXaPNazVaBOhzL+iqEEmEzGypt1Lg/qPVQTZYGLnPL2 NRJ07oK4SyirQXzZQRXQxjDlf7le/7iDH65ROZ2pRUjTKzhmMvokOfB8xqBiSAKGwlEJ X7UxZLSjOau7SIg3e8d9iQjX8xQdO4pVDOECmf/cOhCCERgtoBObkCVwkR/kVk3uhmnO 9jQ7zMF3EvfZv8LGOghOF/C4xupV+Kjzz40GqdFw4fFAZn7/WeV7ZZ22gCpIKs5BOZBd K3Lg==
MIME-Version: 1.0
Received: by 10.182.74.4 with SMTP id p4mr11080644obv.79.1334091829513; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
In-Reply-To: <4F847499.9040105@raszuk.net>
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> <4F847499.9040105@raszuk.net>
Date: Tue, 10 Apr 2012 17:03:49 -0400
X-Google-Sender-Auth: FqFpbysZ4c5069eYSxJ9q-eg_SU
Message-ID: <CAL9jLabH9OZEfFoitONOZ36wDW6V3_Vd8ubKQzt3KiDLG3eAew@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 10 Apr 2012 21:04:36 -0000

On Tue, Apr 10, 2012 at 1:57 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.
>
>
> No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station
> which works today and get's BGP sessions over BMP will now be useless as
> AS_PATH will not be there.

great, so ... bmp can either:
  1) be treated as a non-BGPSEC speaker (synthesize on the output to
bmp listener)
  2) be updated to include the BGPSEC relevant data in payload

downstream tools using the BMP stream(s) of course would have to be
updated. This doesn't seem like a huge deal though, and certainly is
expected.

> I assumed you know, but BMP idea is to replay what you are receiving (as
> verbatim as implementation allows).

sure, so it has to know about new bits/pieces, nothing new here. If
you catch larry you might get this change/addition into his
final/final version before rfc-editor cuts the rfc.

>
>> maybe? so far you've not convinced me... you can feel free to keep
>> trying though? email is cheap.
>
>
> I am not sure there is point in "convincing". Removing mandatory path
> attribute from BGP would be something IDR WG has to formally approve. And it
> will be an interesting precedence in any case ;)

sure... once things settle out on the SIDR side, I'm positive we'll
have this discussion in IDR. You seem to be working through the
machinations of 'how do I deploy bgpsec in a network', is that the
case? would you be willing to document/presentation-style (or wiki or
...) the process for this? It seems like something other folks are
going to want to reference/use/discuss as well, so having a few worked
examples would be nice.

-chris