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

Christopher Morrow <> Tue, 10 April 2012 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9119D21F860D; Tue, 10 Apr 2012 10:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.299
X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P2n-IBLSlahd; Tue, 10 Apr 2012 10:47:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E510E21F85D4; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so42186yhk.31 for <multiple recipients>; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cBnrA/Wo6JIm9UjLbxhntEM57Seu6uN3YCHKKGUGkp8=; b=Ry+2fyXX3i3NghZTpncbbFLRHWHV/6nggINkRezL/EKShs7Fhkxx1cm8Ng+U3w8kGm V5oa6o4lwckyV3/HLRwGQ/nG3cMnnUuAQWLHdKG47Wr3bxc3V0j+220FOEjY3NNXemoE ZjXsqdZ/14WQZNZdwTtuCcSr6Ol3vVELYSgt7rwablWyQRUsB6YwLe1dfL5r5peDtleC Y8rM2lI0UzpPTPPAKgFRVLoRipaumgzsrFs+2pmOkwHKOVJqKWm2dcP7C6boVGXeHQix EoTiiG9C5a9wupfxsqqqChPT3zsAUFN4TKqLlFvVDZBuTmAxXzvUaIWKGvPnSyV1pSrL Bplw==
MIME-Version: 1.0
Received: by with SMTP id w9mr17022206oef.49.1334080061340; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
Received: by with HTTP; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Tue, 10 Apr 2012 13:47:41 -0400
X-Google-Sender-Auth: 07VGFi-0uDlgB4aozWUDOSBeoh8
Message-ID: <>
From: Christopher Morrow <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: " List" <>,
Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
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: Tue, 10 Apr 2012 17:47:42 -0000

On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <> wrote:
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> So far I have always heard that BGPSEC is just providing the hint to the
> operator and does not change how BGP works.


> Here you are saying that now AS_PATH length should be calculated from
> completely different (and optional) attribute.

to the operator (and the implementation) there's not a difference....

> You are also saying that now multipath code which computes which path are
> eligible to be multipath needs to look/parse/decrypt totally different
> attribute.

I didn't say anything about multipath. I presume it'd do the right
thing with the meta-attribute it knows about way deep inside bgp
processing on platforms that do bgp processing.

> 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.

> Regards,
> R.
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<>  wrote:
>>> Anyhow my doubt has been answered and I stay by my opinion that not
>>> sending
>>> AS_PATH and AS4_PATH is a terrible idea.
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>>> Perhaps one could depreciate it in 20 years when world is upgraded to
>>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
>>> helpful for any even potential BGPSEC deployment model.
>> is it helpful for the folks that write bgp code though? "Hey, you will
>> need to re-synthesize the as-path at sec->non-sec boundaries. you need
>> to also create sec-path at none->sec boundaries."
>> -chris