From nobody Mon Dec 3 11:20:13 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15801130F9A; Mon, 3 Dec 2018 11:20:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154386480803.4916.12331278772406047504@ietfa.amsl.com> Date: Mon, 03 Dec 2018 11:20:08 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 19:20:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Algorithms, Key Formats, and Signature Formats Authors : Sean Turner Oliver Borchert Filename : draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt Pages : 22 Date : 2018-12-03 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 3 11:23:36 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593EF130F0E for ; Mon, 3 Dec 2018 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 CoZ38urtPBJY for ; Mon, 3 Dec 2018 11:23:26 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840131.outbound.protection.outlook.com [40.107.84.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA00130E53 for ; Mon, 3 Dec 2018 11:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AvQfzKlMT8TtHCQG+mjng8znatuwQNU78lJ9yd1ZGvU=; b=oEKNYdyuuDoPos4cuYT0HEI63dfHKs+j0klrFCwAv1sJK15NbulLxtZcr1Yh+NQwF/Fq1Z2iZ7QRhWxmloDCz+b1AjJglC9TXBoz90uy6Rk+2uAQkPZcehJZaHtxupxg8tvO0m+mhy8V+zYm15sCjdSJRhXEKOMkWgy5yuLQDSA= Received: from SN6PR0901MB2494.namprd09.prod.outlook.com (52.132.117.144) by SN6PR0901MB2493.namprd09.prod.outlook.com (52.132.117.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.18; Mon, 3 Dec 2018 19:23:24 +0000 Received: from SN6PR0901MB2494.namprd09.prod.outlook.com ([fe80::dce8:cd1c:b7d2:efd5]) by SN6PR0901MB2494.namprd09.prod.outlook.com ([fe80::dce8:cd1c:b7d2:efd5%6]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 19:23:24 +0000 From: "Borchert, Oliver (Fed)" To: "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" , Sean Turner Thread-Topic: New Version Notification for draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt Thread-Index: AQHUiz08zZftuH5n8E6NIPbZHucioKVtEQSA Date: Mon, 3 Dec 2018 19:23:24 +0000 Message-ID: References: <154386480819.4916.11686772303829617645.idtracker@ietfa.amsl.com> In-Reply-To: <154386480819.4916.11686772303829617645.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [2610:20:6222:140:a1ed:eb02:421:a273] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR0901MB2493; 6:IgT50D2ge3mxLzaT+cv+xnhkA5EHHfEkmZTaDJ2z+RIiQXzKWQOPUEO4B/8izNHftnSlHnCw7InWDH4x6n1t8XGMA07EA5WVkspDFYW+z/l9O3gLdk5ooRfwCk+YCxMmW8V3Ps98RwFYjzq4Qnn241yCfz/xmbIm9IMCsDGNAuepbk62siSq1RndYe3q/bovbIDCgmq+ETkQVw9qSkp8JdgPaRZLLFxjwF6rGd7Ypt+fvbL6hiX4y/bpBrGwMAnwKBdYu2/h7dlQtjnBVkA0C+tshcf7FMsrviMj6Ktwil7fGmme/i+dagInYOxk7PF+9mC1w9h/O++biVew6EIVDsrTXtAC0Us5AwLsr7FtUeyw9JRhJ7DMWSZt4/0/Lmxv1Uc7EC5bOg5LPWVLKlEXlX7TqA3r68aUFikUK/8ckN1VG3ODSvwIOW6zGQXQRiHNBqjRcnUBVwYvF1by5IP9/Q==; 5:E/2YP2y8yiB+CcuMcKMR5PScwkUY04/YeD5PyOzljLR5CSJ6qJ+vI8tsEmolob7kQOBDNRVcBDmN6qZDAnunLf0MXr+UOGrrPFilkZLOpzBKFNtHvJ/oiB1H7gnxCwr4QdR/NxkYRy2zMqQkZH50IjF6rcsOjfwldZl9tsspahc=; 7:cA+E7fEQNJrhU7IrUumvcnmO0w2alDRmOfXf2+EcRMq+8Ur1WBXK+WV1vehKZ/U/BNlYHOei73T8ll8MRrW0Pm4bEcJElqHbjKfK3R2kS4Ci4YmqDy/6oR+8GLkzcuaA7tu8cvZcgY/WoqPdn3VnVg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7c4c1b6e-c903-40be-a3fa-08d65954cb58 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2493; x-ms-traffictypediagnostic: SN6PR0901MB2493: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:SN6PR0901MB2493; BCL:0; PCL:0; RULEID:; SRVR:SN6PR0901MB2493; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(106356001)(81166006)(14454004)(305945005)(7736002)(54906003)(81156014)(76176011)(316002)(36756003)(58126008)(6436002)(6486002)(2351001)(5660300001)(1730700003)(8676002)(25786009)(71200400001)(6306002)(71190400001)(966005)(68736007)(8936002)(15650500001)(256004)(14444005)(53936002)(6116002)(2906002)(83716004)(478600001)(99286004)(102836004)(82746002)(11346002)(2616005)(486006)(4326008)(46003)(446003)(476003)(6512007)(5640700003)(6246003)(229853002)(186003)(105586002)(97736004)(2501003)(86362001)(6506007)(6916009)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2493; H:SN6PR0901MB2494.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: j9cibFokR4gsu6z+gtp3Gu/HJacn2Mm7ZBPm6XGgXvteTo5sBfQvqiA4PVYtgbTjxbNFXjb/bxZdCIUyLFAIPj5MZCaw4x829DREa9QDO5jn5Zr4PoWb3ozz0UYYaXaUhgLSSSFesO+bhDkkdz1hpHi46x9xb2vcQriGPlVQeT1mabvla9QrIkyTH2Ntgk/5rdLdtZeAt5jTy2bITW52LwxNKGsAlkGfmOzlCTQ1JwC6wGBREljObKP12JJJrnBWG+3DCZwZrqQxgqdzP6qHV8iTikNqguFib7jmQ0ObYG5g6oNIj1R+IXLp411GPaiCrpB8jqUMT6/eYa1BjitRRSUR+lTS7aSAf1epdslgaIU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 7c4c1b6e-c903-40be-a3fa-08d65954cb58 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 19:23:24.1361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2493 Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 19:23:35 -0000 SSBqdXN0IHVwZGF0ZWQgdGhlIGRhdGVzLA0KT2xpdmVyDQoNCg0K77u/T24gMTIvMy8xOCwgMjoy MCBQTSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gd3JvdGU6DQoNCiAgICANCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1z aWRyb3BzLWJncHNlYy1hbGdzLXJmYzgyMDgtYmlzLTA0LnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgT2xpdmVyIEJvcmNoZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlDQog ICAgSUVURiByZXBvc2l0b3J5Lg0KICAgIA0KICAgIE5hbWU6CQlkcmFmdC1pZXRmLXNpZHJvcHMt Ymdwc2VjLWFsZ3MtcmZjODIwOC1iaXMNCiAgICBSZXZpc2lvbjoJMDQNCiAgICBUaXRsZToJCUJH UHNlYyBBbGdvcml0aG1zLCBLZXkgRm9ybWF0cywgYW5kIFNpZ25hdHVyZSBGb3JtYXRzDQogICAg RG9jdW1lbnQgZGF0ZToJMjAxOC0xMi0wMw0KICAgIEdyb3VwOgkJc2lkcm9wcw0KICAgIFBhZ2Vz OgkJMjINCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRy b3BzLWJncHNlYy1hbGdzLXJmYzgyMDgtYmlzLw0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBhbGdvcml0aG1zLCBhbGdvcml0aG0gcGFyYW1l dGVycywNCiAgICAgICBhc3ltbWV0cmljIGtleSBmb3JtYXRzLCBhc3ltbWV0cmljIGtleSBzaXpl cywgYW5kIHNpZ25hdHVyZSBmb3JtYXRzDQogICAgICAgdXNlZCBpbiBCR1BzZWMgKEJvcmRlciBH YXRld2F5IFByb3RvY29sIFNlY3VyaXR5KS4gIFRoaXMgZG9jdW1lbnQNCiAgICAgICB1cGRhdGVz IFJGQyA4MjA4ICgiQkdQc2VjIEFsZ29yaXRobXMsIEtleSBGb3JtYXRzLCBhbmQgU2lnbmF0dXJl DQogICAgICAgRm9ybWF0cyIpIGJ5IGFkZGluZyBTcGVjaWFsLVVzZSBBbGdvcml0aG0gSURzIGFu ZCBjb3JyZWN0aW5nIHRoZQ0KICAgICAgIHJhbmdlIG9mIHVuYXNzaWduZWQgYWxnb3JpdGhtcyBJ RHMgdG8gZmlsbCB0aGUgY29tcGxldGUgcmFuZ2UuDQogICAgDQogICAgICAgVGhpcyBkb2N1bWVu dCBhbHNvIGluY2x1ZGVzIGV4YW1wbGUgQkdQc2VjIFVQREFURSBtZXNzYWdlcyBhcyB3ZWxsIGFz DQogICAgICAgdGhlIHByaXZhdGUga2V5cyB1c2VkIHRvIGdlbmVyYXRlIHRoZSBtZXNzYWdlcyBh bmQgdGhlIGNlcnRpZmljYXRlcw0KICAgICAgIG5lY2Vzc2FyeSB0byB2YWxpZGF0ZSB0aG9zZSBz aWduYXR1cmVzLg0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAg ICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBU aGUgSUVURiBTZWNyZXRhcmlhdA0KICAgIA0KICAgIA0KDQo= From nobody Tue Dec 4 06:51:51 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E661D12D4EC for ; Tue, 4 Dec 2018 06:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 pFKckg1z2arM for ; Tue, 4 Dec 2018 06:51:46 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D4E128CF2 for ; Tue, 4 Dec 2018 06:51:46 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id k12so18265409qtf.7 for ; Tue, 04 Dec 2018 06:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O0QIz/jnOv1URavYl1eMuXrXoquSDcuMNI4RvtO7uLg=; b=cmie0pj5x/5pdIW2szYwv3rj1wIK9nS8f/wkDFhLVvyjtH8OR80KJRGYyarjlFT+Ul LV6TtSuP5VIKOtvuo1ugs6xdqK79U3iZ4ir8Ud62k1rElYNhjIDLtsa4k9w8tU4cAzxD QoIyZXFiQvoxWFhF73nPfImqgmqoOuDVbdXfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O0QIz/jnOv1URavYl1eMuXrXoquSDcuMNI4RvtO7uLg=; b=RHEs2TvZNPq7eTWOiZl+n1vrlb6Uc6YJdalfjzYwhbU++o6A6O30i/FRjoX+OPasPG ydGsb9pBfVLuap0K0e3BoUS2b+ew79ZO24IQkcAQ2ZCBmgY7A+agU1mBCTQML49hrnU5 VYs6uqd7Fn0tWH8+vjQKAbCktz71OkPW7Bn6Y35tXGHFLmv/koEzEvLu3mhb0pJg3EVB 9YXs8TsgREz1tR2pHAuheIqAAvAo9uzFwAPgA98SbdNNU2pYtr6QRqr/cSpyMQZ3LOzf 533qGfibgYNF6wGMB7eIUNToyWfxgfF+lS1vZYcwjs3mqSLqD03f6A+SKr/ZK0jMT3/H DLnQ== X-Gm-Message-State: AA+aEWY579ALzGciH5MTe1qgFSkeTAj2bkTqdzv+ExKfqLUCbcQxUOYJ +f2p1xI5n5NTE3mZN049Iuo/1Q== X-Google-Smtp-Source: AFSGD/Wo9X1ouaTszKSdJPP2ZBBv1vblIIoQpWdoTSfoJKzblYMdZnDaqqiXv5xa8aYgq04+3QJTJQ== X-Received: by 2002:a0c:8425:: with SMTP id l34mr20288245qva.101.1543935105560; Tue, 04 Dec 2018 06:51:45 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id z8sm11344472qth.34.2018.12.04.06.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 06:51:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Sean Turner In-Reply-To: Date: Tue, 4 Dec 2018 09:51:43 -0500 Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Sidrops] AD Review of draft-ietf-sidrops-rtr-keying X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 14:51:49 -0000 > On Nov 29, 2018, at 20:49, Warren Kumari wrote: >=20 > Please let me know LOUDLY once you've had a chance to look at these, = and I'll kick of IETF LC. A new version has been posted to address these. I will yell in the = email that I forward to you ;) > W > [0]: Once people start pointing out nits, they seem to continue (and = yes, I get the irony :-)) Yep - I am starting to rely on the RFC editor for the copy edits. They = usually do a way better job at tweaking things that I can. spt= From nobody Tue Dec 4 06:52:06 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F799130EDD; Tue, 4 Dec 2018 06:51:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154393511426.4547.16303975210912528209@ietfa.amsl.com> Date: Tue, 04 Dec 2018 06:51:54 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 14:52:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidrops-rtr-keying-01.txt Pages : 18 Date : 2018-12-04 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rtr-keying-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 4 06:53:35 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB81130DD5 for ; Tue, 4 Dec 2018 06:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 qM-6LxuaidxY for ; Tue, 4 Dec 2018 06:53:31 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497AB12D4EC for ; Tue, 4 Dec 2018 06:53:31 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id d18so18271729qto.8 for ; Tue, 04 Dec 2018 06:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kT9WJjV0WtKQbqhWUW+7lk7XQVSw+M+cuiJpXzg8sA0=; b=PGU90KIoC4kYQfIOFt5Vv+zTn3jdN2m01HWIC0kWejzZULpfc5xtAzzdngYUXWEIhj zscaQWOEc3z7kd72R759zgklCEJ+oznn4cGDB9WT/PooaBbgXBlnYeyFws7Y3pjcwS6K FyCw92AwOkOASts5qESOA6zccGUYI1G7C1pjA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kT9WJjV0WtKQbqhWUW+7lk7XQVSw+M+cuiJpXzg8sA0=; b=SeX/OftZ+WzvEVG40BSio58RGaIn98KjLwbui4ngDLMHTsSBYXAlgsRD3SvhtdWPoc MbPxfOIuJWJ4WHjnGfuQYwpcGObOBwbvdxAVmpNojCwv8wFiamjchJGuoIKPxQSrB0/y QaVOatDGGJ1ssK1iLPQevg9YbP9V9K906DdPBuZdRYL3nu00oXogBtrwbHvzWoU06ARF 2dmczhjstmaUDJy1Zw3PHPXO+DWooz7R4EB60RhSSK6Jzr5D28el+msEy+97F1BaAHOE SAM8R21tFXM3j/AtFA8tffXCaDTrKHsCFtWgaWiREGzr/BpASWNxJf8Q8SpTs6rngcby BXHg== X-Gm-Message-State: AA+aEWZeRKareIJ6EkAb+7mRvfCLm1A5HJsYCsF5e5X5dQM8WzjcoBmv nkL1uPKdwngutYBClVfjuT5/jQ== X-Google-Smtp-Source: AFSGD/VpCak6NFKfNUxWH3ijVmE10ABQMJyOPyap33RxXWu0d83pB3rpk7LdyDIhpJaKukJ85p9JgQ== X-Received: by 2002:a0c:e751:: with SMTP id g17mr15656674qvn.160.1543935210425; Tue, 04 Dec 2018 06:53:30 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id n3sm10868153qtc.81.2018.12.04.06.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 06:53:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Sean Turner In-Reply-To: <154393511426.4547.16303975210912528209@ietfa.amsl.com> Date: Tue, 4 Dec 2018 09:53:28 -0500 Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154393511426.4547.16303975210912528209@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 14:53:34 -0000 Warren, NEW VERSION IS POSTED. WE ARE READY FOR IETF LC! Just letting you know loudly :) spt > On Dec 4, 2018, at 09:51, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidrops-rtr-keying-01.txt > Pages : 18 > Date : 2018-12-04 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys in order = to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two = methods > of generating the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-01 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rtr-keying-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 4 09:10:00 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10022130F65 for ; Tue, 4 Dec 2018 09:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 X-J-HTvSQLcz for ; Tue, 4 Dec 2018 09:09:55 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0C3130F62 for ; Tue, 4 Dec 2018 09:09:54 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id b14so3189175wru.12 for ; Tue, 04 Dec 2018 09:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6TPGr3LsKsovw1xHHSuPputEDSQgkhGbFl5pUl+1W0I=; b=UBAUOwAwKHX1oPCWMetkn4N6wFuKFfJtI2XZjKh7GQcawOGU0/Enyg/gHARG2343Tc DctegJfs9urCEWXryHMD/KhP/QqiHfmpNE6m1Cs2BUTy928asyxcjc03Mezhzi1kaxCj lobTuvfWfmFpxP3gH4d7PbYy2fhgvXkYI4AaEhx/Dhe+IIo7J2oRRcybYGbla5xQ2fnh gFyUvC8ds0c4rqlUr8phoarquCi3FtsdhCfpXP1sISSRNQdc5yHI8Ohv5cRxI87GgH98 HTtvY7YWb2aZNOVrOgBXCllJvwf9OBWibNC6URb7BGWvCCc8La/y10PQ8EF11MYch6Nt wyVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6TPGr3LsKsovw1xHHSuPputEDSQgkhGbFl5pUl+1W0I=; b=T8GPK9HZ2BfNccWEOvNhOT3Jwor1K3s0reqHR4tglnD93wxfd0FPIN7qlqREmpeST8 5PoccJfSfigj6+48jy19+HBe+aPUkE1cnMjjLssJAY/vM9o01D0z5SPw03OOd4wPpISc jIjwb3xwV8zALQEYk1Vt7XKfnTkMLSco0IvpOJGukaAKHwTZ1d2frVnkTCCfw97ErhD5 obyg+H1fuDmHIx1Ymyg77BxPjcgjpjlb+EfUn4fZziwYRqPq3b7txWtannKaOBrkxoH2 x/jH9tSUKG/RMmCv2K16Rrnxk0C/DgkbaNHuQk98AiXOb0BLPT9QoVGnh+Su21E8JERw M6WQ== X-Gm-Message-State: AA+aEWYiPadycPQXTN6wRStQoH5abLYsKpH6tl9gQCpqpYTseCB6nz8v 2ENOsQmkpV9eooJYuPWSaLug4tIhCrtn1ugrxaC8sQ== X-Google-Smtp-Source: AFSGD/WfUHX8YAzi52Iy2tQbsIBzFCVlBz0uBFGEsB+goJhJYCvP8Tm9siiu1l5xPlPlvQ3qNOy8qNdz01+yh5PlpTc= X-Received: by 2002:adf:f848:: with SMTP id d8mr1799980wrq.178.1543943393075; Tue, 04 Dec 2018 09:09:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Tue, 4 Dec 2018 09:09:15 -0800 Message-ID: To: Sean Turner Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f818d057c355512" Archived-At: Subject: Re: [Sidrops] AD Review of draft-ietf-sidrops-rtr-keying X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 17:09:59 -0000 --0000000000007f818d057c355512 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 4, 2018 at 6:51 AM Sean Turner wrote: > > > > On Nov 29, 2018, at 20:49, Warren Kumari wrote: > > > > Please let me know LOUDLY once you've had a chance to look at these, and > I'll kick of IETF LC. > > A new version has been posted to address these. I will yell in the email > that I forward to you ;) > Awesome, thank you. > > > W > > [0]: Once people start pointing out nits, they seem to continue (and > yes, I get the irony :-)) > > Yep - I am starting to rely on the RFC editor for the copy edits. They > usually do a way better job at tweaking things that I can. > > Yup, they do a much better job than any of us -- but I figure if I see them while reviewing, it makes their job easier (and it simply politer to them). Also, having an easy to read document with nits addressed helps reassure IETF LC and IESG that the document has been well reviewed. Thanks for the update, IETF LC started, W > spt -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000007f818d057c355512 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tu= e, Dec 4, 2018 at 6:51 AM Sean Turner <sean@sn3rd.com> wrote:


