Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Sat, 14 January 2017 17:23 UTC
Return-Path: <kotikalapudi.sriram@nist.gov>
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 8F8D1129486; Sat, 14 Jan 2017 09:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 eO9_Qh4gwYbN; Sat, 14 Jan 2017 09:23:29 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0123.outbound.protection.outlook.com [23.103.200.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC602129C5C; Sat, 14 Jan 2017 09:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pRvAc551G18DLt544p7xlDwHeJ7oioc/inT0taIJpsA=; b=tZrDYjMucmwPFSS9ZgFPELQ+KFrb1okM+wv9/XckRR+pFwm+Vnhc+uGyCWIs1jjSHnCJ0oX0dv+BoSRxFr99u1T7Yse5zR77P8Ctm3RFKhP4YELXeJY1Yim12hhnb6rsAq0tzU6jrdQXJAG34xcGAJMe+x7P4zs82DCLfa4vsg0=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Sat, 14 Jan 2017 17:23:27 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.020; Sat, 14 Jan 2017 17:23:27 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
Thread-Index: AQHSZtOj8RWDBRi0KkOPVX8e3dZBrKE4RbqM
Date: Sat, 14 Jan 2017 17:23:27 +0000
Message-ID: <DM2PR09MB04464F022CA83E803C01E417847B0@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com>
In-Reply-To: <148356622825.12945.17416255063037873581.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov;
x-originating-ip: [129.6.223.13]
x-ms-office365-filtering-correlation-id: d14fda76-0fef-4408-4012-08d43ca20db1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448;
x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:omuv2vaaqPol82SPL1nnD4hR8VjrIu8qIQqxMVOzYgvCPwnk0yZv2CUetUR035PnC8FRYPM4lmmvHZQiPo8H+jqkc27MrJGRj58/mAN0/EGzzIZL+Ldv/ywuOvAk0/oEddRWredk3kE86uzX3Jc65tHRCbONgb6jd7jQ0dtAIVTsJPtM5jWYsXARySi+/n/ERDwfy6xktm3j0TIFAPZ8K/hDkp/ugeCPbyIN0uAFBu8DNLyMuBciV5dhWRXi1g+rZ7OKOiSRj8cOZJ66+n9ZfGDWmxUlD23ADgTpOBhSNxkXQwAXMXiS23dp1IU99dmOP3kh3cJCBlQhex44Psl4ey0yZ/rwvie5AIPr34r5M1yv4OdVBgkPnbuIlJ3SoMR7c6UScPbEuipEbeMjSlfzyq7lIgYbKMuzRWqaJNFq32O9JmmJkYcLz3juinFwRHIr8r2584Da1LqMOemKibrLwQ==
x-microsoft-antispam-prvs: <DM2PR09MB04484BDB82E405C092722A7A847B0@DM2PR09MB0448.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448;
x-forefront-prvs: 0187F3EA14
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(199003)(189002)(2900100001)(229853002)(54906002)(86362001)(105586002)(122556002)(345774005)(9686003)(92566002)(50986999)(189998001)(2950100002)(68736007)(81166006)(33656002)(81156014)(106356001)(6306002)(7696004)(8676002)(106116001)(230783001)(6116002)(8936002)(102836003)(76176999)(3846002)(54356999)(97736004)(66066001)(2906002)(3660700001)(5001770100001)(25786008)(305945005)(3280700002)(7736002)(55016002)(4326007)(6436002)(99286003)(6506006)(77096006)(101416001)(38730400001)(5660300001)(27001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2017 17:23:27.5202 (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: <https://mailarchive.ietf.org/arch/msg/sidr/SzU7-q56Ze2OOA_0FFRLLxh4s70>
Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, Matthias Waehlisch <m.waehlisch@fu-berlin.de>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 14 Jan 2017 17:23:35 -0000
Hi Ben, Sorry for the delay in responding. Thank you for the review and very helpful comments. Please see my responses inline below. The changes mentioned below that reflect your comments/suggestions are already incorporated in the forthcoming version-22. >-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized > versions of 2119 words. This draft does not. It seems different 2119 > approaches among the various bgpsec draft could be confusing to the > reader. > [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops excludes > non-capitalized versions of 2119 words. (That is to say, it treats them > as their normal English equivalents.)] Thank you for pointing this out. I have gone over the whole document and wherever the standards language [RFC 2119] is applicable, I have made sure that upper case “MUST”, “SHOULD” etc. are used rather than lower case “must”, “should” etc. > - 5.2, step 2: I'm almost sure I've missed something here, but if I > understand correctly, previous sections talked about how a peer can > propagate a BGPsec_Path attribute without modification. Will that cause a > problem in this step if the immediate peer propagated an unmodified > BGPsec_Path that came from a different AS? You are right in pointing this out. The key is that 5.2, step 2 check is meant to be done with eBGP peer (not iBGP). Unmodified BGPsec update is sent only to BGPsec-capable iBGP peers (internal peers). In the case of an eBGP (BGPsec capable) peer, the BGPsec update is always modified and propagated with a new Secure_Path Segment and Signature added. So I have modified the wording in 5.2, step 2 to read as follows: 2. Check that AS number in the most recently added Secure_Path Segment (i.e. the one corresponding to the eBGP peer from which the update message was received) matches the AS number of that peer as specified in the BGP OPEN message. (Note: This check is performed only at an ingress BGPsec router where the update is first received from a peer AS.) > > - 8.4, last paragraph: The text describes a replay attack, and delegates > the mitigation solution to. This is an > informational reference; it draft-ietf-sidr-bgpsec-rollover >seems like it should be normative. The solution for mitigation of replay attacks is out of band (in relation to the BGPsec protocol). As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way' of replay attack mitigation. Techniques for key rollover / replay attack mitigation are expected to continue to evolve. There are various variants of the basic key rollover technique that are discussed in this informational draft: https://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-07 What needs to be pointed out in the BGPsec specification is that there are solutions available for replay attack mitigation. The above are the reasons why draft-ietf-sidr-bgpsec-rollover is included in informational references. Sriram
- [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgps… Ben Campbell
- Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-… Sriram, Kotikalapudi (Fed)
- Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-… Ben Campbell
- Re: [sidr] Ben Campbell's Yes on draft-ietf-sidr-… Sriram, Kotikalapudi (Fed)