IETF Logo Mail Archive

Re: [sidr] BGPsec draft and extended messages

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 15 March 2017 13:45 UTC

Return-Path: <aretana@cisco.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 D97231314F4; Wed, 15 Mar 2017 06:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwFFaMHOejOh; Wed, 15 Mar 2017 06:44:58 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F7C1314F0; Wed, 15 Mar 2017 06:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11826; q=dns/txt; s=iport; t=1489585497; x=1490795097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bI1Kc+ZrDAYFCV6z521apxDkMo9uMG+XI+Ouug7HV7g=; b=OzbGypGgCk5h3SPii1uB7apsOtIxpuHWCXDuGlAUmf2u9q/ClzInchmt 6widcyZEgWewLWbDuYzyIhH0Q2UinC6Q8A+5pirLaPh85uR5X6H5Gd2rk aobU4laNumJwtmbWNl0LKCvY5SbMkIoH7PyKBsIpPEbpQAtuThKZwkYGz o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A7AwD9RMlY/40NJK1dGQEBAQEBAQEBAQEBBwEBAQEBgm5jYYEKB4NZig2RNx+QD4Utgg6GIgIagk8/GAECAQEBAQEBAWsohRYBBAEjVgULAgEIPwMCAgIwFBEBAQQBDQWJeAiuCIImK4o1AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZOggUIgmKHWi6CMQWWAIZDAZI6gXuFJYoFiEaLAAEfOIEEWBVBEQGEQiCBY3WIJYENAQEB
X-IronPort-AV: E=Sophos;i="5.36,168,1486425600"; d="scan'208,217";a="398438011"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 13:44:56 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2FDiu5R000384 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Mar 2017 13:44:56 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Mar 2017 08:44:55 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 15 Mar 2017 08:44:55 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Randy Bush <randy@psg.com>, Steve KENT <steve.kent@raytheon.com>
CC: sidr wg list <sidr@ietf.org>, Matthias Waehlisch <m.waehlisch@fu-berlin.de>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, Sean Turner <sean@sn3rd.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [sidr] BGPsec draft and extended messages
Thread-Index: AdKcN8SBuyxP2TUmTMSCIN0IJlVFkAA0o+kaAAxpUAAAF68igA==
Date: Wed, 15 Mar 2017 13:44:55 +0000
Message-ID: <BC9717B9-C466-4278-B886-48D9C2EA16DF@cisco.com>
References: <CY1PR09MB0444303CC4FC61239C90E6FE84250@CY1PR09MB0444.namprd09.prod.outlook.com> <m2innbv94e.wl-randy@psg.com> <DM2PR09MB0446AA8F2902D240F99A861C84240@DM2PR09MB0446.namprd09.prod.outlook.com>
In-Reply-To: <DM2PR09MB0446AA8F2902D240F99A861C84240@DM2PR09MB0446.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.6]
Content-Type: multipart/alternative; boundary="_000_BC9717B9C4664278B88648D9C2EA16DFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Igt5vr7dLNQsXBlzjONdZ0mNcvA>
Subject: Re: [sidr] BGPsec draft and extended messages
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 15 Mar 2017 13:45:03 -0000

Hi!

[Speaking as AD]

The requirement for Extended Messages has been in the BGPSec draft since the beginning (at least the WG -00 version).  Changing it now would mean a significant deviation in the process – but not impossible.

Before committing to supporting any change to the document, I would like to see changes discussed in the sidr WG list.  You may even be able to convince the sidrops Chairs to give you some time in Chicago to discuss in person.  We would need the WG to reach consensus for such a change.


[Speaking as WG Participant]

I think that a possible path forward is to take any reference to the Extended Messages document out, and simply put text similar to this in (from Sriram’s message):

“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.)”

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


Thanks!

Alvaro.








On 3/14/17, 6:26 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov<mailto:kotikalapudi.sriram@nist.gov>> wrote:

> Alvaro replied to me in detail.

v2.23.0 | Report a Bug | By Email