> On Nov 29, 2018, at 20:49, Warren Kumari <warren@kumari.net> wrote:
>
> Please let me know LOUDLY once you've had a chance to look at thes= e, and I'll kick of IETF LC.

A new version has been posted to address these.=C2=A0 I will yell in the em= ail that I forward to you ;)

Awesome, thank = you.
=C2=A0

> W
> [0]: Once people start pointing out nits, they seem to continue (and y= es, I get the irony :-))

Yep - I am starting to rely on the RFC editor for the copy edits.=C2=A0 The= y usually do a way better job at tweaking things that I can.


Yup, they do a much better job than any of = us -- but I figure if I see them while reviewing, it makes their job easier= (and it simply politer to them).=C2=A0
Also, having an easy to read docume= nt with nits addressed helps reassure IETF LC and IESG that the document ha= s been well reviewed.=C2=A0

Thanks for the update, IETF LC started,
W<= /div>
=C2=A0
spt


--
I don't think the execution is relevant when it was obvious= ly a bad idea in the first place.
This is like putting rabid weasels in = your pants, and later expressing regret at having chosen those particular r= abid weasels and that pair of pants.
=C2=A0 =C2=A0---maf
--0000000000007f818d057c355512-- From nobody Tue Dec 4 16:57:45 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E413101B; Tue, 4 Dec 2018 16:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk CC: morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154397144889.5020.91584389648142319.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2018 16:57:28 -0800 Archived-At: Subject: [Sidrops] Last Call: (Router Keying for BGPsec) to Proposed Standard X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 00:57:37 -0000 The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Router Keying for BGPsec' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Dec 7 12:46:44 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFB131047 for ; Fri, 7 Dec 2018 12:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 SsLdJgLxqsX4 for ; Fri, 7 Dec 2018 12:46:26 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B30E131030 for ; Fri, 7 Dec 2018 12:46:26 -0800 (PST) Received: from [100.115.249.221] (unknown [62.140.137.125]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 39CC51E7CA; Fri, 7 Dec 2018 21:46:24 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1544215584; bh=7l5EJtoHQuZzLJJZ7kPYJV5i/AH7LHfA99aF9PnvDJg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fE4FqZp0DIUXNXh/bLP7qLKW0IKdfZScumz2FFcsaLhk2iyjp+/GKtFNg3oY1whHa myQvswvaVSv1NQQnBsrpbB7RYhqZm5GT5Xd3/EaAvozgTxgwLeY1e1LVuSFD7EJAiG LT9alyg5skGq7WAydwrkVF7/23tu8gt4XKnp7r5c= Content-Type: multipart/alternative; boundary=Apple-Mail-96CD5AA1-CE6C-4ABB-9B4A-DBD5B51C3F17 Mime-Version: 1.0 (1.0) From: Tim Bruijnzeels X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Fri, 7 Dec 2018 21:46:22 +0100 Cc: sidrops@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Alexander Azimov Archived-At: Subject: Re: [Sidrops] Adoption Call for ASPA X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 20:46:35 -0000 --Apple-Mail-96CD5AA1-CE6C-4ABB-9B4A-DBD5B51C3F17 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I haven=E2=80=99t seen any formal adoption call, but I for one would definit= ely support. Kind regards Tim Bruijnzeels > On 29 Nov 2018, at 14:27, Alexander Azimov wrote: >=20 > Hi all, >=20 > I'd like to request working group adoption call for next documents: >=20 > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile-00 > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 >=20 >=20 >=20 > --=20 > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | visit: radar.qrator.net > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail-96CD5AA1-CE6C-4ABB-9B4A-DBD5B51C3F17 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I haven=E2=80=99t seen any formal adoption c= all, but I for one would definitely support.

Kind regards=
Tim Bruijnzeels


On 29 Nov 2018, at 14= :27, Alexander Azimov <aa@qrator.net= > wrote:

Hi all,

I'd li= ke to request working group adoption call for next documents:

=


=

