Re: [sidr] BGPsec draft and extended messages

"Sriram, Kotikalapudi (Fed)" <> Tue, 21 March 2017 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 816F6129ADF; Tue, 21 Mar 2017 08:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hUmon1nqgoed; Tue, 21 Mar 2017 08:41:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63CA5129B37; Tue, 21 Mar 2017 08:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AiUJHsScDjub6YXUXAEyIF7d21E3WJKoldp7+8LxWD8=; b=mIn9pk2JhUCem4ZAuncr3Z64Hcs4XtisVduMrTzBpLQLU7v2lQE7AQSMKus5ynymjjvHXTxoKmEsvMvmXxAnl2TeaX7q2vXIUK0yGjoec7e8yNnAuUJU0daV4350JXpiU2XD//AU9SW1Evi4ZY7ynLVb3huQk41cg6i6LESLWBo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Tue, 21 Mar 2017 15:39:06 +0000
Received: from ([]) by ([]) with mapi id 15.01.0977.019; Tue, 21 Mar 2017 15:39:06 +0000
From: "Sriram, Kotikalapudi (Fed)" <>
To: Wes George <>
CC: "Alvaro Retana (aretana)" <>, Randy Bush <>, Steve KENT <>, sidr wg list <>, "Matthias Waehlisch" <>, "" <>, Sean Turner <>, "" <>
Thread-Topic: [sidr] BGPsec draft and extended messages
Date: Tue, 21 Mar 2017 15:39:06 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 7:PjMlIdMJ0MoEi+vgGeLWUpbRtlLvXoZVQwVe7JGoxArDTGC6hnLYaGAf274ATBABkXrgJwqpW7739fYSh3+o4jOTFVGc5ZPTVvpj6UFaLrOXOlz/vBk7Jwj1LgWqI18LZau2Z0EtnSANSMRTzx/qU4AJs00AgQj4hjGJRrH04LaNgbmOv+4BPC5qur7Gjs9c1800m/Hyhel0KX0db0JBoDGqieZ5SF49Mk80YtEzylSMx4jW8Zy9yeIqDJLUe4EMtyn563go5PyLrEt9dARPuTenhh6Ug4LIHExi6JXJXv48tn8XaiSWNPG9XuyCJrW2RkxzVq1DmKDy4bngC1Yf2Q==
x-ms-office365-filtering-correlation-id: a7139243-deae-48ef-e84b-08d470706929
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DM2PR09MB0446;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446;
x-forefront-prvs: 02530BD3AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(50986999)(76176999)(7736002)(54356999)(110136004)(2900100001)(2420400007)(93886004)(7520500002)(38730400002)(229853002)(3846002)(122556002)(102836003)(6116002)(4326008)(6246003)(19609705001)(790700001)(7110500001)(77096006)(6506006)(3280700002)(53936002)(3660700001)(86362001)(25786008)(189998001)(8676002)(10710500007)(6436002)(54896002)(6306002)(54906002)(2906002)(15650500001)(9686003)(6916009)(2950100002)(99286003)(7696004)(66066001)(33656002)(55016002)(81166006)(8936002)(74316002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446455BBBCC27D9B3A82E11843D0DM2PR09MB0446namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 15:39:06.7443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446
Archived-At: <>
Subject: Re: [sidr] BGPsec draft and extended messages
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Mar 2017 15:41:50 -0000


Thanks for the clarification. My comments below.

….. snip ….
>WG] My original email was insufficiently precise when expressing my concern on this, as it was written in relative haste. I’ll try again. I always interpreted this as allowing for updates that were never secured (because the downstream neighbor doesn’t support it) to be sent between BGPSec capable neighbors, as you explain above. This makes perfect sense given BGPSec’s decision to not allow partially-signed updates.

>WG] My concern is that using this text as justification for updates that otherwise would be secured (because they came through a path of neighbors that all support BGPSec end to end) dropping back to insecure on account of the size of the update violates the principle of least astonishment and again allows for degraded security by failing open.

BGPsec_Path attribute size does not exceed 4K.
ECDSA P-256 signature size is 64 bytes.
So, #bytes added to BGPsec_Path are about 100 bytes per AS.
Extended message was thought to be needed when RSA-2048 (256 bytes sig) was initially proposed.
With P-256, BGPsec_Path attribute does not exceed 4K up to 40 ASes in the path.
(Note: AS prepends are compressed out due to use of pCount.)
In the Internet, the observed maximum AS path length is 14 [Huston].
The maximum AS path length has remained in this ball park for many years now.
Therefore, it doesn’t appear that “dropping back to “insecure on account of
the size of the update”  would happen in practice.

So, the question is: Does the WG agree that the extended messages draft
can be an Informative rather than a Normative reference?

Alvaro (speaking as WG Participant) suggested:

“I would even just mention the “maximum message size” (with no specific numbers) and leave out mention of any future changes.  This way the BGPSec documents (1) don’t depend on the Extended Messages document, and (2) they depend on whatever BGP can do.  If/when Extended Messages are settled and implemented then BGPSec can make use of them (as can any other application using BGP).”

Steve Kent said earlier in the thread:

“I think it makes sense to omit the extended message feature, given the use of ECDSA P-256.”