Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)

"George, Wes" <> Thu, 12 April 2012 12:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22A8521F865A; Thu, 12 Apr 2012 05:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.464
X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSjGIvM2gCam; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D74521F85C2; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="366668114"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:07:10 -0400
Received: from ([]) by ([]) with mapi; Thu, 12 Apr 2012 08:07:44 -0400
From: "George, Wes" <>
To: Christopher Morrow <>, Jakob Heitz <>
Date: Thu, 12 Apr 2012 08:07:43 -0400
Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
Thread-Index: Ac0YADE6kaxr3F1XQ5+wa5TqtHNd3QAOgBhg
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <20120411142053.GA1283@slice> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " List" <>, "" <>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was 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: Thu, 12 Apr 2012 12:08:36 -0000

> From: [] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 12:29 PM
> To: Jakob Heitz
> Cc: List;
> Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC
> intradomain ?)
> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <>
> wrote:
> > Confeds are out of scope.
> how are confeds out of scope?
> if you want path validation for ibgp/originated-by-you routes and the
> originating router is in one of the confed sub-ases you have that
> router sign with the confed-external/public asn, no? I'm fairly
> certain we planned to support this sort of activity... though I could
> be missing the part which is out-of-scope?

[WEG] There was discussion on the SIDR list on November 12 (subject line "various") specifically regarding private ASNs and confeds and their discussion in the bgpsec-ops draft. I am writing offline and therefore can't provide a more specific pointer to the message itself nor confirm (as memory of the more previous versions that I've reviewed fails) that the product of that discussion has made it to an updated version, but I'm pretty sure that it has. I'd encourage you to look back at this and see if you have additional feedback regarding in/out of scope and implementation.

FWIW, confeds being truly out of scope may make BGPSec a no-op in my network, as I can't guarantee that confeds will be gone (unless you are suggesting that they should be deprecated a la AS_SETs). My earlier recommendation is that we have to be specific about how BGPSec handles signing and stripping to manage an ASPath including confeds, whether it only signs at the external side and previous signatures (if exist) are dropped, or if it is capable of handling something like this:

Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -> confed ASN42 (public) -> confed ASN55 -- in that example, if the entire path is BGPSec capable, what does ASN42 send as the signed path? You have several ASNs that maybe need path count 0 in their signature so that they are signed but don't interfere with the externally-visible path, or the Transit ASN1 has to forward sign its updates as if they are directly connected to confed ASN42 (public), meaning that we are potentially allowing it to transit multiple ASNs within the confed unsigned. Randy had said previously that confed ASNs shouldn't sign towards each other, so maybe that answers that question, but since it has come back up, please give it some thought.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.