--
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| v= isit: ra= dar.qrator.net
________= _______________________________________
Sidrops mailing list=
Sidrops@ietf.org
http= s://www.ietf.org/mailman/listinfo/sidrops
<= /div>= --Apple-Mail-96CD5AA1-CE6C-4ABB-9B4A-DBD5B51C3F17-- From nobody Fri Dec 14 03:57:15 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E911B130DCA; Fri, 14 Dec 2018 03:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xV8pcl6qrZ7u; Fri, 14 Dec 2018 03:57:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C7512D7F8; Fri, 14 Dec 2018 03:57:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gXm5V-0003aD-Jk; Fri, 14 Dec 2018 11:57:02 +0000 Date: Fri, 14 Dec 2018 03:57:00 -0800 Message-ID: From: Randy Bush To: Dhruv Dhody Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 11:57:07 -0000 i will leave other issues for sean, who is both more expert and more patient :) > Also, did the authors/WG consider making Router-driven as default > and operator-driven to be used with utmost care and only when > router-driven is not possible? we do not tell operators how to run their networks. for examplem many will choose operator driven because it allows them to quickly swap new gear for a failed device without backflow into the rpki. randy From nobody Mon Dec 17 08:03:17 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35217130E81; Mon, 17 Dec 2018 08:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 IYHs6PTNIYyP; Mon, 17 Dec 2018 08:03:08 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979E2130E84; Mon, 17 Dec 2018 08:03:08 -0800 (PST) Received: from [192.168.192.27] (dhcp-089-098-091-015.chello.nl [89.98.91.15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 62DD71CBBC; Mon, 17 Dec 2018 17:03:06 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1545062586; bh=AmlZHv3ngc8yoKU7GiAb0FB9JPtKAFnbzboq8HaJ+OA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QkQ/cqoxBaWDVEyblJ/TDtGJJQURbIwRhZQ+Ink7H1Uq4uUSbrAwePL6mjFz3jXHV wwt8dgQG11soXHwanWpuoK7EDFcy7q0RCQZYkfK3gQBfCCZxZ5niP+L6s+a7JWE65U b3GVaV0upVsUXu3dzFq5bYwC3+z+wTuBv3qgcCUE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 17 Dec 2018 17:03:05 +0100 Cc: sidrops-chairs@ietf.org, sidrops@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> References: To: Christopher Morrow X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 16:03:16 -0000 I don=E2=80=99t remember seeing any comments on this one. What=E2=80=99s = the next step? Tim > On 5 Nov 2018, at 03:55, Christopher Morrow = wrote: >=20 > Howdy WG Folks, >=20 > Please read/review the document: draft-ietf-sidrops-https-tal >=20 > The abstract: > "This document defines a Trust Anchor Locator (TAL) for the Resource > Public Key Infrastructure (RPKI). This document obsoletes RFC 7730 > by adding support for HTTPS URIs in a TAL." >=20 > explains the gist, and the document is a short 10 page read/review... = Let's have a read/comment and push to get this moved into the IESG = process before xmas 2018! >=20 > -chris > co-chair-sidrops > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Dec 17 08:15:09 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA66130E9D for ; Mon, 17 Dec 2018 08:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 UOpecxcfjN7C for ; Mon, 17 Dec 2018 08:15:06 -0800 (PST) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [198.64.6.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD61B130E7A for ; Mon, 17 Dec 2018 08:15:06 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gYvXr-000AkL-Jx (job@us.ntt.net) for sidrops@ietf.org; Mon, 17 Dec 2018 16:15:06 +0000 Received: by mail-ot1-f43.google.com with SMTP id a11so12625630otr.10 for ; Mon, 17 Dec 2018 08:15:03 -0800 (PST) X-Gm-Message-State: AA+aEWYvBJpUOlyY4PVFuF2VwC+XzIqCENw1TL8D0goLsR18O72QaaPm R9ZQxnw12tTTp9R9RwmX1hVR0NKMZulVjGcgw/nNSg== X-Google-Smtp-Source: AFSGD/XQP1LgGPVrI1jEKU4vKvhauV0lRInaeLhhDJ+TSobALY/iNo4kFqmuG7WxeQOovUEDr7xd+QhS8fQUyn+5azk= X-Received: by 2002:a9d:225:: with SMTP id 34mr10538258otb.224.1545063303216; Mon, 17 Dec 2018 08:15:03 -0800 (PST) MIME-Version: 1.0 References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> In-Reply-To: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> From: Job Snijders Date: Mon, 17 Dec 2018 17:14:52 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Tim Bruijnzeels Cc: Christopher Morrow , sidrops-chairs@ietf.org, SIDR Operations WG , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 16:15:08 -0000 Dear all, I reviewed the document (and previously suggested the addition of the '#' comment). I'd like to see this document published as IETF RFC. Some small nitpicks: Section 1.1 terminology should also point to 8174 Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we are the I= ETF Section 4: "Therefore, the Relying Party MUST continue to retrieve the data in case of errors." I am not sure software "MUST" continue when errors are found - maybe those errors should just be fixed. Generally I'm not a fan of being too forgiving, I'd reconsider the RFC 2119/8174 terminology here, or leave the sentence out. Kind regards, Job On Mon, Dec 17, 2018 at 5:03 PM Tim Bruijnzeels wrote: > > I don=E2=80=99t remember seeing any comments on this one. What=E2=80=99s = the next step? > > Tim > > > On 5 Nov 2018, at 03:55, Christopher Morrow wrote: > > > > Howdy WG Folks, > > > > Please read/review the document: draft-ietf-sidrops-https-tal > > > > The abstract: > > "This document defines a Trust Anchor Locator (TAL) for the Resource > > Public Key Infrastructure (RPKI). This document obsoletes RFC 7730 > > by adding support for HTTPS URIs in a TAL." > > > > explains the gist, and the document is a short 10 page read/review... L= et's have a read/comment and push to get this moved into the IESG process b= efore xmas 2018! > > > > -chris > > co-chair-sidrops > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 18 01:30:40 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146C51310B8; Tue, 18 Dec 2018 01:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 bB5s0g_iA-5Q; Tue, 18 Dec 2018 01:30:31 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93167130E66; Tue, 18 Dec 2018 01:30:30 -0800 (PST) Received: from [IPv6:2a04:b900::1:9ccd:ff7b:6da7:969a] (unknown [IPv6:2a04:b900:0:1:9ccd:ff7b:6da7:969a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 5F1131F01D; Tue, 18 Dec 2018 10:30:28 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1545125428; bh=sNqdLl0qTfBnm+CCxZktya4cXnUtTSHvddFYPmqh1E0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Me9+MbjpjoTcuYpQvUXP51INgZL2yh9SIRzUn8pWww+wBFcJmyl9SK03yItTFDbBS JzzGLBgY/aVc9cECuCX0wllCIB8AF2sJ6ELJUKGjBNdw4LRaKLtHOiMN9SXD6YAMva 7pmEqhaD8C41njIjiWjfmetw9bbZciW9PcSckoWE= Content-Type: multipart/alternative; boundary="Apple-Mail=_F1B9236B-ECF2-48C4-B2D9-531E5E2FD973" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 18 Dec 2018 10:30:27 +0100 Cc: sidrops-chairs@ietf.org, Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org Message-Id: <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> To: Job Snijders X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 09:30:38 -0000 --Apple-Mail=_F1B9236B-ECF2-48C4-B2D9-531E5E2FD973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Job, all, Thank you for reviewing! > On 17 Dec 2018, at 17:14, Job Snijders wrote: >=20 > Dear all, >=20 > I reviewed the document (and previously suggested the addition of the > '#' comment). I'd like to see this document published as IETF RFC. >=20 > Some small nitpicks: >=20 > Section 1.1 terminology should also point to 8174 Ack! > Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we are = the IETF So, the machines will most likely ignore this anyway. I guess that UTF-8 = should be okay, provided we restrict the allowed line breaks to = or for these lines as well. So maybe rephrase: Current: 1. an optional comment section consisting of one or more lines starting with the '#' character, containing human readable informational ASCII text, followed by an empty line using a "" or "" line break only. New: 1. an optional comment section consisting of one or more lines starting with the '#' character, containing human readable informational UTF-8 text, and ending with a "" or=20 "" line break. Followed by an empty line using a "" or "" line break only. I don=E2=80=99t have a strong opinion either way. > Section 4: "Therefore, the Relying Party MUST continue to retrieve the > data in case of errors." I am not sure software "MUST" continue when > errors are found - maybe those errors should just be fixed. Generally > I'm not a fan of being too forgiving, I'd reconsider the RFC 2119/8174 > terminology here, or leave the sentence out. This section was modeled after section 4.3 in RFC8182: https://tools.ietf.org/html/rfc8182#section-4.3 = The reasoning was that, since we have object security in the RPKI, data = can be validated even if the transport channel is not fully trusted = (e.g. rsync). And that having some data to validate would be better than = having no data. At the time of writing this we were afraid that it would = be more common to encounter TLS verification issues due to = misconfigurations as opposed to malice (which can at best withhold or = replay data, and manifests protect somewhat against that). All that being said, I think that these days =E2=80=9CLet=E2=80=99s = Encrypt=E2=80=9D has made it abundantly easy to get this sorted for a = production repository, that I am willing to take this all out and = suggest that validation be strict. Note though that this means that = validation software will rely on the list of (web) Trust Anchors = installed on the system, and not all of these are equally trustworthy, = and the list may be out of date. That said, systems should be kept up to = date, and a possible false positive verification outcome here still = leaves the object security in tact. So adds a layer of security, but = it=E2=80=99s not the only layer. Tim >=20 > Kind regards, >=20 > Job >=20 > On Mon, Dec 17, 2018 at 5:03 PM Tim Bruijnzeels = wrote: >>=20 >> I don=E2=80=99t remember seeing any comments on this one. What=E2=80=99= s the next step? >>=20 >> Tim >>=20 >>> On 5 Nov 2018, at 03:55, Christopher Morrow = wrote: >>>=20 >>> Howdy WG Folks, >>>=20 >>> Please read/review the document: draft-ietf-sidrops-https-tal >>>=20 >>> The abstract: >>> "This document defines a Trust Anchor Locator (TAL) for the = Resource >>> Public Key Infrastructure (RPKI). This document obsoletes RFC = 7730 >>> by adding support for HTTPS URIs in a TAL." >>>=20 >>> explains the gist, and the document is a short 10 page = read/review... Let's have a read/comment and push to get this moved into = the IESG process before xmas 2018! >>>=20 >>> -chris >>> co-chair-sidrops >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_F1B9236B-ECF2-48C4-B2D9-531E5E2FD973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Job, all,
Thank you for reviewing!

On 17 Dec 2018, at 17:14, Job Snijders <job@ntt.net> = wrote:

Dear all,

I reviewed the = document (and previously suggested the addition of the
'#' = comment). I'd like to see this document published as IETF RFC.

Some small nitpicks:

Section 1.1 terminology should also point to 8174

Ack!

Section 2.1 = "ASCII" should probably be UTF-8, this is 2018 and we are the IETF

So, = the machines will most likely ignore this anyway. I guess that UTF-8 = should be okay, provided we restrict the allowed line breaks to = <CRLF> or <LF> for these lines as well. So maybe = rephrase:

Current:

   1.  an optional = comment section consisting of one or more lines
       starting with the '#' character, = containing human readable
      =  informational ASCII text, followed by an empty line using = a
       "<CRLF>" or = "<LF>" line break only.

New:

   1. =  an optional comment section consisting of one or more = lines
       starting with the = '#' character, containing human readable
  =      informational UTF-8 text, and ending with a = "<CRLF>" or 
      =  "<LF>" line break. Followed by an empty line using = a
       "<CRLF>" or = "<LF>" line break only.

I don=E2=80=99t have a strong opinion = either way.

Section 4: = "Therefore, the Relying Party MUST continue to retrieve the
data in case of errors." I am not sure software "MUST" = continue when
errors are found - maybe those errors should = just be fixed. Generally
I'm not a fan of being too = forgiving, I'd reconsider the RFC 2119/8174
terminology = here, or leave the sentence out.

This = section was modeled after section 4.3 in RFC8182:
<= br class=3D"">
The reasoning was that, since we have object = security in the RPKI, data can be validated even if the transport = channel is not fully trusted (e.g. rsync). And that having some data to = validate would be better than having no data. At the time of writing = this we were afraid that it would be more common to encounter TLS = verification issues due to misconfigurations as opposed to malice (which = can at best withhold or replay data, and manifests protect somewhat = against that).

All that being said, = I think that these days =E2=80=9CLet=E2=80=99s Encrypt=E2=80=9D has made = it abundantly easy to get this sorted for a production repository, that = I am willing to take this all out and suggest that validation be strict. = Note though that this means that validation software will rely on the = list of (web) Trust Anchors installed on the system, and not all of = these are equally trustworthy, and the list may be out of date. That = said, systems should be kept up to date, and a possible false positive = verification outcome here still leaves the object security in tact. So = adds a layer of security, but it=E2=80=99s not the only = layer.

Tim



Kind regards,

Job

On Mon, Dec 17, 2018 at 5:03 = PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:

I don=E2=80=99t remember seeing = any comments on this one. What=E2=80=99s the next step?

Tim

On 5 Nov 2018, at 03:55, Christopher Morrow <christopher.morrow@gmail.com> wrote:

Howdy WG Folks,

Please = read/review the document: draft-ietf-sidrops-https-tal

The abstract:
 "This document defines a = Trust Anchor Locator (TAL) for the Resource
=   Public Key Infrastructure (RPKI).  This document = obsoletes RFC 7730
  by adding support for = HTTPS URIs in a TAL."

explains the gist, = and the document is a short 10 page read/review... Let's have a = read/comment and push to get this moved into the IESG process before = xmas 2018!

-chris
co-chair-sidrops
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_F1B9236B-ECF2-48C4-B2D9-531E5E2FD973-- From nobody Tue Dec 18 08:27:40 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01C131146 for ; Tue, 18 Dec 2018 08:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 VxxsSxmhHxA2 for ; Tue, 18 Dec 2018 08:27:32 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CC913113F for ; Tue, 18 Dec 2018 08:27:32 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id p17so18819311qtl.5 for ; Tue, 18 Dec 2018 08:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1uKpkrDH+ZAIJVswo0mZayg69/uXQ6dAQkn0pBwZ29w=; b=hpORKY2v6ccsuC6ON0aXOkI+OGMrHcKlfACxxbrwdeARq+G5nBSz6Eb430Em4l8pwp gOYogTaxwqagSlnxK7nN3RiqrY46nNml7whLfeicOQIqSEtevIBv/MGYMLe99zt5hivQ yK6vI1+zI1MhJJd0i2lufYm94ed+PnMPEqJuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1uKpkrDH+ZAIJVswo0mZayg69/uXQ6dAQkn0pBwZ29w=; b=qjamwPXKR6vjYA9sefwKDtjV7T5V6Df4RZZUItNjlAeOSEPZ+a7r8tpM6bI614T3uP khc/Ydp7nOxBPYfhyoank5QTqeowRBzb98qbrBbxm4rF0D9hTUUwaJtBXRtO0Jru3e3r xk9ISabIZGQXki6DWzYAGhwNIAEidYBQ1vAwMXR9WuZLaMDrJ6kEGR0R0BuQ9UI+LL0U 5Im/swSAWgOeJ+dvzm4vSqsOs0r4U8qPjF1j7UerRQiPlwf3MdNj/R03Bunxs1TnyGOF U6DFKxgbwQWdB9R+fdiISAPOlggo5EIaNx7Ld+F48L1DVZeFmydUbrJz/exzNWaIQfwX gUrg== X-Gm-Message-State: AA+aEWb9jBfJxj8fQUvemG/1lKphJ+7LHIECK0acyj8OehwFbf8WeoH1 +DCWEKHoYgXstBKR0594t8K68g== X-Google-Smtp-Source: AFSGD/WfrzylrVpJh3n/6x/yKXaRbIp4TY1YExVXVJxyK2pL4ulAZx4/P39zoHQJ3zpKOwQiZJB+QA== X-Received: by 2002:a0c:8264:: with SMTP id h91mr18132962qva.116.1545150451392; Tue, 18 Dec 2018 08:27:31 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id z207sm211808qka.57.2018.12.18.08.27.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 08:27:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 18 Dec 2018 11:27:26 -0500 Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody Content-Transfer-Encoding: quoted-printable Message-Id: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> References: To: Dhruv Dhody X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 16:27:38 -0000 Hi! > On Dec 14, 2018, at 05:41, Dhruv Dhody wrote: >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. >=20 > Document: draft-ietf-sidrops-rtr-keying-01 > Reviewer: Dhruv Dhody > Review Date: 14 Dec 2018 > IETF LC End Date: Unknown > Intended Status: Standard >=20 > Summary: >=20 > I have some minor concerns about this document that I think should = be > resolved before publication. >=20 > Comments: >=20 > This document describe the provisioning of BGPsec-speaking routers = with the > appropriate public-private key-pairs. It describes two ways - Router = Driven > and Operator Driven of doing this. This document does not provide = any > protocol extensions. >=20 > Thank you for including Appendix B, it helped a lot. >=20 > Major Issues: >=20 > No major issues found. >=20 > Minor Issues: >=20 > (1) I am not sure about the status of the document. Since this = document > does not define any protocol extensions, this document reads to me = as > Informational or BCP. I am quite sure this is going to be asked = during IESG > reviews, it would be good idea to discuss and conclude on this early = on. You=E2=80=99re right this doesn=E2=80=99t define any protocol so = standards track might not be the way to go, but it was BCP earlier in = its lifetime. The SIDR WG decided to make it standard track. To be = entirely honest here (and I really hate to be writing this), I could = argue any of the options, but I am really just hoping to be told what it = should be by the IESG. > (2) I also find 'sub-methods' to describe the two different = mechanism (or > models) as incorrect. Would just saying =E2=80=9Ctwo methods=E2=80=9D as opposed to =E2=80=9Ctwo= sub-methods=E2=80=9D work for you? > Also, did the authors/WG consider making Router-driven as default = and > operator-driven to be used with utmost care and only when = router-driven is > not possible? See Randy=E2=80=99s response. I should add that there was at least one = person in the WG who thought that router-drive and operator-driven were = fraught with danger so that=E2=80=99s why we have s8. We basically = couldn=E2=80=99t agree which one was the MTI so we just left it alone = because =E2=80=A6 well see Randy=E2=80=99s response :/ > (3) Introduction mentions only Section 8, suggest to include some = more text > that describes the flow of the document to increase the readability. The penultimate paragraph in s1 talks about the rest of the document and = specifically calls out s8 because it=E2=80=99s the one section that = doesn=E2=80=99t quite fit. The rest of the document talks about the = router and operator driven methods and s8 describes another method where = it is more automated. Could we maybe just tweak the last sentence to = say: Section 8 describes another method that requires more capable routers. > (4) Section 4/5 used AS number and the BGP Identifier; where as = Appendix B > says subject name and serial number for the router. We should link = these > somehow. Yes we should; what goes in the subject and serial number field come = from RFC8209 s3.1.1. Let=E2=80=99s change Appendix B to: But before sending it, you need to also send the CA the subject name (i.e., =E2=80=9CROUTER-=E2=80=9C followed by the AS = Number) and serial number (i.e., the 32-bit BGP Identifier) for the router. > (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's EE > certificate(s); This is not clear, is this 'AS's key and = certificate' > belongs to the management station? Can you add a sentence clarifying = this. So what=E2=80=99s going on here is that the operator has generated the = key pair and it needs to get that back to the router. The first = paragraph tells you how to get the private key back with the ability to = verify that the operator actually sent it to the router. The second = paragraph is about verifying the signature on the CMS wrapper that = encapsulates the private key - and to do that you need the operator=E2=80=99= s certificate and any other certificate. I see changing it to = Operator=E2=80=99s EE private key and Operator=E2=80=99s EE certificate = as clarifying this because we don=E2=80=99t use AS EE anywhere else in = the document. > (6) It feels like, this document uses SHOULD as a default level. I = am not > sure if that is right in every instance of its use. >=20 > Nits: >=20 > - section 4 > s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be = used/ sure > - section 5 > s/transmits the AS it has chosen or the router/transmits the AS > it has chosen on the router/ good catch > - section 7 > s/certs-ony/certs-only ditto > - section 9 > Took me a while to parse this, might be helpful to make a list or > rephrase - >=20 > When an active router key is to be revoked, the process of = requesting > the CA to revoke, the process of the CA actually revoking the > router's certificate, and then the process of = re-keying/renewing the > router's certificate, (possibly distributing a new key and > certificate to the router), and distributing the status, takes = time > during which the operator must decide how they wish to = maintain > continuity of operations, with or without the compromised = private > key, or whether they wish to bring the router offline to = address the > compromise. I agree this is pretty wordy, but since you did get through it I am = hoping to relying on the RFC-editor and their excellent copy-editing = skills ;) > - section 10 > Does not parse - >=20 > ..employees that no longer need access to a > routers SHOULD be removed the router to ensure only those = authorized > have access to a router. How about: employees that no longer need access to a router SHOULD have their access rights removed for that router to ensure only those authorized for that router have access. spt From nobody Tue Dec 18 08:30:52 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9045130F4A; Tue, 18 Dec 2018 08:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FxafwbPBmArf; Tue, 18 Dec 2018 08:30:49 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B841A130F4F; Tue, 18 Dec 2018 08:30:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gZIGa-0005yu-Jp; Tue, 18 Dec 2018 16:30:44 +0000 Date: Tue, 18 Dec 2018 08:30:43 -0800 Message-ID: From: Randy Bush To: Sean Turner Cc: Dhruv Dhody , rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody In-Reply-To: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 16:30:51 -0000 >> - section 10 >> Does not parse - >> >> ..employees that no longer need access to a >> routers SHOULD be removed the router to ensure only those authorized >> have access to a router. > > How about: > > employees that no longer need access to a router SHOULD > have their access rights removed for that router to ensure only > those authorized for that router have access. why are we going into ops practice which is not directly relevant? randy From nobody Tue Dec 18 08:32:55 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A1D130F25 for ; Tue, 18 Dec 2018 08:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 JvpjeNW75T2e for ; Tue, 18 Dec 2018 08:32:47 -0800 (PST) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1048130F39 for ; Tue, 18 Dec 2018 08:32:45 -0800 (PST) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gZIIW-000C0S-Hz (job@us.ntt.net) for sidrops@ietf.org; Tue, 18 Dec 2018 16:32:45 +0000 Received: by mail-ed1-f49.google.com with SMTP id p6so14442921eds.0 for ; Tue, 18 Dec 2018 08:32:44 -0800 (PST) X-Gm-Message-State: AA+aEWYrNfjLhoLp7FqA0xQF0Xul5NkSE9O2a3I8ISfE3jZyf2EDOPRL rbBoQvBurc3j0DKYzhQC33wb7hgAO3LRHhfd28nI0Q== X-Google-Smtp-Source: AFSGD/XOG+lBpOrQ7pmLpwnVWBqTUYCLWlHUV9AWzx3vaaiXmZaQJn/L6BOhA5QhJHzOKaQcUCv6s52aGFnNXVkjkS0= X-Received: by 2002:a50:a55c:: with SMTP id z28mr17022391edb.124.1545150762872; Tue, 18 Dec 2018 08:32:42 -0800 (PST) MIME-Version: 1.0 References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> In-Reply-To: From: Job Snijders Date: Tue, 18 Dec 2018 17:32:31 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Randy Bush Cc: Sean Turner , Dhruv Dhody , rtg-dir@ietf.org, rtg-ads@ietf.org, SIDR Operations WG , Dhruv Dhody , draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 16:32:48 -0000 On Tue, Dec 18, 2018 at 5:30 PM Randy Bush wrote: > >> - section 10 > >> Does not parse - > >> > >> ..employees that no longer need access to a > >> routers SHOULD be removed the router to ensure only those authorized > >> have access to a router. > > > > How about: > > > > employees that no longer need access to a router SHOULD > > have their access rights removed for that router to ensure only > > those authorized for that router have access. > > why are we going into ops practice which is not directly relevant? I'd just remove the section about employees, this seems to be going a bit into the weeds. Kind regards, Job From nobody Tue Dec 18 08:37:38 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FB9130F4F; Tue, 18 Dec 2018 08:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tufSy_afYbHP; Tue, 18 Dec 2018 08:37:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A63C130F24; Tue, 18 Dec 2018 08:37:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gZIN2-00060V-Ib; Tue, 18 Dec 2018 16:37:24 +0000 Date: Tue, 18 Dec 2018 08:37:23 -0800 Message-ID: From: Randy Bush To: Job Snijders Cc: Sean Turner , Dhruv Dhody , rtg-dir@ietf.org, rtg-ads@ietf.org, SIDR Operations WG , Dhruv Dhody , draft-ietf-sidrops-rtr-keying.all@ietf.org In-Reply-To: References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 16:37:32 -0000 >>> How about: >>> >>> employees that no longer need access to a router SHOULD >>> have their access rights removed for that router to ensure only >>> those authorized for that router have access. >> >> why are we going into ops practice which is not directly relevant? > > I'd just remove the section about employees, this seems to be going a > bit into the weeds. was polling other authors From nobody Tue Dec 18 08:55:55 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739A4130EDE; Tue, 18 Dec 2018 08:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ootNui0Jce-M; Tue, 18 Dec 2018 08:55:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB4913110E; Tue, 18 Dec 2018 08:55:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gZIee-00064F-7Q; Tue, 18 Dec 2018 16:55:36 +0000 Date: Tue, 18 Dec 2018 08:55:35 -0800 Message-ID: From: Randy Bush To: Job Snijders Cc: Sean Turner , Dhruv Dhody , rtg-dir@ietf.org, rtg-ads@ietf.org, SIDR Operations WG , Dhruv Dhody , draft-ietf-sidrops-rtr-keying.all@ietf.org In-Reply-To: References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 16:55:46 -0000 >>>> How about: >>>> >>>> employees that no longer need access to a router SHOULD >>>> have their access rights removed for that router to ensure only >>>> those authorized for that router have access. >>> >>> why are we going into ops practice which is not directly relevant? >> >> I'd just remove the section about employees, this seems to be going a >> bit into the weeds. > > was polling other authors keyur walked up to my desk and agrees with removal. sean? randy From nobody Tue Dec 18 09:40:13 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4765C131104 for ; Tue, 18 Dec 2018 09:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Jms9wkRLQP6a for ; Tue, 18 Dec 2018 09:40:02 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6027E130ED9 for ; Tue, 18 Dec 2018 09:40:02 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id d19so19088015qtq.9 for ; Tue, 18 Dec 2018 09:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rfzxzvP7B0wvlEu5jjXFwzfhrYYWnzD2/Qq8rB1WHFo=; b=c+oDHCjJwX0q0esW0sgwSaXqGQ0kj0bC/5WDYYpGiC5fguAMbhN42db3jdLym9Jnre CoJFX/Udxy51SS8gGYDtQHd1e5mjOBdjoBiG2SLHfyM7bS/MJvy+HMMluFjJAoxsR+7O ah8VEEwk+ceIdHoybUz18dw4CCR178eHUEkwo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rfzxzvP7B0wvlEu5jjXFwzfhrYYWnzD2/Qq8rB1WHFo=; b=rDu0cHrfUKZ+87bR0fI7k0z91PzMPHPK/zZGkEy6e/v/SecLPxi/mFEwg7Lwp9iaqE OdOq1KXr96TF3K47zo5VEOcre4PSuWNgbZeOXyL4rWhl/0FsSsVSapoqRttyRIg8xePr fDIWT80UaRkd+c7IsxYMTRo68JowsruxRRvtYJxiGzXnsH/AIrMjaLpnX20OLh01lv7P fstVRQPcIcZaIpoX4WH8dzcsgYpDtGBVJSUKRfw7kxKsuy9oyNricDNp76rN4THCxvO9 RqSYgkWgdmgAZAf3LrMtcX30JZl1me+VdJBcHn6elyvxTL2WCbNdbQ+KOul5MVNv7wNB GxQA== X-Gm-Message-State: AA+aEWa38q7i0NNbUjA1TB4CyhRoTkMWlu/ew6ycYkOvik2Gt7xxMO0v SiryAY45DEpG8TldL8cEmlKzNA== X-Google-Smtp-Source: AFSGD/VcSqYlPYgQVFKTAXxOcrigPjBG3M2qGDzFOJvCWjb32Hv3+DDETrnwBK4JU1sn41U93Jn0kg== X-Received: by 2002:aed:25f2:: with SMTP id y47mr18136996qtc.217.1545154801495; Tue, 18 Dec 2018 09:40:01 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id k189sm307344qkf.64.2018.12.18.09.40.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 09:40:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 18 Dec 2018 12:39:59 -0500 Cc: Job Snijders , Dhruv Dhody , rtg-dir@ietf.org, rtg-ads@ietf.org, SIDR Operations WG , Dhruv Dhody , draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <24C33DA0-54F6-446B-B9BB-8D19AA292CDC@sn3rd.com> References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> To: Randy Bush X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 17:40:05 -0000 > On Dec 18, 2018, at 11:55, Randy Bush wrote: > >>>>> How about: >>>>> >>>>> employees that no longer need access to a router SHOULD >>>>> have their access rights removed for that router to ensure only >>>>> those authorized for that router have access. >>>> >>>> why are we going into ops practice which is not directly relevant? >>> >>> I'd just remove the section about employees, this seems to be going a >>> bit into the weeds. >> >> was polling other authors > > keyur walked up to my desk and agrees with removal. sean? > > randy I am fine with that. spt From nobody Tue Dec 18 15:16:15 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569F8131246 for ; Tue, 18 Dec 2018 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Uzdfvxkuukx5 for ; Tue, 18 Dec 2018 15:16:07 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3258F13123A for ; Tue, 18 Dec 2018 15:16:04 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id y20so20198752qtm.13 for ; Tue, 18 Dec 2018 15:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Z/l0ieqBfHX8UGrUyLnSLc1DV7FgteBoNN8dSMKqCg=; b=cKIA8KJyrg5WCE5Jcl+Aa+yCiQ841FqV7JwWXE5jdmXttmQaOgCjFIDlwv7oP81vQF m3WIVKX31KpKf3D0GvX9x5kritltcldjBGK0YZemcuh1n/sESptFpQr7TDtHMvG/EQ3f aCmfsZgNRM9zd0OoBnJvZfOXz8Z65f+g9z83c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Z/l0ieqBfHX8UGrUyLnSLc1DV7FgteBoNN8dSMKqCg=; b=G9o7THBAxkoHtTo1Jf6JyIlFGbyCHfl4MrpbYwuEdJDUQr8BrUTDwGczyoQgIIIHXO SVmXU4HOrQuKSw6B0A9QIzfpeioqPkyxOd3PYxvmaxqhyNl4cizBNbveDD6BkNofbsN7 OVuPCst2UFxCysmbgyW+kvwCYS2GuvjPfq/aSaxLkUnwfDx2HlUiUkL/SZ6tH8UNYjUf reHGPNyJMBsnkgPhCfjyzLz5RXT22Djz7CtueWalgh7GM50rZI4qPjo9Uw/63KS8DLzQ z/59guqP7DuUhoHN4FSTN4wUNiHTw+wTUQK1Z2i+TLy14Dgq9g1TFHwFT0qJogeBc9ZL oA/A== X-Gm-Message-State: AA+aEWaVAPBqkk0WHKLTqGFMV/YDIX4eLYKW/2N1XXAdndA0Nbwcgs/0 DeJR2I3/HfBqnMLHtUMh5TDm7g== X-Google-Smtp-Source: AFSGD/W0s+2u/QFnHp8/yWu4oG5toLaC8Wj047LKV9gAru7kLa9lT9ohch9eJ2C7H3nLfhrGs6feWg== X-Received: by 2002:ac8:892:: with SMTP id v18mr19241279qth.297.1545174963167; Tue, 18 Dec 2018 15:16:03 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id p3sm1057867qkp.48.2018.12.18.15.16.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 15:16:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 18 Dec 2018 18:16:01 -0500 Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody Content-Transfer-Encoding: quoted-printable Message-Id: <42D52121-9466-44D1-B36B-6E5821B865B8@sn3rd.com> References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> To: Dhruv Dhody X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 23:16:09 -0000 Stay tuned for a new version. spt > On Dec 18, 2018, at 12:46, Dhruv Dhody wrote: >=20 > Hi Sean, Randy, >=20 > Thanks for your patience and taking my comments into consideration. > See inline below - >=20 > On Tue, Dec 18, 2018 at 9:57 PM Sean Turner wrote: >>=20 >> Hi! >>=20 >>> On Dec 14, 2018, at 05:41, Dhruv Dhody wrote: >>>=20 >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this >>> draft. The Routing Directorate seeks to review all routing or >>> routing-related drafts as they pass through IETF last call and IESG >>> review, and sometimes on special request. The purpose of the review = is >>> to provide assistance to the Routing ADs. For more information about >>> the Routing Directorate, please see >>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>=20 >>> Although these comments are primarily for the use of the Routing = ADs, >>> it would be helpful if you could consider them along with any other >>> IETF Last Call comments that you receive, and strive to resolve them >>> through discussion or by updating the draft. >>>=20 >>> Document: draft-ietf-sidrops-rtr-keying-01 >>> Reviewer: Dhruv Dhody >>> Review Date: 14 Dec 2018 >>> IETF LC End Date: Unknown >>> Intended Status: Standard >>>=20 >>> Summary: >>>=20 >>> I have some minor concerns about this document that I think should = be >>> resolved before publication. >>>=20 >>> Comments: >>>=20 >>> This document describe the provisioning of BGPsec-speaking routers = with the >>> appropriate public-private key-pairs. It describes two ways - = Router Driven >>> and Operator Driven of doing this. This document does not provide = any >>> protocol extensions. >>>=20 >>> Thank you for including Appendix B, it helped a lot. >>>=20 >>> Major Issues: >>>=20 >>> No major issues found. >>>=20 >>> Minor Issues: >>>=20 >>> (1) I am not sure about the status of the document. Since this = document >>> does not define any protocol extensions, this document reads to me = as >>> Informational or BCP. I am quite sure this is going to be asked = during IESG >>> reviews, it would be good idea to discuss and conclude on this = early on. >>=20 >> You=E2=80=99re right this doesn=E2=80=99t define any protocol so = standards track might not be the way to go, but it was BCP earlier in = its lifetime. The SIDR WG decided to make it standard track. To be = entirely honest here (and I really hate to be writing this), I could = argue any of the options, but I am really just hoping to be told what it = should be by the IESG. >=20 > [Dhruv]: Lets leave it to the IESG then, and in case other authors > have a preference maybe adding a justification in the writup could > help the reviewers. >=20 >>=20 >>> (2) I also find 'sub-methods' to describe the two different = mechanism (or >>> models) as incorrect. >>=20 >> Would just saying =E2=80=9Ctwo methods=E2=80=9D as opposed to =E2=80=9C= two sub-methods=E2=80=9D work for you? >>=20 >=20 > [Dhruv]: Yes. >=20 >>> Also, did the authors/WG consider making Router-driven as default = and >>> operator-driven to be used with utmost care and only when = router-driven is >>> not possible? >>=20 >> See Randy=E2=80=99s response. I should add that there was at least = one person in the WG who thought that router-drive and operator-driven = were fraught with danger so that=E2=80=99s why we have s8. We basically = couldn=E2=80=99t agree which one was the MTI so we just left it alone = because =E2=80=A6 well see Randy=E2=80=99s response :/ >=20 > [Dhruv]: Thanks for the explanation, I will watch out for what the > IESG thinks about this. >=20 >>=20 >>> (3) Introduction mentions only Section 8, suggest to include some = more text >>> that describes the flow of the document to increase the = readability. >>=20 >> The penultimate paragraph in s1 talks about the rest of the document = and specifically calls out s8 because it=E2=80=99s the one section that = doesn=E2=80=99t quite fit. The rest of the document talks about the = router and operator driven methods and s8 describes another method where = it is more automated. Could we maybe just tweak the last sentence to = say: >>=20 >> Section 8 describes another method that requires more >> capable routers. >>=20 >=20 > [Dhruv]: That helps. Maybe go one step further with - >=20 > Section 2 to Section 7 describes the various steps involved for an = operator > to use the two methods to provision new and existing routers. The = methods > described involve the operator configuring the two end points (i.e., > the management station and the router) and acting as the > intermediary. Section 8 describes another method that requires more > capable routers. >=20 >>> (4) Section 4/5 used AS number and the BGP Identifier; where as = Appendix B >>> says subject name and serial number for the router. We should link = these >>> somehow. >>=20 >> Yes we should; what goes in the subject and serial number field come = from RFC8209 s3.1.1. Let=E2=80=99s change Appendix B to: >>=20 >> But before sending it, you need to also send the CA >> the subject name (i.e., =E2=80=9CROUTER-=E2=80=9C followed by the = AS Number) >> and serial number (i.e., the 32-bit BGP Identifier) for the router. >>=20 >=20 > [Dhruv]: That works great! >=20 >>> (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's = EE >>> certificate(s); This is not clear, is this 'AS's key and = certificate' >>> belongs to the management station? Can you add a sentence = clarifying this. >>=20 >> So what=E2=80=99s going on here is that the operator has generated = the key pair and it needs to get that back to the router. The first = paragraph tells you how to get the private key back with the ability to = verify that the operator actually sent it to the router. The second = paragraph is about verifying the signature on the CMS wrapper that = encapsulates the private key - and to do that you need the operator=E2=80=99= s certificate and any other certificate. I see changing it to = Operator=E2=80=99s EE private key and Operator=E2=80=99s EE certificate = as clarifying this because we don=E2=80=99t use AS EE anywhere else in = the document. >>=20 >=20 > [Dhruv]: AS's EE threw me off, use of Operator's EE makes sense! >=20 >>> (6) It feels like, this document uses SHOULD as a default level. I = am not >>> sure if that is right in every instance of its use. >>>=20 >>> Nits: >>>=20 >>> - section 4 >>> s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be = used/ >>=20 >> sure >>=20 >>> - section 5 >>> s/transmits the AS it has chosen or the router/transmits the AS >>> it has chosen on the router/ >>=20 >> good catch >>=20 >>> - section 7 >>> s/certs-ony/certs-only >>=20 >> ditto >>=20 >>> - section 9 >>> Took me a while to parse this, might be helpful to make a list or >>> rephrase - >>>=20 >>> When an active router key is to be revoked, the process of = requesting >>> the CA to revoke, the process of the CA actually revoking the >>> router's certificate, and then the process of = re-keying/renewing the >>> router's certificate, (possibly distributing a new key and >>> certificate to the router), and distributing the status, = takes time >>> during which the operator must decide how they wish to = maintain >>> continuity of operations, with or without the compromised = private >>> key, or whether they wish to bring the router offline to = address the >>> compromise. >>=20 >> I agree this is pretty wordy, but since you did get through it I am = hoping to relying on the RFC-editor and their excellent copy-editing = skills ;) >>=20 >>> - section 10 >>> Does not parse - >>>=20 >>> ..employees that no longer need access to a >>> routers SHOULD be removed the router to ensure only those = authorized >>> have access to a router. >>=20 >> How about: >>=20 >> employees that no longer need access to a router SHOULD >> have their access rights removed for that router to ensure only >> those authorized for that router have access. >>=20 >=20 > [Dhruv]: Since the consenses seems to be removal of this text, (in > case it matters) thats fine with me as well :) >=20 > Thanks! > Dhruv >=20 >> spt >>=20 From nobody Tue Dec 18 15:50:58 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3D131220; Tue, 18 Dec 2018 15:50:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <154517705406.5565.6284178107402908779@ietfa.amsl.com> Date: Tue, 18 Dec 2018 15:50:54 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 23:50:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidrops-rtr-keying-02.txt Pages : 18 Date : 2018-12-18 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rtr-keying-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 18 15:53:04 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78475131219 for ; Tue, 18 Dec 2018 15:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yZve0PpaFcJO for ; Tue, 18 Dec 2018 15:52:56 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B349413121A for ; Tue, 18 Dec 2018 15:52:54 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id p17so20314753qtl.5 for ; Tue, 18 Dec 2018 15:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YP9pvhHToIBBM/0AzTlB2gT5aRHkaTbwWQ31fcGp/vc=; b=BBCrfjMp3Mv7assURnkuZeFi6zN9AqLDa3SPWfmLOdmfC7Ihx6HdNB2NqZX6XzCSXs hfr+SeegDubfFAWXKy8I15p9votiITDBUha7SElHlwEta+pFnNOHYixCNLLH4Hwc4tmJ Po6dDJEJYLfojJGe0J2hEr8zbQqNwsLWmuBlI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YP9pvhHToIBBM/0AzTlB2gT5aRHkaTbwWQ31fcGp/vc=; b=DzeYVTcbW36auIPJqakRUoC3T/NkRK+gUg7zAj72K+g1Wqt2QapXUeqH1wMEXftl4Q GcLoNhI65GevSvonuvq9H1evAzBTCXZtCy8CxNz5QhSgCsetAOKO8kAvZwM+3lEfLDPK skVv+0g7qAqrSxcmbE89ZwTE3FbbTbHglRfQFxtYn4PJWeZvJNKIB5O8z9OTqwg4V3zR hFTdBIwJ2f8a2tLRPpy68r+Grn8zbt64NmR+mFpR731g8XnJMvKyXQz5cq1L3BueVPPV HVuIpht29hY1TRP+zjBMLJxUfMN87ObNGDRUY3e/GIdquckoygTVxrQlJ2og0CuYTp2A jcjQ== X-Gm-Message-State: AA+aEWY+oO8IZ7cIRsD+f4YA4JRvCMdU9EQNXZYRgRn/TqBz0DxvgbFA k4bw3mSWA3ziNiGrq+xA2LC+a0ahn5Q= X-Google-Smtp-Source: AFSGD/VC2Dor628s8NbniHBx2JCaMWaeZJqHNh6oLoNHGN89dKsd5D/q0k5QS4SWyEXPEWVW10q+2A== X-Received: by 2002:aed:3784:: with SMTP id j4mr19298795qtb.50.1545177173551; Tue, 18 Dec 2018 15:52:53 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id o25sm1101375qtj.10.2018.12.18.15.52.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 15:52:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154517705406.5565.6284178107402908779@ietfa.amsl.com> Date: Tue, 18 Dec 2018 18:52:52 -0500 Cc: rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, rtg-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154517705406.5565.6284178107402908779@ietfa.amsl.com> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 23:52:59 -0000 This version address=E2=80=99s Dhruv Routing Directorate review = comments. spt > On Dec 18, 2018, at 18:50, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidrops-rtr-keying-02.txt > Pages : 18 > Date : 2018-12-18 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys in order = to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two = methods > of generating the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-02 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rtr-keying-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 18 21:18:02 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB573130F81; Tue, 18 Dec 2018 21:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 atuy6-bQZp5s; Tue, 18 Dec 2018 21:17:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C841276D0; Tue, 18 Dec 2018 21:17:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A9C8CB80D59; Tue, 18 Dec 2018 21:17:18 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidrops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20181219051718.A9C8CB80D59@rfc-editor.org> Date: Tue, 18 Dec 2018 21:17:18 -0800 (PST) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8488_on_RIPE_NCC=27s_Implementation_of_R?= =?utf-8?q?esource_Public_Key_Infrastructure_=28RPKI=29_Certificate_Tree_V?= =?utf-8?q?alidation?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 05:17:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8488 Title: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation Author: O. Muravskiy, T. Bruijnzeels Status: Informational Stream: IETF Date: December 2018 Mailbox: oleg@ripe.net, tim@nlnetlabs.nl Pages: 17 Characters: 35434 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidrops-rpki-tree-validation-03.txt URL: https://www.rfc-editor.org/info/rfc8488 DOI: 10.17487/RFC8488 This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both. This document is a product of the SIDR Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 20 07:02:57 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0621B130E11 for ; Thu, 20 Dec 2018 07:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2va3qfhK-EGX for ; Thu, 20 Dec 2018 07:02:52 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6778D1271FF for ; Thu, 20 Dec 2018 07:02:51 -0800 (PST) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id ADF4E25885 for ; Thu, 20 Dec 2018 16:02:48 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Date: Thu, 20 Dec 2018 16:02:48 +0100 From: Martin Hoffmann Cc: SIDR Operations WG Message-ID: <20181220160248.204fa146@glaurung.nlnetlabs.nl> In-Reply-To: <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 15:02:55 -0000 Tim Bruijnzeels wrote: > On 17 Dec 2018, at 17:14, Job Snijders wrote: > >=20 > > Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we > > are the IETF =20 >=20 > So, the machines will most likely ignore this anyway. I guess that > UTF-8 should be okay, provided we restrict the allowed line breaks to > or for these lines as well. So maybe rephrase: >=20 > Current: >=20 > 1. an optional comment section consisting of one or more lines > starting with the '#' character, containing human readable > informational ASCII text, followed by an empty line using a > "" or "" line break only. >=20 > New: >=20 > 1. an optional comment section consisting of one or more lines > starting with the '#' character, containing human readable > informational UTF-8 text, and ending with a "" or=20 > "" line break. Followed by an empty line using a > "" or "" line break only. I don=E2=80=99t quite see why the empty line after the comment is necessary= at all. Since all the comment lines start with a hash, the end of the comment section can be identified by the first line not starting with a hash. Kind regards, Martin From nobody Thu Dec 20 19:43:21 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2DA13112D; Fri, 14 Dec 2018 02:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hpbPYnbtWzS2; Fri, 14 Dec 2018 02:41:34 -0800 (PST) Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6071310EF; Fri, 14 Dec 2018 02:41:34 -0800 (PST) Received: by mail-it1-x12a.google.com with SMTP id a6so8601485itl.4; Fri, 14 Dec 2018 02:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=U/u3MZGAWqIMVyPQ/xGfUqe6wO1VOnfjslS+zlrQUVY=; b=IrunAQkUl/MChr6BpV3+RE2XPed/rPqf2DvaOjVRDbFgclObqmfyLaEzfwQiSeSk86 8EEbL0PP0N0b02jxXCmhEeJOCX74/82K54C043j54apOKf0b5I9xYz+QerEmbJj9X4oW R1j5UqMsziy1/s5b/OtuhauN1RjMWs0uQTuEp/pZINNaXAizRLKtMsT0A2oJTjrPLWpH d0TQEaqGCczSSeNnFaI/6SW0scI2OTLICt/KAdMf/RzcBoFzJPcH/eQ+oY9Ug1rKon8X zMdVfrllGyHrcaei4mtHnDoChKbeLJSuXjreLu63tLvizJKuATb28yl+3/INeeWwPqOL JscQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=U/u3MZGAWqIMVyPQ/xGfUqe6wO1VOnfjslS+zlrQUVY=; b=fq7UyqjynuC3z0MMtxjsb4lMm1ImZy2cADAp6FRbwGuURPj57/LfBVwS38keCwhjoU PwD4tMXSMvg1v9jnjATdWqOeinWYhp0mxt8x87ezbwpsNPbDURPc8RFnYz6OH1rUYrrt k4aPaAyCnAFAfUM22eeGEn1jELnTMMSbERcuLJHMnXt+J+M9vcmr9dmXye4OiGCgxThu 6vfZyY/G8DOL75vv4kQwk3UtY7rusWlTGY79/1SmOIcGwB6/w/ESBFBh4XHaIeLJ3EAG Ozfpxk4xF+29crc6Lifl8CB5tUs15JMS7jZQTHODqQa+xY8IJehqIaQ1VGTZAFYkiOnz 9ZYA== X-Gm-Message-State: AA+aEWapFWIi3kfFa+nyRIxNoaE8QjDQ2eO8wCBbycttqNJhcIXvOAvd FsIwBvL3DxpzopHv83BQhN6LeJj8l7ll/xJ51x4W+2Up1hE= X-Google-Smtp-Source: AFSGD/X8l4mBoOXKlk8yLu7VYOcxGcXnYK8sRdjpy9Kv79JQ1mtsC/WaZ0wUYSDAsqEgFdFv5jWKUl3fWWx/xxShuPA= X-Received: by 2002:a02:570d:: with SMTP id u13mr2042083jaa.71.1544784093354; Fri, 14 Dec 2018 02:41:33 -0800 (PST) MIME-Version: 1.0 From: Dhruv Dhody Date: Fri, 14 Dec 2018 16:11:22 +0530 Message-ID: To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Thu, 20 Dec 2018 19:43:20 -0800 Subject: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 10:41:43 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-sidrops-rtr-keying-01 Reviewer: Dhruv Dhody Review Date: 14 Dec 2018 IETF LC End Date: Unknown Intended Status: Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document describe the provisioning of BGPsec-speaking routers with the appropriate public-private key-pairs. It describes two ways - Router Driven and Operator Driven of doing this. This document does not provide any protocol extensions. Thank you for including Appendix B, it helped a lot. Major Issues: No major issues found. Minor Issues: (1) I am not sure about the status of the document. Since this document does not define any protocol extensions, this document reads to me as Informational or BCP. I am quite sure this is going to be asked during IESG reviews, it would be good idea to discuss and conclude on this early on. (2) I also find 'sub-methods' to describe the two different mechanism (or models) as incorrect. Also, did the authors/WG consider making Router-driven as default and operator-driven to be used with utmost care and only when router-driven is not possible? (3) Introduction mentions only Section 8, suggest to include some more text that describes the flow of the document to increase the readability. (4) Section 4/5 used AS number and the BGP Identifier; where as Appendix B says subject name and serial number for the router. We should link these somehow. (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's EE certificate(s); This is not clear, is this 'AS's key and certificate' belongs to the management station? Can you add a sentence clarifying this. (6) It feels like, this document uses SHOULD as a default level. I am not sure if that is right in every instance of its use. Nits: - section 4 s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be used/ - section 5 s/transmits the AS it has chosen or the router/transmits the AS it has chosen on the router/ - section 7 s/certs-ony/certs-only - section 9 Took me a while to parse this, might be helpful to make a list or rephrase - When an active router key is to be revoked, the process of requesting the CA to revoke, the process of the CA actually revoking the router's certificate, and then the process of re-keying/renewing the router's certificate, (possibly distributing a new key and certificate to the router), and distributing the status, takes time during which the operator must decide how they wish to maintain continuity of operations, with or without the compromised private key, or whether they wish to bring the router offline to address the compromise. - section 10 Does not parse - ..employees that no longer need access to a routers SHOULD be removed the router to ensure only those authorized have access to a router. From nobody Thu Dec 20 19:43:26 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9280E131186; Tue, 18 Dec 2018 09:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EAQE18ubE3bf; Tue, 18 Dec 2018 09:46:40 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5ED7131185; Tue, 18 Dec 2018 09:46:40 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id b5so5444695iti.2; Tue, 18 Dec 2018 09:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y3TOEGoGxttZLsQ4Kj4uhnKypVSDm7S+5BWmqimqEYs=; b=BuGV579TmQQSFYRVDtzRxWvqYiIycEDpxSf8LN/Q0gl36eQMyKQrJJbp575mU++fbw EDmVEZEOkGkxWQNR40sWakWJwOJlDjhSljdTYqvnWMt0Hq+nKnEkKqu1T4vtrvCUvRjv W2oJYPgShNxsjQzD1SO+Pt02YszInH70641udxN5xzQ8b9o/3p+C3qBbBLV7QrpzjrIi FsQPkaJ7XnRDnjzOcFvxhbQgxVzFFpE/0dv3ty5ZlS2kDq1jc7otlhJ2eqjjg61mG9qf zdQqBdBbiUB1wRCaob4UcrF4lQpEeObJ+nFoQhN+b5rDn6mbfebqMVFtYP1dBf0rUhiN rJKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y3TOEGoGxttZLsQ4Kj4uhnKypVSDm7S+5BWmqimqEYs=; b=oE2ujGxleN+gTxH9KccS8UjXnwbJFuiTxeHayjspUnh2zY5wAGJHe6t0YT3aA82xza LaALKnotln/1XO89S0mnNDg83h7wLGUl02TpsXsQ2dBUGQCHjRYv78ChZSLl+bPy9QkJ Jl+ngnOQQnM8mPqneDrRnPlE1iBArItqwM2SG91Bfl4ubmvtz3nf1+vyj91Y8IsBjtXE f3MGfhSC9+mAFh97Pzqv3tCjRkP2ewAHHVxWDtrjSlo9RfJTiOttCF2bgB/HnOwPgvzH iamMyA+yvZi4ayE2CHSxbUMaOqzHmGTgRPHhcacPnj3tbYenUEiywl3cNPfvLltWmMC+ 2Kzw== X-Gm-Message-State: AA+aEWY1auE2PpBgoFiXxvotXAVx5inksIo8qNHj8FtwaN+tN7P3lnSd ga5SqqYeTEdhpqQwy/VzxQVzuj1uJPDc3eEJe/9TC4OF6sU= X-Google-Smtp-Source: AFSGD/W7vWlQZEggxwxEN5YUvHN6/PdFADmRPCjzt6rT42W9dtUh416n4lwkYPUCVESBcMnI8OebOojfMjb1naOaNpQ= X-Received: by 2002:a02:570d:: with SMTP id u13mr16343867jaa.71.1545155199735; Tue, 18 Dec 2018 09:46:39 -0800 (PST) MIME-Version: 1.0 References: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> In-Reply-To: <687EE83A-5A88-4836-99E4-7425FE8FF964@sn3rd.com> From: Dhruv Dhody Date: Tue, 18 Dec 2018 23:16:28 +0530 Message-ID: To: sean@sn3rd.com Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, Dhruv Dhody Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 20 Dec 2018 19:43:20 -0800 Subject: Re: [Sidrops] RtgDir review: draft-ietf-sidrops-rtr-keying-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 17:46:44 -0000 Hi Sean, Randy, Thanks for your patience and taking my comments into consideration. See inline below - On Tue, Dec 18, 2018 at 9:57 PM Sean Turner wrote: > > Hi! > > > On Dec 14, 2018, at 05:41, Dhruv Dhody wrote: > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > > draft. The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review is > > to provide assistance to the Routing ADs. For more information about > > the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: draft-ietf-sidrops-rtr-keying-01 > > Reviewer: Dhruv Dhody > > Review Date: 14 Dec 2018 > > IETF LC End Date: Unknown > > Intended Status: Standard > > > > Summary: > > > > I have some minor concerns about this document that I think should be > > resolved before publication. > > > > Comments: > > > > This document describe the provisioning of BGPsec-speaking routers wi= th the > > appropriate public-private key-pairs. It describes two ways - Router = Driven > > and Operator Driven of doing this. This document does not provide any > > protocol extensions. > > > > Thank you for including Appendix B, it helped a lot. > > > > Major Issues: > > > > No major issues found. > > > > Minor Issues: > > > > (1) I am not sure about the status of the document. Since this docume= nt > > does not define any protocol extensions, this document reads to me as > > Informational or BCP. I am quite sure this is going to be asked durin= g IESG > > reviews, it would be good idea to discuss and conclude on this early = on. > > You=E2=80=99re right this doesn=E2=80=99t define any protocol so standard= s track might not be the way to go, but it was BCP earlier in its lifetime.= The SIDR WG decided to make it standard track. To be entirely honest her= e (and I really hate to be writing this), I could argue any of the options,= but I am really just hoping to be told what it should be by the IESG. [Dhruv]: Lets leave it to the IESG then, and in case other authors have a preference maybe adding a justification in the writup could help the reviewers. > > > (2) I also find 'sub-methods' to describe the two different mechanism= (or > > models) as incorrect. > > Would just saying =E2=80=9Ctwo methods=E2=80=9D as opposed to =E2=80=9Ctw= o sub-methods=E2=80=9D work for you? > [Dhruv]: Yes. > > Also, did the authors/WG consider making Router-driven as default and > > operator-driven to be used with utmost care and only when router-driv= en is > > not possible? > > See Randy=E2=80=99s response. I should add that there was at least one p= erson in the WG who thought that router-drive and operator-driven were frau= ght with danger so that=E2=80=99s why we have s8. We basically couldn=E2=80= =99t agree which one was the MTI so we just left it alone because =E2=80=A6= well see Randy=E2=80=99s response :/ [Dhruv]: Thanks for the explanation, I will watch out for what the IESG thinks about this. > > > (3) Introduction mentions only Section 8, suggest to include some mor= e text > > that describes the flow of the document to increase the readability. > > The penultimate paragraph in s1 talks about the rest of the document and = specifically calls out s8 because it=E2=80=99s the one section that doesn= =E2=80=99t quite fit. The rest of the document talks about the router and = operator driven methods and s8 describes another method where it is more au= tomated. Could we maybe just tweak the last sentence to say: > > Section 8 describes another method that requires more > capable routers. > [Dhruv]: That helps. Maybe go one step further with - Section 2 to Section 7 describes the various steps involved for an opera= tor to use the two methods to provision new and existing routers. The metho= ds described involve the operator configuring the two end points (i.e., the management station and the router) and acting as the intermediary. Section 8 describes another method that requires more capable routers. > > (4) Section 4/5 used AS number and the BGP Identifier; where as Appen= dix B > > says subject name and serial number for the router. We should link th= ese > > somehow. > > Yes we should; what goes in the subject and serial number field come from= RFC8209 s3.1.1. Let=E2=80=99s change Appendix B to: > > But before sending it, you need to also send the CA > the subject name (i.e., =E2=80=9CROUTER-=E2=80=9C followed by the AS N= umber) > and serial number (i.e., the 32-bit BGP Identifier) for the router. > [Dhruv]: That works great! > > (5) Section 5.2.1 has 'AS's End Entity (EE) private key' and AS's EE > > certificate(s); This is not clear, is this 'AS's key and certificate' > > belongs to the management station? Can you add a sentence clarifying = this. > > So what=E2=80=99s going on here is that the operator has generated the ke= y pair and it needs to get that back to the router. The first paragraph te= lls you how to get the private key back with the ability to verify that the= operator actually sent it to the router. The second paragraph is about ve= rifying the signature on the CMS wrapper that encapsulates the private key = - and to do that you need the operator=E2=80=99s certificate and any other = certificate. I see changing it to Operator=E2=80=99s EE private key and Op= erator=E2=80=99s EE certificate as clarifying this because we don=E2=80=99t= use AS EE anywhere else in the document. > [Dhruv]: AS's EE threw me off, use of Operator's EE makes sense! > > (6) It feels like, this document uses SHOULD as a default level. I am= not > > sure if that is right in every instance of its use. > > > > Nits: > > > > - section 4 > > s/a BGP Identifier of 0 may be used/a BGP Identifier of 0 MAY be us= ed/ > > sure > > > - section 5 > > s/transmits the AS it has chosen or the router/transmits the AS > > it has chosen on the router/ > > good catch > > > - section 7 > > s/certs-ony/certs-only > > ditto > > > - section 9 > > Took me a while to parse this, might be helpful to make a list or > > rephrase - > > > > When an active router key is to be revoked, the process of requ= esting > > the CA to revoke, the process of the CA actually revoking the > > router's certificate, and then the process of re-keying/renewin= g the > > router's certificate, (possibly distributing a new key and > > certificate to the router), and distributing the status, takes = time > > during which the operator must decide how they wish to maintain > > continuity of operations, with or without the compromised priva= te > > key, or whether they wish to bring the router offline to addres= s the > > compromise. > > I agree this is pretty wordy, but since you did get through it I am hopin= g to relying on the RFC-editor and their excellent copy-editing skills ;) > > > - section 10 > > Does not parse - > > > > ..employees that no longer need access to a > > routers SHOULD be removed the router to ensure only those autho= rized > > have access to a router. > > How about: > > employees that no longer need access to a router SHOULD > have their access rights removed for that router to ensure only > those authorized for that router have access. > [Dhruv]: Since the consenses seems to be removal of this text, (in case it matters) thats fine with me as well :) Thanks! Dhruv > spt > From nobody Wed Dec 26 06:25:47 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B461E130FED; Wed, 26 Dec 2018 06:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 v-iQLeJfRHL9; Wed, 26 Dec 2018 06:25:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2E1130FEC; Wed, 26 Dec 2018 06:25:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gcA7i-0005x1-13; Wed, 26 Dec 2018 14:25:26 +0000 Date: Wed, 26 Dec 2018 09:25:25 -0500 Message-ID: From: Randy Bush To: Scott Bradner Cc: ops-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Rinse Repeat In-Reply-To: <154582975877.9431.8940530526143232465@ietfa.amsl.com> References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 14:25:32 -0000 mornin=A2 scott, > it is hard to see why it should be standards track or why it should=20 > be using RFC 2119 type terminology. these are two separate issues. =20 alvaro and the chairs can adjudicate what flavor of ice cream it should be. it my memory says it was a wg decision. i really do not care. as to 2119 language, i kinda feel it should remain. it is used sparingly. but is crucial when used. e.g. all private keys MUST be protected when at rest in a secure fashion. i suspect we would want to keep that strongly prescriptive; but it is not a hill on which i am interested in dying. randy From nobody Wed Dec 26 07:12:55 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24240130E02; Wed, 26 Dec 2018 07:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 g8dokgvVzjox; Wed, 26 Dec 2018 07:12:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039B3130DFE; Wed, 26 Dec 2018 07:12:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gcArP-00063f-J8; Wed, 26 Dec 2018 15:12:39 +0000 Date: Wed, 26 Dec 2018 10:12:39 -0500 Message-ID: From: Randy Bush To: Scott Bradner Cc: ops-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Rinse Repeat In-Reply-To: References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 15:12:42 -0000 >> all private keys MUST be protected when at rest in a secure >> fashion. > that use of a MUST is commendable but its not exactly an > interoperability issue is The operator MUST ensure that the installed CA certificate is valid. an interop issue? this is an opsec doc; not protocol on the wire. hence its MUSTs are security and operational prudence. but enough already. randy From nobody Wed Dec 26 08:27:24 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3E130FDC; Wed, 26 Dec 2018 05:09:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Scott Bradner To: Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154582975877.9431.8940530526143232465@ietfa.amsl.com> Date: Wed, 26 Dec 2018 05:09:18 -0800 Archived-At: X-Mailman-Approved-At: Wed, 26 Dec 2018 08:27:21 -0800 Subject: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 13:09:19 -0000 Reviewer: Scott Bradner Review result: Serious Issues This is an OPSDIR review of Router Keying for BGPsec (draft-ietf-sidrops-rtr-keying). This seems like a useful document but it is hard to see why it should be standards track or why it should be using RFC 2119 type terminology. Standards track should be reserved for technology specifications where interoperability is an issue. I do not see interoperability issues being addressed in this document since it focuses on how to create keys rather than the features of keys that might be important for interoperability. (as an aside, if this document were adopted on the standards track how would it ever demonstrate interoperability to progress?) This seems much more of an informational document to me and not even a BCP since the practices it describes do not meet what I consider to be BCP material (see RFC 2026 section 5) The same issue arises with the use of RFC 2119 type terminology – RFC 2119 terminology is only to be used where interoperability is an issue – see RF 2119 section 6: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I did not discover any issues worth mentioning with the document if it is viewed as operational guidance. Scott From nobody Wed Dec 26 08:27:31 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE46F131026; Wed, 26 Dec 2018 06:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.393 X-Spam-Level: X-Spam-Status: No, score=0.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 A9nbzvrvITCu; Wed, 26 Dec 2018 06:51:29 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id C6249131010; Wed, 26 Dec 2018 06:51:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id ADDD44E2F36; Wed, 26 Dec 2018 09:51:27 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbGo1DDvk9HH; Wed, 26 Dec 2018 09:51:27 -0500 (EST) Received: from [172.19.248.92] (unknown [104.153.224.168]) by sobco.sobco.com (Postfix) with ESMTPSA id F147B4E2F21; Wed, 26 Dec 2018 09:51:21 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Scott Bradner In-Reply-To: Date: Wed, 26 Dec 2018 09:51:06 -0500 Cc: ops-dir@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Rinse Repeat Content-Transfer-Encoding: quoted-printable Message-Id: References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-Mailman-Approved-At: Wed, 26 Dec 2018 08:27:21 -0800 Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 14:51:40 -0000 that use of a MUST is commendable but its not exactly an = interoperability issue=20 to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in = this document) but, that said, 2119 has been misused for kinda a long time so its not a = new sin Scott > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: >=20 > mornin=E2=80=99 scott, >=20 >> it is hard to see why it should be standards track or why it should=20= >> be using RFC 2119 type terminology. >=20 > these are two separate issues. =20 >=20 > alvaro and the chairs can adjudicate what flavor of ice cream it = should > be. it my memory says it was a wg decision. i really do not care. >=20 > as to 2119 language, i kinda feel it should remain. it is used > sparingly. but is crucial when used. e.g. >=20 > all private keys MUST be protected when at rest in a secure > fashion. >=20 > i suspect we would want to keep that strongly prescriptive; but it is > not a hill on which i am interested in dying. >=20 > randy From nobody Wed Dec 26 08:27:37 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB67130E39 for ; Wed, 26 Dec 2018 08:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 ROZV0DpGumhM for ; Wed, 26 Dec 2018 08:11:44 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8E1130E04 for ; Wed, 26 Dec 2018 08:11:43 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id x10so15993734wrs.8 for ; Wed, 26 Dec 2018 08:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YKVf69+bv3XPhUD+qGoUnRQ4vwojsj5mlc+lZRkur7A=; b=lFiav7VdfR1FAsdY6C2FauERrIOrvQ/ndYxZn2X9yhMnV+FXF0jk8iptECVsHLTJFq qNmdOmcVSghTwikTel9ftfAn3hJgrvfx7NTww00kexqi8a/icin0tAOmk+AhyT/7MbSp RmtSXtcANIDAgMFsyavGj6bzCIt2rLomB0r7vE/CS7p7IJeVbyc5xQCk1kGtmPtvILiG jlysKxsaYYi0SphSNi3MhIubWYe7+wnEzdNRwj1hGiO93lvXFVLrTRTm7xljDh1BQciL ZZHTy1RCNI9j2D1UboVXnWqz22Wr2HD6RmWaqXLuK2eI/F8MDb0hbmRZUzal4fZ0hiJ6 4ejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YKVf69+bv3XPhUD+qGoUnRQ4vwojsj5mlc+lZRkur7A=; b=nFdyp2FQ2+LPyo/uKlY2LeQrBg8K27cSX/AzqxzJeywZT+FDxEFn2TUI7yHmDxO0tK fR80OziWWAA1c74jiG7f/JIQ/JKEmF3Mjr1vlTM1p1LwrU8DT/55JvBgzfgUeorwZeSg Yh2hpLG9yIvwnik+qnfG0MPNrgtNflEp08hCl/zC4BHeKVg1/hO8JZVeVKe3pnvm1ijU B/B9lZrrH0EtKg7/7WriIBLZEJz4aANItNwwdxfeqekinFCdWcSgHfGAl8yjvi+mYOYw m9zBh28u8BTK5pFqclVrMp2NXGliG7m4OXy3M93+atyEzqeDfWds5d9yKhDqaGIuQOT7 uxOA== X-Gm-Message-State: AJcUukdAvrqgztLWhI8MM+DMtslbAZMUFQRT2jRUGTZd5YI6w2LxDNlu kBKVHtN1dluYSLN/P5ElOz/EBrZo3XeBNVAsQJPgKVoXL+atcw== X-Google-Smtp-Source: ALg8bN4TBcJelFq7DHeOAaT0tPCguHbmCwu3F2ePfICmIcGI8+2Hqz9jjqy8oqSyL8SiKh7XY0Z0W97pXbxRm3PLga4= X-Received: by 2002:adf:fa90:: with SMTP id h16mr20215238wrr.326.1545840701949; Wed, 26 Dec 2018 08:11:41 -0800 (PST) MIME-Version: 1.0 References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Wed, 26 Dec 2018 11:11:05 -0500 Message-ID: To: Scott Bradner Cc: Randy Bush , ops-dir , draft-ietf-sidrops-rtr-keying.all@ietf.org, sidrops@ietf.org, IETF Discuss , Sandra Murphy , Alvaro Retana , sidr@ietf.org, SIDROps Chairs Content-Type: multipart/alternative; boundary="000000000000eb5e30057def15d8" Archived-At: X-Mailman-Approved-At: Wed, 26 Dec 2018 08:27:21 -0800 Subject: Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 16:11:48 -0000 --000000000000eb5e30057def15d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ + Sandy, Alvaro ] On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > that use of a MUST is commendable but its not exactly an interoperability > issue > > to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in t= his document) > > but, that said, 2119 has been misused for kinda a long time so its not a > new sin > > This document has a long history -- it was originally a product of the SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to SIDROPS recently, when SIDR closed down ( https://datatracker.ietf.org/wg/sidr/about/). The document was originally a BCP ( https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was changed to Standards Track in -10 ( https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). I have gone back through the agenda and minutes for IETF 92 ( https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 ( https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 ( https://datatracker.ietf.org/doc/agenda-94-sidr/). I also went back and watched the video recordings from IETF 94: https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any discussio= n of why the change was made, but I *was* able to find some changes made between -09 and -10 which seem to be the outcome of those discussions. Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the track change was made? Whatever the case, the IETF LC was done as Standards Track (a higher level), and so it could always be "downgraded" to BCP / informational during IESG Eval. I personally think it "feels" like BCP, but I don't have full history / inherited the document and don't want to be arbitrarily making changes. W [0]: SIDROPS and SIDR participant overlap is almost 100%. > Scott > > > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: > > > > mornin=E2=80=99 scott, > > > >> it is hard to see why it should be standards track or why it should > >> be using RFC 2119 type terminology. > > > > these are two separate issues. > > > > alvaro and the chairs can adjudicate what flavor of ice cream it should > > be. it my memory says it was a wg decision. i really do not care. > > > > as to 2119 language, i kinda feel it should remain. it is used > > sparingly. but is crucial when used. e.g. > > > > all private keys MUST be protected when at rest in a secure > > fashion. > > > > i suspect we would want to keep that strongly prescriptive; but it is > > not a hill on which i am interested in dying. > > > > randy > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000eb5e30057def15d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[= =C2=A0+ Sandy, Alvaro ]

On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner <sob@sobco.com> wrote:
that use of a MUST is commendable but its not exactl= y an interoperability issue

to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in thi= s document)

