Re: [sidr] BGPsec draft and extended messages

"Sriram, Kotikalapudi (Fed)" <> Tue, 14 March 2017 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 730E6129496; Tue, 14 Mar 2017 15:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 ezoEbERQjQvO; Tue, 14 Mar 2017 15:26:50 -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 3D1A9129BB3; Tue, 14 Mar 2017 15:26:50 -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=DZs2Yh0mnvwhNvj0Q1EXuJIp6dWJM/DhUnrlLydUyyc=; b=R7xwG9YGqnzbSZF7I74Jea6XNYbl7IGhBLHU3EEaRb+cJudgZJU+Ty4EUpZqSQ/BpGTrxHPpgUsBVHIq48zcChdLh0NPWwjLcNbvkxQW0g6MvWeKXUloUD08QeHU40Koof0Vq3DwzIeL/hImoTvTJ4HND0pLxAVDBOmWntlYD4w=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Tue, 14 Mar 2017 22:26:46 +0000
Received: from ([]) by ([]) with mapi id 15.01.0961.021; Tue, 14 Mar 2017 22:26:46 +0000
From: "Sriram, Kotikalapudi (Fed)" <>
To: Randy Bush <>, Steve KENT <>
CC: sidr wg list <>, Alvaro Retana <>, "Matthias Waehlisch" <>, "" <>, Sean Turner <>, "" <>
Thread-Topic: [sidr] BGPsec draft and extended messages
Date: Tue, 14 Mar 2017 22:26:46 +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; DM2PR09MB0448; 7:zovzPaFbPwAdivYBUBWnTywijaqAHJ7S91UwAzduKhEM3pOxFnjQz+nRg8+VJVLSOhOFsu/DmXwcvzm/Q48nBhQM5nAZDYzG46C37rUG5hVO2xoYYnVB4V6sq54CkSndgU4PVS12h5cXxsOqvF8Ai4HtSCNo7CtNL6NahT2IxZmLcXB+7aIA9SeekJlj1zmGpME2Ntw8MF7sS7EZoPcrjReDmTDkYljHQ+Tk9k/btVLoObhiU0lpO0zFCUDstk0MIYBVbsZ1Nj7JK/A4D/rpzO8q1xVx6EZh6vhwjI3DCnoGqzm65TpPF6hpjipqhTAh0m91Wm1UE+VNiDsvGGdXAw==
x-ms-office365-filtering-correlation-id: 85cadefb-1c6a-4fe1-4a3e-08d46b293375
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR09MB0448;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448;
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51414003)(25786008)(966004)(6306002)(7696004)(6246003)(6606003)(99286003)(54906002)(33656002)(55016002)(9686003)(5660300001)(4326008)(54896002)(561944003)(53936002)(74316002)(7736002)(122556002)(2900100001)(10710500007)(38730400002)(77096006)(8936002)(8676002)(2906002)(2950100002)(81166006)(53546007)(3846002)(54356999)(6116002)(76176999)(3280700002)(6506006)(19627405001)(50986999)(15650500001)(7110500001)(2420400007)(229853002)(3660700001)(189998001)(66066001)(102836003)(6436002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0446AA8F2902D240F99A861C84240DM2PR09MB0446namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 22:26:46.5207 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448
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, 14 Mar 2017 22:26:52 -0000

Just so that everyone on the list is aware of the background info....

I sent this suggestion (email copied below) to Alvaro.

Alvaro replied to me in detail.

I would request him to post that response on this list as well

so everyone has the full context.

Alvaro asked me to invite comments on the WG list.

Please read the proposal below, and share your thoughts. Thanks.



From: Sriram, Kotikalapudi (Fed)

Sent: Monday, March 13, 2017 4:57 PM

To: Alvaro Retana (aretana)

Subject: BGPsec draft and extended messages

Hi Alvaro,

Just trying to think aloud about a possible way to have wording in the BGPsec draft that does not require normative dependence on the extended message draft. I think it can be done in a rational way as follows. Please feel free to shoot this down if the rationale seems weak.

Currently the draft reads in Section 2.2:

   Note that BGPsec update messages can be quite large, therefore any

   BGPsec speaker announcing the capability to receive BGPsec messages

   SHOULD also announce support for the capability to receive BGP

   extended messages [I-D.ietf-idr-bgp-extended-messages].  Please see

   related operational guidance in Section 7.

Suggestion: Remove the above paragraph from Section 2.2 and add the following in Section 4.2 (Constructing the BGPsec_Path Attribute):

BGPsec update size is subject to a maximum BGP update size. The maximum size at present is 4096 bytes [RFC4271], and it may be extended to a larger size in the future. If the sending router determines that adding its Secure_Path Segment and Signature Segment causes the BGPsec update to exceed the maximum size, then it will convert the BGPsec update to an unsigned traditional BGP update [using the procedure in Section 4.4] and send the unsigned update. (Note: Please see related discussion in Section 7.)

Then the existing discussion paragraph in Section 7 (operations) related to extended messages can be replaced with the following:

BGPsec update size is subject to “current” maximum BGP update size, noting that “current” maximum size may increase in the future. The maximum size at present is 4096 bytes [RFC4271], and it is expected be extended to a larger size in the future [I-D.ietf-idr-bgp-extended-messages]. Given the ECDSA with curve P-256 for the signature algorithm [I-D.ietf-sidr-bgpsec-algs], each AS in an AS path adds approximately 100 bytes of BGPsec data (i.e. Secure_Path Segment and Signature Segment). Hence, the maximum size of 4096 bytes is exceeded only if there are 40 or more distinct ASes in the AS path. (Note: AS prepends are compressed out with the use of pCount as described in Section 3.1.)  Currently, the average and maximum AS path lengths in the Internet are 3.8 and 14, respectively, and have remained in this ball park for many years [Huston].

[Huston] G. Huston, “AS6447 BGP Routing Table Analysis Report,” March 13, 2017.

(BTW, the above wording perhaps also makes it independent of the form extended messages takes eventually – separate RFC that updates BGP-4 or as default in BGP-5 OPEN(?) etc. )

I look forward to hearing your thoughts on this. Thank you.