From nobody Wed Aug 7 08:42:53 2019 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 DC99312040E; Wed, 7 Aug 2019 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=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 paX_nP2j0APh; Wed, 7 Aug 2019 08:42:35 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840130.outbound.protection.outlook.com [40.107.84.130]) (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 C2AAD120450; Wed, 7 Aug 2019 08:42:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V7tYN5H1n4jTkhVszz267/ER1T6pHkj5OjwMVF6XreuxLPqUAOqyI3L2lndo6ALfwXPY1Q2k2amBL8H/XzEQMEXbGrFYrlSZH+QG7XlIQQpNzfPINuNHmyo34pnT/n+Ymx6qxoiPXECgrWIbNbaotCcZtfcFC4nPRFegB3GvRzFSSNhj0U5wSK9G/aIMG3+d21V8WqWNkPnFtQMwK3/g2rc7/P9GLiuQtkwoLoWTmOJNXGPh+vHqrHERdMxNowao+o7Pzq3EQ2QKnjTNZOgRgJw79+Y4WPHy6lPDe/DGPllu0PMacngPhP95bniYSDzZxdtGpuwiK44WZ/X1URri9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=84jnc6QDEXkQ9CIurAB6CRZ0r4WYzRh0byWoZ46d860=; b=UreUV7o23E6VRXnT9TazIeD0MVSWmO/HthjsrEw9qALssf/OOBuGQUD7vJ/0H2XzngRdHgBlDzdz94gr0OWrRcP5iJm+mMWBifRyF1GLsrMo6jMSLcCr+UCtcmv2VgV4zd/qdFPjz0KCEOAGIE5h+75ScABjY6/V3ocSMIkLr0O2T9Ye935bKsBnQnd+6GT2l4PIVUAfM5heejgzcC8A9/pV8s5DWxnTg6q4Pp7/aoeAGuQHF8UNjMr5cDCaeyAjy/EqFfro7zlQOzU8CUl2M254QvxAk0GNPHa4AmylQubcj8ODmg9heIXvfL75qD1wviFSrJDyPfplMEduPCOjvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nist.gov;dmarc=pass action=none header.from=nist.gov;dkim=pass header.d=nist.gov;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=84jnc6QDEXkQ9CIurAB6CRZ0r4WYzRh0byWoZ46d860=; b=KM57RU97QND6t3f9IIxlwFt3NjTke/S4cMWhKs6SmoQa5I8cbqhYsoLnLsflDD9DbnGi3Z9KjT9rwLsT6aoxeKloDBrFpLKh9hmQr5/MuT67fkGC2ULDOnMB3Zeb4O8O3FvodoMBfxB63y8PNwc+XvRaLX1ezQt+YJ4ks7KP/ss= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB3516.namprd09.prod.outlook.com (20.179.52.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.14; Wed, 7 Aug 2019 15:42:34 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 15:42:34 +0000 From: "Sriram, Kotikalapudi (Fed)" To: IDR , GROW WG CC: "sidrops@ietf.org" , "idr-chairs@ietf.org" Thread-Topic: Deprecation of AS_SET and AS_CONFED_SET -- feedback requested Thread-Index: AQHVTTL4B77hNRR7Ck2ALhCdtVXslA== Date: Wed, 7 Aug 2019 15:42:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [173.73.254.145] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40038569-ea4b-4f72-5c0f-08d71b4ddde5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR09MB3516; x-ms-traffictypediagnostic: DM6PR09MB3516: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(366004)(39860400002)(346002)(189003)(199004)(8936002)(66946007)(66556008)(64756008)(66476007)(91956017)(3846002)(86362001)(4744005)(76116006)(33656002)(66446008)(2906002)(81156014)(6506007)(966005)(6116002)(305945005)(8676002)(81166006)(14454004)(7736002)(74316002)(66066001)(9686003)(6436002)(55016002)(54906003)(316002)(99286004)(25786009)(486006)(110136005)(476003)(4326008)(53936002)(102836004)(68736007)(6306002)(7696005)(71200400001)(26005)(4743002)(52536014)(5660300002)(256004)(478600001)(71190400001)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3516; H:DM6PR09MB3019.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 75fVH/RCCgfq12yhr1JA0dDJyrk5fDrACD9VMcgvUV6TvSON5BosgV8sR+zlHn4pTBcxXeOnGMP5Su7ror0m3NTFacsLSIgTsC1pE3UI3fuh41tU7DWQWlC/3J/wfaSakiG6uy1Mv4vZUfb2SORnnx9iqTVZ++JGXLaIdG0PwE9mF18tRASe9SkVJG+bP5RleWKsYTtu/0gKTLT6Mw/isl7MjoYy5ElZfAy51Smz936Lwr7SCrXPMiC101UUNGHsoAwDs/LZ+bz2771UWlaLm5hJyU0EhV37uzZMEjVYQdmOzK4DmJZ8j20TyWKmKgQc0tOml/5Ya35RWcZT2RFeebjeMpKIulUoTng5G6FvkDf/Ya2jvsX4gUOi2HI4GaLUdFqs6lcfOJyiNs58TZtBiE4W4grchdjD7CKz5bEnT48= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 40038569-ea4b-4f72-5c0f-08d71b4ddde5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 15:42:34.3813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Wry4MU3SOSIB7h4Qy/C0v1ZRCZb+VhIPka1scviaziFHjQs+nhi77uoqf7Q/wOK6LOgzu0nRSK4qEXVgSvZhhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3516 Archived-At: Subject: [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested 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, 07 Aug 2019 15:42:38 -0000 There was significant interest expressed during a SIDROPS presentation in M= ontreal and in the discussion that followed at the mike about advancing the followi= ng individual draft: https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14 =20 (standards track) =20 The authors have revised and uploaded a new version (-14). Your inputs/comments are welcome. In particular, please share any specific= =20 operational considerations/concerns you may have regarding this topic. (Note: A BCP was published on this topics in 2011 -- https://tools.ietf.org= /html/rfc6472 ) =20 Thank you. Sriram = From nobody Wed Aug 7 09:00:08 2019 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 CDA9F1205CE; Wed, 7 Aug 2019 08:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 XIFxk1uVJ5It; Wed, 7 Aug 2019 08:59:09 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C741205CD; Wed, 7 Aug 2019 08:59:08 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from [192.168.2.7] (ppp089210015049.access.hol.gr [89.210.15.49]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x77FwroN037920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2019 16:59:04 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host ppp089210015049.access.hol.gr [89.210.15.49] claimed to be [192.168.2.7] To: "Sriram, Kotikalapudi (Fed)" Cc: IDR , GROW WG , "idr-chairs@ietf.org" , "sidrops@ietf.org" References: From: Nick Hilliard Message-ID: <8c7ccdfb-bbcd-baf3-9335-e12f426c80f1@foobar.org> Date: Wed, 7 Aug 2019 18:58:51 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested 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, 07 Aug 2019 15:59:16 -0000 Sriram, Kotikalapudi (Fed) wrote on 07/08/2019 18:42: > The authors have revised and uploaded a new version (-14). > Your inputs/comments are welcome. In particular, please share any specific > operational considerations/concerns you may have regarding this topic. It would be great if this were to progress to standards track RFC. AS_SETs are a nuisance and cause real-world confusion with no appreciable gain. Nick From nobody Wed Aug 7 09:23:44 2019 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 C578012062B; Wed, 7 Aug 2019 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 ib514gnXcdZF; Wed, 7 Aug 2019 09:23:35 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 4EA2612064C; Wed, 7 Aug 2019 09:23:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=97.112.26.170; From: "Susan Hares" To: "'Sriram, Kotikalapudi \(Fed\)'" , "'IDR'" , "'GROW WG'" Cc: , References: In-Reply-To: Date: Wed, 7 Aug 2019 12:23:30 -0400 Message-ID: <01c201d54d3c$74375ee0$5ca61ca0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJ3Gvpsfq5scv306P9AOlHgxlUbL6WsQsmQ X-Antivirus: AVG (VPS 190807-0, 08/07/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Sidrops] [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested 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, 07 Aug 2019 16:23:37 -0000 Sriram: Are you asking for WG Adoption of this draft at this time or just feedback? Sue -----Original Message----- From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi (Fed) Sent: Wednesday, August 7, 2019 11:43 AM To: IDR; GROW WG Cc: idr-chairs@ietf.org; sidrops@ietf.org Subject: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested There was significant interest expressed during a SIDROPS presentation in Montreal and in the discussion that followed at the mike about advancing the following individual draft: https://tools.ietf.org/html/draft-kumari-deprecate-as-set-confed-set-14 (standards track) The authors have revised and uploaded a new version (-14). Your inputs/comments are welcome. In particular, please share any specific operational considerations/concerns you may have regarding this topic. (Note: A BCP was published on this topics in 2011 -- https://tools.ietf.org/html/rfc6472 ) Thank you. Sriram _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow From nobody Wed Aug 7 15:24:44 2019 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 DFFC61200DF; Wed, 7 Aug 2019 15:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 qA_cyS1yDzWn; Wed, 7 Aug 2019 15:24:41 -0700 (PDT) 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 1BD03120047; Wed, 7 Aug 2019 15:24:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 01046B816B6; Wed, 7 Aug 2019 15:24:15 -0700 (PDT) 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: <20190807222416.01046B816B6@rfc-editor.org> Date: Wed, 7 Aug 2019 15:24:15 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?BCP_224=2C_RFC_8634_on_BGPsec_Router_Certifi?= =?utf-8?q?cate_Rollover?= 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, 07 Aug 2019 22:24:43 -0000 A new Request for Comments is now available in online RFC libraries. BCP 224 RFC 8634 Title: BGPsec Router Certificate Rollover Author: B. Weis, R. Gagliano, K. Patel Status: Best Current Practice Stream: IETF Date: August 2019 Mailbox: bew.stds@gmail.com, rogaglia@cisco.com, keyur@arrcus.com Pages: 11 Characters: 26170 See Also: BCP 224 I-D Tag: draft-ietf-sidrops-bgpsec-rollover-04.txt URL: https://www.rfc-editor.org/info/rfc8634 DOI: 10.17487/RFC8634 Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost. This document is a product of the SIDR Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 Wed Aug 7 15:25:04 2019 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 968711206F3; Wed, 7 Aug 2019 15:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 sXyyMFXZ7GsG; Wed, 7 Aug 2019 15:24:49 -0700 (PDT) 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 77EC91206F2; Wed, 7 Aug 2019 15:24:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 654EBB816BF; Wed, 7 Aug 2019 15:24:24 -0700 (PDT) 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: <20190807222424.654EBB816BF@rfc-editor.org> Date: Wed, 7 Aug 2019 15:24:24 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8635_on_Router_Keying_for_BGPsec?= 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, 07 Aug 2019 22:24:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8635 Title: Router Keying for BGPsec Author: R. Bush, S. Turner, K. Patel Status: Standards Track Stream: IETF Date: August 2019 Mailbox: randy@psg.com, sean@sn3rd.com, keyur@arrcus.com Pages: 21 Characters: 48774 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidrops-rtr-keying-06.txt URL: https://www.rfc-editor.org/info/rfc8635 DOI: 10.17487/RFC8635 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 (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven. This document is a product of the SIDR Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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 Fri Aug 9 16:33:53 2019 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 3D2D9120254; Fri, 9 Aug 2019 16:33:44 -0700 (PDT) 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 9CouxkXFHwlr; Fri, 9 Aug 2019 16:33:42 -0700 (PDT) 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 4D8BF1201B7; Fri, 9 Aug 2019 16:33:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3CF46B81F24; Fri, 9 Aug 2019 16:33:15 -0700 (PDT) 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: <20190809233315.3CF46B81F24@rfc-editor.org> Date: Fri, 9 Aug 2019 16:33:15 -0700 (PDT) Archived-At: Subject: [Sidrops] =?utf-8?q?RFC_8630_on_Resource_Public_Key_Infrastructu?= =?utf-8?q?re_=28RPKI=29_Trust_Anchor_Locator?= 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, 09 Aug 2019 23:33:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8630 Title: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator Author: G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels Status: Standards Track Stream: IETF Date: August 2019 Mailbox: gih@apnic.net, weiler@csail.mit.edu, ggm@apnic.net, kent@alum.mit.edu, tim@nlnetlabs.nl Pages: 11 Characters: 24173 Obsoletes: RFC 7730 I-D Tag: draft-ietf-sidrops-https-tal-08.txt URL: https://www.rfc-editor.org/info/rfc8630 DOI: 10.17487/RFC8630 This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate. This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme. This document is a product of the SIDR Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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 Mon Aug 19 14:09:19 2019 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 E8D121200CD; Mon, 19 Aug 2019 14:09:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156624895394.19892.16437061604284771584.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 14:09:13 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 106 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, 19 Aug 2019 21:09:18 -0000 A new meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 62 Conflicts to Avoid: Chair Conflict: idr grow lsvr rtgwg lsr mpls pim spring 6man People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Aug 20 02:08:57 2019 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 A96E1120072 for ; Tue, 20 Aug 2019 02:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 DFdkYPvGRpYU for ; Tue, 20 Aug 2019 02:08:53 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 8D23D120024 for ; Tue, 20 Aug 2019 02:08:53 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id n1so1135169oic.3 for ; Tue, 20 Aug 2019 02:08:53 -0700 (PDT) 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=UxXGHAI65mBDopu/HOSm/qKjolI2WwNGmTsgQacogPY=; b=pHUwxthXQ6buKbGUa/eGv5jukQs6QxOFOkCZF3arbf/IgUm8p+ws2tMV6iJNipODxf wXkOsjSzGH80DDD5UWeVknfBOhlwmtCYdviSXjBYJEqNuse4NU9c7OeSqe9xVoaOHiQL Sk9cweuO5FtLW4jYpCp7I3RuApAj16rTdy1ciLY2KEhF5ZYBjs0+MYwItUADQTXxMDkn vRiu4jzr6wsEZL5zXLvRpFv+ZUIMTuCpooly1AySQFoIqE7TCHRXYQuUovtAEqaaYQf8 CriJCZyablZuqwGtgOSl9c5TsdMPGm736czcHfuSIhxIQh/cOjvd2co6nXrwUw415789 QSSA== 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=UxXGHAI65mBDopu/HOSm/qKjolI2WwNGmTsgQacogPY=; b=pjxlruOZdu3QvW/vfAagYqjgANtNBf6M1CndUIWYTIk3gcetTqNNFA5tPtdUMuaUZA /MFnXTV8XsiaFVR4LM9mEqZOSil+jjANX8uUj7nefOPuDlTMP1l+3sY6UACA+4eHEEop XOeb9YfXcCxV0qW1+ouKK1/1okG0IqgQdlWfaR3LvhMe/TLLkOGrJPTwnlYapyoKq2rN qU7vkH8EkGWTRbvc6RcChzeiBXB9XDvtUAp3hUbyg5MDc1E5oDePLupnqG7uFOe2fplo Ds6aZs556wjyEXhcWUBeLpsGxrCpCO6IqGglHbrp3lwqCUy0jhYnBQKNo/dESAXzRJrP 6kHw== X-Gm-Message-State: APjAAAUVNlOzeOCXLPoKsX/zWhWGPjbw7qzMWn24rHa3hvYnhuT2Mdad c2THnY8H/gsGm3DI+2ysPsvKzZD05icmgpA/BeM= X-Google-Smtp-Source: APXvYqwz7Paa7XMwGbCKudRquSogwSaraBmK05RBlyqctBoko31pvlwtHnjXvEjRJ3CQvck1LNoCD9gmE///ydNNr0w= X-Received: by 2002:aca:1a02:: with SMTP id a2mr9660696oia.32.1566292132472; Tue, 20 Aug 2019 02:08:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Tue, 20 Aug 2019 12:08:38 +0300 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002baa74059088cee1" Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-verification-01: Handling unknowns 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, 20 Aug 2019 09:08:56 -0000 --0000000000002baa74059088cee1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jakob, I'm sorry that it took so long to reply to your suggestion. I think that explicitly state what means the absence of record (AS-A, AS-C) is a good idea. There are already several minor issues that were found in the draft, I will work them through in the next couple of weeks. =D1=81=D0=B1, 27 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 04:35, Jakob Heitz= (jheitz) : > The draft states: > > An ASPA attests that a Customer AS holder (CAS) has authorized a > particular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv= 6 > announcements onward, e.g. to the Provider=E2=80=99s upstream providers o= r peers. > > I suggest to make this more precise and to add the "otherwise" condition: > > An ASPA attests that a Customer AS holder (CAS) has authorized a > particular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv= 6 > announcements to all of the provider's neighbors. If an AS, AS-A publishe= s > at least one ASPA and it lists AS-B as a provider and AS-C is connected t= o > AS-A, but AS-A does not list AS-C in an ASPA, then AS-A authorizes AS-B t= o > propagate the announcements of AS-A to all of AS-B's neighbor ASes and > authorizes AS-C to propagate AS-A's announcements only to ASes that > consider AS-C to be their provider. I.e., AS-A prohibits AS-C from > propagating the announcements of AS-A to AS-D if AS-D does not consider > AS-C to be provider for AS-D. > > Consequently, a chain of ASPAs can be used to verify the plausibility of > an AS-PATH. > > > Thanks, > Jakob. > > > On Jul 26, 2019, at 11:08 AM, Alexander Azimov > wrote: > > I'm sorry for the last email. It was supposed to be bigger. > > =D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 08:38, Jakob Hei= tz (jheitz) : > >> If you receive an AS-PATH of 2 ASes and neither of them make any >> attestation, >> >> then your procedure calls it valid. It could be invalid, >> >> so it must be considered unknown. >> > It an interesting point. When I was writing the ASPATH verification > procedure I had in mind that we need to detect invalids. But for debuggin= g > purposes, it might be also useful to distinguish fully verified paths whe= re > all pairs are valid and those paths that represent a combination of valid > and unknown pairs. It will also require clarification that for backward > compatibility such unknown paths MUST be treated as valid. We should add > this option into consideration. > > If an AS-PATH contains an AS-SET, then the segments on either side of >> >> the AS-SET can still be verified. If any such segment turns out to be >> >> invalid, then the whole path must be considered invalid, not unverifiabl= e. >> > I do agree and that's how both downstream path upstream path procedures > are defined in the draft. > As we discussed in person, we might need additional clarification in the > beginning where {AS(I), AS(I-1)...} sequence is defined. > > >> My procedure accounts for these cases and more. >> >> For the cases where every AS makes an attestation, my procedure agrees >> with yours. >> > If you have ASPA(1, 2) you can't make assumptions about relations of 2. > Otherwise, it may lead to incorrect results in the case of siblings. > > BTW, you have a copy/paste error in 5.2 Downstream paths: >> >> If a route from ROUTE_AFI address family is received from a customer >> >> should be: >> >> If a route from ROUTE_AFI address family is received from a provider >> >> Yes, you are right. Copy-paste can become tricky. Will be fixed in the > next version. > > --=20 Best regards, Alexander Azimov --0000000000002baa74059088cee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jakob,

I'm sorry that it t= ook so long to reply to your suggestion.

I think that explicitly sta= te what means the absence of record (AS-A, AS-C) is a good idea.
There a= re already several minor issues that were found in the draft, I will work t= hem through in the next couple of weeks.

=D1=81=D0=B1, 27 =D0=B8=D1=8E=D0= =BB. 2019 =D0=B3. =D0=B2 04:35, Jakob Heitz (jheitz) <jheitz@cisco.com>:
The draft states:

An ASPA attests that a Customer AS holder (CAS) has authorized a parti= cular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv6 annou= ncements onward, e.g. to the Provider=E2=80=99s upstream providers or peers= .

I suggest to make this more precise and to add the "otherwise&quo= t; condition:

An ASPA attests that a Customer AS holder (CAS) has authorized a parti= cular Provider AS (PAS) to propagate the Customer=E2=80=99s IPv4/IPv6 annou= ncements to all of the provider's neighbors. If an AS, AS-A publishes a= t least one ASPA and it lists AS-B as a provider and AS-C is connected to AS-A, but AS-A does not list AS-C in an ASPA, the= n AS-A authorizes AS-B to propagate the announcements of AS-A to all of AS-= B's neighbor ASes and authorizes AS-C to propagate AS-A's announcem= ents only to ASes that consider AS-C to be their provider. I.e., AS-A prohibits AS-C from propagating the announce= ments of AS-A to AS-D if AS-D does not consider AS-C to be provider for AS-= D.

Consequently, a chain of ASPAs can be used to verify the plausibility = of an AS-PATH.


Thank= s,
Jakob.


On Jul 26, 2019, at 11:08 AM, Alexander Azimov <a.e.azimov@gmail.com> wrote:

I'm sorry for the last email. It was supposed to be bi= gger.

=D0=BF=D1=82, 26 =D0=B8=D1=8E=D0=BB. = 2019 =D0=B3. =D0=B2 08:38, Jakob Heitz (jheitz) <jheitz@cisco.com>:

If you receive an AS-PATH of 2 ASes an= d neither of them make any attestation,

then your procedure calls it valid. It= could be invalid,

so it must be considered unknown.

It an interesting point. When I was writing the ASPATH verification procedu= re I had in mind that we need to detect invalids. But for debugging purpose= s, it might be also useful to distinguish fully verified paths where all pa= irs are valid and those paths that represent a combination of valid and unknown pairs. It will also require c= larification that for backward compatibility such unknown paths MUST be tre= ated as valid. We should add this option into consideration.

If an AS-PATH contains an AS-SET, then= the segments on either side of

the AS-SET can still be verified. If a= ny such segment turns out to be

invalid, then the whole path must be c= onsidered invalid, not unverifiable.

I do agree and that's how both downstream path upstream path proce= dures are defined in the draft.
As we discussed in person, we might need additional clarification in t= he beginning where {AS(I), AS(I-1)...} sequence is defined.
=C2=A0

My procedure accounts for these cases = and more.

For the cases where every AS makes an = attestation, my procedure agrees with yours.

If you have ASPA(1, 2) you can't make assumptions about relations = of 2. Otherwise, it may lead to incorrect results in the case of siblings.<= /div>

BTW, you have a copy/paste error in 5.= 2 Downstream paths:

If a route from ROUTE_AFI address family is rece= ived from a customer

should be:

If a route from ROUTE_AFI address family i=
s received from a provider
Yes, you are right. Copy-paste can become tricky. Will be fixed in the= next version.



--
Best regards,
Alexander Azimov
--0000000000002baa74059088cee1-- From nobody Tue Aug 20 02:43:35 2019 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 33AB4120983 for ; Tue, 20 Aug 2019 02:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 cOno4JfTBjSG for ; Tue, 20 Aug 2019 02:43:25 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 5B93A12093A for ; Tue, 20 Aug 2019 02:43:25 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id q20so4466067otl.0 for ; Tue, 20 Aug 2019 02:43:25 -0700 (PDT) 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=cCN7xAj1vFeqhjxBAIi0uXT9Y1LDUD5QWw2p2udj7pY=; b=H4C7vZR2BYEfLmOlKKKFQD8F+LuJKHkR7vGIJuSqOcQ6IDsFP0EqakvvSZL05kFeIx V/koxYHa4vCJUkuBZ9bv8o2oJr2a2eOSVbUjGB45K6HLkcK3T7U8lgYRBtffIHjpSxLT epe0etYII+mBoHCVbg7Daxkp0DNQtEm5pc03fvSgNyj00TaR8ixOt70+Zsu8BHKy4SPW q5kr4qW/RBp/LoHm1mPfuEE0aExXLsFlXJSzg7iTplFBH3W7/FdVc3sfZhwbHr0Uo1NE gmC3To6jFVfItSBFtx57PP+H82v3xoguLgCEjSvcFZ1Crwla+BhOnOLJFAAvL80OyxTu Ui3w== 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=cCN7xAj1vFeqhjxBAIi0uXT9Y1LDUD5QWw2p2udj7pY=; b=aLRR4xrCvVPHdN2ILUInJ/aifuIaZEkUHwOQGatB926qxo/Sp8kKNl3Oh1mjhAjUrl 8l7a4iwkc5We3usKVLsD+I81gz7tAoreKZv0k7+ryH8XRbug60pXPeBI6uzOkJeECsMT 8cLcILpFxcURxaXEyVFvOUmBX5kfPEgA2AsKxy4DzNQJMR5xQ3lJ9I8kMhjTEEiT+mhk JuUeFAHHeBPKlBcKajQ1ReyQ5k2EFxUbtl6fbK6tXd+2pdAdBddokHC/KpAxOZ5f8noA D59MzVEPcO7frQlKHIto+iRNKxks3ERb7rAe1NH6Sxh0WiCH4186MvPhuompkTL4B/Mn awew== X-Gm-Message-State: APjAAAUCIY5sBTbmf07wg0rJL5V5B7/F87NedCPo4csF1tku7HzeQ8B3 tC34yPp8ZyT0o5JhD8V2Z4Qi1a3Uvcr58lDvvZs= X-Google-Smtp-Source: APXvYqxE3teRhXkBssJehZSMXyKZ7UPv1AFeV1idIasUHtcOwjYfr1wuEUCyqM8KE12YVpyOGeYFFMGFaloulkFHmjw= X-Received: by 2002:a05:6830:17d2:: with SMTP id p18mr20962834ota.113.1566294204634; Tue, 20 Aug 2019 02:43:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Tue, 20 Aug 2019 12:43:12 +0300 Message-ID: To: Oleg Muravskiy Cc: Randy Bush , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000ae5b670590894910" Archived-At: Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-egress 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, 20 Aug 2019 09:43:34 -0000 --000000000000ae5b670590894910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm slightly late, but I also support the adoption of this document. =D0=BF=D0=BD, 29 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 15:01, Oleg Muravs= kiy : > On 23 Jul 2019, at 22:37, Randy Bush wrote: > > > > request wg adoption of draft-ymbk-sidrops-ov-egress > > > > randy > > Support > > Oleg > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --000000000000ae5b670590894910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm slightly late, but I also support the adoption of = this document.

=D0=BF=D0=BD, 29 =D0=B8=D1=8E=D0=BB. 2019 =D0=B3. =D0=B2 = 15:01, Oleg Muravskiy <oleg@ripe.net>:
On 23 Jul= 2019, at 22:37, Randy Bush <randy@psg.com> wrote:
>
> request wg adoption of draft-ymbk-sidrops-ov-egress
>
> randy

Support

Oleg

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov
--000000000000ae5b670590894910-- From nobody Wed Aug 21 02:11:17 2019 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 B05931208C7 for ; Wed, 21 Aug 2019 02:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 n8oHcfLkw37h for ; Wed, 21 Aug 2019 02:11:12 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.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 9240A1208BD for ; Wed, 21 Aug 2019 02:11:12 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:184d:f3fa:5377:1453] (unknown [IPv6:2001:981:4b52:1:184d:f3fa:5377:1453]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E33F1226C8; Wed, 21 Aug 2019 11:11:09 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1566378669; bh=ZzXyNd78P42S+wUnkFCkrwJZ6yPl81cXBHnbqL7XZtY=; h=From:Date:Subject:To; b=GXEg2yDOyvWSsv8GddhZqXNJm4xOz0Vgibk08uCdnoi4hC1so3VVZZ6WyGdJeii2P ABEkmku0AMbtJVv7pblnTl3mwSS8FZlsIaZs2b0QM74bRNu9koYWbt3lfOLe0/Qff2 8CW1VujEsiQuJiFBUf2UnMZhaOzWGANHjpbzq0yQ= From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 21 Aug 2019 11:11:08 +0200 Message-Id: <1CF3E143-98E7-4B66-AEE5-02617A639BCC@nlnetlabs.nl> To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00 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, 21 Aug 2019 09:11:15 -0000 Hi all, Triggered by an email exchange with Alexander, I figured I would send my = (minor) comments on the aspa profile to the list as well. =3D Multiple "providerASID" For ASPA verification it's important that routers get all = "providerASIDs" for a "customerASID". Since it's a single "customerASID" = who signs the ASPA I think it would be best to allow all "providerASIDs" = in a single object. Like so: OLD: ASProviderAttestation ::=3D SEQUENCE { version [0] ASPAVersion DEFAULT v0, AFI AddressFamilyIdentifier, customerASID ASID, providerASID ASID } NEW: ASProviderAttestation ::=3D SEQUENCE { version [0] ASPAVersion DEFAULT v0, AFI AddressFamilyIdentifier, customerASID ASID, providerASID SEQUENCE (SIZE(1..MAX)) OFASID } Of course it's possible to make separate ASPA objects for each = "providerASID", but I think it introduces avoidable risks with no clear = benefits. When managing separate objects signing CAs would need to make = sure that they publish changes as a set. If RPs use rsync as the fetch = protocol they may learn of some, but not all, objects if the repository = is being updated just as they are fetching. The use of RRDP can mitigate this issue, but having a single object in = this case is cheap and avoids some of the risks. An RP would always see = the full set (for the moment that it validates). =3D Small EE certs The draft currently has: The autonomous system identifier delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ASPA), and the customer AS number in the ASPA is contained within the set of AS numbers specified by the EE certificate's autonomous system identifier delegation extension. I think it's better practice to require that: The autonomous system identifier delegation extension [RFC3779] = MUST be present in the end-entity (EE) certificate (contained within = the ASPA), and MUST contain a single AS number that matches the = customer AS number. The IP address delegation extensions MUST NOT be used. The reason for this is fate-sharing. If any of the other irrelevant = resources on the EE certificate would no longer be contained on the CA = certificate - e.g. because of a resource transfer - then the object as a = whole would become invalid. There is still discussion about transfers and the deployment of = 'reconsidered' validation rules. But.. I think that's best discussed = outside of this draft. Here it seems that the problems can simply be = avoided by having a single AS on the EE cert. =3D Add file extension to section 6 (IANA considerations) In addition to the OIDs I believe a filename extension should be = registered.=20 IANA is to add an item for the Signed TAL file extension to the "RPKI Repository Name Scheme" created by [RFC6481] as follows: Extension | RPKI Object | References -----------+------------------------------------------- .asp | Trust Anchor Keys | [this document] (of course feel free to chose another extension - I think four = characters: .aspa would also be fine)=20 File extensions were introduced to help RPs in parsing - so they don't = have to do trial an error parsing of objects as all possible types. The = OIDs are not quite enough, because certificates and CRLs are not RPKI = signed objects. Kind regards Tim