but, that said, 2119 has been misused for kinda a long time so its not a ne= w sin


This document has a long history -- it was = originally a product of the SIDR Working Group (as draft-ietf-sidr-rtr-keyi= ng), and only moved over to SIDROPS recently, when SIDR closed down (https://datatracker.ietf.= org/wg/sidr/about/).

The document was originally a BCP (https://d= atatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was change= d to Standards Track in -10 (https://www.ietf.org/archive/id/draft-ietf-= sidr-rtr-keying-10.txt).


I have gone back through the agend= a and minutes for IETF 92 (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93= (https://data= tracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 (https://datatracker.ietf.org/doc/a= genda-94-sidr/).=C2=A0
I also went back and watched the video recording= s from IETF 94:=C2=A0http= s://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any discu= ssion of why the change was made, but I *was* able to find some changes mad= e between -09 and -10 which seem to be the outcome of those discussions.=C2= =A0

Authors / SIDROPS [0] & SIDR / chairs -=C2=A0 can y'all re= member why the track change was made?=C2=A0

=
Whate= ver the case, the IETF LC was done as Standards Track (a higher level), and= so it could always be "downgraded" to BCP / informational during= IESG Eval.
I personally think it "feels" like BCP, b= ut I don't have full history / inherited the document and don't wan= t to be arbitrarily making changes.


W
[0]: SIDROPS and SIDR participant overlap is almost 100%.


=C2=A0
Scott

> On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
>
> mornin=E2=80=99 scott,
>
>> it is hard to see why it should be standards track or why it shoul= d
>> be using RFC 2119 type terminology.
>
> these are two separate issues.=C2=A0
>
> alvaro and the chairs can adjudicate what flavor of ice cream it shoul= d
> be.=C2=A0 it my memory says it was a wg decision.=C2=A0 i really do no= t care.
>
> as to 2119 language, i kinda feel it should remain.=C2=A0 it is used > sparingly. but is crucial when used.=C2=A0 e.g.
>
>=C2=A0 =C2=A0 =C2=A0 all private keys MUST be protected when at rest in= a secure
>=C2=A0 =C2=A0 =C2=A0 fashion.
>
> i suspect we would want to keep that strongly prescriptive; but it is<= br> > not a hill on which i am interested in dying.
>
> randy



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000eb5e30057def15d8-- From nobody Wed Dec 26 08:30:06 2018 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA65131012; Wed, 26 Dec 2018 08:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jWllux0lU-1p; Wed, 26 Dec 2018 08:29:41 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D99B130E06; Wed, 26 Dec 2018 08:29:41 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id h65so20715007ith.3; Wed, 26 Dec 2018 08:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FrhKyEbKNZyaQ7Y7w0ZEiIiKhWWqI5D0dZSGpJmiB0Q=; b=QxQzUQeQ9G1kChZYHmowdVegl64Yf0/KqhTxxiGw1p4mFgY267vrf5IY0h08m4RUTn Z5M8EpV65YrneDALiIdIVEQ+Py0PBJRl0IddrhiykWTPhP3Qw1oxUXLlgbtA2LUIfEcj CmQBBKgK6NQLSTk3DACMwblAcb/Upm6kELwxKlPJGdUpZF8lDwNBkczaJ3Z61gmT6Q4T QKvyaRyxQcpZm7Q+BpwfEsN3AeNxKx9LeWEE8Jrrv1RVH3ZCSAVLYOra0JJ5X1pWEx91 rTn1kCcw8AlVYztlUhnYSkOnaocziI8VrOFjgzMgpYj+fiSYlMNzk0Nr0fPVSHNqJ9SO gUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FrhKyEbKNZyaQ7Y7w0ZEiIiKhWWqI5D0dZSGpJmiB0Q=; b=qplmmfpQt7O/mpXz2VuA8kLr40H7tPCJam83JkRT7kHSSrSEApAVAsaUCW/9TNaAwO 1dClWc/oSi/DhQaBRSvIlzq6Fhzyy3F0bnwDvhy9kyxCjyzKGWWWCYscXwjbesEzuThv MuxepztJKab3w3biGcbsOn+DL5qD+q2/3AfkrhfTYQ70Vsb8/iRp9molTeB8EXyO4BPw sSpsRFg0eZ9DTE1Om4oqbL2d79hc4KZcX4NMuqB5FGN7XTaE4arC4XFVSdLQ7JKaGWbC XQxTEvTdeX9q9Luy1TaIEe2vzgEZJQedIWD7AjLFjZBTGYDKCwiZSQhhpkk0UQnGghpP mjvw== X-Gm-Message-State: AA+aEWZbJBZvFXlo87RAVumz0rdQg0h40GmPR9PjnWmE6RxqN6lBxhVV 4lPwg4Z/oGKP5EKo4wRTe1esofB8iJxI/j8ey0nHcA== X-Google-Smtp-Source: AFSGD/Vt1h8JaUAUHt2qy/7Q33vyZIAvWkuUsmVk0oSlwtW2DJ0LsTe5CLSjJ4OH+hFC2J8qTfNLhL8AU1v4hswCCYQ= X-Received: by 2002:a02:6019:: with SMTP id i25mr13875083jac.137.1545841780581; Wed, 26 Dec 2018 08:29:40 -0800 (PST) MIME-Version: 1.0 References: <154582975877.9431.8940530526143232465@ietfa.amsl.com> In-Reply-To: From: Christopher Morrow Date: Wed, 26 Dec 2018 11:29:29 -0500 Message-ID: To: Warren Kumari Cc: Scott Bradner , SIDROps Chairs , ops-dir , IETF Discuss , sidrops@ietf.org, sidr@ietf.org, draft-ietf-sidrops-rtr-keying.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000035ec01057def5677" Archived-At: Subject: Re: [Sidrops] [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 16:29:44 -0000 --00000000000035ec01057def5677 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BCP seems like a fine answer here, I'm not remembering why we would have swapped to ST from BCP. On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari wrote: > [ + Sandy, Alvaro ] > > On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner wrote: > >> that use of a MUST is commendable but its not exactly an interoperabilit= y >> issue >> >> to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in = this document) >> >> but, that said, 2119 has been misused for kinda a long time so its not a >> new sin >> >> > This document has a long history -- it was originally a product of the > SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over t= o > SIDROPS recently, when SIDR closed down ( > https://datatracker.ietf.org/wg/sidr/about/). > > The document was originally a BCP ( > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was > changed to Standards Track in -10 ( > https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt). > > > I have gone back through the agenda and minutes for IETF 92 ( > https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 ( > https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 ( > https://datatracker.ietf.org/doc/agenda-94-sidr/). > I also went back and watched the video recordings from IETF 94: > https://youtu.be/fElkBi4UMEA?t=3D2397 and wasn't able to find any > discussion of why the change was made, but I *was* able to find some > changes made between -09 and -10 which seem to be the outcome of those > discussions. > > Authors / SIDROPS [0] & SIDR / chairs - can y'all remember why the track > change was made? > > Whatever the case, the IETF LC was done as Standards Track (a higher > level), and so it could always be "downgraded" to BCP / informational > during IESG Eval. > I personally think it "feels" like BCP, but I don't have full history / > inherited the document and don't want to be arbitrarily making changes. > > > W > [0]: SIDROPS and SIDR participant overlap is almost 100%. > > > > >> Scott >> >> > On Dec 26, 2018, at 9:25 AM, Randy Bush wrote: >> > >> > mornin=E2=80=99 scott, >> > >> >> it is hard to see why it should be standards track or why it should >> >> be using RFC 2119 type terminology. >> > >> > these are two separate issues. >> > >> > alvaro and the chairs can adjudicate what flavor of ice cream it shoul= d >> > be. it my memory says it was a wg decision. i really do not care. >> > >> > as to 2119 language, i kinda feel it should remain. it is used >> > sparingly. but is crucial when used. e.g. >> > >> > all private keys MUST be protected when at rest in a secure >> > fashion. >> > >> > i suspect we would want to keep that strongly prescriptive; but it is >> > not a hill on which i am interested in dying. >> > >> > randy >> >> > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --00000000000035ec01057def5677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BCP seems like a fine answer here, I'm not remembering= why we would have swapped to ST from BCP.

On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari <warren@kumari.net> wrote:
[=C2=A0+ Sandy, Alvaro ]
On Wed, Dec 26, 2018 at= 9:51 AM Scott Bradner <sob@sobco.com> wrote:
that use of a MUST is commendable but its not exactly an in= teroperability issue

to me =E2=80=9Cmust=E2=80=9D works in this case (and the other cases in thi= s document)

but, that said, 2119 has been misused for kinda a long time so its not a ne= w sin


This document has a long history -- it was = originally a product of the SIDR Working Group (as draft-ietf-sidr-rtr-keyi= ng), and only moved over to SIDROPS recently, when SIDR closed down (https:/= /datatracker.ietf.org/wg/sidr/about/).

The document was originally= a BCP (https://datatracker.ietf.org/doc/draft-ietf-sidr= -rtr-keying/09/), but was changed to Standards Track in -10 (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.t= xt).


I have gone back through the agenda and minutes for IETF= 92 (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 (https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 (ht= tps://datatracker.ietf.org/doc/agenda-94-sidr/).=C2=A0
I also went bac= k and watched the video recordings from IETF 94:=C2=A0https://youtu.be/fElkBi4UMEA= ?t=3D2397 and wasn't able to find any discussion of why the change = was made, but I *was* able to find some changes made between -09 and -10 wh= ich seem to be the outcome of those discussions.=C2=A0

Authors / SIDRO= PS [0] & SIDR / chairs -=C2=A0 can y'all remember why the track cha= nge was made?=C2=A0

Whatever the case, the IETF L= C was done as Standards Track (a higher level), and so it could always be &= quot;downgraded" to BCP / informational during IESG Eval.
=
= I personally think it "feels" like BCP, but I don't have full= history / inherited the document and don't want to be arbitrarily maki= ng changes.


W
[0]: SIDROPS and SID= R participant overlap is almost 100%.


= =C2=A0
Scott

> On Dec 26, 2018, at 9:25 AM, Randy Bush <randy@psg.com> wrote:
>
> mornin=E2=80=99 scott,
>
>> it is hard to see why it should be standards track or why it shoul= d
>> be using RFC 2119 type terminology.
>
> these are two separate issues.=C2=A0
>
> alvaro and the chairs can adjudicate what flavor of ice cream it shoul= d
> be.=C2=A0 it my memory says it was a wg decision.=C2=A0 i really do no= t care.
>
> as to 2119 language, i kinda feel it should remain.=C2=A0 it is used > sparingly. but is crucial when used.=C2=A0 e.g.
>
>=C2=A0 =C2=A0 =C2=A0 all private keys MUST be protected when at rest in= a secure
>=C2=A0 =C2=A0 =C2=A0 fashion.
>
> i suspect we would want to keep that strongly prescriptive; but it is<= br> > not a hill on which i am interested in dying.
>
> randy



--
I don't think th= e execution is relevant when it was obviously a bad idea in the first place= .
This is like putting rabid weasels in your pants, and later expressing= regret at having chosen those particular rabid weasels and that pair of pa= nts.
=C2=A0 =C2=A0---maf
=
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--00000000000035ec01057def5677--