IETF Logo Mail Archive

[sidr] AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18

"Alvaro Retana (aretana)" <aretana@cisco.com> Sun, 04 December 2016 12:58 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 087AE1294E8; Sun, 4 Dec 2016 04:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 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=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ZHAi8qLrYp8o; Sun, 4 Dec 2016 04:58:30 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9744212711D; Sun, 4 Dec 2016 04:58:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13332; q=dns/txt; s=iport; t=1480856309; x=1482065909; h=from:to:cc:subject:date:message-id:mime-version; bh=TgFosTz42epVegHEq9J8GStOVJ0/0hNa74eBV3JVvoI=; b=BN0Ie5g5pFx4pXM65LHCi1cwEi/x9Glrivxqm5gtfJ3GesQN9yBuzo6x gzNM3Fu6V5L34dT3aph7JhGrkUv7zmGA26mo8ImT5cnpLwn0lWP+oxIRv eEGc6tWp8dJEf8DNtr//2gvYPoHY4GLy405UWMX5u0Y+6dOlC06YEA5l2 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AsBACxEkRY/4sNJK1dGgEBAQECAQEBAQgBAQEBgnNFAQEBAQEfWoENjUCmZIUiggiGIhyCAz8UAQIBAQEBAQEBYh0LhG8jCkwSAQZEAgQwJwQOiHSPa51HgikvinwBAQEBAQEBAQEBAQEBAQEBAQEBAR2GPoF9iiotghIeBZR8hWoBkRaBcoR9iU6HYIouAR83gRkxAQGFIoceK4EDgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.33,298,1477958400"; d="scan'208,217";a="182792306"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Dec 2016 12:58:21 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id uB4CwLUC006326 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 4 Dec 2016 12:58:21 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Dec 2016 06:58:20 -0600
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; Sun, 4 Dec 2016 06:58:20 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-sidr-bgpsec-pki-profiles@ietf.org" <draft-ietf-sidr-bgpsec-pki-profiles@ietf.org>
Thread-Topic: AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18
Thread-Index: AQHSTi4WSu/tt18RUk64ZuozIah2bA==
Date: Sun, 04 Dec 2016 12:58:20 +0000
Message-ID: <C835CAC9-9CBB-41B3-B376-D1E3A79F4638@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_C835CAC99CBB41B3B376D1E3A79F4638ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/9guldBGRXmNYK1PKp86agUJr9rg>
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: [sidr] AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18
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: Sun, 04 Dec 2016 12:58:32 -0000

Dear authors:

Hi!  I just finished reading this document.

I have some comments (please see below) I would like you to address, but I wouldn’t characterize any of them as major, so I’m starting the IETF Last Call and placing this document in the next available IESG Telechat.

Thanks!

Alvaro.


Comments:

C1. From the Introduction: “A router holding the private key is authorized to send route advertisements (to its peers) that contain one or more of the specified AS number as the last item in the AS PATH attribute.”  First of all, if BGPSec is used, then the AS_PATH attribute is not.  Second, what does “one or more of the specified AS number as the last item” mean?  There is only one “last item”…but I’m guessing you might be referring to pre-pending.

C2. “Border Gateway Protocol Security protocol (BGPsec)”  I haven’t seen BGPsec expanded anywhere else like that.  In fact, ID.sidr-bgpsec-protocol just used BGPsec (no expansion).

C3. s/ID.sidr-rfc6485bis/rfc7935

C4. In Section 3.1.3.2. (Extended Key Usage): “As specified in [RFC6487] this extension MUST be marked as non-critical.”  Because the behavior was specified in RFC6487, then the “MUST” shouldn’t be Normative here; s/MUST/must

C5. Section 3.3. (BGPsec Router Certificate Validation) says that the “validation procedure…is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), but using the constraints applied come from this specification.”  It Is strange to me that the phrase inside the parenthesis is included here since there isn’t an update to the procedure – is there a specific reason why you need to call future (unknown) updates out at this point?   BTW, s/using the constraints applied come from this specification/using the constraints from this specification

C6. References.
- RFC6818 can be made Informative.
- RFC6486 and ID.sidr-bgpsec-protocol should be Normative.

C7. s/to an Internet Service Providers (ISP)/ to an Internet Service Provider (ISP)

C8. s/The CA also generate./  (orphan phrase)

C9. s/The [RFC6480]/[RFC6480]

C10. s/3.1.1.1./3.1.1.

C11. “…the efforts of Steve Kent…were instrumental in preparing this work”  Steve is an author.

v2.23.0 | Report a Bug | By Email