
From nobody Mon Nov  1 02:43:05 2021
Return-Path: <nathalie@ripe.net>
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 C80333A11EA for <sidrops@ietfa.amsl.com>; Mon,  1 Nov 2021 02:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ripe.net
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 CG81mi5Zf7ZT for <sidrops@ietfa.amsl.com>; Mon,  1 Nov 2021 02:42:59 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 4BDDD3A11E8 for <sidrops@ietf.org>; Mon,  1 Nov 2021 02:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Message-Id:To:Date:Subject:Mime-Version:Content-Type:From:CC ; bh=7d4ejWX/9mJMokLcod7Nk31CwgjRZUqDGMxIcW6JuFY=; b=NL4qmEajK1KvxYPCHIfTlJ1k Cu3rU0aqn/VsopNfdorGcC8xec70wQ/AcHDPaKutR+COZ6uWAshom/F+/sWlBiRDy5CNBEedZ1UZW Dn+d2YyfPpA6kT567/qA3rdBkxQ+dNQ9ZZt6h12SvsuyykhTqMSe68d1gic0DyWIyaSy7mjFKipoA VPhX08GVfdVdBQ6xTgo5Fa4z4tBdaaed2UQQfpKk24VNO3zCPHEgfWAQ+hU/fKJyl4egVG8uvsw0Q mu2LuLMawv8K+Em1V1CKyKOwNb6Bi/IKgWp3WktQqhO7UWS/3rRgH5kb3/qVNgEa36QAzE3EU31mL GtBHrGo7Mw==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:33642) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mhTq9-0006ct-Ii for sidrops@ietf.org; Mon, 01 Nov 2021 10:42:53 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mhTq9-0006iK-GJ for sidrops@ietf.org; Mon, 01 Nov 2021 10:42:53 +0100
From: Nathalie Trenaman <nathalie@ripe.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 1 Nov 2021 10:42:53 +0100
References: <27FC93B9-0AE7-4021-A4F8-948CF8B76C70@ripe.net>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <27FC93B9-0AE7-4021-A4F8-948CF8B76C70@ripe.net>
Message-Id: <63149F34-2293-41A1-9BB6-AA20300F0E97@ripe.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a00e3ba8d9624f6a6a79d5874dda48bac
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/dSp_Dq6nvvbT5svNa0ew90N-Db8>
Subject: Re: [Sidrops] IETF112 -- Online -- Call for Agenda Items
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Nov 2021 09:43:04 -0000

Gentle reminder: Please let us know if you wish to present. Plenty of =
time available!



> Op 21 okt. 2021, om 10:39 heeft Nathalie Trenaman <nathalie@ripe.net> =
het volgende geschreven:
>=20
> Hi all,
>=20
> SIDROPS will meet online at IETF-112 on Monday 8 November 2021 at =
12:00 UTC  (This is in 18 days!) Please forward any SIDROPS agenda items =
you may have to Keyur, Chris and me on sidrops-chairs@ietf.org
> We'll have a 120 minute slot.=20
>=20
> Regards,
> Chris, Keyur and Nathalie
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Mon Nov  1 07:41:21 2021
Return-Path: <giovane.moura@sidn.nl>
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 F3A543A1131 for <sidrops@ietfa.amsl.com>; Mon,  1 Nov 2021 01:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level: 
X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-3.33, 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=sidn.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 5kjzxIzEhe9z for <sidrops@ietfa.amsl.com>; Mon,  1 Nov 2021 01:08:53 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::615]) (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 4BAE33A112D for <sidrops@ietf.org>; Mon,  1 Nov 2021 01:08:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cWwt2a80JAPPxQoOk6kllSmxDg0CPxbyIVqIBjcAmgteWiw6umUsZ910eL0yryh6xyVE41LaoLr/Q1Fukj2IB6TG9dRKBerBdN3p4eTMBf7MaflKLCBg6BM1MA6qXrxGTm/lUJhRtB1uS+xYvTjsCRBPq3znxR/1W+2poA3NF6paHZMkyJSxqGx6UB3PlSDS0bGsgXdZaqclyOcnj6/daOR0whi916NiCpoNY7WdRIfcKRUyQ1KiiR5AnZq0M/qe+bQUXxpMgTZ23MCnGbS0092rLf3bYm+74K1GAM9qLQfWNLlx4RIGMKuqifDOA8LIoIN5LfqQxQEGCFmxv1J4Eg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=B5qlKh7I7fvZJpRoNAU41bX42l7fqwalTm8VvMK398k=; b=QegQ02uyeAwdDRwVKYK/Fy1oc6TOZ1BMY5RQqnrbS8whLDs/0JmrBG3dvOlvIO7pRJ5NL7PnxvoQYceXt0n6kJwCPzw3mcXyJDr4sAx/oy+8k87G+Ae7ZS0YcEp3MCyQp0ovFHpVMwT0Ljj+BH0PelCh7w4dsUqylaSE4PfM1lGh7pHRTXazz3Ce9RUvJutQSy3Hvb+dwgjUW/PZhDUKN9xDZFp9SeUII5bwveqNdIKddr2utTNQix3CJK2TEGo+P7volPJGeaOKjYI/tNpcPSo4GjJ09qIZT5/w3zWnkgs8x4ejQaiqh7t9RrIRo5VtBPc2LrZGex8KYA5UhSoAFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B5qlKh7I7fvZJpRoNAU41bX42l7fqwalTm8VvMK398k=; b=T9xBwXeVfMiXUWcShN63vgARiUASyoqhO4k1WJOKDogEUD0zCbhl6TlX9yjVP4mBEhPE4bw+We8uWBxpvVN6cQCahcqOyfXgoM3nVXbP0zsLlBExXzyKrILg9IPYPsjWpbbvc6QP2BfBfXR76mAL62CWWrgCqWjIslK5P88g1eQ=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=sidn.nl;
Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31) by AM8P194MB1675.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:322::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.15; Mon, 1 Nov 2021 08:08:44 +0000
Received: from AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::116a:5021:45d5:152e]) by AM0P194MB0257.EURP194.PROD.OUTLOOK.COM ([fe80::116a:5021:45d5:152e%5]) with mapi id 15.20.4649.019; Mon, 1 Nov 2021 08:08:43 +0000
To: Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>, North American Network Operators' Group <nanog@nanog.org>
References: <m2pmrosku9.wl-randy@psg.com>
From: "Giovane C. M. Moura" <giovane.moura@sidn.nl>
Message-ID: <ed2ad454-ae0f-e8d5-7b26-f53fc970e9b4@sidn.nl>
Date: Mon, 1 Nov 2021 09:08:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
In-Reply-To: <m2pmrosku9.wl-randy@psg.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: AM0PR02CA0153.eurprd02.prod.outlook.com (2603:10a6:20b:28d::20) To AM0P194MB0257.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:61::31)
MIME-Version: 1.0
Received: from [192.168.1.172] (31.21.111.111) by AM0PR02CA0153.eurprd02.prod.outlook.com (2603:10a6:20b:28d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14 via Frontend Transport; Mon, 1 Nov 2021 08:08:43 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7437cadb-5e9e-4c6e-42f9-08d99d0ed25b
X-MS-TrafficTypeDiagnostic: AM8P194MB1675:
X-Microsoft-Antispam-PRVS: <AM8P194MB1675B7F9A11C15557123FEFAF18A9@AM8P194MB1675.EURP194.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: HNurxxuwR7iwy3v6OgHdj7hagEMpNbYgtrmZcUPRFMrQ9YEpTYgOAcQcjKd+N0di++zZfICbxoCZjSMau8yLJ7Vas5WkYWs2Dukiecaanj/HD/KFOMMt7L743Z7JKEzpEVQl7BWxltIQLalNd+YZq/75exyHvYuZo/+AXeOkvlgdjxi+hhLeBkrTFkmlWEERqTxNd3Bw7+GuKiTU6FiNJGZKPcOghs+gw4AsH2g5CpMbK0i/5YAy9grMjudNSH2T2vxe4jjB2jAEqLaP7QiffuaGREX8xQBxFnEoox2ZmkM0xCNuBegjjm0J1KcyrD1pIjKCKNG+m05DwEzl1oM3N8nnhJPgFIMd7bQW5CBTr8NDpvKiEZGOHVWV28KQbFU89Bsi5SPQwRk1gVoGyNeiYTSzhLkToVk/pWyL0GNtcFUes/G3hMZRny4kWbVd0/q6CjjfVad5xWQt/IMTXNSKpKJhgHVNqYffto8qMDnP4Unxsv+y9gdOazIsmGmZrwUSZdZtFXtxegyokwIzc68DNIv43kx45av0H5VND8JqTH6zOCAiCA2pTS9F++AA4bDNfvDmiNKFJtMtUdpvwEDySGNIVHODDOFqv3u6RYdLObAwFzvOtBxF+wyuYb8nnLhr1fKwKKOq2UrAndqQTm3VIqtxyc+nVO9Ses948j6Xb1rNZPLHtM9scqHNFW1gQNOeVPqJs2LFs1qFEENhuKAIDxDgu3Lv4C/kGwGBxUu0kLLs1yOJt/B1jAKPddm0T9FScXx2x+6C9A/rBMy/o6n4wSDLWGzh7MULrAv+mg3uzrzTvI3sBAIREDb0iWnc5YYiPdc5xYAaz5KIGG+2KocoRA==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0P194MB0257.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(366004)(31686004)(186003)(66476007)(66556008)(26005)(66946007)(83380400001)(53546011)(52116002)(31696002)(19627235002)(6486002)(86362001)(5660300002)(8936002)(316002)(16576012)(110136005)(508600001)(956004)(8676002)(966005)(2616005)(38100700002)(38350700002)(2906002)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dlZFSlE0aDU0WlZVSHcvWG5uTHdPVlpHTmE2S2VHdm1XcTBNa1EzeXVWbE1H?= =?utf-8?B?blcxelVKTDBndSt4T3pVRnZJa1l0dnVWVlNpR1dBdGJzMUVmUTdUcFltdkg4?= =?utf-8?B?b3FEVE14SFd2dUdzMU5sZE5oandvZkJQRjBtYU00dDl2SERLa3pLYWl0NGVa?= =?utf-8?B?TUZIUVNKdXp4QUl2YjNtdUF3REpVQnYwR3A3SDNmOVBwQUZDYXNGOU45OTZR?= =?utf-8?B?cS9tZDU3T0J0YytrSGtzVDBwZ21RbE9aZjN1QzdCMDVlRSs5UTlKSUlIeFhq?= =?utf-8?B?SkNxdjBKc3FWMFpETm1nRnBKR0xMREdnUE9acTl0WlJXVEtRZVovdFM3VUJN?= =?utf-8?B?ZGc2K1JBUFNrYndvOTNKUXpyRDhxK1BJeEllUlFwUSthZC9sSTRWWXNDdVJu?= =?utf-8?B?SXdia1ozTzdUUHl1WE1ERENHVGZWRGZRUmNIdzl4UWhXSlloWjRKS1BUM3Vq?= =?utf-8?B?Wm5wcVVqK081VmpORm8vdzBsWWxmaVVtbDNtVTNRRkU1RlN5Z056QkFPZXdF?= =?utf-8?B?OGRPc3V1NkM0anRZVkVSMzFOdzIxWWZ0ZmdrYmVFczN2K0kvdDlybjFUcVZ2?= =?utf-8?B?Wml4Mk1JVGp6ZVZQdW5RTXZlQytFTGlxZ0l1ZzlEU0E0alVURmNndjZGTkZW?= =?utf-8?B?c2FGdVpZUzRDY05OSmg5OTkwaG9QMlFyWVU4bithbzRBMkRkRSs3T0gxTTVP?= =?utf-8?B?SWY3MVo0UHR5d05SYnhwV2V2eWFrd1FjSFBUNVNoV2hGN1l3ZnhQbWtaaVdV?= =?utf-8?B?RXFyN1ZMRGVBSHNacmdNUDFaMDBnd3FmRk9iMnNCekFTVlEwYjB3OHVDcGF4?= =?utf-8?B?dUMzcGxlUWdyODJ0VkpZR0NWRTJoMkFIOVRBSytvSTFYSDZrbzNJY1ljTzlj?= =?utf-8?B?MGtnYjZpTzEwaXVYdWN1eEZ4aU4vbnNQeVFLZ0pMRzJGeHNmVVB0WUdJK2tV?= =?utf-8?B?SjBDNnArNEJqaXBxUDBsZHRONHJpR3VZdkRzOHErV3JzQjhkMURiL0xvalBB?= =?utf-8?B?SWRLNXNqOHMxbFpXeHpNVnZlOTlpSjFyZWxadHN0cmxWTDRpZmlNYUdxM2Qv?= =?utf-8?B?ZnlySzRGUDhsUktRUjJEQnQ5bUpua2dBanRBQzBxRHIwSGh2NFhxbGM3Z25W?= =?utf-8?B?VGpOakkwZEo1UEtYSnlaeXl1YjBBVzVCZ3M4QXNpQlNBQWJGV0NQRTRJNGxW?= =?utf-8?B?dUJuZ2REeDRTZnA0RGFNdktXSnZBUDNYUDZlVW02TkMxRktHSXhNL0NEZWI2?= =?utf-8?B?U2lhZnNIWnJaUEV5ckNYOTFrTlRKaUFBUFZlNjBpbjJ4YUdnTExzQkJOQXAv?= =?utf-8?B?UG5nRmRoQ2NJV0V6QzZ2S2Zab3pJaTdwMlRWWFJ3MTQ0YmV3RDJaR1N4NFkz?= =?utf-8?B?a2M5VFRaVnd1SjZPMjhIYU1FMFh2SXNKc2I3dTBDbW04WmRDT1k5TGp5OXJX?= =?utf-8?B?dml2OVFEQmxkTWwxbHpPbkZFQklIT3crUzdHUUkxZDUzM3BpOWlXdHdFaG4z?= =?utf-8?B?cFJTRTZ6S3JmSkRPaWpJbkdFUWExWVhjaUdQdmQwalA0MXlvOXIwdU0yVDkx?= =?utf-8?B?N1YyT2pSeVhsaGkvVVlkZURlRTFKNFFFcndQUWQzYjA2cUJMR1hZdXVCOWpL?= =?utf-8?B?OUZTMHg2VFkwR1lWY0xmOVNEcWVsMXF4VHFGY2FuY1BqWlVKaEwybTVscEtT?= =?utf-8?B?b3NSSXJqcERRdjVqZU9zTm84Mk1DV2NhdUd3a2VHSnc4Q1o5ak5hcXdJVGFq?= =?utf-8?B?UVN5MGxKSEloVkFBaS9DOWhQcXhIblBQOUVNMUlVbStlSURjOERQUmNINWxN?= =?utf-8?B?QjdvMHJaN29SYk9XL2ZGalZJNU5tU2NiTzI4MlpDZ2tuWFQ2WEg2Qkk2aEJk?= =?utf-8?B?MkpTSUtBeXhpeTltOVA5N1JCc0NIb3J0NkFlVkkrZENKejNKM3UxcnJZSVNo?= =?utf-8?B?Tk95Mi84M2lzU2pMMjI1UnZVeUFqL0t0WkdZcDRxQnRPWUNNbk5ybTBmSXAz?= =?utf-8?B?UExZVjViM1J1WUlTMXo1SWZRMm8xY2V4WjZqelJQVytucWljL3VEbWhrcU1G?= =?utf-8?B?RzNkaXZBKzk5TFRaYXZSd09mNnJORjdXODYzNm1ySTJEZi9hdWVwc1Fna2xC?= =?utf-8?B?b29SZkpTTk53VTQxcU0rRFFnaU1FNXB6NHJmYVUzL3JiL2NuZUE5NHRYL0Nz?= =?utf-8?Q?iXoEu4obuYTJ+evIueblfdU=3D?=
X-OriginatorOrg: sidn.nl
X-MS-Exchange-CrossTenant-Network-Message-Id: 7437cadb-5e9e-4c6e-42f9-08d99d0ed25b
X-MS-Exchange-CrossTenant-AuthSource: AM0P194MB0257.EURP194.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2021 08:08:43.7972 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CE8W8l1nDeCRsZbEcopBu3Pi+RMTq7IDu77uk3B7fjmcLTxvxU49jYbPYf+qdZnxMIugKvaEO/n2SSDJV/XDDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P194MB1675
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/lUTcHir-MYmYnq5e38A3lTd3ZRE>
X-Mailman-Approved-At: Mon, 01 Nov 2021 07:41:19 -0700
Subject: Re: [Sidrops] possible rsync validation dos vuln
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Nov 2021 08:08:59 -0000

Good news: the disclosure has been postponed


Quoting from:

https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of-rpki-cvd-procedure

Update 31 October: Talks have resumed, disclosure is postponed.

Since 30 October, constructive conversation is fortunately taking place
with the parties involved. As such, the NCSC will not publish details
about this vulnerability on Monday 1 November, as previously announced,
but at a later moment (in agreement with the parties involved).


/giovane

On 10/29/21 3:03 AM, Randy Bush wrote:
> received this vuln notice four days before these children intend to
> disclose.  so you can guess how inclined to embargo.
> 
> randy
> 
> 
> From: Koen van Hove <k.w.vanhove@student.utwente.nl>
> Subject: CVD: Vulnerabilities in RPKI Validators
> To: randy@psg.com, sra@hactrn.net
> Cc: cert@ncsc.nl
> Date: Wed, 27 Oct 2021 14:59:21 -0700
> 
> Dear Randy Bush and Rob Austein,
> 
> Apologies, this email was previously sent to the wrong email address.
> 
> On behalf of the University of Twente and the National Cyber Security
> Centre of the Netherlands (NCSC-NL) we want to notify you of a Coordinated
> Vulnerability Disclosure for RPKI vulnerabilities that also impact rcynic
> developed by Dragon Research Labs.
> 
> The vulnerabilities were discovered by scientific research on the
> implementation of RPKI validators.
> Together with you, the NCSC-NL, the University of Twente, and multiple
> other parties, we would like to come to a timely solution before the
> results of this research will be made public. More information about
> Coordinated Vulnerability Disclosure can be found here [1].
> 
> The vulnerabilities are classified as a denial of service vulnerability and
> impact multiple implementations of RPKI validators including rcynic. Since
> RPKI is of international interest we hope that you will work together with
> us on this CVD.
> 
> The goal is to have fixes available before 1 November which will also be
> the date that the results of this research will become public. Before 1
> November the information in the CVD, or the fact that a CVD is taking
> place, is to be kept strictly confidential. The fixes are to be released
> collectively on 1 November.
> 
> Please let us know whether you agree to these terms, and want to
> participate in this CVD. If so, we will send you the details. We hope to
> hear from you.
> 
> If there are any further questions, please let us know.
> 
> Yours sincerely,
> 
> Koen van Hove
> University of Twente
> 
> [1] https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
> 
> - --
> Koen van Hove
> -----BEGIN PGP SIGNATURE-----
> Version: FlowCrypt Email Encryption 8.1.5
> Comment: Seamlessly send and receive encrypted email
> 
> wsDzBAEBCgAGBQJhecu4ACEJEPnqm/++VTh9FiEE5Q3GCKqW0RQyUpA/+eqb
> /75VOH1CjwwAq8Hd0psDhfj6mL4X9ybLGogONpzFKYp9Okv9/CKzQvG4AkLR
> Cvrz3vHlQRKJP8I2PYSLZvtG9D/HXjjKcU+m24jjl2qbKKuSwprqQhLAqabN
> Md+RZFjQGve5Z4vtJsfhXKc4PhaAzMujVc4Mh5Mdbs4sFEdrub1hSnYKlcQV
> PvS/O9SpCYU0E0IC1I455HXxSXUtme+KHtzbGIWQe/mz4KpnZD2Me/Cr1LvG
> Od9izri0Qx5vF+kdpR51PEiwHgN+QkmnUP6Gkrca8TSC2x3ta9B1/ZprdCoZ
> ZYQ7QUFUAkfV+tKCMaBECNOrnDjw8E9GonvzmqpDHBtKBZ3LaxjZX/sxuuTC
> +Ele5nVeWW0ZFqrbanbPy9y1q04tFQd8ewdSN40iXdTj7Ha8GadUhcdSLWqJ
> cLmf71qUAvdwpp0Bt1nhExpU/bEtAaxfnEcTRDX43yUkZXSqV5BxYEyneSLj
> IvFV9AUi56Cx45ESkGRR1ASuCzoc8FCjRH7KOWnaL3fl
> =YQZI
> -----END PGP SIGNATURE-----
> 


From nobody Tue Nov  2 08:50:12 2021
Return-Path: <keyur@arrcus.com>
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 ACD343A0787 for <sidrops@ietfa.amsl.com>; Tue,  2 Nov 2021 08:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBHlEpHeg62f for <sidrops@ietfa.amsl.com>; Tue,  2 Nov 2021 08:50:05 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2083.outbound.protection.outlook.com [40.107.244.83]) (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 48FAE3A077F for <sidrops@ietf.org>; Tue,  2 Nov 2021 08:50:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ObWMJ1lDykqZNl3pitn2tm1nWMHhB/OxJid6usM4eWQsCQKSThPwiNTxJT7A0Ag/fIvf+d/X0enLAeJBB+BZmQuSeB8bfnPAxmuAcDVUx/Vylv5EMezhylDQya8kr+kT0PY79PJHWDrqSrLMwcHBykXYxFRFxNXfaCjJoCAOSkL56C13QvOuv7i2yHybZddsUy8t6eMMbS05nFzVpJyFLTu3IgU2aGrtZzLFbtp9IoQ8xh90XNKgiImqf0e27bwKcrd8z+b8Uw9c46lEF/SgXLoQGwdpfQnPHFv3E32lUijTpn+nNXK+TZRzfjdS1I/Hj4feiiO1j1Di4ERfNecO1w==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HKhh17udyIYSmVb20Na8sh5ZwghZn6EthFh27uXT77k=; b=XHsCJs75Nf1AQ5xwl3ONyDsrCncBCBS2aMYbZ5nbIUqLl6oY1w4noK+p9W+tdy7RImEHjCxroPpNjjeoPb+J9AQqvofXyYsfm4XYZ+zy0xbyjwkfBy0Guf1lbmk7fFEmfkpty+v1s29ux2UhfRzBYa6IyxK574nDaJ5b3WaVTW8AYEkELFNuigqYwY9B4+UOOOKG6biGUFkI596WiIUYOE2KACMLhFDLNCTWYplhtfokD2Oht9DqwlOX26hCnmWuvH2gz6xc1W8VHygwg7IUsmysgllVGEv9fIayn/Rs0GdCcGWpiRwrnnpEAkz3yI8GZVqqvhlgy+AteU5/XXI0fg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HKhh17udyIYSmVb20Na8sh5ZwghZn6EthFh27uXT77k=; b=ri+bnymOw5DgeW8TC6NqbpycdfQa4mvV7NpHYAWYml2Pbyl6sOG2expA1t6pYBDlkssIryahkTbMBgE7KNWuW+6J56G9rlalyGDO7Cu1/kU6ZaSNv4mcbIbTDxjg4GbM73JjYfRS3qXobEUVcx6iZsJbzKkqGKow97e6YLYCsKs=
Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2967.namprd18.prod.outlook.com (2603:10b6:a03:103::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.18; Tue, 2 Nov 2021 15:50:04 +0000
Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162%5]) with mapi id 15.20.4649.020; Tue, 2 Nov 2021 15:50:04 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] Extended - [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - Ends 23/November/2021
Thread-Index: AQHX0AFNLj/47ziiOE+o0c3rJHuliw==
Date: Tue, 2 Nov 2021 15:50:03 +0000
Message-ID: <A55D980D-F524-454D-A2D5-3810327CFE1B@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a5bfbdac-9a4c-4581-6225-08d99e186fbe
x-ms-traffictypediagnostic: BYAPR18MB2967:
x-microsoft-antispam-prvs: <BYAPR18MB296720C709944C4D9E091558C18B9@BYAPR18MB2967.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uETCFl0R7ZOrfF6sDfr9UoB8R7sUIz49RittV5xHqHoUSHEG3qssemK5FviGCfTPYjquwZCvjvu0t1mGnEHGGp+KBIxP4YRy6yiuOeXX47mmTcSDs6TLv0d1AXuNGbEzpvPpcB6llBYtdtTRzMtoj0rgMGeDAlYlpgh1wBNsvwSok3LIp+zVD3EWSBBhVlIYe4NGL4DWjSF4vWd2A5Nl61ARh3j6GuynO8xXjyTml/32poFShC70o8UEBYoVBRFtMpYqoetgrPIhl8uQb8TKE6fQaqoZRDd1a4yilQjbTnz8bZbRaNIx6k7+o1GQy9EMf5J4Xefgo2ktdB+iJPfiJtmbrBcOovUjPCKDVXdhU1qoF+6yx4m4Kb+XLkpTRmo6E6Uvuu0NJulw5d0l0/Y0snjHJE9AJslK2HWbFbW8eiG5vQKzOJ+T1Dw/se5YH8TP3LvFJI/BCSm85hu5wlOLLysOzu7kcnOn2LPYME2SGF3gE7Mme7q5sUfn9inx+X9DpYVRZ3qiTn6yzgUoYovjtDqDx/JNi/I1+pes9Ayj+/azL57faTH4b0Rg1E0/ImPsvDYeupvKeW6Jf2sGfWJkoowMswiwhvRjBZyr6lxrqYJaLgs8eDzIy/p43HJ9OU5+W4jMIwgHVdQTpFfOjveahi5wjOFkuZOQ1cpeWs864LXdzenkYqVdeWJWeRMTSXt8U0WRHWXwAW2FI0UXEqI4mv4IvS6EbBdvED9T8vw/BHqbHJRy9jqtDI8CSPNwf3+rGv8bz9G4QulFWStsb6eM5sgGdvsYCfT70hZPfLhUT50qxlf5qZDoiajOesy5P/sS
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFS:(346002)(39840400004)(376002)(396003)(136003)(366004)(64756008)(66476007)(66556008)(66446008)(186003)(76116006)(6512007)(66946007)(6486002)(5660300002)(86362001)(8936002)(71200400001)(508600001)(966005)(33656002)(2616005)(91956017)(9326002)(2906002)(316002)(38100700002)(36756003)(122000001)(6916009)(8676002)(53546011)(4744005)(38070700005)(83380400001)(166002)(6506007)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UFF3WGEvWUNzVnI5U0V1RjZWcWlGZzdDTGlITzN6SGVGcWNvOFpkZ1c5WEJ4?= =?utf-8?B?enE3U2x1MFBvRFdGUG5jTDY1bGJKb00rcGNaR0N4YmN3LzFDRFN5NXJza1lM?= =?utf-8?B?OXd1TlhkcVhuTVNBbXVSWUJueFdWcHUwaDdJeGNEK0VmK1RZTWpmdCtnWldy?= =?utf-8?B?eFNqMnB0c1RuMkhGZzdlT3VTQ013eW1GajZBMEZnc0JJR0dUb0Z3cGU1VW03?= =?utf-8?B?MHFJNkVqdFcxVlk0L2RWYW1LT1ZENG03bktWNWJDeXNLY0tjdHNHNFpIdk8r?= =?utf-8?B?b2dEZG83OXByazg2ZFRUTGo5M29scTdldUp1MXlvVWl0TUJuT2taam84KzZG?= =?utf-8?B?YkNIRmVQU3pNcVNVWGo5UEZLWkVydWFlMk5SdUZWT01EL0dvaVBKTEVJcEVi?= =?utf-8?B?ZUtxbktlWFdoY2tQQTd4dGtTdXlCVEZnV0tYMDRjVnRsSXh4bmtMem04QklL?= =?utf-8?B?c1h0SlZrVUJMSjNZK0hwZUJlTnhKSGZTYjk0S1dvUk9MQTI0TUcwVXp1d2Uy?= =?utf-8?B?QVF6MG5kUE5CbHBrZ09WN2Fyd1EyakFqbTAwT2czaUVTa2ZYZFJjbHNNd3lK?= =?utf-8?B?SkY4clh1V3pXUXNpNEdnNXdmVitWT1M3S29KNHdrdDlqZ0pxYXRtOXhzV3VV?= =?utf-8?B?RVpxZnRZU1UzU1RnUXJjNTRSZTN0M0hQYnIwVXpPRWluejV6cmJoQTVHR2ZS?= =?utf-8?B?ajVIWGcyS2VyVkhlQW5XTUV3blVmQzI0VEtUb3N1ZTRYTlA4Y0s0U0VRLy9t?= =?utf-8?B?ZmJQVFh5aHdZVklIM3RPa3U1RkZvOTVnYzNiSW5CNjFuNFlWdzR2Zjl1N0xy?= =?utf-8?B?aElINTc1dS9kYmVybjRReVF5TnkvUnBENjJFTlAyczRiTVdOa0lxOUFKdzMr?= =?utf-8?B?SE8rV25VWVpBWnJPTW9WME1MNERZTHhKOVVlRUJZM085YjhOTGNNUk1JTjZo?= =?utf-8?B?RWIzZXZtY1ZBWVIzSGZKSVQ3aXZhNXNWQ2hxL01YcDFCaFpZV21EYTl1aGVP?= =?utf-8?B?Umw2bWlWbFN4UFMwcmoxNXovUXdpcUVJQkoyMmkwbDFPU0FpYkFYWG9sd0NS?= =?utf-8?B?UkUyb3Uvb1VITkVieGhpemd6dkE1Wnk5ZlhaZDVQb255YXo3RHN1R1dKV2Q3?= =?utf-8?B?V3BsOVBsZGtkUGFWU3Z6Q1gvZE8yMWVyZmtuTGM1Y3BWWFlVS1gwVjVzbytO?= =?utf-8?B?M2xsdmZGZDNQQ1V5NjZORTJ4V3Bud2lrbmpMZ1NJdytXTXE2eEpNWmdXSWs5?= =?utf-8?B?T3BDT3V3ckl0L1ZJZ0U3OVVTb0RYUlJzTUplMFZKM2xpZ0FpS2l5TWtTdzVK?= =?utf-8?B?UWlaM040ZFZxbkVaUWlDMTB3Z0RjdjRnY3RkODJ0Ym9wR09XeWlMcVYvNUts?= =?utf-8?B?QzY0QnhtVTluV1FwNHo3VG85aDkwNVRWRDhpS1VQUmF6VFhoNXkyUFpaV3Nk?= =?utf-8?B?TnYyVm5hV0Z1em4vOXZCcUJvTXhYeXpCRGhKdmQxcldzcTlTdjJReU5Cc3ll?= =?utf-8?B?eXVCbnBtRUhxczh2ZUFubHFPaVFmaXJKRnVULzE3V0tTbXFkSjNNY3o1cVpF?= =?utf-8?B?Q2t2bTdPZDlFK202eVV5T3NvNU1PYVZianRZSmcxdE52bm1uZjQxS3MzT3M3?= =?utf-8?B?VGdlbnRnNWNYY2x0S01DcVN3a2pUZncvVWttSGZPRzRWSFNBRkkwMVBuVExh?= =?utf-8?B?L0dnWm5lc0lSQVpKS1hBdFpCekw4VXI4NCtNRDlJMEVoS2JKbmRzNkhsVk5o?= =?utf-8?B?Mmd3eUI3SDZ0Tk1TdHkwMlFNZzlwbTJROTUvYytjNVdaSXA3bUpseG4vZ3gr?= =?utf-8?B?dnNlL0xXRjE3MDA5bnF3UW9YL2NVQnpZYTRBaWExbTIrZ2dFR21VVXIwTllO?= =?utf-8?B?NHljVkZNK3FFcE5UOHFOTDI4WDh0QWZLT0hBQnBwZEtybUVaMXF1aUNBOVNB?= =?utf-8?B?a1BJc1FnZlIvdW13WVJ4VDdlTTlHRkx0alBWOFRHZVdTdWlxdWpUSGhRazNN?= =?utf-8?B?ZUF2WG9pYkRFdUc0OG5GOVY4M1BSYUdNU0ViS2p2MVlpZ3dFeE1yQktETklO?= =?utf-8?B?OG1yQjQ1MEtTVmhRK24rZStRUy85aTNTVXNhdGpuNDdpbGZiYjhYZmpqSzQx?= =?utf-8?B?elR4UWVOS3FqR0lSMGk4NmJrOEwzdGU0SEFWK1ZiYTFKWWRkQWlWT2hCT0l0?= =?utf-8?B?M1VPcmlHUE1IMlA5eVJIaVY2R1BOSk5mWGxNem05UU02Vks5cHdQUFBIM3Fs?= =?utf-8?Q?rTx59l5Q9Xb6mTVjF8f4B05+aVD5jgJ395gIxiatk8=3D?=
Content-Type: multipart/alternative; boundary="_000_A55D980DF524454DA2D53810327CFE1Barrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5bfbdac-9a4c-4581-6225-08d99e186fbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2021 15:50:03.9378 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3noMrETIGL5Co/LpNBBsMXz6OyQplMNjfCm7J44tD/1B3+0AqHUmuVRt7k6zvM57RPo6w12Ki/rEqy9Bind3rg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2967
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/VbS7a662QiuvPByPcr-Qqxu6blI>
Subject: Re: [Sidrops] Extended - [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - Ends 23/November/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Nov 2021 15:50:11 -0000

--_000_A55D980DF524454DA2D53810327CFE1Barrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRm9sa3MsDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgZXh0ZW5kZWQgZm9y
IGFub3RoZXIgdGhyZWUgd2Vla3MgKGluY2x1ZGluZyB0aGUgaWV0ZiB3ZWVrKSB0byBOb3ZlbWJl
ciAyMywgMjAyMS4gSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGRyYWZ0IGF1dGhvcnMgY2FuIGFk
ZHJlc3MgYWxsIHRoZSBjb21tZW50cyBhbmQgcG9zdCB0aGUgdXBkYXRlZCB2ZXJzaW9uIGZvciB0
aGUgcmV2aWV3Lg0KDQpSZWdhcmRzLA0KTmF0aGFsaWUsIENocmlzICYgS2V5dXINCg0KRnJvbTog
U2lkcm9wcyA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2V5dXIgUGF0
ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMTEsIDIwMjEgYXQg
NjoxOSBQTQ0KVG86ICJzaWRyb3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1Ympl
Y3Q6IFtTaWRyb3BzXSBbV0dMQ10gZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDggLSBl
bmRzIDI1L09jdG9iZXIvMjAyMQ0KDQoqKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoqKg0K
SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVk
IGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOCwg4oCcVGhlIFVzZSBvZiBNYXhs
ZW5ndGggaW4gdGhlIFJQS0nigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIg
Y29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE9jdG9iZXIgMjV0aCwgMjAyMS4NCg0KVGhl
IGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
aHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOC4gQXV0aG9ycywgcGxlYXNlIHJl
cGx5IGluZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0
aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyAm
IEtleXVyDQoNCg0K

--_000_A55D980DF524454DA2D53810327CFE1Barrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <393D698AA502734FB1FB768D929EB73F@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND
MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw
YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls
U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg
dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+SGkgRm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij5UaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIGV4dGVuZGVkIGZvciBhbm90
aGVyIHRocmVlIHdlZWtzIChpbmNsdWRpbmcgdGhlIGlldGYgd2VlaykgdG8gTm92ZW1iZXIgMjMs
PHN1cD4NCjwvc3VwPjIwMjEuIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSBkcmFmdCBhdXRob3Jz
IGNhbiBhZGRyZXNzIGFsbCB0aGUgY29tbWVudHMgYW5kIHBvc3QgdGhlIHVwZGF0ZWQgdmVyc2lv
biBmb3IgdGhlIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaWRyb3BzICZsdDtzaWRyb3BzLWJvdW5j
ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJyY3Vz
LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBPY3RvYmVyIDExLCAyMDIxIGF0IDY6
MTkgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Np
ZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltTaWRyb3BzXSBbV0dMQ10g
ZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDggLSBlbmRzIDI1L09jdG9iZXIvMjAyMTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4qKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoqKg0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs
aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl
YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29y
ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog
cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0
LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJl
cXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDgsIOKAnFRoZSBVc2Ug
b2YgTWF4bGVuZ3RoIGluIHRoZSBSUEtJ4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0
aCB5b3VyIGNvbW1lbnRzLiBUaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj53aWxsDQogZW5kIG9uIE9jdG9iZXIgMjU8c3VwPnRoPC9zdXA+LCAyMDIxLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFs
aWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdl
YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29y
ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBkcmFmdCBjYW4g
YmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PGEg
aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNp
ZHJvcHMtcnBraW1heGxlbi0wOCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt
bC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wODwvYT48L3NwYW4+LiBBdXRob3JzLA0K
IHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxl
dmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12
YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz
OiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4N
CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtv
cnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1z
aXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29s
b3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+TmF0aGFsaWUsIENocmlzICZhbXA7IEtleXVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk
b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A55D980DF524454DA2D53810327CFE1Barrcuscom_--


From nobody Thu Nov  4 13:37:37 2021
Return-Path: <christopher.morrow@gmail.com>
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 73DB13A0942; Thu,  4 Nov 2021 13:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 M9uKmO7XN9Yr; Thu,  4 Nov 2021 13:37:34 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 9DE3F3A0929; Thu,  4 Nov 2021 13:37:34 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id w9so278305qtk.13; Thu, 04 Nov 2021 13:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:from:date:message-id:subject:to; bh=YyYsaR5ivoubWSdUJLd6Z9LbuHiT7ACBPjAX0jcrbXs=; b=M7H9IH2ZyXoetTmtR47/0/b9xLpTVa7sMHZOVI4TcAC2dEtP9KK/fpHokBbOOh3fRG aqNTll4e+VZ81G3p6fVLn4+qAMyD3a7xovl6oxY65e5PhpsJ2uD2dSEqn/FbLhDiIBG/ NJ323adZUJiZ2fF451qgx4oHyPCnSRMqRXozUzxvmgzPXDFX3U5xTv35jP0GZKBRfDnz 9d+JHUVbyWwVFKtiY604oh13tFZr5g83b+5CAYIyDC8De6G1Kw2RfeqWh934AjWSHCmU AlEDzl1Vl5B+3RwlVz/bB2StXzX4DdY++m2QRy/MjHzIQIYxFjFmnP/h/6+zikze4m5k TZXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YyYsaR5ivoubWSdUJLd6Z9LbuHiT7ACBPjAX0jcrbXs=; b=AvtBpOXqKhjqZit+TVrshSXGSd9YDVjzxxgm/birpIpNkLOSUcV3T1GT522h0ZqzOn LUOy3DOjJRXtB9xU1ckbiOw5jTymHM5Pjb+PvY2EalFqnR6GojUIokO+bqTr2NeP7AJ4 clYEP4IbX7+4ymUvbB4FQlTMp7Ff8GzQyiebJsb51UkeMq/UNFxCmPZ+5t0Xdpp9hZ9j zFCcS1pabgJ07kOKdepTvt4H86vXoawy0w/0iudShS+OycKtSLRVxbG2gh4n+N/cQ7NN c797cX6ZaUtiYQXa0sdcZ/evUF6T5p7ZOURAOFXNBOZFyYr3KJ4+K5x8pxZ7cw8NepDG Bw+Q==
X-Gm-Message-State: AOAM5331IHHNJfwuXf/tv6loBf49PSsSyUOFXWsNyOhcaYvOVciNPCfG T6cm0TQVLayWA5xCPp57gRkTDv6lMiQNpBTQ62XOasILv5s=
X-Google-Smtp-Source: ABdhPJwg+uoIKXi4878gC10imPGMsmOhV+jCCbPOExwQ1XklZJXJ5bx9N1Hfi+Hiw2i0swT8Mo3THqpyWEZa68hqPSs=
X-Received: by 2002:ac8:7dcb:: with SMTP id c11mr56366818qte.12.1636058252728;  Thu, 04 Nov 2021 13:37:32 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Thu, 4 Nov 2021 16:37:22 -0400
Message-ID: <CAL9jLabyxzss_R=JyrS4SLpvKyny4QU9C5QN5fMPFgAbnBYSkw@mail.gmail.com>
To: SIDR Operations WG <sidrops@ietf.org>, SIDROps Chairs <sidrops-chairs@ietf.org>, sidrops-ads@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fc5d9e05cffc7ed8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/IFme9Pv5QADSoE5oqV7Rmmu0M58>
Subject: [Sidrops] Meeting Preparations!
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Nov 2021 20:37:37 -0000

--000000000000fc5d9e05cffc7ed8
Content-Type: text/plain; charset="UTF-8"

Howdy!
For folks presenting at the upcoming meeting (monday <time> time) please be
sure to have your slides mailed to the chairs prior to Sunday night 9pm
Eastern USA (gmt - 4 now?).

For everyone else, prepare your barbed hooks and pointy sticks!
(which you will leave at home and not need because civil discourse is the
rule!!! don't make me pull this car over right now!!)

See you all in ~88 hours or so!

-chris
co-chair-persona

--000000000000fc5d9e05cffc7ed8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Howdy!<div>For folks presenting at the upcoming meeting (m=
onday &lt;time&gt; time) please be sure to have your slides mailed to the c=
hairs prior to Sunday night 9pm Eastern USA (gmt - 4 now?).</div><div><br>F=
or everyone else, prepare your barbed hooks and pointy sticks!<br>(which yo=
u will=C2=A0leave at home and not need because civil discourse is the rule!=
!! don&#39;t make me pull this car over right now!!)</div><div><br></div><d=
iv>See you all in ~88 hours or so!</div><div><br></div><div>-chris</div><di=
v>co-chair-persona</div></div>

--000000000000fc5d9e05cffc7ed8--


From nobody Fri Nov  5 14:40:33 2021
Return-Path: <tim@nlnetlabs.nl>
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 122483A0E92 for <sidrops@ietfa.amsl.com>; Fri,  5 Nov 2021 14:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 Y41rNpncMWhM for <sidrops@ietfa.amsl.com>; Fri,  5 Nov 2021 14:40:26 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 61D3F3A0E81 for <sidrops@ietf.org>; Fri,  5 Nov 2021 14:40:25 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DDCAC29F for <sidrops@ietf.org>; Fri,  5 Nov 2021 21:40:19 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1636148419; bh=xDk0/3fBY89P81q37/P1aVZMF5zDDMeAy8Q04MA8PgY=; h=From:Date:Subject:To:From; b=BE8mSOzl1bLn3OQ+34fRLTbNA71B+3EXiZVz0LCCO0R1ubPQ1c9DmZE1EpHgwBsWO H4PSMJP7tx+NUgVoNYtmR/PJzrlhW9rTh8w3xWBNRiVinGBA4AeqgEuSSyvWFb1p0k nUMdTi2PyIdjw+z/01Km8hiE625VpeKDAWQTztOVF7+34NSrim4uo0uGtm9+wHO1Bv kfUBvmIDFb8ZG1qD4bP1qNE9oOIu6O4Ophj9JT8uaL5HyDslz6ppz/uFQPzhkByhQM Q+k9k5VHoTi08b9Jd07Q6Na5eX6Yo/Sb7Zk5ApWLDfXN9W28o7xxlY7fcvKLbEhCR9 nRruC6jUWlogw==
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 5 Nov 2021 22:40:17 +0100
Message-Id: <4427CFCB-D170-4B25-A5C3-E5614F04BACD@nlnetlabs.nl>
To: SIDR Operations WG <sidrops@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/S-LkMOTC0YdByssGdS-YlYIGeHM>
Subject: [Sidrops] Experimental ASPA object published in testbed
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Nov 2021 21:40:32 -0000

Dear all,

It's not my habit to announce new Krill releases here, but... we added
experimental ASPA support to the new release candidate (0.9.3-rc2).

We are running this version in our acceptance environment as a child =
under
the RIPE NCC Test environment:

=
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-tes=
t-environment

We have created an ASPA object, based on the latest proposed profile on
the list, at the following location:

rsync://rsync.accept.krill.cloud/repo/accept/0/AS211321.asa

Because there is no official OID yet, and we don't wish to squat one =
either,
we use a private OID that Ben Maddison set aside for this purpose:

  1.3.6.1.4.1.35743.3.1.1.1.7

We will update this when an official OID becomes available.

If anyone wants to try out the CA side of this, please have a look at
the documentation here:

=
https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.htm=
l

Note that to use the CLI for this, you will have to explicitly compile
krill with the 'aspa' feature enabled. Of course we hope to make this =
all
available by default in future, but at this point in time this is really
meant to support the WG in getting hands-on implementation experience.

Please, do not try to use this under any of the production RIR TAs.

If you have any questions or find any issues, please let me know!

Kind regards,

Tim=


From nobody Sun Nov  7 06:33:27 2021
Return-Path: <warren@kumari.net>
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 9F0D63A0D16 for <sidrops@ietfa.amsl.com>; Sun,  7 Nov 2021 06:33:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=kumari.net
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 nKU1AYRZcCKt for <sidrops@ietfa.amsl.com>; Sun,  7 Nov 2021 06:33:20 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 A0B953A0D39 for <sidrops@ietf.org>; Sun,  7 Nov 2021 06:33:20 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id g184so12838940pgc.6 for <sidrops@ietf.org>; Sun, 07 Nov 2021 06:33:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google;  h=mime-version:from:date:message-id:subject:to; bh=AGd0IKDSI12NaV1mKYxmuW2GY/tU/NtF5/RO0fbTwm8=; b=E2ZGR9OubSO6H9HcKoHL/5Ht7kByW4FjYWAhMupmQ4rou+aS1RQRlmH8Creqblpy5M FZ3CksdiNkfFouUsBwvYVvuXEN8EGxxXtWnNSwFkEtchhZL0700ki8kVHD1FMJ5VKQZV dslJ9iOLMAf9B0GvaG1EppMUaBin5NCf42CqI8ODAHiD7ZbV6R35dUPLRfLRfq7ZYwAu BIqSF1LYHwKO0UfqrfxsZljJbBQd+gt6UAKD8LaQvcg+9JqcrHbQBy+U6G1u31f5KHa0 0f4NYRlDVXHwGHjyHJTr+a8iK2GiQgaMmqknnGpovD9oACd7alJbu7oiPLVZvbAIpIf5 kZ7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AGd0IKDSI12NaV1mKYxmuW2GY/tU/NtF5/RO0fbTwm8=; b=kDCfQsYUFdtNySYiE/e6+dC3X9uBcuTbEeYXgkb85f+4QSmGHlA7wdctbjmmJE2a0B yx0NwliJmluX+L/1JVn+e8qIiYx0KpM+6OUKylJ8dogTywLYMPU/dDHISZlimrY69Nks phwILUBHOK4UCpvg6P1caVo15LVe1nkxUJDsxIQkmec8M9jEnF1o7flc3Fb3kA5HOz1V QODM7Cf+eHXbDhjMehe3qk0lIAN4pSPXYpB2lUXQG8ARiqXtPki2enNDXyjgKuu7I0JS wA8ZVXAtnC1igqnnjCcUM3DejvMwt+fqrT/DqYln/vhkeFohsiUsHpUrMgauNyptxEov a4nw==
X-Gm-Message-State: AOAM533YVMm0kryKuSq4qlizOmxkUyHsRQ6+Quetcs2OWoxLqKNNsCUw UPTPtDaLioZshfNAwEGvuUA/JERbzJ5S6WSP/tE8NF8SYA4=
X-Google-Smtp-Source: ABdhPJytc0NLSdbPx47s/FiNTnP0hFs5HezhvJ7mw79ATMG0WSr5d62tC5hbNWg0NyZRVp7f62jqK7E+pCWTSnZqVcg=
X-Received: by 2002:a63:4b58:: with SMTP id k24mr48268916pgl.326.1636295598150;  Sun, 07 Nov 2021 06:33:18 -0800 (PST)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Sun, 7 Nov 2021 09:33:07 -0500
Message-ID: <CAHw9_iKc6jBQH1xbEFq+Ez=-1QD_Cuq0JuyrxpUTF2F0EDw9Lg@mail.gmail.com>
To: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e04d2a05d033c1ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/gSHqyV6BqauwIWyAx_JFmMlnMwQ>
Subject: [Sidrops] Reminder: SIDROPS meeting & Daylight Saving time
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2021 14:33:26 -0000

--000000000000e04d2a05d033c1ff
Content-Type: text/plain; charset="UTF-8"

Hi there all,

Just a reminder that DST happened in the USA this morning.

Please remember to adjust your clocks and double check the schedule to make
sure you know when the meeting starts...

W
-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

--000000000000e04d2a05d033c1ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi there all,<div dir=3D"auto"><br></div><div dir=3D"auto">Just a reminder =
that DST happened in the USA this morning.=C2=A0</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Please remember to adjust your clocks and double c=
heck the schedule to make sure you know when the meeting starts...</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">W</div>-- <br><div dir=3D"ltr" c=
lass=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr=
">Perhaps they really do strive for incomprehensibility in their specs.<br>=
After all, when the liturgy was in Latin, the laity knew their place.<br>--=
 Michael Padlipsky<br></div></div>

--000000000000e04d2a05d033c1ff--


From nobody Mon Nov  8 03:44:30 2021
Return-Path: <nathalie@ripe.net>
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 892E23A0CA4 for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 03:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=ripe.net
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 DNHUXuqLjNn9 for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 03:44:23 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 8FCDA3A0A66 for <sidrops@ietf.org>; Mon,  8 Nov 2021 03:44:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From:CC ; bh=zFsemdN9na620G76bBPku64P4yzsOjPNG4B+Fgj8pfY=; b=gdtS2YZ8h6vt+pX/campUD+/ /kNY+8JtaKlsQuWHJsNCDhI6y/qh9ErrAw3L3jmtyIdPggbpu9eRSRhoh/5xB2OrZoDlIWM1Bok7K P69N7flF6VpxlINBVw+FeNaO4FMbZyVRRE4jA68Eta7ZPSFvINzbZ5uJpi/ErKoDOJEuNJ5JY2gvR tkcEiEhigwq+6XRlEm/pQRBXMT5nxRVPRoC4fhd5mjrQ9TLLYnG3tmuL+kefHj3N7o2gJQkzkj3RW yji7MW0QGxETh76RoZaBT8Hr0nFp0qIfivZ0RHX6aWIFzToNfBYu1zIdD1okzKlv+/4egGgjkdV0e /I89XQ5dBA==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:54872) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mk34S-0008XG-DQ for sidrops@ietf.org; Mon, 08 Nov 2021 12:44:16 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mk34S-0007zg-Al for sidrops@ietf.org; Mon, 08 Nov 2021 12:44:16 +0100
From: Nathalie Trenaman <nathalie@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3EE39329-5C63-42D5-A070-9B0836D68B46"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Message-Id: <87FA68DB-3D61-42F3-A61D-D3A33D0AD059@ripe.net>
Date: Mon, 8 Nov 2021 12:44:15 +0100
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92af13eecf27a4d18b86e0c031bbbdb0e9d
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/LskWBq9fPFylP4Z8MYTZonau-dA>
Subject: [Sidrops] IETF112 - sidrops starts in a bit
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 11:44:29 -0000

--Apple-Mail=_3EE39329-5C63-42D5-A070-9B0836D68B46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

Meetecho link: =
https://wws.conf.meetecho.com/conference/?group=3Dsidrops&short=3D&item=3D=
1 =
<https://wws.conf.meetecho.com/conference/?group=3Dsidrops&short=3D&item=3D=
1>
Agenda: =
https://datatracker.ietf.org/meeting/112/materials/agenda-112-sidrops-01 =
<https://datatracker.ietf.org/meeting/112/materials/agenda-112-sidrops-01>=


See you soon!
Nathalie=

--Apple-Mail=_3EE39329-5C63-42D5-A070-9B0836D68B46
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">Meetecho link:&nbsp;<a href="https://wws.conf.meetecho.com/conference/?group=sidrops&amp;short=&amp;item=1" class="">https://wws.conf.meetecho.com/conference/?group=sidrops&amp;short=&amp;item=1</a></div><div class="">Agenda:&nbsp;<a href="https://datatracker.ietf.org/meeting/112/materials/agenda-112-sidrops-01" class="">https://datatracker.ietf.org/meeting/112/materials/agenda-112-sidrops-01</a></div><div class=""><br class=""></div><div class="">See you soon!</div><div class="">Nathalie</div></body></html>
--Apple-Mail=_3EE39329-5C63-42D5-A070-9B0836D68B46--


From nobody Mon Nov  8 05:47:20 2021
Return-Path: <tim@nlnetlabs.nl>
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 571543A073E for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 05:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 b7uvlfcBInsF for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 05:47:13 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A740E3A0637 for <sidrops@ietf.org>; Mon,  8 Nov 2021 05:47:13 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 36BE58A0 for <sidrops@ietf.org>; Mon,  8 Nov 2021 13:47:07 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1636379226; bh=rSGaAExTmdgG8Q3Qc7ixGpBxsX+daSWCygVZ9qwVDBU=; h=From:Date:Subject:To:From; b=Yckq467maut4b1RSvzcJd46K9J+4pCQLG8Jdi2ZvAC1O5lFP/Yi31bEZnS6mv/NbW OtlGdceugdtDyeHrjsgjUQbHedWJ8MPliwk0JmRSPM+53cqgBmE+rgzd9ocTre4ZQP s0NXFgeZlwzJfD0ir3eAaRcklLmmrpgQ4+F8x5QOy7Hf2YFrxLjIaE41SD/dDSdoT1 HdZF3q+r/e3hMDDNU/FDlcLrsop81m+u/l/ZBGKN+l5S86oScyNimg40+cO+RqkTrp wFTLtVZ1BkDQYzN2HBiQaqbO+fdTZteDasll+KYsEW6RrLtbgURamz+ZO/n9KFAhZf QYQsoAxSRDTSw==
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 8 Nov 2021 14:47:05 +0100
Message-Id: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl>
To: SIDR Operations WG <sidrops@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1Ufk5j02wwH5c7veRDuJCnpIm08>
Subject: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 13:47:18 -0000

Hi,

The nice work done by Oliver and team triggered me to ask the
question whether there would be value in having a well defined
human notation for ASPA object content.

As I mentioned last Friday we have added experimental ASPA
support to the new Krill release candidate. As part of this
we also invented a human readable notation for use with the
CLI:

=
https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.htm=
l#aspa-configuration-notation

TL;DR -> two examples:

AS65000 =3D> AS65001, AS65002(v4), AS65003(v6)
AS65001 =3D> <none>

So, note that we assumed that we would have an explicit empty
list, rather than AS0, which is described here using '<none>'.

So, to repeat the question:
Do we think there is value in defining a notation like this?

If so, this may help operators when they use different
implementation and/or components. I am open to change..

If not, then implementations can just use their local
ways to describe.

Thanks
Tim=


From nobody Mon Nov  8 11:52:37 2021
Return-Path: <jsnijders@fastly.com>
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 EBDC43A0FE3 for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 11:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=fastly.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 FC-834IYJI3g for <sidrops@ietfa.amsl.com>; Mon,  8 Nov 2021 11:52:30 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5DCFC3A0FD4 for <sidrops@ietf.org>; Mon,  8 Nov 2021 11:52:30 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id h23so18192127ila.4 for <sidrops@ietf.org>; Mon, 08 Nov 2021 11:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dUJK2ex+a8fcMaYD+NXxx05QNM/wBaFmVMjZUw0XLRo=; b=toHvJ2Dnz454EGp/tNrHe8/DxoLaRuK5yT7ZoTIAZNgkyGBQA8K/IRVNLvD9BSP7/R l+StsjbcYKZgNxvQgaeutkykin/dw5MD3b1LzRODlv+dFKOLB/hJ2oCYAKLu+Cj3R8Zb K6uJsRg+7FzZAkkJDCt6n9PqxqC6BjrgGKiLc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dUJK2ex+a8fcMaYD+NXxx05QNM/wBaFmVMjZUw0XLRo=; b=6v7eVg8P9eJDv+BUTxCFd0XST9OgBD3xVyp7Jmvbx42xzHjrwCmEFda4NmDBgAVzo8 Cf+khuVoWiAdQBJgqZqVWL0JGpoPh/y/H+c1vzMgz3hQIwsFR0nK/5z5ETrTK/2P3fBo beQF3A4K5oZenoPy2p63p742miBhsrm1kHqX70ld9goQdYZ8pAR1yAIaCUnGBYWdjKKz wLHRoyJQkV0Z+DLa0Pv+l7ZqDCQONjJKofzsLCQEVA7gSyOb0nWkukUVWEA8Y/FFLWcN cPtKHQ+z9huSwgByUKAa+dmpEvsdxs7izEdTkL1lv8IuD1m3cndj7R3ZTJFIpmA01ou6 lABw==
X-Gm-Message-State: AOAM532YkOifXOPkG+PhU/KUGrUJuQdEX/Z+we23+PG8+B3oOdVCG0UL q7LI25PzehAHMSD1HZ31vlgd9QjHvE/laLO9tmppY9kdO7w=
X-Google-Smtp-Source: ABdhPJwZjQ5S9rD3rFgQkL6EVlAn1LVCK3xJYKPzc/6f10yyokGU801r4L1bOzENi4LarDeX362YY3nnGTi97Qu3xKg=
X-Received: by 2002:a05:6e02:1546:: with SMTP id j6mr1184291ilu.223.1636401148757;  Mon, 08 Nov 2021 11:52:28 -0800 (PST)
MIME-Version: 1.0
References: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl>
In-Reply-To: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl>
From: Job Snijders <job@fastly.com>
Date: Mon, 8 Nov 2021 20:52:18 +0100
Message-ID: <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ea66a05d04c550f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/rv4xY8gmRpjSWNcmpR1zqKOg6dM>
Subject: Re: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2021 19:52:35 -0000

--0000000000002ea66a05d04c550f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim, others,

I think you bring up a good idea.

Should you proceed to capture this idea in an internet-draft, I=E2=80=99d l=
ike to
offer a recommendation how to formalise the syntax: please use ABNF (
https://datatracker.ietf.org/doc/html/rfc5234) to describe the notation
format.

With some luck, such a human notation format becomes the de facto format
(or at least an inspiration) for multiple open source/commercial BGP
implementations when they consider the CLI/UI aspect of their respective
2021-2022 ASPA projects.

Indeed, down the road this might make life easier for future operators who
wish to statically configure ASPA entries on their BGP edge routers.

Kind regards,

Job

On Mon, 8 Nov 2021 at 14:47, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:

> Hi,
>
> The nice work done by Oliver and team triggered me to ask the
> question whether there would be value in having a well defined
> human notation for ASPA object content.
>
> As I mentioned last Friday we have added experimental ASPA
> support to the new Krill release candidate. As part of this
> we also invented a human readable notation for use with the
> CLI:
>
>
> https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.ht=
ml#aspa-configuration-notation
>
> TL;DR -> two examples:
>
> AS65000 =3D> AS65001, AS65002(v4), AS65003(v6)
> AS65001 =3D> <none>
>
> So, note that we assumed that we would have an explicit empty
> list, rather than AS0, which is described here using '<none>'.
>
> So, to repeat the question:
> Do we think there is value in defining a notation like this?
>
> If so, this may help operators when they use different
> implementation and/or components. I am open to change..
>
> If not, then implementations can just use their local
> ways to describe.
>
> Thanks
> Tim
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>

--0000000000002ea66a05d04c550f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Tim, others,</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I think you bring up a good idea.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Should you proceed to capture this idea in an internet-=
draft, I=E2=80=99d like to offer a recommendation how to formalise the synt=
ax: please use ABNF (<div dir=3D"auto"><a href=3D"https://datatracker.ietf.=
org/doc/html/rfc5234">https://datatracker.ietf.org/doc/html/rfc5234</a>) to=
 describe the notation format.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">With some luck, such a human notation format becomes the de facto fo=
rmat (or at least an inspiration) for multiple open source/commercial BGP i=
mplementations when they consider the CLI/UI aspect of their respective 202=
1-2022 ASPA projects.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In=
deed, down the road this might make life easier for future operators who wi=
sh to statically configure ASPA entries on their BGP edge routers.</div></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Kind regards,</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">Job</div><div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 8 Nov 2021 at 14:47,=
 Tim Bruijnzeels &lt;<a href=3D"mailto:tim@nlnetlabs.nl">tim@nlnetlabs.nl</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:=
1ex;border-left-color:rgb(204,204,204)">Hi,<br>
<br>
The nice work done by Oliver and team triggered me to ask the<br>
question whether there would be value in having a well defined<br>
human notation for ASPA object content.<br>
<br>
As I mentioned last Friday we have added experimental ASPA<br>
support to the new Krill release candidate. As part of this<br>
we also invented a human readable notation for use with the<br>
CLI:<br>
<br>
<a href=3D"https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage=
-aspas.html#aspa-configuration-notation" rel=3D"noreferrer" target=3D"_blan=
k">https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.h=
tml#aspa-configuration-notation</a><br>
<br>
TL;DR -&gt; two examples:<br>
<br>
AS65000 =3D&gt; AS65001, AS65002(v4), AS65003(v6)<br>
AS65001 =3D&gt; &lt;none&gt;<br>
<br>
So, note that we assumed that we would have an explicit empty<br>
list, rather than AS0, which is described here using &#39;&lt;none&gt;&#39;=
.<br>
<br>
So, to repeat the question:<br>
Do we think there is value in defining a notation like this?<br>
<br>
If so, this may help operators when they use different<br>
implementation and/or components. I am open to change..<br>
<br>
If not, then implementations can just use their local<br>
ways to describe.<br>
<br>
Thanks<br>
Tim<br>
_______________________________________________<br>
Sidrops mailing list<br>
<a href=3D"mailto:Sidrops@ietf.org" target=3D"_blank">Sidrops@ietf.org</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidrops" rel=3D"noreferrer=
" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sidrops</a><br>
</blockquote></div></div>

--0000000000002ea66a05d04c550f--


From nobody Tue Nov  9 05:53:16 2021
Return-Path: <job@fastly.com>
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 D3C403A0D58 for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 05:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 8rBwTJchzWMA for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 05:53:01 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 DD93D3A0D2F for <sidrops@ietf.org>; Tue,  9 Nov 2021 05:53:00 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id g14so76320089edz.2 for <sidrops@ietf.org>; Tue, 09 Nov 2021 05:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:subject:message-id:mime-version:content-disposition;  bh=duQTxob5bHa3R394ZRnIKD05kxv8TH/dXc5zwHgXIzY=; b=U1FOGDFPVlD0XZowvLz34uKb8JmuKNCxfLTp//dvuz89hK/G73EgIbdBWPDUuOg4iF KVymCXpe7WZwmWT3iEeFqUzlPOl3+lGeQtTmJZRinPCY6EDyrqPoHR7/UxGYdCCozmy9 oMdirUrWIZ3pD+TMHUSICo9nFr+USxOHOsMPI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=duQTxob5bHa3R394ZRnIKD05kxv8TH/dXc5zwHgXIzY=; b=WTu3YkmblC+JLzlqdm3NKITXTyqM6Bgf2wMLrlitN94rbO9dN+X2qqlv/AQYZ7NRGD KbRgztMBVb3mFpBpQKK8rOY+IWpiqg2YatVBZi0otbYraX/BsovSMkqt7/bBepPatdqN m/thWYl8mkpEjI4sOMH5dCTDNQETNdF4uRrzHrC8ou9booKGefeH0VGddY5Ln0zHaVYq JzGwWk9kQt+li+dH9kSAsHwG2V4IGqggfKTFOwc3ynajmzzZPu8vAMfMwKzl8RawGWrB o7d4ZPpMinIgcZIJs/snivJ2EH68y3f4LjquuNF2j+VdRNMDq5JDDl98OhEtpBMTwFy+ zFGA==
X-Gm-Message-State: AOAM532V6cBU4eG+xN31MS7f+3tAJo4ra0EClpuODN43rgknb1G0WirC U842KhicpwArIG241FpUTmqWaN0nreUpcAtjxwi5IgiulcKBsCtLeekomVtAEY42jJF2dFWetX/ DnuM7+mW6tDHJA5M6CEeGzrs8o1EwdKsi11jW3U9SqRIfb6uwhsMSzhI=
X-Google-Smtp-Source: ABdhPJwFzZONUZjzVaXt0pHdjwMFkHkgsWcBYmSJyCXz0JF+18lUK5h/2d2Y81QZyQ0KYXkrAEHwlw==
X-Received: by 2002:a17:906:82c5:: with SMTP id a5mr9948806ejy.127.1636465974037;  Tue, 09 Nov 2021 05:52:54 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id hw8sm7649616ejc.58.2021.11.09.05.52.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Nov 2021 05:52:53 -0800 (PST)
Date: Tue, 9 Nov 2021 14:52:52 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YYp9NJkyMdFiF/7+@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/q1cP95f0UoTAoA9wAgUWJ4srWh8>
Subject: [Sidrops] IANA Assignment for draft-ietf-sidrops-aspa-profile
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 13:53:11 -0000

Dear all,

IANA graciously made a permanent registration in the SMI Security for
S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1

Henceforth, ASPA objects will be known as OID 1.2.840.113549.1.9.16.1.49

The ASPA filename extension is ".asa": https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes

Thanks to Amanda, Keyur, and Russ!

Kind regards,

Job


From nobody Tue Nov  9 08:48:34 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 0F4E53A0CBC for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 08:48:33 -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, 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=student.utwente.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 2LdiOAxkK3ob for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 08:48:28 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 ADD563A0CB9 for <sidrops@ietf.org>; Tue,  9 Nov 2021 08:48:27 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id v11so76835131edc.9 for <sidrops@ietf.org>; Tue, 09 Nov 2021 08:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=mime-version:from:date:message-id:subject:to; bh=CojobinxTYJ1Q53goeVVUv8DuQmLKGh1+6Djv8Zmlec=; b=PJXwxkVkPOG7s1XpstyC5TtZSDx+E7RwNMN6rHw9Uj0GdNH0rkR0CabYGr7f4/aa3I ZCQQSJRQ4cA3zeoEagj/8CkHcasrpPDczOeysjhvjaXm+2OAQgiGkSRSQ5YoFFEei1tI kngvglQz0PFOLEqcwmH7NXDpFaxBt5lYtId0CUZkPF8MeSMXlSdSC1Y1uNABwzauR+CS 20gAwlG9kAyfj5ggunkTtAL3ni30Fg7rqHsZETTY59U8xRWEh1r7v28vt2bOWOtfUeqP u50fenG5VRviPPzMRnx11AJREHlSz//3HgFZMtqehbXmpjPktW8R5e49tiFMN2TMmlNh kXIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CojobinxTYJ1Q53goeVVUv8DuQmLKGh1+6Djv8Zmlec=; b=APUm6996T6dqEFpnWx125Ao//FyGezjG3WWHfjyK3JLvlY5/Kk+aSzlZnjrtiPjWsv 8AtlrfOJuEe1ui1z+VAJYKBUQZGjcjTsgVjYFRKP6D2XpGlWneVeT0M1t26DAUSRi4H0 A4YHX5NO8nOyl9KhnopFqoolT17d8VoFMnzx4jM6/rEto6WcAJKNhdwf0EILFrsUkmlO AGs40ftVboqvCJV4A5PIBOrpQSxXVhypngWicU/S+4yGX7TGZSCDzYvi4XaulhX45ozf WcZlSswQuxNPYACQh6ng/Ln4XT3YnL9nQbbTSweBx0gBKK+3W+TfocIxRPg3Rr7gkTj/ nSiw==
X-Gm-Message-State: AOAM532dglVQdO+sg1cKqP1j2cbQssn8y9k2v2zC8ACB4OJStlyd1/px bfUYJvtD6FMFd09kzAnKFIYspWhiY0dpm+FfwPIHaFEvfL+DyA==
X-Google-Smtp-Source: ABdhPJyIRxnJrKiwSsHBoCHd+FdJkDqe4l5hmPQMh4SsBfHX6poWVCt2Gwdt7fEDh6FLAoxAw8ZbXuUEn7rKzl3cZ3A=
X-Received: by 2002:a50:f18c:: with SMTP id x12mr11769819edl.357.1636476504539;  Tue, 09 Nov 2021 08:48:24 -0800 (PST)
MIME-Version: 1.0
From: Koen van Hove <k.w.vanhove@student.utwente.nl>
Date: Tue, 9 Nov 2021 17:48:12 +0100
Message-ID: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
To: sidrops@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FCttiTVor2IpXuqiGljuoN66Xio>
Subject: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 16:48:33 -0000

Dear all,

Let me quickly introduce myself, my name is Koen van Hove from the
University of Twente. Some of you might know me from other channels.

Recently there have been a couple discussions about limits. I found
two issues regarding limits that may be problematic for the
availability of RPKI, and to kill two birds with one stone, I propose
the "RPKI Tree Hints" draft, which can act as a framework for future
limits in RPKI. Here is a direct link:
https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/

Issue 1
=======
Every CA in RPKI can have one or more children, who in turn can have
children, etc. Several implementations already impose limits on the
depth of this chain, the most restrictive currently being 12. However,
if a CA goes wide and deep, then due to the exponential growth in the
number of repositories, a shallow depth might suffice to disrupt RPKI.
Imagine the following: a CA has 10 children, who all have 10 children,
ad infinitum. At six layers deep, this already means RPs have to
traverse 111,111 repositories. As I control these repositories, I can
of course make sure that this process is not exactly quick. If I make
every repository take 10 seconds, which is not unreasonable for
current repositories, then this process would already take over 12
days to complete. If instead we use 15 children, then it takes several
years. I believe I do not say anything controversial when I say that
this is too long, and can severely harm the availability of RPKI.

The difficulty in solving this is that having 15 children is in and of
itself nothing special, and nothing that should raise alarm bells.
Limiting this using a global value would severely hinder the
flexibility of the RPKI structure in the future. As the structure is
unknown before walking the tree, discovering this using heuristics is
tricky, and bound to give headaches for many years to come.

Issue 2
=======
The RP retrieves the ROAs, parses them, and then sends them to the
router via RTR. Let us imagine that I own a /48 (which to my knowledge
is not too difficult to obtain). I can split that /48 in 2^80 /128s,
or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do
that for all 2^32 possible ASNs, creating 2^113 entries in total. This
all has to go over RTR and into the router, and contemporary routers
are to my knowledge not capable of processing such a large amount of
information.

Limiting either the prefixes or ASNs globally is going to be
difficult, as there are legitimate cases where a lot of ASNs are used,
or a lot of different prefixes, but when everyone does that it becomes
a problem.

To solve these two issues, I propose a new object that enables parents
to provide hints about their children (and their descendants). This
way, if a malicious child does something unusual, an RP can detect it
without it impacting the other honest CAs.

I am interested to hear your thoughts on both the issues, as well as
the proposed solution. After all, many roads lead to Rome.

Yours sincerely,
Koen van Hove


From nobody Tue Nov  9 09:39:42 2021
Return-Path: <cjeker@diehard.n-r-g.com>
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 2339A3A0E4A for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 09:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 0Pnb2Q-vJbsu for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 09:39:36 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB84C3A0E18 for <sidrops@ietf.org>; Tue,  9 Nov 2021 09:39:35 -0800 (PST)
Received: (qmail 21831 invoked by uid 1000); 9 Nov 2021 17:39:27 -0000
Date: Tue, 9 Nov 2021 18:39:27 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: sidrops@ietf.org
Message-ID: <YYqyTzjY1hyeH09l@diehard.n-r-g.com>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5IacfL1aYx4et41IxGK4T_qtj9g>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 17:39:41 -0000

On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
> Dear all,
> 
> Let me quickly introduce myself, my name is Koen van Hove from the
> University of Twente. Some of you might know me from other channels.
> 
> Recently there have been a couple discussions about limits. I found
> two issues regarding limits that may be problematic for the
> availability of RPKI, and to kill two birds with one stone, I propose
> the "RPKI Tree Hints" draft, which can act as a framework for future
> limits in RPKI. Here is a direct link:
> https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
> 
> Issue 1
> =======
> Every CA in RPKI can have one or more children, who in turn can have
> children, etc. Several implementations already impose limits on the
> depth of this chain, the most restrictive currently being 12. However,
> if a CA goes wide and deep, then due to the exponential growth in the
> number of repositories, a shallow depth might suffice to disrupt RPKI.
> Imagine the following: a CA has 10 children, who all have 10 children,
> ad infinitum. At six layers deep, this already means RPs have to
> traverse 111,111 repositories. As I control these repositories, I can
> of course make sure that this process is not exactly quick. If I make
> every repository take 10 seconds, which is not unreasonable for
> current repositories, then this process would already take over 12
> days to complete. If instead we use 15 children, then it takes several
> years. I believe I do not say anything controversial when I say that
> this is too long, and can severely harm the availability of RPKI.
> 
> The difficulty in solving this is that having 15 children is in and of
> itself nothing special, and nothing that should raise alarm bells.
> Limiting this using a global value would severely hinder the
> flexibility of the RPKI structure in the future. As the structure is
> unknown before walking the tree, discovering this using heuristics is
> tricky, and bound to give headaches for many years to come.
> 
> Issue 2
> =======
> The RP retrieves the ROAs, parses them, and then sends them to the
> router via RTR. Let us imagine that I own a /48 (which to my knowledge
> is not too difficult to obtain). I can split that /48 in 2^80 /128s,
> or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do
> that for all 2^32 possible ASNs, creating 2^113 entries in total. This
> all has to go over RTR and into the router, and contemporary routers
> are to my knowledge not capable of processing such a large amount of
> information.
> 
> Limiting either the prefixes or ASNs globally is going to be
> difficult, as there are legitimate cases where a lot of ASNs are used,
> or a lot of different prefixes, but when everyone does that it becomes
> a problem.
> 
> To solve these two issues, I propose a new object that enables parents
> to provide hints about their children (and their descendants). This
> way, if a malicious child does something unusual, an RP can detect it
> without it impacting the other honest CAs.
> 
> I am interested to hear your thoughts on both the issues, as well as
> the proposed solution. After all, many roads lead to Rome.

While interesting this can already be solved by the parent CA pulling the
plug on such bad CA repo. This is very simple to implement (removing the
certificate from the parent repository and issue a new manifest).
It would require that the RIRs monitor their part of the tree (which would
be generally a good idea).

Additionally for issue 2 it makes little sense to have VRPs for routes
that are filtered in the DFZ. At least every network admin I know limits
prefix lenght on transit and peering links.

The problem here is that parent publication points need to take
over more responsibility. There is a general weakness in a design that
starts with untrusted input and tries to produce trusted output.
It would be better to have at least some limit on what is fed into the
validator software. At least it seems to be a better plan than
implementing a complex system to impose per CA limits.

Also some of the limits are questionable like minTransferSpeed or
maxTransferSize. The transfer speed of a download can vary a lot and is
not under the control of the publisher of such a limit (all connection
limits have a similar issue). For the transfer size, it depends on the
protocol used and is limited by the maxRepositorySize which gives a upper
bound.

-- 
:wq Claudio


From nobody Tue Nov  9 11:53:53 2021
Return-Path: <tdekock@ripe.net>
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 C533D3A104D for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 11:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=ripe.net
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 YEsMP90lH9Gu for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 11:53:45 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 2EAAE3A1047 for <sidrops@ietf.org>; Tue,  9 Nov 2021 11:53:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=mmfiPGEaF1SqOwKTs9i5VFY1+PaFBuvkQifGG6b0Tp0=; b=ghvcU0EnsHbaWyrPl65bC128 7xvVbJpXTxx1cMVS4OARwGmrLp2Cbh/BubNee/pQD+tlfrPG1p6dAMhrANjRl8YqHqyN9HGIg2Ydr D2dZlvd9mUOe/b7QUxhqK5pXxLHe7nKhwalkITryNgFohaU9ebI97MN3xc7gSkNusPJDCK6JCMq4G 7zZqSBJbepVJWyyJLEF18+0sNzwf7yW2gjvNcOjM3n8wk8uka32uQFogEtBHpj/xmkCMqF+V19LSA BdQdmnqQGZ5K1ttfNcoQkDs13jhn7f6s9gp657mIoaNawfWDfldLumnx8GsqMft8KCkMt3vXwgzWs ynhPw3Yydg==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:43172) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mkXBb-000BWo-Ad; Tue, 09 Nov 2021 20:53:39 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mkXBb-0001Fr-7C; Tue, 09 Nov 2021 20:53:39 +0100
From: Ties de Kock <tdekock@ripe.net>
Message-Id: <92A6852A-5009-461C-B939-700381282249@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_36EDC45F-7091-46C8-9C75-342D59A959CF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 9 Nov 2021 20:53:38 +0100
In-Reply-To: <YYqyTzjY1hyeH09l@diehard.n-r-g.com>
Cc: Koen van Hove <k.w.vanhove@student.utwente.nl>, sidrops@ietf.org
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYqyTzjY1hyeH09l@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e18cb82e9d4cee51ed79c7a2e99d76efcb
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/hl8BPxaIaFj1AHtkSr02OIO2zsQ>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 19:53:51 -0000

--Apple-Mail=_36EDC45F-7091-46C8-9C75-342D59A959CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 9 Nov 2021, at 18:39, Claudio Jeker <cjeker@diehard.n-r-g.com> =
wrote:
>=20
> On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
>> Dear all,
>>=20
>> Let me quickly introduce myself, my name is Koen van Hove from the
>> University of Twente. Some of you might know me from other channels.
>>=20
>> Recently there have been a couple discussions about limits. I found
>> two issues regarding limits that may be problematic for the
>> availability of RPKI, and to kill two birds with one stone, I propose
>> the "RPKI Tree Hints" draft, which can act as a framework for future
>> limits in RPKI. Here is a direct link:
>> =
https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
>>=20
>> Issue 1
>> =3D=3D=3D=3D=3D=3D=3D
>> Every CA in RPKI can have one or more children, who in turn can have
>> children, etc. Several implementations already impose limits on the
>> depth of this chain, the most restrictive currently being 12. =
However,
>> if a CA goes wide and deep, then due to the exponential growth in the
>> number of repositories, a shallow depth might suffice to disrupt =
RPKI.
>> Imagine the following: a CA has 10 children, who all have 10 =
children,
>> ad infinitum. At six layers deep, this already means RPs have to
>> traverse 111,111 repositories. As I control these repositories, I can
>> of course make sure that this process is not exactly quick. If I make
>> every repository take 10 seconds, which is not unreasonable for
>> current repositories, then this process would already take over 12
>> days to complete. If instead we use 15 children, then it takes =
several
>> years. I believe I do not say anything controversial when I say that
>> this is too long, and can severely harm the availability of RPKI.
>>=20
>> The difficulty in solving this is that having 15 children is in and =
of
>> itself nothing special, and nothing that should raise alarm bells.
>> Limiting this using a global value would severely hinder the
>> flexibility of the RPKI structure in the future. As the structure is
>> unknown before walking the tree, discovering this using heuristics is
>> tricky, and bound to give headaches for many years to come.
>>=20
>> Issue 2
>> =3D=3D=3D=3D=3D=3D=3D
>> The RP retrieves the ROAs, parses them, and then sends them to the
>> router via RTR. Let us imagine that I own a /48 (which to my =
knowledge
>> is not too difficult to obtain). I can split that /48 in 2^80 /128s,
>> or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do
>> that for all 2^32 possible ASNs, creating 2^113 entries in total. =
This
>> all has to go over RTR and into the router, and contemporary routers
>> are to my knowledge not capable of processing such a large amount of
>> information.
>>=20
>> Limiting either the prefixes or ASNs globally is going to be
>> difficult, as there are legitimate cases where a lot of ASNs are =
used,
>> or a lot of different prefixes, but when everyone does that it =
becomes
>> a problem.
>>=20
>> To solve these two issues, I propose a new object that enables =
parents
>> to provide hints about their children (and their descendants). This
>> way, if a malicious child does something unusual, an RP can detect it
>> without it impacting the other honest CAs.
>>=20
>> I am interested to hear your thoughts on both the issues, as well as
>> the proposed solution. After all, many roads lead to Rome.
>=20
> While interesting this can already be solved by the parent CA pulling =
the
> plug on such bad CA repo. This is very simple to implement (removing =
the
> certificate from the parent repository and issue a new manifest).
> It would require that the RIRs monitor their part of the tree (which =
would
> be generally a good idea).

While CAs must monitor their part of the tree, they can not reliably =
detect a
_malicious_ repository. It is trivial to present a split view and decide =
what
parties should observe what version of the tree.

An attacker can pick what instance they attack. An attacker can choose =
what
objects to present. Even if there were an audit log (with associated =
reduced
availability), an attacker could choose what set of objects to combine =
for a
client, changing their effects.

Furthermore, I think the recent "natural experiment" also shows that =
many RP
instances are not monitored as acutely as they should be. Many RP =
instances
do not recover when they crash, and the usage of the affected RP was =
still
significantly lower on 1-11.

>=20
> Additionally for issue 2 it makes little sense to have VRPs for routes
> that are filtered in the DFZ. At least every network admin I know =
limits
> prefix lenght on transit and peering links.
>=20
> The problem here is that parent publication points need to take
> over more responsibility. There is a general weakness in a design that
> starts with untrusted input and tries to produce trusted output.
> It would be better to have at least some limit on what is fed into the
> validator software. At least it seems to be a better plan than
> implementing a complex system to impose per CA limits.

I agree that you can apply limits there and at least one of the =
implementations
already filters by /24 and /64. However there are other ways to create a =
large
number of effective objects. I would take this issue as an example of a =
class of
issues.

Picking thresholds for heuristics is hard. Picking the wrong value for a =
limit
(for example maximum object size) can cause an RP instance to lose a =
large part
of the tree for an extended period of time. Picking one value for a =
limit that
is needed at the top of the tree likely is unsafe when abused by a =
forest of
sub-CAs.

I think some method of applying heuristics selectively from a point in =
the
three downward is needed, and this draft proposes one such approach. I =
also see
why you want to delegate this responsibility instead of letting the RIRs =
control
it completely.

Kind regards,
Ties
>=20
> Also some of the limits are questionable like minTransferSpeed or
> maxTransferSize. The transfer speed of a download can vary a lot and =
is
> not under the control of the publisher of such a limit (all connection
> limits have a similar issue). For the transfer size, it depends on the
> protocol used and is limited by the maxRepositorySize which gives a =
upper
> bound.
>=20
> --=20
> :wq Claudio
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org <mailto:Sidrops@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidrops =
<https://www.ietf.org/mailman/listinfo/sidrops>

--Apple-Mail=_36EDC45F-7091-46C8-9C75-342D59A959CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 9 Nov 2021, at 18:39, Claudio Jeker &lt;<a =
href=3D"mailto:cjeker@diehard.n-r-g.com" =
class=3D"">cjeker@diehard.n-r-g.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
charset=3D"UTF-8" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove =
wrote:</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">Dear =
all,<br class=3D""><br class=3D"">Let me quickly introduce myself, my =
name is Koen van Hove from the<br class=3D"">University of Twente. Some =
of you might know me from other channels.<br class=3D""><br =
class=3D"">Recently there have been a couple discussions about limits. I =
found<br class=3D"">two issues regarding limits that may be problematic =
for the<br class=3D"">availability of RPKI, and to kill two birds with =
one stone, I propose<br class=3D"">the "RPKI Tree Hints" draft, which =
can act as a framework for future<br class=3D"">limits in RPKI. Here is =
a direct link:<br class=3D""><a =
href=3D"https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree=
-hints/" =
class=3D"">https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-t=
ree-hints/</a><br class=3D""><br class=3D"">Issue 1<br =
class=3D"">=3D=3D=3D=3D=3D=3D=3D<br class=3D"">Every CA in RPKI can have =
one or more children, who in turn can have<br class=3D"">children, etc. =
Several implementations already impose limits on the<br class=3D"">depth =
of this chain, the most restrictive currently being 12. However,<br =
class=3D"">if a CA goes wide and deep, then due to the exponential =
growth in the<br class=3D"">number of repositories, a shallow depth =
might suffice to disrupt RPKI.<br class=3D"">Imagine the following: a CA =
has 10 children, who all have 10 children,<br class=3D"">ad infinitum. =
At six layers deep, this already means RPs have to<br class=3D"">traverse =
111,111 repositories. As I control these repositories, I can<br =
class=3D"">of course make sure that this process is not exactly quick. =
If I make<br class=3D"">every repository take 10 seconds, which is not =
unreasonable for<br class=3D"">current repositories, then this process =
would already take over 12<br class=3D"">days to complete. If instead we =
use 15 children, then it takes several<br class=3D"">years. I believe I =
do not say anything controversial when I say that<br class=3D"">this is =
too long, and can severely harm the availability of RPKI.<br =
class=3D""><br class=3D"">The difficulty in solving this is that having =
15 children is in and of<br class=3D"">itself nothing special, and =
nothing that should raise alarm bells.<br class=3D"">Limiting this using =
a global value would severely hinder the<br class=3D"">flexibility of =
the RPKI structure in the future. As the structure is<br =
class=3D"">unknown before walking the tree, discovering this using =
heuristics is<br class=3D"">tricky, and bound to give headaches for many =
years to come.<br class=3D""><br class=3D"">Issue 2<br =
class=3D"">=3D=3D=3D=3D=3D=3D=3D<br class=3D"">The RP retrieves the =
ROAs, parses them, and then sends them to the<br class=3D"">router via =
RTR. Let us imagine that I own a /48 (which to my knowledge<br =
class=3D"">is not too difficult to obtain). I can split that /48 in 2^80 =
/128s,<br class=3D"">or 2^79 /127s, etc. In total I will have ~2^81 =
entries. I can also do<br class=3D"">that for all 2^32 possible ASNs, =
creating 2^113 entries in total. This<br class=3D"">all has to go over =
RTR and into the router, and contemporary routers<br class=3D"">are to =
my knowledge not capable of processing such a large amount of<br =
class=3D"">information.<br class=3D""><br class=3D"">Limiting either the =
prefixes or ASNs globally is going to be<br class=3D"">difficult, as =
there are legitimate cases where a lot of ASNs are used,<br class=3D"">or =
a lot of different prefixes, but when everyone does that it becomes<br =
class=3D"">a problem.<br class=3D""><br class=3D"">To solve these two =
issues, I propose a new object that enables parents<br class=3D"">to =
provide hints about their children (and their descendants). This<br =
class=3D"">way, if a malicious child does something unusual, an RP can =
detect it<br class=3D"">without it impacting the other honest CAs.<br =
class=3D""><br class=3D"">I am interested to hear your thoughts on both =
the issues, as well as<br class=3D"">the proposed solution. After all, =
many roads lead to Rome.<br class=3D""></blockquote><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">While interesting this can =
already be solved by the parent CA pulling the</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">plug on such bad CA repo. This =
is very simple to implement (removing the</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">certificate from the parent repository and issue a new =
manifest).</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">It would =
require that the RIRs monitor their part of the tree (which =
would</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">be generally =
a good idea).</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""></div></blockquote><div><br class=3D""></div><div>While =
CAs must monitor their part of the tree, they can not reliably detect =
a</div><div>_malicious_ repository. It is trivial to present a split =
view and decide what</div><div>parties should observe what version of =
the tree.</div><div><br class=3D""></div><div>An attacker can pick what =
instance they attack. An attacker can choose what</div><div>objects to =
present. Even if there were an audit log (with associated =
reduced</div><div>availability), an attacker could choose what set of =
objects to combine for a</div><div>client, changing their =
effects.</div><div><br class=3D""></div><div>Furthermore, I think the =
recent "natural experiment" also shows that many RP</div><div>instances =
are not monitored as acutely as they should be. Many RP =
instances</div><div>do not recover when they crash, and the usage of the =
affected RP was still</div><div>significantly lower on =
1-11.</div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Additionally for issue 2 it makes little sense to have VRPs =
for routes</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">that are =
filtered in the DFZ. At least every network admin I know =
limits</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">prefix lenght =
on transit and peering links.</span><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">The problem here is that parent publication points need to =
take</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">over more =
responsibility. There is a general weakness in a design that</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">starts with untrusted input and =
tries to produce trusted output.</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">It would be better to have at least some limit on what is fed =
into the</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">validator =
software. At least it seems to be a better plan than</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">implementing a complex system to =
impose per CA limits.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div><div>I agree that you can apply limits there and =
at least one of the implementations</div><div>already filters by /24 and =
/64. However there are other ways to create a large</div><div>number of =
effective objects. I would take this issue as an example of a class =
of</div><div>issues.</div><div><br class=3D""></div><div>Picking =
thresholds for heuristics is hard. Picking the wrong value for a =
limit</div><div>(for example maximum object size) can cause an RP =
instance to lose a large part</div><div>of the tree for an extended =
period of time. Picking one value for a limit that</div><div>is needed =
at the top of the tree likely is unsafe when abused by a forest =
of</div><div>sub-CAs.</div><div><br class=3D""></div><div><div>I think =
some method of applying heuristics selectively from a point in =
the</div><div>three downward is needed, and this draft proposes one such =
approach. I also see</div><div>why you want to delegate this =
responsibility instead of letting the RIRs control</div><div>it =
completely.</div></div></div><div><br class=3D""></div><div>Kind =
regards,</div><div>Ties</div><blockquote type=3D"cite" class=3D""><div =
class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">Also some of =
the limits are questionable like minTransferSpeed or</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">maxTransferSize. The transfer =
speed of a download can vary a lot and is</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">not under the control of the publisher of such a limit (all =
connection</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">limits have a =
similar issue). For the transfer size, it depends on the</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">protocol used and is limited by =
the maxRepositorySize which gives a upper</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">bound.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">--<span class=3D"Apple-converted-space">&nbsp;</span></span><br=
 style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">:wq Claudio</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" =
class=3D"">_______________________________________________</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">Sidrops mailing list</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"mailto:Sidrops@ietf.org" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D"">Sidrops@ietf.org</a><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/sidrops" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" =
class=3D"">https://www.ietf.org/mailman/listinfo/sidrops</a></div></blockq=
uote></div><br class=3D""></body></html>=

--Apple-Mail=_36EDC45F-7091-46C8-9C75-342D59A959CF--


From nobody Tue Nov  9 12:09:07 2021
Return-Path: <housley@vigilsec.com>
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 ABAE03A1079 for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 12:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 QQx-F3VN1YJ7 for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 12:09:02 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739393A106F for <sidrops@ietf.org>; Tue,  9 Nov 2021 12:09:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 83D63300BF4 for <sidrops@ietf.org>; Tue,  9 Nov 2021 15:09:03 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ybpto8r9Houp for <sidrops@ietf.org>; Tue,  9 Nov 2021 15:09:02 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8D429300B38 for <sidrops@ietf.org>; Tue,  9 Nov 2021 15:09:02 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Message-Id: <243AB88A-8211-4134-9387-F1B6A843A1F3@vigilsec.com>
Date: Tue, 9 Nov 2021 15:08:59 -0500
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/SB-UbXHvDClramq9QyjLgORDNIg>
Subject: [Sidrops] Alignment of ASAP to RFC 3779
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 20:09:06 -0000

I was looking at RFC 3779 for something else, and I realized two small =
differences in the ASN.1.  I doubt that these differences would break =
anything, but I'd like them to be the same unless there is a reason.


DIFFERENCE 1: AS Identifier

RFC 3779 uses:

	ASId ::=3D INTEGER

ASPA uses:

	ASID ::=3D INTEGER


DIFFERENCE 2: Address Family Identifier

RFC 3779 uses:

	OCTET STRING (SIZE (2..3))

ASPA uses:

	OCTET STRING (SIZE (2))


Is there any reason for these to be different?

Russ


From nobody Tue Nov  9 12:23:41 2021
Return-Path: <benm@workonline.africa>
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 0C8283A104B for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 12:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=workonline.africa
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 E-g3nTR5sSvk for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 12:23:34 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) (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 106473A1049 for <sidrops@ietf.org>; Tue,  9 Nov 2021 12:23:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DpXy4S14OOUH14uCr6SNLG5+avOs+UsXr6aJ/66elMCWJlzISya0f3DolFtV49HwKvvHUTl4AQSY20Agxw63aVqb/mXNObCz10Rj09OQ0m3dvlunRm7FcDWVCq6/dWOW+Gl0zhEQmtZAFqGyz8TFoAE2sRiyQrurciRz7OSwtclrWdE/1UkWuIJbpbw+teGjb6E8GVB5gFBwWL/LnIo01hHBzDxiIasuhgG1sfW6ROJO6sZHuqhQjRXw9hO+n4l3Z6gTWHBcWleDaDYeWLKZxviaB5LScxlsaiN/0EXZyyjbG9aFggaHabhHB9vmaYKNkDm8+9ICh5vhqz3pQZSpsg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8XpQS046LAmkMhncVy5AyByIu/Unf8KWGWDBohZU6JM=; b=CQV11gQyAcVpqq/K4Mtx6m32g+JHKjJ+pbSfq74kVwOSuWcTeuJaOyQLVBflIrvRdI/LyMzkAJpQp+2cZL+KvmOhXt0kx9gVRuCyzOys1ocg4zZ77JFohuwn/I9m6vVnf9evQoLKGJBKNZjxLG3MlogdENEcRVm0ZD2zqhLDy4DHFNIz2dJ+gH/+7NEVXSDB8fdELVXqn4LRDNshdpo1DSS5mboc6t2S5+gsVWpbhzs6efozqzstcW8I9IYUWes+VQJt5A6cqwnNjtIow4aEDqwJGL1Zj4/VNdL+k4bAlbBcUTrMnXJl0ibS4h+FMbk919FsPmtNlXvjWR1cr0DwnQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8XpQS046LAmkMhncVy5AyByIu/Unf8KWGWDBohZU6JM=; b=DVbmrSmdV3mOPwKKNmua9AowjChGjC9tdmuDdtJdkCryjHBNO6FNjl8+y5TP7aTj6ZUcr7HV1zWPX2MZhZFeOreaWUunclnpW4D7uyxytvmmrEB5UXp4QmPojhB4znyc4hz7XSmneO8yIrSHwGpxJ41+xgXwCF3/pgUS6Yi7f0Y=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa;
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1637.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3fc::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15; Tue, 9 Nov 2021 20:23:29 +0000
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%6]) with mapi id 15.20.4669.016; Tue, 9 Nov 2021 20:23:29 +0000
Date: Tue, 9 Nov 2021 22:23:22 +0200
From: Ben Maddison <benm@workonline.africa>
To: Russ Housley <housley@vigilsec.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20211109202322.gghskcxad4qardsz@benm-laptop>
References: <243AB88A-8211-4134-9387-F1B6A843A1F3@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7sajps3tvus6n42g"
Content-Disposition: inline
In-Reply-To: <243AB88A-8211-4134-9387-F1B6A843A1F3@vigilsec.com>
X-ClientProxiedBy: JNXP275CA0045.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::33) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13)
MIME-Version: 1.0
Received: from localhost (160.119.236.41) by JNXP275CA0045.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11 via Frontend Transport; Tue, 9 Nov 2021 20:23:28 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b826721b-8fa0-4385-7d1e-08d9a3becac8
X-MS-TrafficTypeDiagnostic: AS8P190MB1637:
X-Microsoft-Antispam-PRVS: <AS8P190MB1637BFBEFAFAC8CE241C8A76C0929@AS8P190MB1637.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Xfj9kcHMXtTFBVCYq7MkOpD+MnVpVb4bLqZUFbUnJAMRV70rDbnq4osTXfTCzklikwqspMcDit2fQSPNgPzQTLcN/m2X/fKvwn0xgPuPASqKtTtYdMj4iEURNKJYIC54CDIUqVwaOnp0taja7ISKN/bq8Z5OkHXsy/4EShJ2HAHDFGbDrqjXawyk3+Qt+Pvk214ZAh0vlyM3Dv8tWZB/5u3dR0bwKaF87h75VZrzauG6WypMVvYQ2ZzD29RZBhj9wdKe4yBmWSbOEKxsZcfinLfaQxLesSFmrkncLI9N5/pO9W01aKAHCMujlbvIOXChgyNkCLxzq0fkfKHMLRTA9+3y22Lys4djF1I+UhVD6eKGnqWJ923K89BES67NcgmSc/4etAMghVRomsce+Ld1WWvd0d9sdzhKi3+o08yTS57xw/rFvn/sCOpPr97zzeCmwdWEggPJTS5N+EfXThM5hesgEIJHgL3SqRt+vE702DC09R8CLM8UFdmye2NpQyjekVv7cYXzxbjy5Qb5CXJ1zJXTfK/lf/RFikcAO1OZuR+Y7wxMSmWrwv2bpGrHhMuUgXdx6MxT1BPch/jRoOeyjKHegdCXtXgs4/9M/4Oyk1FZgKtdRhJIm9yoBRoGoCERTQiyVGA4Zmrp43Lem9LZevpca452Yuab/Ls3jcsPCy3PlOcfBnQIU+ZoXdulIWkIvqoYG//pt8ZwYabgCt4kgPxwrX/rKbH/OwxV0oxlbpuPPVogQr5TCqouFa61h+6v
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(7916004)(136003)(346002)(396003)(366004)(39830400003)(376002)(9686003)(6486002)(66556008)(5660300002)(6496006)(38100700002)(66946007)(956004)(66476007)(44144004)(6916009)(33716001)(26005)(21480400003)(38350700002)(186003)(52116002)(86362001)(4326008)(316002)(2906002)(8936002)(8676002)(1076003)(508600001)(6666004)(46492013)(2700100001); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eAe9jxtpKl5wKoBPXP/mcYrazDLo+MujUzDmV207MF8RtRvWhkrqXRwfPP0/?= =?us-ascii?Q?gVY/99e4IRU2xFdEaGOr/m/EyhlMBDNiIpYrp3hJ6P4kIJQWDvO800iK8D2v?= =?us-ascii?Q?DVVN11aK+00+capM9p5vYNZHneQATH5PB879pCt83YQHn1uvVkalsBsjdeAR?= =?us-ascii?Q?qyAvvIOSP2F6vW2Z+8biPqvs7GGxiLd7hBwqFuZoS3n1ULwcgYguaIhROcF3?= =?us-ascii?Q?a5v9H8ayY5tgPdr/jxMur4jfLW7U06m9OX80a9HhKZbl6sZ6ri0kolAlw1Dv?= =?us-ascii?Q?Qc9vBdwj6Em4ElM+IVc9HSq7MuuKLzZI3WRGQKXiBfZJ/cx5cPDrEYdwAvDs?= =?us-ascii?Q?aTZ2Lsi+mcJSbNrd3AbLt59FE18CYayFNqLKuUJeGI6Vwd2ELwXNQMEN31h6?= =?us-ascii?Q?qxK0vE2JapxmvYULRvjZx4lOJP7UUXRHzXeIToPCeMglTCNMj1a0BUI4pzEi?= =?us-ascii?Q?tQYpa+53bSfDZ21ERdYF/zT4+qM4ATSVQwYwdZYKp60xOgNmtBrIFt03gGur?= =?us-ascii?Q?QdCR7MqKqMB9Z34rnYVaC19JPVAYeWCeJ1UIQ2qh26YILT5Kha2CvOK4/tIN?= =?us-ascii?Q?k9pdh/FIp1+Rcp+9Dp814L4eRwdHgecfy170fNRGksRFEPa9WGalIJjgkasR?= =?us-ascii?Q?FKk2ObXsZCqxYTGV/I0R5WIMUTve4i6bLyneodni+48/yJlkmWsN+GnIPEza?= =?us-ascii?Q?YIefNPaXwxVtr77wF8wSQxxfCPDl1JWM7+3Dsq9A+QJtPUKmQSsLHqlzouIM?= =?us-ascii?Q?3C6Noh54doOAp+jI8Jd+BRxe2CJTkMvB7dE+Ke5vVC2UWEMuIAU0bsjK0B8k?= =?us-ascii?Q?sEbrPniS3WRgoS120DFr3PL3ft+/uiyaBEQ/WkmpGkS4IqIT1+JBRvSzuFEa?= =?us-ascii?Q?OFG7/t+V1ChC4Hc13TOwTHr1KroeBnkTErYnycXurinzacn6NWABhjQKahVF?= =?us-ascii?Q?9luMF+Cb04EpvWz05fDHsWfJXSY8p8NoI2Ezd8qo8PLUnr4xiAC0uC6t7NHA?= =?us-ascii?Q?k47ORAI/O4RdRs0HJyP8ZIYsN6WSHXhJFUQP+0Mf/ReAt7Ok/fYTwCJhKk8c?= =?us-ascii?Q?B3wvuIG8vU6HhGeqBjrMygi2ZnyR+RyCGeOF2/52GOvHlOM1lBfYy15ZNoFO?= =?us-ascii?Q?3uTLdUZh8kfYgS6430IK9CG0C5+zcRsCRQvGQiUkMMHugE3opksukiaa1ZOl?= =?us-ascii?Q?DGHIt0ctYTeeeQfZpCQRMYVukrLKpXdtqJnVpGb1JXsTzpu9zt2sfTKlW2Rf?= =?us-ascii?Q?ruHVhV7CdR0KqXNZNeAA9d31nHnV9pL5QvnuEqnxe/n0OYWd+zoY3x4GoBhK?= =?us-ascii?Q?NaqK+LY3mggK2mW2bOQFwhEWiTSk5lBvCXCirB7vp1biPQnW/0LjcAHdIqDy?= =?us-ascii?Q?OccY25IwNEyRclTb8h1iGOT/hTywf7PurLMzCrEh/gHE6zbvgqhEa/mb4B0A?= =?us-ascii?Q?6ifLDgM3yQuUC+1skHzT0gEb2qS4Yiu9ELGEYWyLQTtI/16YwllEOjGtId+5?= =?us-ascii?Q?569o/Un13QEWK5VjlAo+09WA7zi0aEnihCTa3s3RiebUnQS6Udwm0bq9A0Qx?= =?us-ascii?Q?bihFoRyFuCXZsOBBNH5BX5LYn6aVZ+Akxj3ft02GXZ0jDpIJhdy4+V1P5Cjy?= =?us-ascii?Q?bzH8AvGvDPXzs9PSRNrC+d0=3D?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: b826721b-8fa0-4385-7d1e-08d9a3becac8
X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2021 20:23:29.2628 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UulRWrx8bPIXCSYz05zuDqBtfG6X+BGvkSMlrCBh38J9h8gbXQ/o/wZMT2Kc5mrpHLl9QI/oogJnBbY25gtdbw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1637
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/75Ww_KnTLEykaT87GB0dS7NSLlw>
Subject: Re: [Sidrops] Alignment of ASAP to RFC 3779
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 20:23:40 -0000

--7sajps3tvus6n42g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Russ,

On 11/09, Russ Housley wrote:
> I was looking at RFC 3779 for something else, and I realized two small di=
fferences in the ASN.1.  I doubt that these differences would break anythin=
g, but I'd like them to be the same unless there is a reason.
>=20
>=20
> DIFFERENCE 1: AS Identifier
>=20
> RFC 3779 uses:
>=20
> 	ASId ::=3D INTEGER
>=20
> ASPA uses:
>=20
> 	ASID ::=3D INTEGER
>=20
Not that I can see. ASPA should probably use ASId for consistency
(although, since the "ID" is an acronym, the capitals are probably more
appropriate).
>=20
> DIFFERENCE 2: Address Family Identifier
>=20
> RFC 3779 uses:
>=20
> 	OCTET STRING (SIZE (2..3))
>=20
> ASPA uses:
>=20
> 	OCTET STRING (SIZE (2))
>=20
Yes, the SAFI byte is not used in ASPA.

The same is true in a ROA, but RFC 6482 uses SIZE(2..3) despite
explicitly mandating only two 2-octet values in the text:

   Within the ROAIPAddressFamily structure, addressFamily contains the
   Address Family Identifier (AFI) of an IP address family.  This
   specification only supports IPv4 and IPv6.  Therefore, addressFamily
   MUST be either 0001 or 0002.

=2E.. which I find weird, and slightly contradictory.

It would be nice to have an enumeration defined somewhere, that can
simply be IMPORTed, but I don't think that you can enumerate OCTET
STRINGs like you can for INTEGERs, can you?

Cheers,

Ben

--7sajps3tvus6n42g
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmGK2LoACgkQOkYk/rSL
aGDD6RAAhM+V1xLv8A6YAishRLwDf6LgLoRE+hmx2byKD1EOsoUycfwAhNbTjYnb
nl52DfTM9nF7kwDFf7s8zrlPZ6v2tUghzgYU9Fq540QYZl7dth0Mgg5sZNxG0NCo
ZglOqDU0VEYREj2J+V+/11QVQLhR0wpfPz1UirmI0+8TUioWrdDpuQQDHhoM7dYH
4yctJ4icme4sCOiq4UhGauWkm8C8Q91AQH3wmO5cmzvLgTIn8sa4cyssM3T7SPvD
7LY10GTn+yzMqWmUySQnvsq/yAutQEX72oztle5f6V/P6sdv947AUgK8gWkxpPMw
IJBEgF4vSwDU6nTwZ7u0gv5fBqaWmqYY6hk0KuU5UYn9dfDkdX8FOdsQFwD+mAiI
aOafUjA8B/HllF0ctB3195DZWty1x+bnuojltMHrqBZWtS0NBPJBrNGg/bgY1sid
tzzV20hDO0k3LDKe1EUtVWNAy+INARQ5OhLQ+8TiniBW06yRRn2GT2smDUjKycug
ri3EQ23gSf1wEDS/6utMVZ5c3CSP//PO46VkjNDRy8Jubz79+MK2vJc0jqwJTIJz
JmOcZFs8vzgX8GI3/w7SC8RSZGOCziMchWfFDJ9Ymy1//l7oF+oMmWyeOMbutj1N
ZY8sE9UNTZr6LN8EOQD4G/5XklsIE6Mz8C7zsyJfsm5YRvtkKN4=
=wVMj
-----END PGP SIGNATURE-----

--7sajps3tvus6n42g--


From nobody Tue Nov  9 13:40:15 2021
Return-Path: <job@fastly.com>
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 F09323A11E4 for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 13:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 bdUENhb2jKen for <sidrops@ietfa.amsl.com>; Tue,  9 Nov 2021 13:40:04 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 1A8053A11BA for <sidrops@ietf.org>; Tue,  9 Nov 2021 13:40:04 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id ee33so2030983edb.8 for <sidrops@ietf.org>; Tue, 09 Nov 2021 13:40:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DCq9pUpAjHzFVv0HcRW7xAaDViJDTG2mT6J/AKyg/uY=; b=Kn7Wr9zRm5vYGl8gyiHaogYX/iUsywyK1vysIuP6QyYj5tHKfBFnj/V3e+M6Y6lRAj uXGJf7GBMxVMRfIul4Y15LTSxYpt3Adp5z9fU5PsyTsRzXtxBjBXBX5J3tF1Dc3hsCHm 4EqYH38P1ioB/OW6GRqWgHc6/F6nHHsmv/UU4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DCq9pUpAjHzFVv0HcRW7xAaDViJDTG2mT6J/AKyg/uY=; b=L3pzwYJdQl46u/wBRtzHQP9LnLAkr4xekUVC9SscLzVcTrQDdrmI/acMml9Y2OIAFN PkDyj3za5BFYZFZ6zuKRRbeFjGXDCGDRpEmFdW011hMvsbfc7a5ZmIB4FDFI6xKlWUY3 U3c3zy0vie4sejs38xRgXKxS+q+wegTyN/0am3goCzG9le8+53jAZxsC1e+53d2/tSEv Hp8SPsxVoyhSAhvvX2xF4j/Q7EhsIUqsJye/PLbGnQZa49Bh9pyaV8oDxDAlqJIhaSTl 9IevQP/cc6Sl/9lexzgHmer8ITOW4Iy+Z6K+0/gf1JmoO/2in9Vlui2bwqsEhcHsaAm9 eDVQ==
X-Gm-Message-State: AOAM532k3p8yX4ZOiDMwIO+5h1Q8U597PwWaINdJRQ2prGE4pz83+fXp VvfwV4Yq3jxXLY14wW8Bm3ED4cEOqS7USg==
X-Google-Smtp-Source: ABdhPJzocWmirUoPkZ5iTnaBmqBLZjGF6CWpWY8ls7HVnp93HUS292xsZk89FoFFkPuuyfAm4QeklQ==
X-Received: by 2002:a17:906:2f09:: with SMTP id v9mr13730558eji.163.1636493997457;  Tue, 09 Nov 2021 13:39:57 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id z25sm5832071ejd.80.2021.11.09.13.39.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Nov 2021 13:39:57 -0800 (PST)
Date: Tue, 9 Nov 2021 22:39:55 +0100
From: Job Snijders <job@fastly.com>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: sidrops@ietf.org
Message-ID: <YYrqq1a0VOWyiMsM@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9LMrkYsuwXcs0nhKDF6J5Sf31Y0>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 21:40:14 -0000

Hi Koen, group,

On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
> Recently there have been a couple discussions about limits. I found
> two issues regarding limits that may be problematic for the
> availability of RPKI, and to kill two birds with one stone, I propose
> the "RPKI Tree Hints" draft, which can act as a framework for future
> limits in RPKI. Here is a direct link:
> https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/

Welcome to the IETF! I appreciate you have joined this community and are
now engaging with the right group of people. Sharing ideas and concepts
by publishing an internet-draft is very helpful for dialogue. Kudos for
taking the effort to write the Tree Hints draft.

> Limiting this using a global value would severely hinder the
> flexibility of the RPKI structure in the future. As the structure is
> unknown before walking the tree, discovering this using heuristics is
> tricky, and bound to give headaches for many years to come.

Good observations, indeed, perhaps there should not be 'global values'
(established through RFCs). An alternative approach is: each implementer
picks their own default limits.

The IETF guidance could be "make sure you set some reasonable limits",
which implementers and operators then take to heart, by ensuring their
software imposes reasonable limits. What constitutes 'reasonable' is
in the eye of the beholder.

Recent versions of OpenBSD rpki-client impose all kinds of limits; these
limits are based on the developers' growth expectations for the next 1
or 2 years, and a bit of highly subjective experience.

Additionally, our expectation is that operators upgrade their RP
instances at least once a year.  (hopefully more frequently as it is
security software!!!! ALWAYS BE UPDATING!!!!) ... Wild idea: as a
security feature, RP implementations could refuse to boot if they
somehow recognize they are older than 2 years.... I digress.

To illustrate the 'hard-coded limits' workflow with an example:

1/ In this announcement we shared some limits: https://mailarchive.ietf.org/arch/msg/sidrops/cFVeb2u1MlYq4PfIsYcoD4a8wks/

2/ One of the SIDROPS participants took note and provided feedback, which resulted in this proposal: https://marc.info/?l=openbsd-tech&m=163645589724336&w=2

3/ rinse repeat

As time goes by we learn, and we'll keep adjusting limits and keep
releasing new versions. This method seems a productive way to keep the
system running. It is better than nothing. :-)

Kind regards,

Job


From nobody Wed Nov 10 00:56:30 2021
Return-Path: <tim@nlnetlabs.nl>
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 95C473A0944 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 00:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 wTqw7EU9YYW7 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 00:56:08 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 4ADC93A0898 for <sidrops@ietf.org>; Wed, 10 Nov 2021 00:56:07 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 2EC5C277; Wed, 10 Nov 2021 08:56:04 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1636534563; bh=jLi+vmY+sl9g0oe4s7pOVvYfLbFzXEir18DO4V65eN0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=R0tvFO9BGyk6mNmOhbhazNk+1xx3sQ0hndNQe/Nsk9qtAOhVlqF2wg1Myd4UQEDUg lR6izbqhU1F4zerG3Z5gEPgX+wnXjwTSP+3XY/ND9hbthxrQHjSIaOzgeeg+5aJbgS FgOxDwlMZuU4Z+jyYa72yLyZ12PRAZAkwU3IGxCC1jKCituu0074/CWjnIz0+Al3Gk iidpHYqTsFH/SbicjPAifsVJ1LzDj7tPcSyb2UlUbujBrKCgXYZVJnUmeXgnHhCyTN BoqM66vAfbeTZhnFprGraeLAectjh0TNlVqjPdy/x0lpoBXkrR9+Swi3Z8yD9O/G0j WhODr3GxEsoOQ==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com>
Date: Wed, 10 Nov 2021 09:56:00 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0AD1B4E-6B3C-495A-B914-5EEF6CA4798E@nlnetlabs.nl>
References: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl> <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Tc44rntLjLus_ynp9RmgUep1x_0>
Subject: Re: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 08:56:16 -0000

Hi Job,

My initial thought on this was that it could perhaps be included in one =
of the
current ASPA drafts. But then I thought again..

This should most likely be an INFORMATIONAL thing - as this is really =
just for
convenience and not critical. And putting this in a separate draft has =
the
advantage that it can be really small and focussed.

So I can draft something up - probably next week - and give people =
something
concrete to shoot at.

Related to this we could also define notations for other object types, =
but
I think it would be best to keep things separate if we do.

Tim

> On 8 Nov 2021, at 20:52, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>=20
> Hi Tim, others,
>=20
> I think you bring up a good idea.
>=20
> Should you proceed to capture this idea in an internet-draft, I=E2=80=99=
d like to offer a recommendation how to formalise the syntax: please use =
ABNF (
> https://datatracker.ietf.org/doc/html/rfc5234) to describe the =
notation format.
>=20
> With some luck, such a human notation format becomes the de facto =
format (or at least an inspiration) for multiple open source/commercial =
BGP implementations when they consider the CLI/UI aspect of their =
respective 2021-2022 ASPA projects.
>=20
> Indeed, down the road this might make life easier for future operators =
who wish to statically configure ASPA entries on their BGP edge routers.
>=20
> Kind regards,
>=20
> Job
>=20
> On Mon, 8 Nov 2021 at 14:47, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> Hi,
>=20
> The nice work done by Oliver and team triggered me to ask the
> question whether there would be value in having a well defined
> human notation for ASPA object content.
>=20
> As I mentioned last Friday we have added experimental ASPA
> support to the new Krill release candidate. As part of this
> we also invented a human readable notation for use with the
> CLI:
>=20
> =
https://krill.docs.nlnetlabs.nl/en/prototype-aspa-support/manage-aspas.htm=
l#aspa-configuration-notation
>=20
> TL;DR -> two examples:
>=20
> AS65000 =3D> AS65001, AS65002(v4), AS65003(v6)
> AS65001 =3D> <none>
>=20
> So, note that we assumed that we would have an explicit empty
> list, rather than AS0, which is described here using '<none>'.
>=20
> So, to repeat the question:
> Do we think there is value in defining a notation like this?
>=20
> If so, this may help operators when they use different
> implementation and/or components. I am open to change..
>=20
> If not, then implementations can just use their local
> ways to describe.
>=20
> Thanks
> Tim
> _______________________________________________
> 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 Wed Nov 10 01:50:21 2021
Return-Path: <tim@nlnetlabs.nl>
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 905763A0C67 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 01:50:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 91KuU1jT0lej for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 01:50:14 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 C78213A0C74 for <sidrops@ietf.org>; Wed, 10 Nov 2021 01:50:13 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 9EF6B277; Wed, 10 Nov 2021 09:50:09 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1636537808; bh=UNwRzDxEwzU8NdClR92dJIVI+wFk0/5L6B/zWYKEMSg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=u/XErQHpHtKS7AJca/94xVKwnscVA+i7ynnpU49ze4nmUPtZe5iTP0oZzFPjVyqQZ tKTVy458Pl5X5e55JSfSRNZsqyF+0oLZ5zl6FJaOIp+e5tGEEZfj5KM4MSnVNwvxgp YVP2uK6xpqEu+tceTtiFNDgv9dkCaFV5GWIx7G8joeagw1H9iBh0qBGNqUNpdcf6BA p7+Lr5Z4pPK3ZM4a6gOV9p4xZjpjE6uGQB7EirTIjvQqGpM0Jp9YuwlcPt7c/u4msz OW2OVm8F3PyUBsXI2FiFpWR3vNBcvxh7dNQ1plvibxsyNwZGaakgo1w1Vah7pFVhl4 WuRFwFPy/778w==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <YYrqq1a0VOWyiMsM@snel>
Date: Wed, 10 Nov 2021 10:50:05 +0100
Cc: Koen van Hove <k.w.vanhove@student.utwente.nl>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <56159567-0C7E-4B88-886B-9EA1779F80A6@nlnetlabs.nl>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYrqq1a0VOWyiMsM@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScAvjQ>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 09:50:19 -0000

> On 9 Nov 2021, at 22:39, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>=20
> Hi Koen, group,
>=20
> On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
>> Recently there have been a couple discussions about limits. I found
>> two issues regarding limits that may be problematic for the
>> availability of RPKI, and to kill two birds with one stone, I propose
>> the "RPKI Tree Hints" draft, which can act as a framework for future
>> limits in RPKI. Here is a direct link:
>> =
https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
>=20
> Welcome to the IETF! I appreciate you have joined this community and =
are
> now engaging with the right group of people. Sharing ideas and =
concepts
> by publishing an internet-draft is very helpful for dialogue. Kudos =
for
> taking the effort to write the Tree Hints draft.
>=20
>> Limiting this using a global value would severely hinder the
>> flexibility of the RPKI structure in the future. As the structure is
>> unknown before walking the tree, discovering this using heuristics is
>> tricky, and bound to give headaches for many years to come.
>=20
> Good observations, indeed, perhaps there should not be 'global values'
> (established through RFCs). An alternative approach is: each =
implementer
> picks their own default limits.
>=20
> The IETF guidance could be "make sure you set some reasonable limits",
> which implementers and operators then take to heart, by ensuring their
> software imposes reasonable limits. What constitutes 'reasonable' is
> in the eye of the beholder.
>=20
> Recent versions of OpenBSD rpki-client impose all kinds of limits; =
these
> limits are based on the developers' growth expectations for the next 1
> or 2 years, and a bit of highly subjective experience.
>=20
> Additionally, our expectation is that operators upgrade their RP
> instances at least once a year.  (hopefully more frequently as it is
> security software!!!! ALWAYS BE UPDATING!!!!) ... Wild idea: as a
> security feature, RP implementations could refuse to boot if they
> somehow recognize they are older than 2 years.... I digress.
>=20
> To illustrate the 'hard-coded limits' workflow with an example:
>=20
> 1/ In this announcement we shared some limits: =
https://mailarchive.ietf.org/arch/msg/sidrops/cFVeb2u1MlYq4PfIsYcoD4a8wks/=

>=20
> 2/ One of the SIDROPS participants took note and provided feedback, =
which resulted in this proposal: =
https://marc.info/?l=3Dopenbsd-tech&m=3D163645589724336&w=3D2
>=20
> 3/ rinse repeat
>=20
> As time goes by we learn, and we'll keep adjusting limits and keep
> releasing new versions. This method seems a productive way to keep the
> system running. It is better than nothing. :-)

I agree that each RP implementation *will* have to apply limits.

That said.. this will lead to differences in implementations which may
cause objects to be considered invalid (or perhaps not be considered at
all) under implementation A, but appear valid under implementation B.

Documenting the decisions as rpki-client did helps. There is also merit
in a public discussion about limits and motivations. I think different =
PR
implementations can benefit from sharing. It may also help operators
if limits are documented somewhere and RPs give clear errors when limits
are applied.

The way I see it though, the tree hints proposal is orthogonal to this.
It would allow CAs to give RPs *additional* hints as to what limits may =
be
applied. RPs should not go beyond their own limits based on these, but =
they
may then know that they can safely apply even more restrictions.

Of course, the parent CAs have the power to revoke a child in case of
abuse (or hanlon's razor for that matter). But this is by definition =
reactive.
The tree hints would give RPs more 'pro-active' information. And of =
course,
the parent CAs could (perhaps should) then still monitor their children. =
And,
if they would use an RP that honours the defined tree hints, then this =
could
really help them to detect issues quickly.

As an aside: for this to work well I think we should also consider =
extending
the RFC 6492 provisioning protocol so that child CAs can be told by =
their
parents what their limits actually are..

Tim







>=20
> Kind regards,
>=20
> Job
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Wed Nov 10 02:08:41 2021
Return-Path: <ggm@algebras.org>
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 9F7BE3A0CCB for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=algebras-org.20210112.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 lcOrbJqVocNv for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:08:34 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 869713A0CB4 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:08:34 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id k37so4775903lfv.3 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:08:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vn3tFU/helo3Thy1O8P42gAQaCExLId1rPL+ojyOAAc=; b=oBSM48uwIuegOxVcGIWiErJ4fsxED4TvU/HhcinHfPbw3UPTsqrlAgKGXFPI0LRlho Tyvk73p9b2FL6UByEwoXIsmT1zpThVuWqy+FYtCQ1R+QJMtaH1KSR3fk8pWU+M867ujl agaMOhv88DSYAXe6NYwIsYCmb1vEvsEczmilLB6PCMuVVfAbr+R83UrNHiOv9xwJKi1g tyEDAOD3smAa+oMcNFtCm74bKL1HIJCTiHu8K9h1+6d5/uEV5wo3RKUTgfMYDvKq74Qm CT0LgOLZz/i5+1fm1ePAQpkRqHwnJgEGX/FYepVmVpQrtC9I/ntyCF/4KeUagNvk5fq+ wOTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vn3tFU/helo3Thy1O8P42gAQaCExLId1rPL+ojyOAAc=; b=qYTATz1W9QYBx2ZRO62PHKn7it96BNAQgHrU68RlSJz0hDZwLTBqAjs3yElSYvzm+p vXk0oprr8Vk8XYWvRVsbvO6IjaxYOe3dQA/w8lwblkJm/mLRK83ZmLsmaNsoo1FEeWg5 m72iBZ0Rh1EithQ7UV0ANRAB8nnYJuetq6V1hDCHjuR32ZupIjRbQrCVoEsBPoq3ch6g Q9Sq9cY07RS7f/03Zo7Z21TJ/1/XxYrxBI8fgsIvnti1S3o8JEJlPHsoYCHUHGYevOm6 PDWZsWVkSxES2qYAVyzNJuAWvQOnWyF89r64bmLAGTAfWCEIAJ0lk2nIaWzJ4xi+fDRd 2QHQ==
X-Gm-Message-State: AOAM531omT1KI/9isrpcNr0grC75rCRwJcluDfMqb4qJr+JPA3bNaKSh PZL4KH2KT1t2OthHFUBuHVpwgdHo3tAJvDALYMW9HGXIvE0=
X-Google-Smtp-Source: ABdhPJzHnDhu/ep62zqBs/ki1xOnbiSmu6IuIXDa6IkTq6cIVJuoP8dZZxgRKDXBRCe2t2Z6Biu4TPEsruTBznczWUA=
X-Received: by 2002:a05:6512:3416:: with SMTP id i22mr13491358lfr.4.1636538911904;  Wed, 10 Nov 2021 02:08:31 -0800 (PST)
MIME-Version: 1.0
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
In-Reply-To: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
Date: Wed, 10 Nov 2021 20:08:20 +1000
Message-ID: <CAKr6gn0TD7cX4UNA=zWSaa4-74U7pn5aQTZ_FrQp_PntdHrkWg@mail.gmail.com>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000816e0605d06c68a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FIEY7VTNVEVrSmDByCy-PnqwwB0>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 10:08:40 -0000

--000000000000816e0605d06c68a4
Content-Type: text/plain; charset="UTF-8"

Well formed mandatory extensions can be useful. A good rule which 3779
brings to the table is "only subsets, no extras" so a rule on defined
limits encoded by parent signing could be made more restrictive but not
less.

I don't like purely arbitrary magic numbers, but it's possible this has to
float for a while between RPs and OPs  before it settles. I personally
think encoded, magic numbers in the spec process here is OK, maybe a
least-worst outcome.

G

On Wed, 10 Nov 2021, 2:48 am Koen van Hove, <k.w.vanhove@student.utwente.nl>
wrote:

> Dear all,
>
> Let me quickly introduce myself, my name is Koen van Hove from the
> University of Twente. Some of you might know me from other channels.
>
> Recently there have been a couple discussions about limits. I found
> two issues regarding limits that may be problematic for the
> availability of RPKI, and to kill two birds with one stone, I propose
> the "RPKI Tree Hints" draft, which can act as a framework for future
> limits in RPKI. Here is a direct link:
> https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
>
> Issue 1
> =======
> Every CA in RPKI can have one or more children, who in turn can have
> children, etc. Several implementations already impose limits on the
> depth of this chain, the most restrictive currently being 12. However,
> if a CA goes wide and deep, then due to the exponential growth in the
> number of repositories, a shallow depth might suffice to disrupt RPKI.
> Imagine the following: a CA has 10 children, who all have 10 children,
> ad infinitum. At six layers deep, this already means RPs have to
> traverse 111,111 repositories. As I control these repositories, I can
> of course make sure that this process is not exactly quick. If I make
> every repository take 10 seconds, which is not unreasonable for
> current repositories, then this process would already take over 12
> days to complete. If instead we use 15 children, then it takes several
> years. I believe I do not say anything controversial when I say that
> this is too long, and can severely harm the availability of RPKI.
>
> The difficulty in solving this is that having 15 children is in and of
> itself nothing special, and nothing that should raise alarm bells.
> Limiting this using a global value would severely hinder the
> flexibility of the RPKI structure in the future. As the structure is
> unknown before walking the tree, discovering this using heuristics is
> tricky, and bound to give headaches for many years to come.
>
> Issue 2
> =======
> The RP retrieves the ROAs, parses them, and then sends them to the
> router via RTR. Let us imagine that I own a /48 (which to my knowledge
> is not too difficult to obtain). I can split that /48 in 2^80 /128s,
> or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do
> that for all 2^32 possible ASNs, creating 2^113 entries in total. This
> all has to go over RTR and into the router, and contemporary routers
> are to my knowledge not capable of processing such a large amount of
> information.
>
> Limiting either the prefixes or ASNs globally is going to be
> difficult, as there are legitimate cases where a lot of ASNs are used,
> or a lot of different prefixes, but when everyone does that it becomes
> a problem.
>
> To solve these two issues, I propose a new object that enables parents
> to provide hints about their children (and their descendants). This
> way, if a malicious child does something unusual, an RP can detect it
> without it impacting the other honest CAs.
>
> I am interested to hear your thoughts on both the issues, as well as
> the proposed solution. After all, many roads lead to Rome.
>
> Yours sincerely,
> Koen van Hove
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>

--000000000000816e0605d06c68a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Well formed mandatory extensions can be useful. A good ru=
le which 3779 brings to the table is &quot;only subsets, no extras&quot; so=
 a rule on defined limits encoded by parent signing could be made more rest=
rictive but not less.<div dir=3D"auto"><br></div><div dir=3D"auto">I don&#3=
9;t like purely arbitrary magic numbers, but it&#39;s possible this has to =
float for a while between RPs and OPs=C2=A0 before it settles. I personally=
 think encoded, magic numbers in the spec process here is OK, maybe a least=
-worst outcome.</div><div dir=3D"auto"><br></div><div dir=3D"auto">G</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Wed, 10 Nov 2021, 2:48 am Koen van Hove, &lt;<a href=3D"mailto:k.w.vanhov=
e@student.utwente.nl">k.w.vanhove@student.utwente.nl</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
Let me quickly introduce myself, my name is Koen van Hove from the<br>
University of Twente. Some of you might know me from other channels.<br>
<br>
Recently there have been a couple discussions about limits. I found<br>
two issues regarding limits that may be problematic for the<br>
availability of RPKI, and to kill two birds with one stone, I propose<br>
the &quot;RPKI Tree Hints&quot; draft, which can act as a framework for fut=
ure<br>
limits in RPKI. Here is a direct link:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tr=
ee-hints/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://datatrac=
ker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/</a><br>
<br>
Issue 1<br>
=3D=3D=3D=3D=3D=3D=3D<br>
Every CA in RPKI can have one or more children, who in turn can have<br>
children, etc. Several implementations already impose limits on the<br>
depth of this chain, the most restrictive currently being 12. However,<br>
if a CA goes wide and deep, then due to the exponential growth in the<br>
number of repositories, a shallow depth might suffice to disrupt RPKI.<br>
Imagine the following: a CA has 10 children, who all have 10 children,<br>
ad infinitum. At six layers deep, this already means RPs have to<br>
traverse 111,111 repositories. As I control these repositories, I can<br>
of course make sure that this process is not exactly quick. If I make<br>
every repository take 10 seconds, which is not unreasonable for<br>
current repositories, then this process would already take over 12<br>
days to complete. If instead we use 15 children, then it takes several<br>
years. I believe I do not say anything controversial when I say that<br>
this is too long, and can severely harm the availability of RPKI.<br>
<br>
The difficulty in solving this is that having 15 children is in and of<br>
itself nothing special, and nothing that should raise alarm bells.<br>
Limiting this using a global value would severely hinder the<br>
flexibility of the RPKI structure in the future. As the structure is<br>
unknown before walking the tree, discovering this using heuristics is<br>
tricky, and bound to give headaches for many years to come.<br>
<br>
Issue 2<br>
=3D=3D=3D=3D=3D=3D=3D<br>
The RP retrieves the ROAs, parses them, and then sends them to the<br>
router via RTR. Let us imagine that I own a /48 (which to my knowledge<br>
is not too difficult to obtain). I can split that /48 in 2^80 /128s,<br>
or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do<br>
that for all 2^32 possible ASNs, creating 2^113 entries in total. This<br>
all has to go over RTR and into the router, and contemporary routers<br>
are to my knowledge not capable of processing such a large amount of<br>
information.<br>
<br>
Limiting either the prefixes or ASNs globally is going to be<br>
difficult, as there are legitimate cases where a lot of ASNs are used,<br>
or a lot of different prefixes, but when everyone does that it becomes<br>
a problem.<br>
<br>
To solve these two issues, I propose a new object that enables parents<br>
to provide hints about their children (and their descendants). This<br>
way, if a malicious child does something unusual, an RP can detect it<br>
without it impacting the other honest CAs.<br>
<br>
I am interested to hear your thoughts on both the issues, as well as<br>
the proposed solution. After all, many roads lead to Rome.<br>
<br>
Yours sincerely,<br>
Koen van Hove<br>
<br>
_______________________________________________<br>
Sidrops mailing list<br>
<a href=3D"mailto:Sidrops@ietf.org" target=3D"_blank" rel=3D"noreferrer">Si=
drops@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidrops" rel=3D"noreferrer=
 noreferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sidrop=
s</a><br>
</blockquote></div>

--000000000000816e0605d06c68a4--


From nobody Wed Nov 10 02:37:12 2021
Return-Path: <job@fastly.com>
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 3E4B63A0D5F for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 Q197cEDvdAMP for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:37:06 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 36C5A3A0D61 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:37:06 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id m14so8892021edd.0 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:37:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=vS7LstDnh1NlcvxVFwcUqKhXgnt0Qzp07ThTPyzy9UQ=; b=WicH7oE7Jju+z7qN+FCK2YST4fDcZsXv4vVrmn3WUjk/pllJsNAHmZNH3SDgmyhcPJ 756lHf6b0rtwyPcTWV+p4xbj9gyOkb893HQziTjhHNgZEzv4x0VMs/OMolHAICVJfQVP 0ZTqC577oswKfa3grUVkyVV1yJ/e5CLd6Q3yU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=vS7LstDnh1NlcvxVFwcUqKhXgnt0Qzp07ThTPyzy9UQ=; b=cip68RQmONfz6pAF+6Tr0A1CvAId14JFAGzjNxs8nyble+OXWo4x+Xii2YHNSkCjX6 3w46u3o3+N4cFOPi6YDhrwdJboivlWUw3tSefkhTHnp5nzR43Pn4USrlUE80aJVH+qwK uqnk/yzGuHW9OaLTlLNBCDwOW3NlQcfnUKUrUM8MVkhGtLKj4Nqy7UBmynW8y/lm1YgP PrgujxUoGmPeFdLiH78mgh7iOk/bmwPxAUEFsdVigNtFZqAGxkDEpphSmz7oeR2Krn+s 5IHQ2LyllQMfIZ2E/Bi+nY5lKwCI5Kw51z6nxM7SXNZmJUbE8FQu0SbhxyhvLnxSyuQc xJrg==
X-Gm-Message-State: AOAM533Xs8p04V8/dvamjoOqRY2NmMzLD1E6vRY1ptQsHZbMqtXSSJKK +V7zUelnJLQejTIgxTktBaj+MhFJxjRAcw==
X-Google-Smtp-Source: ABdhPJxXQwBSsQ9xWuL7Thwa9DDT9LDnT/wHlpugVHuZAj3NCj/DvS6nkHDyz0dW2JtUO68TeWpDFA==
X-Received: by 2002:a17:907:1dd5:: with SMTP id og21mr19904717ejc.233.1636540623654;  Wed, 10 Nov 2021 02:37:03 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id eg33sm12471622edb.77.2021.11.10.02.37.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 02:37:03 -0800 (PST)
Date: Wed, 10 Nov 2021 11:37:01 +0100
From: Job Snijders <job@fastly.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: Koen van Hove <k.w.vanhove@student.utwente.nl>, sidrops@ietf.org
Message-ID: <YYugzcpTgi9Orfo/@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYrqq1a0VOWyiMsM@snel> <56159567-0C7E-4B88-886B-9EA1779F80A6@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <56159567-0C7E-4B88-886B-9EA1779F80A6@nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-aVHZhS9OTT_25skCckHoP547aE>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 10:37:11 -0000

Hi all,

Let's make some todo items:

1/ The tree-hints draft should be amended and define a new X.509 v3
information access extension containing an AccessDescription to the Tree
Hints Distribution Point. Inspiration can be taken from "X509v3 CRL
Distribution Points". I think it is important a robust arc exists from
the CA to the applicable Tree Hints object. Merely listing a Tree Hints
object on a manifest is too lose of a coupling for my taste.

2/ Reduce Section 6 to the bare minimum.  Antoine de Saint-Exupéry once
said "Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away." Remove at least:
connectionRetryCount, connectionTimeout, connectionTransferTime, and
minTransferSpeed.

3/ The "NRO Engineering Coordination Group"
(https://www.nro.net/technical-coordination/) should consider and
prepare a position on whether the Trust Anchors are willing to impose
limits on their children. If for one reason or another the RIRs are not
willing to declare limits, this effort is dead in the water anyway. If at
least some of the RIRs have appetite to continuously monitor their tree
and issue appropriate Tree Hints, I'm willing to invest time on the RP
side.

Kind Regards,

Job


From nobody Wed Nov 10 02:41:09 2021
Return-Path: <robert@ripe.net>
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 32F203A0D6F for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.429
X-Spam-Level: 
X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, 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=ripe.net
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 aJmAb7zpBN3g for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:41:03 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 EA38A3A0D6A for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:Subject:From:To:MIME-Version:Date:Message-ID:CC ; bh=vFYS0yIbpSFkDz9bxwDX73FyqBFiRof/q2lJ/bsxl8s=; b=J4HG0RQGppwcqEhkqsRpvzVH esgHjCO0n/f8i1y4nIg/7uSqqvuUHST+ytAVSm5/40/GPVN9PU4X34T35PpDHf3TJgutPuXsUs/2r DqNBt6Q0v0V6gJaG9yU6rffK4TS7Edn2dA8OwbVquBfn/jBg+ubs2GCQozidltPCPN980jw8gB014 112h70KIkeVru5vM7oqYXyGitzrkhTGBFs2jTtYFjqvzvyzdrgJoO9asw6VGpU5l4Py+gU4t+Z9eP Rf/7K6LikYZmOkIRQHNTvYvbsSNM14qkNcqMKtiMLtKPnF5WneyoIcED4SxOals/IMSWSUV1cUqOv /lu4JS96KA==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:50352) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <robert@ripe.net>) id 1mkl2I-000AIx-Or for sidrops@ietf.org; Wed, 10 Nov 2021 11:40:58 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPV6:2001:67c:2e8:1200::865]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <robert@ripe.net>) id 1mkl2I-000674-MJ for sidrops@ietf.org; Wed, 10 Nov 2021 11:40:58 +0100
Message-ID: <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net>
Date: Wed, 10 Nov 2021 11:40:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-GB
To: sidrops@ietf.org
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
From: Robert Kisteleki <robert@ripe.net>
Organization: RIPE NCC
In-Reply-To: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2742f0faa9ccdcfe35b06daae3a247fb611
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QH5tocTnqs8cdA4qv45sgoaPIYs>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 10:41:08 -0000

On 2021-11-09 17:48, Koen van Hove wrote:

> Recently there have been a couple discussions about limits. I found
> two issues regarding limits that may be problematic for the
> availability of RPKI, and to kill two birds with one stone, I propose
> the "RPKI Tree Hints" draft, which can act as a framework for future
> limits in RPKI. Here is a direct link:
> https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/

I'm not a fan of this approach. I believe enforcing such limits in a 
hierarchical fashion is a ticking time bomb. For example restricting the 
size of *all descendants* may work well for a while, but at some point 
in time a (grand)child naturally grows beyond it and will just be 
automatically rejected because of these restrictions.

In addition, what should operators *do* in this situation, particularly 
if the limit was specified some levels above in the hierarchy? Change 
requires the (manual) cooperation of multiple levels - while the 
"suffering" repo owner may not even have a direct relation to the 
"enforcing" CA.

Similarly, prescribing minimum bandwidth requirements between 
essentially random hosts on the network is unlikely to work in practice.

I believe such limits should be specified / enforced in client software, 
where the operator has direct control in case something is amiss. And as 
others mentioned CAs do have the power to deal with deliberately abusive 
clients anyway.

Robert


From nobody Wed Nov 10 02:53:04 2021
Return-Path: <job@fastly.com>
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 069223A0D75 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 ozCchaf3jJLO for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:52:57 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 AA8FD3A0D6D for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:52:57 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id o8so8853526edc.3 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:52:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wCf3KXutYvhSGATkyGau1eWSvvUpOGTOa8Zx1xkzzcQ=; b=vnT9icaZpfb4Jl0YWWAjo7R8DS9NcgzlkI0BZ0v3jyzvro51C+eLqpLRk47GoHu1rf YRBrrXwn2xSSdv5w292csh1+cyUPKwNXY8FT8F1SWJBMffZC+CmsdFJESiw5HXFYdCSd smaPZoj6UPh2rVoq99mRlzI9YcXoLPP+cK9eM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wCf3KXutYvhSGATkyGau1eWSvvUpOGTOa8Zx1xkzzcQ=; b=zjrbtN/5P40NIevHB/lDZtfmE0cLgKz6oR1QwqNxgsg++JNrN76DBMwQ1bWjZxBlUr 2HCOqzm/Cx0BG36s7dCzck6nmHdFVn/gKH7ECsFRqtlvDGi4wHlb9BV4B4xLqc7tjJ7F NPn63iLNgXuaGnPx2CEoLwe+zMTzqeC9lQ5xxwMRm3c4BsC5wC7fca7HYEKQIJe+r5IM 7N8t1hdXHgOp9EYVyYbc6b2p70WmVbFXaehnBOl3YjC3eUSrjCotm0ZY24F3Me+krCcs aOzLeIuk3LALpLfVtWOYH3M3wsLMandcX4IEwDv9jfmZoO8E7Xm2k3wMKOCmEKdyEzGe 3hpA==
X-Gm-Message-State: AOAM533vJJa4slIgY4vJoocNweixxbM2l0EuyhiGN2354POR1+rKqJYw 5Tt0tvh+cfcmbDTkMU3v3PD22vZlaRy47m8AOJJD5SBh7vovBT2HHBTTAA9G5itkMO0ujwbEuVv 34BdLLmdUTONJuo6qYaD6+sIwvd7xc6UIJrcVzwR9ujV98JnRT5sYaW0=
X-Google-Smtp-Source: ABdhPJxYKil5we40o5nXk9DMaL9j11NEfnI0UFNYSifcuzSBQJG58ibCJf7e8nTKTrk7cSxF0jw/vA==
X-Received: by 2002:a05:6402:2920:: with SMTP id ee32mr20321533edb.136.1636541574670;  Wed, 10 Nov 2021 02:52:54 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id h17sm14373301ede.38.2021.11.10.02.52.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 02:52:54 -0800 (PST)
Date: Wed, 10 Nov 2021 11:52:52 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YYukhKHqusxVE1bY@snel>
References: <YYp9NJkyMdFiF/7+@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YYp9NJkyMdFiF/7+@snel>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/XJCVD-B3pVvAZ_JC3xQhk79LAZw>
Subject: Re: [Sidrops] IANA Assignment for draft-ietf-sidrops-aspa-profile
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 10:53:02 -0000

Hi all,

The OID has been submitted to LibreSSL and OpenSSL

https://github.com/openssl/openssl/pull/17002

https://github.com/openbsd/src/commit/1bce098d5bb44c900e6c57abeb66f35026dfc307#diff-b90813b7cc35f885ca764a8da4119d79254ba476ca6918343cd7fb47e179fc6e

Kind regards,

Job

On Tue, Nov 09, 2021 at 02:52:52PM +0100, Job Snijders wrote:
> Dear all,
> 
> IANA graciously made a permanent registration in the SMI Security for
> S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry at
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1
> 
> Henceforth, ASPA objects will be known as OID 1.2.840.113549.1.9.16.1.49
> 
> The ASPA filename extension is ".asa": https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes
> 
> Thanks to Amanda, Keyur, and Russ!
> 
> Kind regards,
> 
> Job


From nobody Wed Nov 10 02:57:14 2021
Return-Path: <job@fastly.com>
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 632B93A0D75 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 xbwChibJSH07 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 02:57:06 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 94F433A0D71 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:57:06 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id ee33so8812376edb.8 for <sidrops@ietf.org>; Wed, 10 Nov 2021 02:57:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZbU326jCV7b+ep+xZFHsp5WN9XtQ1oaD5NNT1rWITIM=; b=krjhviWc0vrPV8THREncXqtPDvKgmOtI4u0UOfpaKRUkSJ2IjD6DRS/8ykOT35IaDo CMzRLVhjf40LQbV642YQuhLdZTG9BJGr/U9QQefWOSYe/Zbu5bz9HWMYqVERakcwgXDu poy0YYSsmTcZzcnT4aGh4MRjaV+9WkOvK7UBw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZbU326jCV7b+ep+xZFHsp5WN9XtQ1oaD5NNT1rWITIM=; b=7nCiSk+s+Ubm38+/Tga8XFPt7i/aij8h/5taZNpwhGoHFTuD+5ItTPAgClA1oHnpO3 ZXroBqxcLNHTkLAAYbWQryqCVJjbPnVMe5GeWkDFymP/m4PlHKhu4KGkcSL5x4PwmFCL lGfggn8pFxPFdA2OGEPnfeqrUpR9L2HmpgpeyTPP5Lk1e1j6CVK1yO+e45UmS2sIGYX3 kJhbMu+Xf/SZj5hCAJq/szGKpFZXMGscwJg4RCoQDKfw5sTZOnkPIsjlsrpGdGTWI1fc pN6AVkIIL5kNt57yDOaP6eEPHdblAOSXkjY9+I40OnPYb7QjkwMZ+fOZW1Cc9ymjKfV8 qtKA==
X-Gm-Message-State: AOAM530WvqkzPi6ip2roZwVSbOD55VMLKrXjKKOuqp8lb8KRi6hipGz/ jlJ4Wh2YK/JlkbBOd/x+4Ze5NA==
X-Google-Smtp-Source: ABdhPJxbJaRUkYjlwS3GzP7AfeELjgivjz+xIxH1dUmjSMTpPyh43gTVt6lfcRitIbzHoH1JhKY0kA==
X-Received: by 2002:a17:907:7d88:: with SMTP id oz8mr19928336ejc.173.1636541824204;  Wed, 10 Nov 2021 02:57:04 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id b11sm13270647ede.52.2021.11.10.02.57.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 02:57:03 -0800 (PST)
Date: Wed, 10 Nov 2021 11:57:02 +0100
From: Job Snijders <job@fastly.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <YYulfnPb/HOzYIDv@snel>
References: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl> <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com> <B0AD1B4E-6B3C-495A-B914-5EEF6CA4798E@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B0AD1B4E-6B3C-495A-B914-5EEF6CA4798E@nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BVWW2boYY_w8StjIenG8Z6IohjM>
Subject: Re: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 10:57:12 -0000

On Wed, Nov 10, 2021 at 09:56:00AM +0100, Tim Bruijnzeels wrote:
> This should most likely be an INFORMATIONAL thing - as this is really
> just for convenience and not critical. And putting this in a separate
> draft has the advantage that it can be really small and focussed.
> 
> So I can draft something up - probably next week - and give people something
> concrete to shoot at.

nice!

> Related to this we could also define notations for other object types, but
> I think it would be best to keep things separate if we do.

agreed.

Kind regards,

Job


From nobody Wed Nov 10 03:54:19 2021
Return-Path: <job@fastly.com>
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 AEDBE3A0E7B for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 03:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 r-yXpfJoPYUG for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 03:54:13 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 EA2973A0E7C for <sidrops@ietf.org>; Wed, 10 Nov 2021 03:54:12 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id z21so9467891edb.5 for <sidrops@ietf.org>; Wed, 10 Nov 2021 03:54:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+aYmpqA7Q7WLBZ0TEz5D7FOpmVVJxlLQMiG6wWx4Qic=; b=rei2Py5OLN5SN9cY7HruTt6nG7JlP+/o3ORcLqlSQCQi1rOnBAGcf/WMDI8w53aWJd yPxV7E72JsPUk0b6RiwleOp9dIGR7J+LtEiCBIY9kitVtNNiOGl8cSV3pBIxD3H9KnnB U7AZUBtFSdl5ef8JC7r180sebmAr+KDW4rZD0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+aYmpqA7Q7WLBZ0TEz5D7FOpmVVJxlLQMiG6wWx4Qic=; b=w+S79gndNIcuKaCv0VNBfX4VTAST8tvevjb4Q3dkW1TXXE+1BJ+UtfqxvzF3lPIfPL +KOh/YjZoGCdb0OTY0CH3yjhpsNzYmX05HMUlYFid9FDFeB5QFdVdfUuKf4iflYL1Ojn 9dVo5iIyL0f1rO/pZgMxzaFYMTjh8ilBOsgaqUQzcuRO56rNwOZXHRCEAHFbhlL8pZSX k67PpqIiI/7kxQZfk6Qa4ROMMPqzoxhEZMPscsIpfhw5cXDRR3LvTCVMi9S1eiBo7U3d rPDM/vQ0O4wRSTWacQf+XkkhFi/OvPE+Hy8uSAw2gNTCZT6b8v+xgsozrqrA/AA2kTdV QKGw==
X-Gm-Message-State: AOAM530M2Wxi4wOp3KDpMK64WAPojmkqm2XkpB6/qfOgZ3//5qSBDMyq hNJdQ/k/0gFxYGVVhaOrDcO/t7lnb4VshA==
X-Google-Smtp-Source: ABdhPJw08KtiX5mn4Bbq8IyK29qGjXtlM1YNrDtsaYe3yN/cEMLv58CTeV4rNbYqUMa48JGWWtmNQQ==
X-Received: by 2002:a17:906:6088:: with SMTP id t8mr19758006ejj.537.1636545246378;  Wed, 10 Nov 2021 03:54:06 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id g10sm12490150edr.56.2021.11.10.03.54.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 03:54:05 -0800 (PST)
Date: Wed, 10 Nov 2021 12:54:04 +0100
From: Job Snijders <job@fastly.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <YYuy3GiuEZJtUpJD@snel>
References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <C80AF40F-7F86-4156-8915-5694D745AD31@nlnetlabs.nl> <YXWCvDSGSPHaPpZ9@snel> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <YXWfgwuZ7bG24hye@snel> <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RQTi6TbyRQtYpfaigA5OA0JJNvg>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 11:54:18 -0000

Hi Tim, others,

On Wed, Oct 27, 2021 at 12:40:36PM +0200, Tim Bruijnzeels wrote:
> To the second point. The rsync library support may not be an issue
> for rpki-client, and the new openrsync implementation. But it is an
> issue that has been felt by many other RP implementers.

For me new information came to light which I thought I should share with
this group. Jeroen Massar pointed me to even more rsync implementations.

    "rsyn" - Wire-compatible rsync client in Rust
    https://github.com/sourcefrog/rsyn

    "rsync-os" - port of rsync written in Go, with object storage
    https://github.com/kaiakz/rsync-os

I can't vouch for the quality and applicability of the above software
packages, however it seems to me that if there is a desire to remove the
'exec()' dependency on an external rsync binary, there might be a path
for various RP implementers active in this working group.

Some of the rsyn/rsync-os work appears to have been inspired by the
existence of openrsync! It's a funny world :-)

Kind regards,

Job


From nobody Wed Nov 10 04:45:25 2021
Return-Path: <oliver.borchert@nist.gov>
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 8036D3A0ED6 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level: 
X-Spam-Status: No, score=-3.101 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, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-1, 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 FKEJpJ31t177 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:45:19 -0800 (PST)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on20726.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::726]) (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 8E6FD3A0E2D for <sidrops@ietf.org>; Wed, 10 Nov 2021 04:45:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=COfeQhDLSFUWvrfcieqy6VQcXyf5lOKJFez7O/C2jrfGhN7gBj6heS/4tAixMthHHo0ZKl3nVjIVM54rKUqJFqvKxrbAcQJ+IvpDFxkU6CuNeullAJk23+1zpYitvJedn1rZiFezAJUaU76ZiCeTDl22Nikbp7hPuAJjQO0zNnNu0L74L4e6QaTQjGcGYo8LvKWQzzYfS6DGysnYuoOo0OYghxx3vC2XabQEfMufUU6WKYIHud2y3Zn2FiWZ7d+rmdm8YyJSERdTBWKz2UKGvpsFxA3jugxTqtQ/EtyIKtGaaMA3jXZ4aFYEUgGg/iTaDEb3a8jZC1a/2A6jeipzYg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QRgW0TMTg2/4Cu87wByS8QpzZD9sG3/7hwCwVkY4U5E=; b=TrsILLM3YCnZ4gQYsh38Wj6jvqPGYnQNE/rCF8FZuLuY8u3VdK3Tg9ZM+dzFycCv54Im4tU6DROTudbRWw0XJLtWJeBIe9mPKIZS7yCbLUX5KN7cgaIYK9NQku6IrMrLuYjiwA0V3v6bPTki3uaISvMFrVNGx2gj71EXpDuetYoQ2aRwsHpdod5nQGVP0xC3tJZFrVusSfUOJRGqipPBr18aSdSefE1oEMU6kLQqif4AjkJv778BazGQIDQPwyTH7j1ZVb6YNUKvVOboMeNAvSGr5GDhRJD9MG7qbRaGfHwX1/VWc3cI+BsXCegKr4NW06lcHm9at6M40D0HQzEVUw==
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=QRgW0TMTg2/4Cu87wByS8QpzZD9sG3/7hwCwVkY4U5E=; b=A7m3DfOJqMIrX1qJEl1E7/PyCXWRgrNRfx+VBfcFFbjlUt+/sQ5SlYbM4oRBM6wlioF/LyOfgD/szl23f7pH53OWyi3IcSn9GczhWOfq8M5Br3wxzd4n6DYhC+4xSlCzO/HLlecAngym99hzrsyis7QvSLSebQKIlzkQOg9pKKE=
Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6563.namprd09.prod.outlook.com (2603:10b6:208:2a4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.17; Wed, 10 Nov 2021 12:45:14 +0000
Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4690.016; Wed, 10 Nov 2021 12:45:14 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>, SIDR Operations WG <sidrops@ietf.org>
CC: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] ASPA human notation format needed?
Thread-Index: AQHX1KdmLJrjvBdGGE23KklsBc+CEav8ZHuA
Date: Wed, 10 Nov 2021 12:45:14 +0000
Message-ID: <29D4EDC6-CBEC-4FCA-B5E0-F06B424BE376@nist.gov>
References: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl>
In-Reply-To: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c79038d8-026f-4676-589e-08d9a447f117
x-ms-traffictypediagnostic: BLAPR09MB6563:
x-microsoft-antispam-prvs: <BLAPR09MB656343DE3242493E65D16CED98939@BLAPR09MB6563.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iRmaQfJ8A6r3GEPdVegEj7oL61xVOOfUhzIP2GuiJLeW5Buytt1exH4plVgqHUO+q1u/LLtd3gLjVqtGXa25XlaolVy26hKS1H3UQdlG0PLx2J5s8wXyINDiRzDxhWbLuZ9aAmQrfN5sJEwBwymeJkPtNc/pkTumJicyWf9gNWOBy7sUjwg3yv19TECCfXGWoFFwXiEQ3Z0PQZnojRkELw8Fpr1iqnkowYx1lJ5V0ahouSHGroHQsBbqURNhUuZTSPYok+s0ikXD8zg4E/N8MRw8A97eN2wWzxTCW8f4Usm4g2DHs5wJVW2CzHWTL5dXz9Oa2kgmEHjRz3eemdCNq5QAQxDWrKfuu4IzqelgrW+NfQSsVYhVNCSiUuzWKK1IfsKD3Y9jjU0PQ/TI4mLGTS4as4Qys3ZwiT85vy/NwByKQc8ARihsrzhTj8UyzNKXX5RcwZpeHIDbv3JyFj1d02a38V2BZfccARocDsa3V3+vR31UrS9v3y5uLTeo18Yo9t4jRSE98p34usnj6/jkW8kl109zVAu2n56KCeIyf2e6zD2y3ygncli+Oq+Azglg3w5C5DCqHD7sajpk70Gao/0XzOF2FaFwAHPc3Cu2hFIxQgtCjj3aNM7bkmWXjo+gTdcPNvPpaHhgVj2EShSlt7MmULj2DI2URHvKLuDHEvasb1xIy9o5c3lrP+OZ9Y1ZXmFWYdLDojhfGYD6NLhzdDAYN90lENuen4908zej+Xyhngp+V1Jw5X5ftvxMVcNcfhYfk7f3Cm+/MkpiKfs4PcmcR+IPtW46fPF3GXsfwiEtnFchNt2jJxw3OhhXEPr1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(45080400002)(2906002)(82960400001)(5660300002)(8936002)(107886003)(38070700005)(966005)(2616005)(4326008)(6512007)(33656002)(508600001)(110136005)(316002)(40140700001)(186003)(86362001)(6486002)(38100700002)(36756003)(66476007)(66946007)(66556008)(64756008)(122000001)(76116006)(66446008)(6506007)(8676002)(71200400001)(45980500001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VGFzQ0djTVMwUFVHOGVic1FHY1loYW1LakU2VkpmZUNodGkxT2h6dXpnaEN1?= =?utf-8?B?VTdkRFdUQ3pwbUZwNEdleVM1TGtZdS9oeHJzUGVkdTJPME1oSGdBUEJOMVN4?= =?utf-8?B?cXFXaThIeDZaQ0w2Z0NPMEFlaVNDNVdnbXY3NnN4SVdPbFlHSUt6YS9mZE9o?= =?utf-8?B?ckFuVDlscE00eFlqbUVnQXJ6TnRWclkyMG5LaFkwYkZxMjFIWmVTREVLMEQ0?= =?utf-8?B?SHlHQkFPUTJzWHQvMTJBZ2JJVStFMXNNcnlpUTU1cll5c3F6aXU0NHl5MUth?= =?utf-8?B?UGRvMlBra1JEUzBWY3FVd242dHNDVy9RQXFOdWNPbUhVT1BxNlNOZzZka2Zq?= =?utf-8?B?d2hqaG9EcnZvdWxMYnUweWtHTkl1WFZVZTBkNk9jMEthelVPT1IwUGlNSUVj?= =?utf-8?B?bzZFa3drT2xHaEJBaTluTVNZY3orbXdKRTVtd1dzZVlzc2VtTTMrVmtMMno3?= =?utf-8?B?bk5LQ1RVUE5mU0ZoQy9HY3h2Q3hCQ2FjSVAveEZmbGg5bjkvRWJORU96SGtQ?= =?utf-8?B?d3JKREQyWVhFdnFIRTRqd1JpUFBvLytBZTYraHZka1RWY21oTzVKbHJ1Z1Vp?= =?utf-8?B?eUZiSFhXOVgxYTZ6b1hrcm1ZUE9lYWJZNnJCOE9UaU96SURCWlBmTVNpUU85?= =?utf-8?B?NTNDMkZudEljSXJWS01jY1d2enBiMFFUeTVSRmRYTVdNVTNrRjNmUDU1bWV3?= =?utf-8?B?N0dPcllnbWppVUpRQ2RXZW1IcERQRlVYa2FZY0FIRWpuZ05IODFvVHpmdTVh?= =?utf-8?B?SHBObWdNMSttUFBhZ2tIZHpadHhvejJRREFmY3AvSVRwTk9iVUpBZTNqSnl3?= =?utf-8?B?K2NVZWhWRnFzRGM2K1ZmWStRL1hWQ0ZDcXpZT3lqYUVNYzdvck5jdmlmb1M5?= =?utf-8?B?N0NOSStENkpmeW9pUG15UWRYTzFRU2tocGtPWlNxNUw4VEpsYTV2b3RXdENR?= =?utf-8?B?WFFyM21aQ2c1WFlpUHgyMEtVbDU4bzVaSUZiOUUrTlBkV0pjRjVZN2hMM1F0?= =?utf-8?B?TS9oMll0K3Z2d0hsM3NHSE5RUGNacW41Tzd0VFp4eE9xVW5rN1Jwd0VwMUJp?= =?utf-8?B?TWlXN3pGaXc3bXU0MWZCZERjam9jMzE3VmVRTCs5ckFEOFhVRVBwSDlmdity?= =?utf-8?B?S3RzUVVsWHhZRmZ2cmdoc1lOQjRoT1AyREtLNXRNQ3RtbENVd2lySEQ4aVdu?= =?utf-8?B?MmxKZVRkR3BYb0hBZWl4SUF0c2VPb2NrRlpvRW1XeXhUM09VZzNRVXRFcEhi?= =?utf-8?B?bWlNNWlCbDdOMEJyUFV0UWxaTUlnVnN0UjhUVjVFYTV3eG1LKzZjWjE3R3ZC?= =?utf-8?B?NjkwVExDeDh4K0s5SnNkMGZuQ254K2ZqTXFycUZZb1Z3NVFNZldpSWVDOGFL?= =?utf-8?B?d3pZSmJ4RDFkb0x0S0FEWmFKbnliL1ErbjJjVnVvT2NtMEdRbHdhTHBRS1hs?= =?utf-8?B?a3F6eTBVYnQ5TDdZRnFvUDJ4NTA3dUVkeDQ4ME1MQ0ZoNFJsMlZESlV2SWxh?= =?utf-8?B?ZFdPdFNlTldKVFVKMTVaamdyYjhWdEpWdlhJS3hIdkhPbldXL0lhdWxVQ0hq?= =?utf-8?B?bXYyY3RYNzRvZ0VIUnNGelBwRW1UaWs3S2RVdWk2b0paaWxUYTVZUndGZXdM?= =?utf-8?B?dmdVOWdRYm0xVkhWd2lWNDRqemdRejR5NFg1WTdyd293R0NQZ0xPUmwyTFBr?= =?utf-8?B?OFhnSElhOEMvQ1JTUzZyZXBXOEdOYlBBUDkvMFlYQXpzTjNDVURWdExpQmRF?= =?utf-8?B?MTFSa2Q3L0psMGRqUUozMk5Eb0RNMTRqMU85K0dQL3BQR3N0bjh4QnM4Nktz?= =?utf-8?B?c2krbUpURUw2Y050My9kQT09?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <B51D81F895AF8A4DB7CCE1B03E7DC003@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c79038d8-026f-4676-589e-08d9a447f117
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2021 12:45:14.2505 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6563
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/rkVDrVxG74CxtsazZntTUbucoOQ>
Subject: Re: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 12:45:25 -0000

SGkgVGltLA0KDQpJIGFtIGFsbCBmb3IgaXQuIEVzcGVjaWFsbHkgd2hlbiBpdCBjb21lcyB0byBk
ZWZpbmluZyBleHBlcmltZW50YXRpb24sIHVzaW5nIA0KYSB3ZWxsLWRlZmluZWQgaHVtYW4gbm90
YXRpb24gYWxsb3dzIHVzIHRvIGNyZWF0ZSBuaWNlIGV4cGVyaW1lbnRhdGlvbiBzZXQgDQppbmRl
cGVuZGVudCBvZiB0b29scyBiZWluZyB1c2VkLg0KDQpPbGl2ZXINCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0
ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9s
b2d5DQooT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCihHVm9pY2UpICsxLjI0MC42NjguNDExNw0K
IA0KDQrvu79PbiAxMS84LzIxLCA4OjQ5IEFNLCAiU2lkcm9wcyBvbiBiZWhhbGYgb2YgVGltIEJy
dWlqbnplZWxzIiA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0aW1Abmxu
ZXRsYWJzLm5sPiB3cm90ZToNCg0KICAgIEhpLA0KDQogICAgVGhlIG5pY2Ugd29yayBkb25lIGJ5
IE9saXZlciBhbmQgdGVhbSB0cmlnZ2VyZWQgbWUgdG8gYXNrIHRoZQ0KICAgIHF1ZXN0aW9uIHdo
ZXRoZXIgdGhlcmUgd291bGQgYmUgdmFsdWUgaW4gaGF2aW5nIGEgd2VsbCBkZWZpbmVkDQogICAg
aHVtYW4gbm90YXRpb24gZm9yIEFTUEEgb2JqZWN0IGNvbnRlbnQuDQoNCiAgICBBcyBJIG1lbnRp
b25lZCBsYXN0IEZyaWRheSB3ZSBoYXZlIGFkZGVkIGV4cGVyaW1lbnRhbCBBU1BBDQogICAgc3Vw
cG9ydCB0byB0aGUgbmV3IEtyaWxsIHJlbGVhc2UgY2FuZGlkYXRlLiBBcyBwYXJ0IG9mIHRoaXMN
CiAgICB3ZSBhbHNvIGludmVudGVkIGEgaHVtYW4gcmVhZGFibGUgbm90YXRpb24gZm9yIHVzZSB3
aXRoIHRoZQ0KICAgIENMSToNCg0KICAgIGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmtyaWxsLmRvY3MubmxuZXRsYWJzLm5s
JTJGZW4lMkZwcm90b3R5cGUtYXNwYS1zdXBwb3J0JTJGbWFuYWdlLWFzcGFzLmh0bWwlMjNhc3Bh
LWNvbmZpZ3VyYXRpb24tbm90YXRpb24mYW1wO2RhdGE9MDQlN0MwMSU3Q29saXZlci5ib3JjaGVy
dCU0MG5pc3QuZ292JTdDMzIxMTBlMDM4NjE2NGQ0YmQ5NzQwOGQ5YTJiZTUxOTIlN0MyYWI1ZDgy
ZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3NzE5NzYxNDc3Mzg5NjE3JTdD
VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ
aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPU1Wd2J1JTJC
ZFh2Rm1NbEw2eUhVME0yUnozOEx6dGJXOXpkTGslMkYlMkJUUWhoQXclM0QmYW1wO3Jlc2VydmVk
PTANCg0KICAgIFRMO0RSIC0+IHR3byBleGFtcGxlczoNCg0KICAgIEFTNjUwMDAgPT4gQVM2NTAw
MSwgQVM2NTAwMih2NCksIEFTNjUwMDModjYpDQogICAgQVM2NTAwMSA9PiA8bm9uZT4NCg0KICAg
IFNvLCBub3RlIHRoYXQgd2UgYXNzdW1lZCB0aGF0IHdlIHdvdWxkIGhhdmUgYW4gZXhwbGljaXQg
ZW1wdHkNCiAgICBsaXN0LCByYXRoZXIgdGhhbiBBUzAsIHdoaWNoIGlzIGRlc2NyaWJlZCBoZXJl
IHVzaW5nICc8bm9uZT4nLg0KDQogICAgU28sIHRvIHJlcGVhdCB0aGUgcXVlc3Rpb246DQogICAg
RG8gd2UgdGhpbmsgdGhlcmUgaXMgdmFsdWUgaW4gZGVmaW5pbmcgYSBub3RhdGlvbiBsaWtlIHRo
aXM/DQoNCiAgICBJZiBzbywgdGhpcyBtYXkgaGVscCBvcGVyYXRvcnMgd2hlbiB0aGV5IHVzZSBk
aWZmZXJlbnQNCiAgICBpbXBsZW1lbnRhdGlvbiBhbmQvb3IgY29tcG9uZW50cy4gSSBhbSBvcGVu
IHRvIGNoYW5nZS4uDQoNCiAgICBJZiBub3QsIHRoZW4gaW1wbGVtZW50YXRpb25zIGNhbiBqdXN0
IHVzZSB0aGVpciBsb2NhbA0KICAgIHdheXMgdG8gZGVzY3JpYmUuDQoNCiAgICBUaGFua3MNCiAg
ICBUaW0NCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgU2lkcm9wc0BpZXRmLm9yZw0KICAgIGh0
dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz
QSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2Rh
dGE9MDQlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDMzIxMTBlMDM4NjE2NGQ0
YmQ5NzQwOGQ5YTJiZTUxOTIlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzEl
N0MwJTdDNjM3NzE5NzYxNDc3Mzk5NTc3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9p
TUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUz
RCU3QzMwMDAmYW1wO3NkYXRhPVNoMHFHbXhRcVIzcEJLZERyejF4Q0ZBaXVaSmRyTHhFODBMcSUy
QlFISHBkZyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQo=


From nobody Wed Nov 10 04:46:26 2021
Return-Path: <oliver.borchert@nist.gov>
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 9D7413A0E2D for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level: 
X-Spam-Status: No, score=-3 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, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=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 Ifo9TALX3Lnl for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:46:19 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::72a]) (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 C72673A0EE6 for <sidrops@ietf.org>; Wed, 10 Nov 2021 04:46:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I878j148eEwq89YriwQ3Ox5UT0o60NyflCEv6xRL4duK+qfzb/9ZdRDPCnqjjolb+/vNmvbwoByh8gdINuF+k/oNv5U/OfSy0gcvk+liWYmXuJ8X0d0zrBWajLhvaIXsvP7lvqlYRh2eURfKrtbzJj9R0sTv2M1mnq+6heOAax02jUNrGFHIIKhVW1Nqd6wqw9cxCEPatgwOn6Dm+ofGreQ+1fW7IcFVlegKYtR4l7nLVTS/IlX9R/7dbvj0HWWT3qFqsv1+9EuNVVDDRO+4ackfLrqQ8CCV8QqB2exvtR4TMzGQmGRJLpjKXDVg67tc8iVOiPtzGyd5E1BqE4GDXg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tRkJ4Pv/obUhbQH0Yv5JGe669biJf7nAqTpN80Cu4ns=; b=bau1WqY3dIqe1gA+OUVjM/7mxjgEwWMEVDTdLavBksshm4jSnl5CYBvjfFL56UsyVLZGsvrxfIQ4QLioBIvR4K7hSJ/nP2cKTOKXKLO/8hbYIMC8Ab0h2tB9CoznvIsqpjZa4BR1lLccJ9KGDPraPlBWVE1RFhjHThoHuTyg+LlxWC45UPVJZnB52c3Sw9QlxF3SSYv4MibzgIoebf77NLP3TTWfezeH9Wcell12rXIGvrrODGLQOxbnIyZr2hE+n6y2Sqeg1oLAMmUSBa+PVo/vvNtMRYQ9W/KsAFrP/ur63adSVfd9KQ18zdmg93WZuboybjmC/x3yXGmrOUj5Wg==
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=tRkJ4Pv/obUhbQH0Yv5JGe669biJf7nAqTpN80Cu4ns=; b=TPgCxOU1qck1lJJJVgUjyULdVD4mbJ6fz+rUi+AJZUW42kXXou+F2PX+QdGEwWgeOryfeKa5GfLfqK3rPjLM4spFJf8fMR8AvTdv4f7AzYIZzXLQmEfmY9zSrSHRK6i6n1cznNih8YUlW8ANlv36xLwM7usdxv0OUF2FvqsGUjI=
Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB7219.namprd09.prod.outlook.com (2603:10b6:208:2ab::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Wed, 10 Nov 2021 12:46:10 +0000
Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4690.016; Wed, 10 Nov 2021 12:46:10 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>, Tim Bruijnzeels <tim@nlnetlabs.nl>
CC: SIDR Operations WG <sidrops@ietf.org>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] ASPA human notation format needed?
Thread-Index: AQHX1KdmLJrjvBdGGE23KklsBc+CEav6CvYAgAJZx4A=
Date: Wed, 10 Nov 2021 12:46:10 +0000
Message-ID: <5F67CDBC-937B-4092-A3EF-E73B867BFB7B@nist.gov>
References: <77951978-A15C-44B8-A180-B310EF66920B@nlnetlabs.nl> <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com>
In-Reply-To: <CAMFGGcAH-P3OeX9SpWp-hsoSOZA3U5A9f1OeDvr51Ca69vN0bA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1831e811-bb28-4ace-13f4-08d9a448125c
x-ms-traffictypediagnostic: BLAPR09MB7219:
x-microsoft-antispam-prvs: <BLAPR09MB7219526AFE4C78211A03920E98939@BLAPR09MB7219.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qqihr8TZkBlwa88csoxYPDR0pZUHa9zZ+w0f7Kq1HM8m5Zp0SdbekPmFne7x9GuY7+uzO2B0T3Jhr1YL/zXejPnuwBe10HPh3tnmehnl0wze/6pPj172uuH2j8h9nw9GU5FSWDrmDW+q9rzd5IZsuyxNzeCQ29Py3KG9kdcQtlVp3KQ+cCgvBgAs8xnwpQxDYnSRP35t5TqsS0nPNhsPym/KGmpq3MW2B/e+eqVB44fT3NhkbKiX4HsV3HVl9yxfEiMZeOYaLbPzFhMLIyhgSyIuD2l6AVDRWcFUgcKTGYW+qlasxNbKvzRkDLNFvqlgws5iIq5nlQ7Oyi/I6qzkS+FgRWE0PXC6ohrvGtQGJso7EozZZhl38BPA4nV/u7YW7D2a1ydGL9u7je8TbUb+ZZzPOnaGY6n9BTtEUZ+Ry/Iwduh6AOkcY9X0cvVkQO0TuF93kNyFI6/h+GKZ2Tuxeai2S9w/SVbXQpP5IHx8J+Srb3cb2k761wu7P3Up8T1u6sbhyhgBJF5kKSV4vPc+U7YtSabSqBK9VxtGBm4SC2BFHig/nHMyAgTQ4JB2bnyG38KPfJ9zPm6VBVQ6Iimun89fMu7PcFoQo3rg/sGcEEybWEL97Ved+k8i4lHBjnbV6FG1aNib9suGqgM9WPov7/6ct6QeLi521I3pR6Pz9jwHKQ/BH0gELEJCopZ9c4w768SI/ZQ8UmXuuttHyUu2E0fGhC7sLEiw47AkGK2JXRB3Idy8olpWXjEYupXpAf2iSUwKtS/g83fbsdONEJpltPFpA6cxzpbZ6/x/3/MixesxUmHFeHXCQaCv/fPyIam0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(110136005)(33656002)(53546011)(6506007)(38070700005)(54906003)(186003)(5660300002)(4326008)(316002)(38100700002)(2906002)(40140700001)(8936002)(2616005)(8676002)(122000001)(64756008)(966005)(508600001)(86362001)(66556008)(36756003)(71200400001)(76116006)(66946007)(66476007)(66446008)(166002)(107886003)(6486002)(66574015)(82960400001)(6512007)(45980500001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YVRJU1BwOTFCQ0tuWFVBQ1pFVUZRUi9nWVBSbTEzQ1VYTEtWUS9UOUkrL003?= =?utf-8?B?VUJyeUFOM21vUG1CZXRlRjljOHgrWTg2T0RBSG91OXdqekVVVS9vV2JhNU5u?= =?utf-8?B?ZGNDTHhKR0E0Tk5HdU5OeGM5TVoxczRCRi8zYlpLaUdWK3hQUzRndUtzUUs0?= =?utf-8?B?TEJSMVhDSHZZbGZ2RW9iQm9sUlM3cVRZK0Mrc1kzQUxqb0gwdVBOeXJSeCt4?= =?utf-8?B?ZjZOZ1RKUThBSFNidGhrNkRFWnltTE5sVktFcXRSNDhNTXN1bWhmSFp2RDJr?= =?utf-8?B?WXdGaHV2aFJUVmZ3bjZNMWx0eXk3VjJPRUx5dk9nMnBhQ1dvdE5UT2MwcEx1?= =?utf-8?B?SE1QUUt2OEt0ZTBwamVQVER4WnJYMC9jUEd5YUovYjNXMTBwazJZc1UrM1c4?= =?utf-8?B?VWF0TnQxL0RCdlFHalZrZmE0dnlIanFyVUJrWk80QVpoN3p5Tmd5K010REds?= =?utf-8?B?UWVqVjhxc01IWENrSCs0ZVZ2ZkF3WVhsdU1ZR1diWExwdE94aWZpb2RTWElX?= =?utf-8?B?NUxhaExZRjI3TUdMRFVxVWpGK2hNcGVGZHRnZVE5bHpmYTh6WnJMUE53d1VY?= =?utf-8?B?SHY0ZXRxVVBjWk9RdmxGb0MrRHdJQVNtS3g1Q29JSVFHM3hrTzBZQWg2Rjcz?= =?utf-8?B?aDBDamFRdlkvZ1ZNUG9WRXI4VHFFVGxxcmF5V1djL2NhM0Y1YWxCS3BDa2h5?= =?utf-8?B?ejl2bDBLaUttM01hZGJYQUMvaXlYYjd1SHhGQUxVR3VIZ2dkYUdKaERnbGVG?= =?utf-8?B?aC9MZExoODJCYzNvbmVVbnd1NlF6V0Q3bHBqQTNROU1tTTQwK3J2dEVCdzJX?= =?utf-8?B?QkVpcXRsSnZZN01lU2dnT0NkZzdoRVp4SDY1UTQrejJoVjlRN0JoWnUrWWVT?= =?utf-8?B?TGY5R21Dc08rRlprVXIrUlVTdDNEdThKb2tUaWlLUGltR2h3Y0pLL21PdlZD?= =?utf-8?B?bTdZNGdFTCtQcTNGZWVRV0lZdExGSnA3REhBdnZhZzE0WUxmWVU5NUJCU2ZU?= =?utf-8?B?ME1RNnorN1NGNVI2a3l1UDRYNDVKMW9xcTFmVHVxT1NXV2NaQUhuNU1rVVV2?= =?utf-8?B?aklzMlRjUTZ0ekQwUlU5bFA2RmJoT0w1VWc1cDNBdnZ0cU1LV2oyTVAxK05h?= =?utf-8?B?Uk4zTFMxU00wVDJXZXRpTmRMUWJPaWlRNlhmc0ZyNkNKYUQwMGxKSHV5MHJB?= =?utf-8?B?aXV6eVVNT1J6SnpnMTBLK0NvVklmZm9WWWp0aUgrb2hKdGsyTmNYZ29veS90?= =?utf-8?B?ZDBhbUZEd1dOSVZJSEVlemRkVFBIMmZyS3VtSGdsR0dtVEtEVlhWZ1Q4NVlz?= =?utf-8?B?ZlFjYXc4RG9USnFVMzRkWkNIMC91dWNJY3hOYVI4Q0haTnRwaXF4M3d2TmVy?= =?utf-8?B?UWRFRGlPa0hLbHA1ajZ0NjllMjZzT1RyWkRXTDlmQ2ZiY3NOME9vYXFlbjNJ?= =?utf-8?B?SnJEUU1PRzNLTkhrY091R2xOOUdkOUVmb3I3bS9rYTI1N1llNDN4Z2M2TzU0?= =?utf-8?B?UDc4TW9RelJOaExQOE9XK0VlUERVMVduU2Q0cXFaeUJ6ZXI2OXhkMEFHa0JM?= =?utf-8?B?cG4ydjU2NDlGWWdyUTRIUFdQT0Via1NSb1RYRGtiN0ZDRTRzdm5NSTRSdnYx?= =?utf-8?B?SmZrdVdmc2ZNYnIvWGVnUEhaamdQQjJoVHFYTFJtODB2WjhLaGtYSUhDMGth?= =?utf-8?B?aW1EdytQM080ZmJRUS9yVzljYmFGSGxNc0JBcFVJVUhhVUd3dDZJNVFMcVFB?= =?utf-8?B?c1Z5bmZ6a1NqOXdRSkNhbVhJTFdkVmRTcWRTR0JLRHVKczZLcHc1K2JDbCsy?= =?utf-8?B?VFRFODB0L0JRbUJ6WE1rZz09?=
Content-Type: multipart/alternative; boundary="_000_5F67CDBC937B4092A3EFE73B867BFB7Bnistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1831e811-bb28-4ace-13f4-08d9a448125c
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2021 12:46:10.1563 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7219
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/V955TlBw3dTVvFWmL3uNhRKC5LY>
Subject: Re: [Sidrops] ASPA human notation format needed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 12:46:25 -0000

--_000_5F67CDBC937B4092A3EFE73B867BFB7Bnistgov_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9s
aXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2Yg
U3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQooT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCihHVm9p
Y2UpICsxLjI0MC42NjguNDExNw0KDQoNCkZyb206IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNlc0Bp
ZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpvYiBTbmlqZGVycyA8am9iPTQwZmFzdGx5LmNvbUBkbWFy
Yy5pZXRmLm9yZz4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgOCwgMjAyMSBhdCAyOjU0IFBNDQpU
bzogVGltIEJydWlqbnplZWxzIDx0aW1AbmxuZXRsYWJzLm5sPg0KQ2M6IFNJRFIgT3BlcmF0aW9u
cyBXRyA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbU2lkcm9wc10gQVNQQSBodW1h
biBub3RhdGlvbiBmb3JtYXQgbmVlZGVkPw0KDQpIaSBUaW0sIG90aGVycywNCg0KSSB0aGluayB5
b3UgYnJpbmcgdXAgYSBnb29kIGlkZWEuDQoNClNob3VsZCB5b3UgcHJvY2VlZCB0byBjYXB0dXJl
IHRoaXMgaWRlYSBpbiBhbiBpbnRlcm5ldC1kcmFmdCwgSeKAmWQgbGlrZSB0byBvZmZlciBhIHJl
Y29tbWVuZGF0aW9uIGhvdyB0byBmb3JtYWxpc2UgdGhlIHN5bnRheDogcGxlYXNlIHVzZSBBQk5G
ICgNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNTIzNDxodHRwczov
L2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl
MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM1MjM0JmRhdGE9MDQlN0Mw
MSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNTFlMDc0YzY4YzNiNDk1ZjBiZDgwOGQ5
YTJmMTVjNDAlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3
NzE5OTgwNDAzOTYzMzk0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN
REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAm
c2RhdGE9Q1hGOHFESWNHUms4QiUyRnROciUyQjduVjl0ZHU3czc2VERvVDFvV1NkVzklMkJaayUz
RCZyZXNlcnZlZD0wPikgdG8gZGVzY3JpYmUgdGhlIG5vdGF0aW9uIGZvcm1hdC4NCg0KV2l0aCBz
b21lIGx1Y2ssIHN1Y2ggYSBodW1hbiBub3RhdGlvbiBmb3JtYXQgYmVjb21lcyB0aGUgZGUgZmFj
dG8gZm9ybWF0IChvciBhdCBsZWFzdCBhbiBpbnNwaXJhdGlvbikgZm9yIG11bHRpcGxlIG9wZW4g
c291cmNlL2NvbW1lcmNpYWwgQkdQIGltcGxlbWVudGF0aW9ucyB3aGVuIHRoZXkgY29uc2lkZXIg
dGhlIENMSS9VSSBhc3BlY3Qgb2YgdGhlaXIgcmVzcGVjdGl2ZSAyMDIxLTIwMjIgQVNQQSBwcm9q
ZWN0cy4NCg0KSW5kZWVkLCBkb3duIHRoZSByb2FkIHRoaXMgbWlnaHQgbWFrZSBsaWZlIGVhc2ll
ciBmb3IgZnV0dXJlIG9wZXJhdG9ycyB3aG8gd2lzaCB0byBzdGF0aWNhbGx5IGNvbmZpZ3VyZSBB
U1BBIGVudHJpZXMgb24gdGhlaXIgQkdQIGVkZ2Ugcm91dGVycy4NCg0KS2luZCByZWdhcmRzLA0K
DQpKb2INCg0KT24gTW9uLCA4IE5vdiAyMDIxIGF0IDE0OjQ3LCBUaW0gQnJ1aWpuemVlbHMgPHRp
bUBubG5ldGxhYnMubmw8bWFpbHRvOnRpbUBubG5ldGxhYnMubmw+PiB3cm90ZToNCkhpLA0KDQpU
aGUgbmljZSB3b3JrIGRvbmUgYnkgT2xpdmVyIGFuZCB0ZWFtIHRyaWdnZXJlZCBtZSB0byBhc2sg
dGhlDQpxdWVzdGlvbiB3aGV0aGVyIHRoZXJlIHdvdWxkIGJlIHZhbHVlIGluIGhhdmluZyBhIHdl
bGwgZGVmaW5lZA0KaHVtYW4gbm90YXRpb24gZm9yIEFTUEEgb2JqZWN0IGNvbnRlbnQuDQoNCkFz
IEkgbWVudGlvbmVkIGxhc3QgRnJpZGF5IHdlIGhhdmUgYWRkZWQgZXhwZXJpbWVudGFsIEFTUEEN
CnN1cHBvcnQgdG8gdGhlIG5ldyBLcmlsbCByZWxlYXNlIGNhbmRpZGF0ZS4gQXMgcGFydCBvZiB0
aGlzDQp3ZSBhbHNvIGludmVudGVkIGEgaHVtYW4gcmVhZGFibGUgbm90YXRpb24gZm9yIHVzZSB3
aXRoIHRoZQ0KQ0xJOg0KDQpodHRwczovL2tyaWxsLmRvY3MubmxuZXRsYWJzLm5sL2VuL3Byb3Rv
dHlwZS1hc3BhLXN1cHBvcnQvbWFuYWdlLWFzcGFzLmh0bWwjYXNwYS1jb25maWd1cmF0aW9uLW5v
dGF0aW9uPGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy
bD1odHRwcyUzQSUyRiUyRmtyaWxsLmRvY3MubmxuZXRsYWJzLm5sJTJGZW4lMkZwcm90b3R5cGUt
YXNwYS1zdXBwb3J0JTJGbWFuYWdlLWFzcGFzLmh0bWwlMjNhc3BhLWNvbmZpZ3VyYXRpb24tbm90
YXRpb24mZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M1MWUwNzRj
NjhjM2I0OTVmMGJkODA4ZDlhMmYxNWM0MCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYx
ZGVjJTdDMSU3QzAlN0M2Mzc3MTk5ODA0MDM5NzMzNDglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4
ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW
Q0k2TW4wJTNEJTdDMzAwMCZzZGF0YT00dHd6R0w5NHdNMmZRbkhEaWJ4Tm5KR2ptZ0JkVlQlMkYy
b0dDT09nUzdsTmclM0QmcmVzZXJ2ZWQ9MD4NCg0KVEw7RFIgLT4gdHdvIGV4YW1wbGVzOg0KDQpB
UzY1MDAwID0+IEFTNjUwMDEsIEFTNjUwMDIodjQpLCBBUzY1MDAzKHY2KQ0KQVM2NTAwMSA9PiA8
bm9uZT4NCg0KU28sIG5vdGUgdGhhdCB3ZSBhc3N1bWVkIHRoYXQgd2Ugd291bGQgaGF2ZSBhbiBl
eHBsaWNpdCBlbXB0eQ0KbGlzdCwgcmF0aGVyIHRoYW4gQVMwLCB3aGljaCBpcyBkZXNjcmliZWQg
aGVyZSB1c2luZyAnPG5vbmU+Jy4NCg0KU28sIHRvIHJlcGVhdCB0aGUgcXVlc3Rpb246DQpEbyB3
ZSB0aGluayB0aGVyZSBpcyB2YWx1ZSBpbiBkZWZpbmluZyBhIG5vdGF0aW9uIGxpa2UgdGhpcz8N
Cg0KSWYgc28sIHRoaXMgbWF5IGhlbHAgb3BlcmF0b3JzIHdoZW4gdGhleSB1c2UgZGlmZmVyZW50
DQppbXBsZW1lbnRhdGlvbiBhbmQvb3IgY29tcG9uZW50cy4gSSBhbSBvcGVuIHRvIGNoYW5nZS4u
DQoNCklmIG5vdCwgdGhlbiBpbXBsZW1lbnRhdGlvbnMgY2FuIGp1c3QgdXNlIHRoZWlyIGxvY2Fs
DQp3YXlzIHRvIGRlc2NyaWJlLg0KDQpUaGFua3MNClRpbQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NClNpZHJvcHMgbWFpbGluZyBsaXN0DQpTaWRyb3Bz
QGlldGYub3JnPG1haWx0bzpTaWRyb3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zaWRyb3BzPGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l
MkZsaXN0aW5mbyUyRnNpZHJvcHMmZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlz
dC5nb3YlN0M1MWUwNzRjNjhjM2I0OTVmMGJkODA4ZDlhMmYxNWM0MCU3QzJhYjVkODJmZDhmYTQ3
OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3MTk5ODA0MDM5ODMzMDclN0NVbmtub3du
JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp
STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1OT201NFA4S1RQeWQ2SlIwR2hT
OTAxMGdGJTJCZEhWQnNIeU00am1NTU1oWGclM0QmcmVzZXJ2ZWQ9MD4NCg==

--_000_5F67CDBC937B4092A3EFE73B867BFB7Bnistgov_
Content-Type: text/html; charset="utf-8"
Content-ID: <5401BF014FDF8541A3CF8E5F0D434111@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg
MiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q291cmllcjsNCgljb2xvcjp3aW5kb3d0ZXh0
Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkNvdXJpZXIiPisxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6Ymxh
Y2siPk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJp
ZXI7Y29sb3I6YmxhY2siPk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hu
b2xvZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+KE9mZmljZSkgKzEuMzAxLjk3
NS40ODU2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPihHVm9pY2UpICsxLjI0MC42
NjguNDExNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToN
Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlNp
ZHJvcHMgJmx0O3NpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEpvYiBT
bmlqZGVycyAmbHQ7am9iPTQwZmFzdGx5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5E
YXRlOiA8L2I+TW9uZGF5LCBOb3ZlbWJlciA4LCAyMDIxIGF0IDI6NTQgUE08YnI+DQo8Yj5Ubzog
PC9iPlRpbSBCcnVpam56ZWVscyAmbHQ7dGltQG5sbmV0bGFicy5ubCZndDs8YnI+DQo8Yj5DYzog
PC9iPlNJRFIgT3BlcmF0aW9ucyBXRyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T
dWJqZWN0OiA8L2I+UmU6IFtTaWRyb3BzXSBBU1BBIGh1bWFuIG5vdGF0aW9uIGZvcm1hdCBuZWVk
ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PkhpIFRpbSwgb3RoZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPkkgdGhpbmsgeW91IGJyaW5nIHVwIGEgZ29vZCBpZGVhLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlNob3VsZCB5b3UgcHJvY2VlZCB0byBjYXB0
dXJlIHRoaXMgaWRlYSBpbiBhbiBpbnRlcm5ldC1kcmFmdCwgSeKAmWQgbGlrZSB0byBvZmZlciBh
IHJlY29tbWVuZGF0aW9uIGhvdyB0byBmb3JtYWxpc2UgdGhlIHN5bnRheDogcGxlYXNlIHVzZSBB
Qk5GICg8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVj
dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl
MkZkb2MlMkZodG1sJTJGcmZjNTIzNCZhbXA7ZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0
JTQwbmlzdC5nb3YlN0M1MWUwNzRjNjhjM2I0OTVmMGJkODA4ZDlhMmYxNWM0MCU3QzJhYjVkODJm
ZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3MTk5ODA0MDM5NjMzOTQlN0NV
bmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp
TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9Q1hGOHFESWNH
Ums4QiUyRnROciUyQjduVjl0ZHU3czc2VERvVDFvV1NkVzklMkJaayUzRCZhbXA7cmVzZXJ2ZWQ9
MCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM1MjM0PC9hPikNCiB0
byBkZXNjcmliZSB0aGUgbm90YXRpb24gZm9ybWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldpdGggc29tZSBsdWNrLCBzdWNoIGEgaHVtYW4gbm90YXRp
b24gZm9ybWF0IGJlY29tZXMgdGhlIGRlIGZhY3RvIGZvcm1hdCAob3IgYXQgbGVhc3QgYW4gaW5z
cGlyYXRpb24pIGZvciBtdWx0aXBsZSBvcGVuIHNvdXJjZS9jb21tZXJjaWFsIEJHUCBpbXBsZW1l
bnRhdGlvbnMgd2hlbiB0aGV5IGNvbnNpZGVyIHRoZSBDTEkvVUkgYXNwZWN0IG9mIHRoZWlyIHJl
c3BlY3RpdmUNCiAyMDIxLTIwMjIgQVNQQSBwcm9qZWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JbmRlZWQsIGRvd24gdGhlIHJvYWQgdGhpcyBtaWdo
dCBtYWtlIGxpZmUgZWFzaWVyIGZvciBmdXR1cmUgb3BlcmF0b3JzIHdobyB3aXNoIHRvIHN0YXRp
Y2FsbHkgY29uZmlndXJlIEFTUEEgZW50cmllcyBvbiB0aGVpciBCR1AgZWRnZSByb3V0ZXJzLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+S2lu
ZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i
PkpvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gTW9u
LCA4IE5vdiAyMDIxIGF0IDE0OjQ3LCBUaW0gQnJ1aWpuemVlbHMgJmx0OzxhIGhyZWY9Im1haWx0
bzp0aW1AbmxuZXRsYWJzLm5sIj50aW1AbmxuZXRsYWJzLm5sPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGksPGJyPg0KPGJyPg0KVGhlIG5pY2Ugd29yayBkb25lIGJ5
IE9saXZlciBhbmQgdGVhbSB0cmlnZ2VyZWQgbWUgdG8gYXNrIHRoZTxicj4NCnF1ZXN0aW9uIHdo
ZXRoZXIgdGhlcmUgd291bGQgYmUgdmFsdWUgaW4gaGF2aW5nIGEgd2VsbCBkZWZpbmVkPGJyPg0K
aHVtYW4gbm90YXRpb24gZm9yIEFTUEEgb2JqZWN0IGNvbnRlbnQuPGJyPg0KPGJyPg0KQXMgSSBt
ZW50aW9uZWQgbGFzdCBGcmlkYXkgd2UgaGF2ZSBhZGRlZCBleHBlcmltZW50YWwgQVNQQTxicj4N
CnN1cHBvcnQgdG8gdGhlIG5ldyBLcmlsbCByZWxlYXNlIGNhbmRpZGF0ZS4gQXMgcGFydCBvZiB0
aGlzPGJyPg0Kd2UgYWxzbyBpbnZlbnRlZCBhIGh1bWFuIHJlYWRhYmxlIG5vdGF0aW9uIGZvciB1
c2Ugd2l0aCB0aGU8YnI+DQpDTEk6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGa3JpbGwu
ZG9jcy5ubG5ldGxhYnMubmwlMkZlbiUyRnByb3RvdHlwZS1hc3BhLXN1cHBvcnQlMkZtYW5hZ2Ut
YXNwYXMuaHRtbCUyM2FzcGEtY29uZmlndXJhdGlvbi1ub3RhdGlvbiZhbXA7ZGF0YT0wNCU3QzAx
JTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M1MWUwNzRjNjhjM2I0OTVmMGJkODA4ZDlh
MmYxNWM0MCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3
MTk5ODA0MDM5NzMzNDglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01E
QWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZh
bXA7c2RhdGE9NHR3ekdMOTR3TTJmUW5IRGlieE5uSkdqbWdCZFZUJTJGMm9HQ09PZ1M3bE5nJTNE
JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9rcmlsbC5kb2NzLm5sbmV0
bGFicy5ubC9lbi9wcm90b3R5cGUtYXNwYS1zdXBwb3J0L21hbmFnZS1hc3Bhcy5odG1sI2FzcGEt
Y29uZmlndXJhdGlvbi1ub3RhdGlvbjwvYT48YnI+DQo8YnI+DQpUTDtEUiAtJmd0OyB0d28gZXhh
bXBsZXM6PGJyPg0KPGJyPg0KQVM2NTAwMCA9Jmd0OyBBUzY1MDAxLCBBUzY1MDAyKHY0KSwgQVM2
NTAwMyh2Nik8YnI+DQpBUzY1MDAxID0mZ3Q7ICZsdDtub25lJmd0Ozxicj4NCjxicj4NClNvLCBu
b3RlIHRoYXQgd2UgYXNzdW1lZCB0aGF0IHdlIHdvdWxkIGhhdmUgYW4gZXhwbGljaXQgZW1wdHk8
YnI+DQpsaXN0LCByYXRoZXIgdGhhbiBBUzAsIHdoaWNoIGlzIGRlc2NyaWJlZCBoZXJlIHVzaW5n
ICcmbHQ7bm9uZSZndDsnLjxicj4NCjxicj4NClNvLCB0byByZXBlYXQgdGhlIHF1ZXN0aW9uOjxi
cj4NCkRvIHdlIHRoaW5rIHRoZXJlIGlzIHZhbHVlIGluIGRlZmluaW5nIGEgbm90YXRpb24gbGlr
ZSB0aGlzPzxicj4NCjxicj4NCklmIHNvLCB0aGlzIG1heSBoZWxwIG9wZXJhdG9ycyB3aGVuIHRo
ZXkgdXNlIGRpZmZlcmVudDxicj4NCmltcGxlbWVudGF0aW9uIGFuZC9vciBjb21wb25lbnRzLiBJ
IGFtIG9wZW4gdG8gY2hhbmdlLi48YnI+DQo8YnI+DQpJZiBub3QsIHRoZW4gaW1wbGVtZW50YXRp
b25zIGNhbiBqdXN0IHVzZSB0aGVpciBsb2NhbDxicj4NCndheXMgdG8gZGVzY3JpYmUuPGJyPg0K
PGJyPg0KVGhhbmtzPGJyPg0KVGltPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpTaWRyb3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9
Im1haWx0bzpTaWRyb3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U2lkcm9wc0BpZXRmLm9y
ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91
dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz
dGluZm8lMkZzaWRyb3BzJmFtcDtkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0
LmdvdiU3QzUxZTA3NGM2OGMzYjQ5NWYwYmQ4MDhkOWEyZjE1YzQwJTdDMmFiNWQ4MmZkOGZhNDc5
N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzcxOTk4MDQwMzk4MzMwNyU3Q1Vua25vd24l
N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ
NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1OT201NFA4S1RQeWQ2SlIw
R2hTOTAxMGdGJTJCZEhWQnNIeU00am1NTU1oWGclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHM8L2E+
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_5F67CDBC937B4092A3EFE73B867BFB7Bnistgov_--


From nobody Wed Nov 10 04:46:31 2021
Return-Path: <nathalie@ripe.net>
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 1AC923A0ED6 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ripe.net
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 hnqiZ4R92M8a for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 04:46:20 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 8BE533A0EDE for <sidrops@ietf.org>; Wed, 10 Nov 2021 04:46:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From:CC ; bh=q23B1svML1DDBmC9av4tYhSgpsRyCmErVxrq7oeuZH8=; b=aX6YKncgyYy+DMpweD+E74sW t9XicMVzwostn9u6Bevhw9KcblZi/5pFfaD3yer6hyTlPBqSGN1yclDr4af/Y5hLtco4mr1eQu+a4 8icbog2WR49UbVYGmNUYYDAKq+rS5hRzns5cWkTx3N4B46S9+YabsZa7DQ4+1wwWdVm7vPZ/r/R98 Nj7JGuH78Yy4lXUyIhTncuCfDxQjodHJzWCD0rtXTMbbxVtOw7tsnPYGf8iSvrxXbpTJdd7GTM4RP elhj40A0bxuDhC7sLNEnwvBujnNzczTwrqaU6tDakBxz7N+LqVaQ8NUzZ5FrTHD13+eoR8Y2igO2J gLm6ZgRI2w==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:35778) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mkmzW-0007FM-Qq for sidrops@ietf.org; Wed, 10 Nov 2021 13:46:14 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <nathalie@ripe.net>) id 1mkmzW-0006ib-Oe for sidrops@ietf.org; Wed, 10 Nov 2021 13:46:14 +0100
From: Nathalie Trenaman <nathalie@ripe.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Message-Id: <0DCCE6E9-3B49-4E5D-97DD-1E377BB8C261@ripe.net>
Date: Wed, 10 Nov 2021 13:46:14 +0100
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a3d4e4e9e92421a7f8fa901db5cb21a93
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xcbtPlMotd-mSbLjsVWYS2mIGIE>
Subject: [Sidrops] Sidrops 112 meeting notes
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 12:46:25 -0000

Hi all,

Here are the draft minutes for sidrops 112, held last Monday.
Comments, edits welcome!

https://datatracker.ietf.org/doc/minutes-112-sidrops/

And thanks George, for your lightning fast note taking skills!

Nathalie


From nobody Wed Nov 10 05:52:45 2021
Return-Path: <job@fastly.com>
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 CC5563A0FFA for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 05:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 sSCzmbNVsS74 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 05:52:39 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 1DF8D3A0FF5 for <sidrops@ietf.org>; Wed, 10 Nov 2021 05:52:39 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id f4so10735314edx.12 for <sidrops@ietf.org>; Wed, 10 Nov 2021 05:52:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:subject:message-id:mime-version:content-disposition;  bh=6Sol+YK7106PLi+eWISCqnm3Rrq1tzw/S1QPzSVGtrI=; b=HVohK1N2gbUqF8kYST8+lIhsA0xoVwyDE7dWPm+uMp1jk648Htg5/hAzNmZJq9L3ao vl2OW19HNw1EFY2z2Wzej8Q7Bd8jiksvb29L2Jvp+e59cOw4jzczfrmOp65QBRFN6T2D 0o62j9QTr1h74eDWQ8j2ySe4pLko9ywoPRnbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=6Sol+YK7106PLi+eWISCqnm3Rrq1tzw/S1QPzSVGtrI=; b=0ewcLAQ8W8+gVpOMoD6bBvrVmj6vLjBND2JM4UFTFFedjfM7++kwDULYugXyrttM14 hnVfKwAhAc9q06YfnOgHTRwwHY1rxckgBaynMrFVOlyIotiObWpGQup/oUqfEkyfsmWB hGAGLQDLrTo4EzFv/S91zfO03yyAtnoeQ1Ix1kOsKCKPHbgNvQwQ1csg+IEOHelxhiDZ F1dINYFCXXHpnbFp5mP4XBQUzbeMZzGeYC/kBJ2ZcVxHMQQHHquJw0cFesw0g2Me9vRy QROfilnORfAwl+vhFddKrt7oudSjlkk7CZchBogGPC2tMIaZqpwAed4eom2DBa4L+s4Q ecxQ==
X-Gm-Message-State: AOAM531p3B9OJ3mcUfGhPZK1RLM7+J/QaPTy4SPkalr1c5zzpJG93rXY HZKXAFOuHiNjCYAnywyYISw+xGcavJHXF/5FbaTVfoiihOyeMFSoCReoQ+yeq7sgpo7cVDeBMSV T+AWT43H1DfhAdPOL11KHgyDgVB6uG7o9geQSC2aIvH9fkZstL1wx3bw=
X-Google-Smtp-Source: ABdhPJxHcZmy75gA5QlaXdKFWW8Tth/iH+Zftumwda4hrDmyfL2seiwRGSsu8RBEYoR2ew4lx20Y4w==
X-Received: by 2002:a50:cdd8:: with SMTP id h24mr20672967edj.139.1636552356447;  Wed, 10 Nov 2021 05:52:36 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id e7sm13586084edk.3.2021.11.10.05.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 05:52:36 -0800 (PST)
Date: Wed, 10 Nov 2021 14:52:34 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org, gih@apnic.net
Message-ID: <YYvOop1mWMNc9tCG@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8Y5Mf0u6DTX94j3NaddyibvKCH0>
Subject: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 13:52:44 -0000

Dear all,

(Geoff, NIST - suggested todo items at the bottom of this email :-)

On Wed, Nov 10, 2021 at 10:50:05AM +0100, Tim Bruijnzeels wrote:
> Documenting the decisions as rpki-client did helps. There is also
> merit in a public discussion about limits and motivations. I think
> different PR implementations can benefit from sharing. It may also
> help operators if limits are documented somewhere and RPs give clear
> errors when limits are applied.

To elaborate a bit more on the current limits and behavior of
rpki-client. Some of the current limits (with annotation comment)

    $ grep MAX extern.h
    #define MAX_IP_SIZE             200000	/* RFC 3779 IP entries */
    #define MAX_AS_SIZE             200000	/* RFC 3779 AS entries */
    #define MAX_URI_LENGTH          2048	/* length in bytes */
    #define MAX_FILE_SIZE           4000000	/* length in bytes */
    #define MAX_MANIFEST_ENTRIES    100000	/* largest manifest is ~ 16K */
    #define MAX_CERT_DEPTH          12		/* longest allowed auth chain */
    #define MAX_RSYNC_PROCESSES     16		/* concurrent processes */
    #define MAX_REPO_PER_TAL        1000	/* mitigation 'issue H' */
    #define MAX_REPO_TIMEOUT        (15 * 60)	/* timeout in seconds */

(We are happy to consider additional limits, or change limits.)

Let's zoom in on how exactly MAX_REPO_PER_TAL works, as "issue H"
appears unresolved in some implementations.

rpki-client processes repositories in order of 'closeness to the root'.
After MAX_REPO_PER_TAL (1000) publication points have been discovered,
no new publication points will be added to the processing queue. The
children of a misbehaving CA always will be 'further away' from the root
than the RIR hosted CAs or nominally operating delegated CAs (like
chloe.sobornost.net, rpki-repo.registro.br, rpki-repository.nic.ad.jp).
Consequently, 'good CAs' are stay alive, 'bad CAs' are punished by
virtue of being further removed from the root.

The combination of processing in a specific order, and hard-capping at a
(generous) limit seems to make for a pragmatic and hopefully fairly
effective defense against the "issue 1" Koen brought up here [1].

Looking forward
===============

When 'fencing in the RPKI' (restricting the RPKI) - there are many
dimensions to consider (wall clock time, file sizes, width, depth, etc).
If we operate under the assumption that RPs are upgraded once a year, it
would be very helpful to establish growth projections for the next 1, 2
and 3 years.

Geoff - perhaps you'd be willing to look in your crystal ball, just like
you seem to enjoy predicting internet-scale FIB sizing? :-)

NIST, perhaps your team can also produce projections based on the RPKI
Deployment Monitor data, so that we have two sources to help set course?

The strategy here is to make an inventory of all aspects of the RPKI
that can 'balloon up', and then impose a limit on those things which
permit organic growth (in the next 18 months), but not much more than
that.

This working group has the right people to make this approach work.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/FCttiTVor2IpXuqiGljuoN66Xio/


From nobody Wed Nov 10 06:17:27 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 64C8D3A1022 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:17:25 -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, 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=student.utwente.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 fAMauW8FxD-D for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:17:20 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 3F5A43A1015 for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:17:20 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id v11so11094442edc.9 for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:17:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HEUSJNKGvRY+yNSjHhUqhodvXcpdjAAIOKmu9bXqgEg=; b=UniIOVNiJhD0pEbkhd2d0tmb/Yj64erGJTn5SaNYkPMqs0r86tdRkbjeqk11lFIxlf 4vKyJp6pzOXxuuUtmnir8y5Bt3HBxl1XLIH1TQsFv3v101r6fuUaElNivPMEoOasDJNX K2qCBk733uwLVXaM3/JN5lG1tjAa4KMCWy2cNyAQhdRny7BOk+FJ3L+5ILdarNRoRPHU XBumkDjvZyxhD9VPxpHPKbg7kkERmsbRAXrgdm+wVtjfzoi4u8qzoYowCDYZThY/Y7c0 CPhsK+gbHw6SU4e64TuVgyZYB4Ts2MrUOLy9e+qO0uIhGlQusnRvjMMN60TybXGCir7L WyWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HEUSJNKGvRY+yNSjHhUqhodvXcpdjAAIOKmu9bXqgEg=; b=UMPahhb3WvZwzh1HjzefQDnyZD5Qbn4CCC8j/4gdssQd4o7HfZocpsohJEK8WfUrSH NhXMy8rxILvL/x1eS79WMHovRuNM88RXrt6JQA2wkURx83HqGvZ5ZJO1HSqEomrcsW+3 DsG3tJaNU7EhRjIMV8Kh7o4BANFsMRzJT9v39L/fqdyy+r+EBRmBNj32ZawpmIxIuY5X LC8xLd+sGGzSBiJMXm6L1Cdfdv2II2Shnp3s1BMQKI21fTFgTdoBi08guOzgwFMTTwEE gK9AhZ0L24tDGW9TsnPuiKQhT3sBA4JDItGYQJPJgTAM9bWtnDqQnjDE1urEGBrY/84d /Rpw==
X-Gm-Message-State: AOAM5330T+8sUGUasYYyRnCgIGh0B3sGlzaAxpRCuIEIe8jzVDi6FyCb G2sTbkeOHTa9vKsy0haBlPUDxbj00sPSNqDUWcpDGYQFdHg=
X-Google-Smtp-Source: ABdhPJyUfFzOXGP0lFg9SCzUPM96QH1WeVd/3NuSzufsOShi0SVEhx1jyuU7FrAu1A/J67kFuNjCCnKLdriwBAyf9B0=
X-Received: by 2002:a17:906:fcba:: with SMTP id qw26mr20958768ejb.448.1636553836399;  Wed, 10 Nov 2021 06:17:16 -0800 (PST)
MIME-Version: 1.0
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYqyTzjY1hyeH09l@diehard.n-r-g.com>
In-Reply-To: <YYqyTzjY1hyeH09l@diehard.n-r-g.com>
From: Koen van Hove <k.w.vanhove@student.utwente.nl>
Date: Wed, 10 Nov 2021 15:17:05 +0100
Message-ID: <CAEgZXjFc17KPuvtHYSyoxsJAvc9OXSb=fnLn2LjBFWpKTVkjJA@mail.gmail.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Cc: sidrops@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/H6JnBU2r1Ri2G2yam9gg32YKDXk>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 14:17:25 -0000

The assumption that is made is that the "view" of RPKI is the same
across the globe. However, I can easily change what data I serve based
on the source IP address. This would make monitoring by TAL operators
difficult, as I can target my attack to a specific organisation. I
would like to have a system where we can trust the input, but I
believe one of the reasons the RPKI exists is because the good faith
approach in BGP has its flaws. For those reasons, I believe being able
to proactively prevent "RPKI abuse" is more valuable than having
monitoring to correct it afterwards, as by then the damage can already
be done.

Regarding the selection of limits: they are based on limits already
imposed by current RP implementations (6.2 - 6.8), as well as new
potential threats (6.1; 6.9). If those are deemed undesirable, then it
might be worth providing some extra guidance for both relying parties
and publication points with uniform limits (or safe values).

Koen van Hove

Op di 9 nov. 2021 om 18:39 schreef Claudio Jeker <cjeker@diehard.n-r-g.com>:
>
> On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
> > Dear all,
> >
> > Let me quickly introduce myself, my name is Koen van Hove from the
> > University of Twente. Some of you might know me from other channels.
> >
> > Recently there have been a couple discussions about limits. I found
> > two issues regarding limits that may be problematic for the
> > availability of RPKI, and to kill two birds with one stone, I propose
> > the "RPKI Tree Hints" draft, which can act as a framework for future
> > limits in RPKI. Here is a direct link:
> > https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
> >
> > Issue 1
> > =======
> > Every CA in RPKI can have one or more children, who in turn can have
> > children, etc. Several implementations already impose limits on the
> > depth of this chain, the most restrictive currently being 12. However,
> > if a CA goes wide and deep, then due to the exponential growth in the
> > number of repositories, a shallow depth might suffice to disrupt RPKI.
> > Imagine the following: a CA has 10 children, who all have 10 children,
> > ad infinitum. At six layers deep, this already means RPs have to
> > traverse 111,111 repositories. As I control these repositories, I can
> > of course make sure that this process is not exactly quick. If I make
> > every repository take 10 seconds, which is not unreasonable for
> > current repositories, then this process would already take over 12
> > days to complete. If instead we use 15 children, then it takes several
> > years. I believe I do not say anything controversial when I say that
> > this is too long, and can severely harm the availability of RPKI.
> >
> > The difficulty in solving this is that having 15 children is in and of
> > itself nothing special, and nothing that should raise alarm bells.
> > Limiting this using a global value would severely hinder the
> > flexibility of the RPKI structure in the future. As the structure is
> > unknown before walking the tree, discovering this using heuristics is
> > tricky, and bound to give headaches for many years to come.
> >
> > Issue 2
> > =======
> > The RP retrieves the ROAs, parses them, and then sends them to the
> > router via RTR. Let us imagine that I own a /48 (which to my knowledge
> > is not too difficult to obtain). I can split that /48 in 2^80 /128s,
> > or 2^79 /127s, etc. In total I will have ~2^81 entries. I can also do
> > that for all 2^32 possible ASNs, creating 2^113 entries in total. This
> > all has to go over RTR and into the router, and contemporary routers
> > are to my knowledge not capable of processing such a large amount of
> > information.
> >
> > Limiting either the prefixes or ASNs globally is going to be
> > difficult, as there are legitimate cases where a lot of ASNs are used,
> > or a lot of different prefixes, but when everyone does that it becomes
> > a problem.
> >
> > To solve these two issues, I propose a new object that enables parents
> > to provide hints about their children (and their descendants). This
> > way, if a malicious child does something unusual, an RP can detect it
> > without it impacting the other honest CAs.
> >
> > I am interested to hear your thoughts on both the issues, as well as
> > the proposed solution. After all, many roads lead to Rome.
>
> While interesting this can already be solved by the parent CA pulling the
> plug on such bad CA repo. This is very simple to implement (removing the
> certificate from the parent repository and issue a new manifest).
> It would require that the RIRs monitor their part of the tree (which would
> be generally a good idea).
>
> Additionally for issue 2 it makes little sense to have VRPs for routes
> that are filtered in the DFZ. At least every network admin I know limits
> prefix lenght on transit and peering links.
>
> The problem here is that parent publication points need to take
> over more responsibility. There is a general weakness in a design that
> starts with untrusted input and tries to produce trusted output.
> It would be better to have at least some limit on what is fed into the
> validator software. At least it seems to be a better plan than
> implementing a complex system to impose per CA limits.
>
> Also some of the limits are questionable like minTransferSpeed or
> maxTransferSize. The transfer speed of a download can vary a lot and is
> not under the control of the publisher of such a limit (all connection
> limits have a similar issue). For the transfer size, it depends on the
> protocol used and is limited by the maxRepositorySize which gives a upper
> bound.
>
> --
> :wq Claudio


From nobody Wed Nov 10 06:23:44 2021
Return-Path: <job@fastly.com>
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 D0D443A1045 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 XIXsfjmS9JRm for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:23:37 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 152C03A0FFB for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:23:37 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id b15so11124352edd.7 for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:23:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XFmOW4j1QCjzMOawvsTg0d1TLHNFyvq41mq+Br6RoaQ=; b=hA715edHBwSB4U3h5S5elcg+GxruYxQenbIZVaMdCZywOqCbRfCgtwMlzdHWYp4aXj 3nL7wCoH8i2fbMlHJakxWt/teOXZmMq6GAAL5VLuVFMbhc6n5llAmDYKnEc62hChI7P7 MWI20KwEFxiVtWfhmBOlJArWYw39XEqYAXdlU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XFmOW4j1QCjzMOawvsTg0d1TLHNFyvq41mq+Br6RoaQ=; b=y26lDivHuyoZwasSXPN1chTdmkpuw4Dp6izTpdp+d6su3pBWQqVcohULKEGPPbj0EN vMh9OjMwcU4mFnuRkNW2Z1T7qaTUXoIieFFvAQogSsh2wbJzWntCfPsB5HcylvFD7b72 ihSu8oQmgEQ3GiLgFNjW1lsPF9f++9Lcmr24cQOrm9g6vduMd8AHa1fJcBUev8/ONOR9 z9gZQC2XgDMrkTeMIKAo8cXZOPM9Hw3PyfZDSwDkuad4W54sw2+BNOajR4IcrYQ+zYEs LNyl0TJ475n14YBa+JpLDMc0T2BXyZabdUUE1I54Ih5amzq+wxenn6AMIgoxLNLlrkUE w8dw==
X-Gm-Message-State: AOAM532I4753gcgvWzh3brbgsB6QxJRtdFaKa92i6+0gcTufzmRr7r3m UT2XhH5OgTg52RDpZQ3es194lg==
X-Google-Smtp-Source: ABdhPJxIq9m+OZAqKgJARYeRBlmJl5A/UaGl63LBQSH0Ay9v8ur9yetbpY+dhsWtQTxcOvErfDwr7A==
X-Received: by 2002:a17:906:58c6:: with SMTP id e6mr21224637ejs.524.1636554211664;  Wed, 10 Nov 2021 06:23:31 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id d10sm5215204eja.4.2021.11.10.06.23.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 06:23:30 -0800 (PST)
Date: Wed, 10 Nov 2021 15:23:29 +0100
From: Job Snijders <job@fastly.com>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: Claudio Jeker <cjeker@diehard.n-r-g.com>, sidrops@ietf.org
Message-ID: <YYvV4aOYiz5wwd7p@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYqyTzjY1hyeH09l@diehard.n-r-g.com> <CAEgZXjFc17KPuvtHYSyoxsJAvc9OXSb=fnLn2LjBFWpKTVkjJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEgZXjFc17KPuvtHYSyoxsJAvc9OXSb=fnLn2LjBFWpKTVkjJA@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/mEIwi2Ar0SqCI8ehVhpEZW6IA6w>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 14:23:42 -0000

On Wed, Nov 10, 2021 at 03:17:05PM +0100, Koen van Hove wrote:
> The assumption that is made is that the "view" of RPKI is the same
> across the globe. However, I can easily change what data I serve based
> on the source IP address. This would make monitoring by TAL operators
> difficult, as I can target my attack to a specific organisation.

I don't think we make that assumption. I'd flip the argument around: TAL
operators (and others) are able to monitor normal operating levels,
based on that data limits can be established, which help thwart
two-faced attackers.

Kind regards,

Job


From nobody Wed Nov 10 06:59:05 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 100203A1081 for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:59:04 -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, SPF_HELO_NONE=0.001, 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=student.utwente.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 NafKaHZMslAf for <sidrops@ietfa.amsl.com>; Wed, 10 Nov 2021 06:58:59 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 BCA5E3A109F for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:58:58 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id w1so11625038edd.10 for <sidrops@ietf.org>; Wed, 10 Nov 2021 06:58:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fq+bneIX9EqD8MZ07TNwJjg34b0YVkWPJHtRlOPeE0o=; b=P25dEGEmIaaovEdvutBhlo9/FQ4cDKwfG13lbQqgNJ5q+DadRcpF6s4EiX50I1fsdI McBvyOEsw9NlucryuJNqsr1CwclekFE2Iu1+udPmgzxIm3R0Y7Oea9je/K8wWPk3+bx9 mYU3iqE/rGWmD3ZxdhxKIpilHMKrbPUI0XS9fWTjxg+katjFbACJL6ZZf4ayRL2Z1Lnm AN1RByxy5FOtMB+KL7sIQE1El5YNiw+dYrNYVD2c5WkS/K3Gy/VQORKWiVxsOJ+OHHgA IRiHh4qWOfJ0myg3vkhnT/iYp7jEKUnBBl198KouJo7RHPeA3iOY6GWGcoNC4Kjj2iCS m5wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fq+bneIX9EqD8MZ07TNwJjg34b0YVkWPJHtRlOPeE0o=; b=pcHI3NM7jPjwnZtp70wd7Ci5WP9YitH9OI+RBFBlEqHe1G8YZOZ9Qb7Mv/lLJoAMKR O80FhoqSLXTpryP4yUI4N9BTsA0BmQsYRWuByJ/OPJ1ikDD9F3NHN+9OeSAF+rYgUlqi Ckem7hJG7nlt5xEXmP+NV9XE6u91yxCJpCUT3TKAtPFB1On9WlzoR/FLIg8qSBAybyWS 0V1ts6FYDGldWvj/H01zKpQNZEpgw405z3ceEBBfiYe2ZUCmx/zp2L1U2qJV/LTHmV30 lBOUgfyTMvqgXkzPNZLN/MXFR7fwlfUd+N7DbD8Wdlt8TF5RhUyaC09VL53VIKibQdMz jvaw==
X-Gm-Message-State: AOAM533wLG9MBwCo2fC/GHjQlrqC9/UOpci4DHutEg8I7gkLnajOP2eQ IPvf3pqDpbVljt/hLZ+IamXgRo6O2v4TFAUuNGGaHQ==
X-Google-Smtp-Source: ABdhPJzTTiJm3zqL0LSUb/aVNGx3MROOblBRt8ZrgccGVFxpx8OU1+AlkbGQrm+NkvOcTAQMXUeCs2syMbwenKvv2GI=
X-Received: by 2002:aa7:cb41:: with SMTP id w1mr188097edt.327.1636556335254; Wed, 10 Nov 2021 06:58:55 -0800 (PST)
MIME-Version: 1.0
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <YYrqq1a0VOWyiMsM@snel> <56159567-0C7E-4B88-886B-9EA1779F80A6@nlnetlabs.nl>
In-Reply-To: <56159567-0C7E-4B88-886B-9EA1779F80A6@nlnetlabs.nl>
From: Koen van Hove <k.w.vanhove@student.utwente.nl>
Date: Wed, 10 Nov 2021 15:58:44 +0100
Message-ID: <CAEgZXjEtmKVijM1KG2ZB5=VksgSvkhNpWB5yVwGsJDpKm8Kc+g@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>, sidrops@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1-FyN_u87147PYUZ7OqS1juhGqA>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 14:59:04 -0000

I agree that it would be good to have a way to inform a CA of their
effective limits, and that an extension to 6492 might be a good
solution for that. If an RP detects a violation of a tree hint, they
can already contact the responsible repository using (one of) its
Ghostbusters Records.

Koen van Hove

Op wo 10 nov. 2021 om 10:50 schreef Tim Bruijnzeels <tim@nlnetlabs.nl>:
>
>
>
> > On 9 Nov 2021, at 22:39, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> >
> > Hi Koen, group,
> >
> > On Tue, Nov 09, 2021 at 05:48:12PM +0100, Koen van Hove wrote:
> >> Recently there have been a couple discussions about limits. I found
> >> two issues regarding limits that may be problematic for the
> >> availability of RPKI, and to kill two birds with one stone, I propose
> >> the "RPKI Tree Hints" draft, which can act as a framework for future
> >> limits in RPKI. Here is a direct link:
> >> https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
> >
> > Welcome to the IETF! I appreciate you have joined this community and are
> > now engaging with the right group of people. Sharing ideas and concepts
> > by publishing an internet-draft is very helpful for dialogue. Kudos for
> > taking the effort to write the Tree Hints draft.
> >
> >> Limiting this using a global value would severely hinder the
> >> flexibility of the RPKI structure in the future. As the structure is
> >> unknown before walking the tree, discovering this using heuristics is
> >> tricky, and bound to give headaches for many years to come.
> >
> > Good observations, indeed, perhaps there should not be 'global values'
> > (established through RFCs). An alternative approach is: each implementer
> > picks their own default limits.
> >
> > The IETF guidance could be "make sure you set some reasonable limits",
> > which implementers and operators then take to heart, by ensuring their
> > software imposes reasonable limits. What constitutes 'reasonable' is
> > in the eye of the beholder.
> >
> > Recent versions of OpenBSD rpki-client impose all kinds of limits; these
> > limits are based on the developers' growth expectations for the next 1
> > or 2 years, and a bit of highly subjective experience.
> >
> > Additionally, our expectation is that operators upgrade their RP
> > instances at least once a year.  (hopefully more frequently as it is
> > security software!!!! ALWAYS BE UPDATING!!!!) ... Wild idea: as a
> > security feature, RP implementations could refuse to boot if they
> > somehow recognize they are older than 2 years.... I digress.
> >
> > To illustrate the 'hard-coded limits' workflow with an example:
> >
> > 1/ In this announcement we shared some limits: https://mailarchive.ietf.org/arch/msg/sidrops/cFVeb2u1MlYq4PfIsYcoD4a8wks/
> >
> > 2/ One of the SIDROPS participants took note and provided feedback, which resulted in this proposal: https://marc.info/?l=openbsd-tech&m=163645589724336&w=2
> >
> > 3/ rinse repeat
> >
> > As time goes by we learn, and we'll keep adjusting limits and keep
> > releasing new versions. This method seems a productive way to keep the
> > system running. It is better than nothing. :-)
>
> I agree that each RP implementation *will* have to apply limits.
>
> That said.. this will lead to differences in implementations which may
> cause objects to be considered invalid (or perhaps not be considered at
> all) under implementation A, but appear valid under implementation B.
>
> Documenting the decisions as rpki-client did helps. There is also merit
> in a public discussion about limits and motivations. I think different PR
> implementations can benefit from sharing. It may also help operators
> if limits are documented somewhere and RPs give clear errors when limits
> are applied.
>
> The way I see it though, the tree hints proposal is orthogonal to this.
> It would allow CAs to give RPs *additional* hints as to what limits may be
> applied. RPs should not go beyond their own limits based on these, but they
> may then know that they can safely apply even more restrictions.
>
> Of course, the parent CAs have the power to revoke a child in case of
> abuse (or hanlon's razor for that matter). But this is by definition reactive.
> The tree hints would give RPs more 'pro-active' information. And of course,
> the parent CAs could (perhaps should) then still monitor their children. And,
> if they would use an RP that honours the defined tree hints, then this could
> really help them to detect issues quickly.
>
> As an aside: for this to work well I think we should also consider extending
> the RFC 6492 provisioning protocol so that child CAs can be told by their
> parents what their limits actually are..
>
> Tim
>
>
>
>
>
>
>
> >
> > Kind regards,
> >
> > Job
> >
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>


From nobody Thu Nov 11 07:09:47 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 E8BA53A0818 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 07:09:45 -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, 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=student.utwente.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 SOPQ3z_3kIZT for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 07:09:40 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 3B8303A0817 for <sidrops@ietf.org>; Thu, 11 Nov 2021 07:09:40 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id w1so25443977edd.10 for <sidrops@ietf.org>; Thu, 11 Nov 2021 07:09:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=3S/4pxssHpVXtV1dwczOx2jk0AqqB67HgO2BNtVV7d8=; b=kiies1o4IDSMysfh9TaUIpMhgEikjF9q6zLFx2LRvzD7pR3WHfvOOvds0YE8/JACpG VvdJCrRqF/d9BvL1V1yWeL5LKKHegKkYgwEdQMWsgaokF9V5e0cUEABQ0zgzLLxrKbZT qRxkkfvTHA8mh3WsA1hzokPpa+270/ogcI+dNdDU5bpD2TmHQ28qBEWJm8beGDM0hYLM e1tJeSAxSjZozha1t1aNDIRvzsJ7k7wbpSdk1FA1s0nZ4L405GL1XaqaLq4NNq46kkut JNn6mRjZOTp6qqFULSTyt+1fP+Gu8bKKRj5ZN3D6L1DSWoe3+j+LF7oGWdsV/73V0lSo 8dZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=3S/4pxssHpVXtV1dwczOx2jk0AqqB67HgO2BNtVV7d8=; b=cqQCHq92mHI6cvfxPYeDfxPJ38hlo9wVZlAiZ3eg/i9TyiKI2oUKRs3eaCtg8rUKQA me4AE9p1eZI1ft+uYsyE2fLYUxYKWtlGCH5zsyg9BMeaeVZZR1e/z09bmVM9+lA8BYkw ZCjLAoeaIUt67tE3D4PXgAgJeWsw56/1CW5EEeAYlzTi4S4O22Tay0XwUW4x7HiMyP45 1FYG0b/96xh676RX3IlNHadxrFb9U5U5/2Zy6JhtFT0UBJHA/hROjOIQj2vr/KuQOpJN uVl0jYR8eJJpFCfKBx8yrdfce9/34mIpp/qDfRlWtMHnpwNtjB53C3eUE3XLvPJeHvWd fClw==
X-Gm-Message-State: AOAM532qDRbALVnUIS5rD8e0qe5QVpXCMbzgLX3mGVqg8PI6C4DVV6hE ivUElgl76UTW6ChOj2aSsiRF9Q==
X-Google-Smtp-Source: ABdhPJzTOtKLNb5+RYIgY7cHjTlMpNigGXvpLOXPV5+fJQL3bcvzQaoy0GDS4/yCbzXt57AWff0CyA==
X-Received: by 2002:a05:6402:270e:: with SMTP id y14mr10666248edd.140.1636643378532;  Thu, 11 Nov 2021 07:09:38 -0800 (PST)
Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id cs15sm1480681ejc.31.2021.11.11.07.09.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Nov 2021 07:09:37 -0800 (PST)
From: <k.w.vanhove@student.utwente.nl>
To: "'Job Snijders'" <job@fastly.com>, <sidrops@ietf.org>, <gih@apnic.net>
References: <YYvOop1mWMNc9tCG@snel>
In-Reply-To: <YYvOop1mWMNc9tCG@snel>
Date: Thu, 11 Nov 2021 16:09:36 +0100
Message-ID: <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFyWdSzoQig0DwblVC7L9ouDcgmDazIJEdA
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/N6cgV-CUKTHUyTad_b0euZamEMc>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 15:09:46 -0000

This is an interesting approach. To me it feels like there might be an
implicit assumption that the deeper down the tree one goes, the less
important the objects become. This seems to me as limiting the freedom that
RPKI provides, which, especially in the advent of IPv6, is a choice that, I
believe, if it were to be made, should be consciously made with wide
consensus, rather than be the consequence of an implementation. Take the
following case: a federal government has an IPv6 prefix, and delegates part
of it to its states, who delegate parts to the districts [1].

>From a practical point of view: imagine I can create ~900 repositories
(which is not unlikely based on current RPKI trees), and I make it so that
they would all finish just before timeout, which is defined at 15 minutes.
Then if I wanted to, I could make them take just under those 15 minutes.
That would mean it takes 900 * 15 * 60 = ~9 days if run sequentially. Now if
we use 16 parallel processes (which is the maximum amount of parallel rsync
processes you define), it still takes *14 hours*. This is without processing
trickery (large ROAs, etc.), rsync start-up times, etc. which would make it
take even longer. Is this really "resolved"? I would argue that everything
over an hour is too long (I believe rpki-client also makes this assumption
with the "killme" timer). Similarly, I am not 100% sure what MAX_FILE_SIZE
means, but if it means the maximum size of each file in the repository, then
I can have a  MAX_MANIFEST_ENTRIES * MAX_FILE_SIZE size repository, which is
400 GB. I can have 900 of them, thus 360 TB. These are exactly the type of
situations I meant when I mentioned that heuristics are difficult.

These considerations are why I believe a dynamic approach might be more
suitable, and more futureproof, than fixed limits based on future
predictions. 

Koen van Hove

[1] https://www.nro.net/wp-content/uploads/2010-burger.pdf#page=4

-----Oorspronkelijk bericht-----
Van: Job Snijders <job@fastly.com> 
Verzonden: woensdag 10 november 2021 14:53
Aan: sidrops@ietf.org; gih@apnic.net
Onderwerp: [Sidrops] RPKI fencing limits (was: Tree Hints)

Dear all,

(Geoff, NIST - suggested todo items at the bottom of this email :-)

On Wed, Nov 10, 2021 at 10:50:05AM +0100, Tim Bruijnzeels wrote:
> Documenting the decisions as rpki-client did helps. There is also 
> merit in a public discussion about limits and motivations. I think 
> different PR implementations can benefit from sharing. It may also 
> help operators if limits are documented somewhere and RPs give clear 
> errors when limits are applied.

To elaborate a bit more on the current limits and behavior of rpki-client.
Some of the current limits (with annotation comment)

    $ grep MAX extern.h
    #define MAX_IP_SIZE             200000	/* RFC 3779 IP entries */
    #define MAX_AS_SIZE             200000	/* RFC 3779 AS entries */
    #define MAX_URI_LENGTH          2048	/* length in bytes */
    #define MAX_FILE_SIZE           4000000	/* length in bytes */
    #define MAX_MANIFEST_ENTRIES    100000	/* largest manifest is ~ 16K
*/
    #define MAX_CERT_DEPTH          12		/* longest allowed auth
chain */
    #define MAX_RSYNC_PROCESSES     16		/* concurrent processes */
    #define MAX_REPO_PER_TAL        1000	/* mitigation 'issue H' */
    #define MAX_REPO_TIMEOUT        (15 * 60)	/* timeout in seconds */

(We are happy to consider additional limits, or change limits.)

Let's zoom in on how exactly MAX_REPO_PER_TAL works, as "issue H"
appears unresolved in some implementations.

rpki-client processes repositories in order of 'closeness to the root'.
After MAX_REPO_PER_TAL (1000) publication points have been discovered, no
new publication points will be added to the processing queue. The children
of a misbehaving CA always will be 'further away' from the root than the RIR
hosted CAs or nominally operating delegated CAs (like chloe.sobornost.net,
rpki-repo.registro.br, rpki-repository.nic.ad.jp).
Consequently, 'good CAs' are stay alive, 'bad CAs' are punished by virtue of
being further removed from the root.

The combination of processing in a specific order, and hard-capping at a
(generous) limit seems to make for a pragmatic and hopefully fairly
effective defense against the "issue 1" Koen brought up here [1].

Looking forward
===============

When 'fencing in the RPKI' (restricting the RPKI) - there are many
dimensions to consider (wall clock time, file sizes, width, depth, etc).
If we operate under the assumption that RPs are upgraded once a year, it
would be very helpful to establish growth projections for the next 1, 2 and
3 years.

Geoff - perhaps you'd be willing to look in your crystal ball, just like you
seem to enjoy predicting internet-scale FIB sizing? :-)

NIST, perhaps your team can also produce projections based on the RPKI
Deployment Monitor data, so that we have two sources to help set course?

The strategy here is to make an inventory of all aspects of the RPKI that
can 'balloon up', and then impose a limit on those things which permit
organic growth (in the next 18 months), but not much more than that.

This working group has the right people to make this approach work.

Kind regards,

Job

[1]:
https://mailarchive.ietf.org/arch/msg/sidrops/FCttiTVor2IpXuqiGljuoN66Xio/




From nobody Thu Nov 11 08:17:18 2021
Return-Path: <job@fastly.com>
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 404163A0B83 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 08:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 mGpbhCkN0MhD for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 08:17:11 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 8925E3A0B9F for <sidrops@ietf.org>; Thu, 11 Nov 2021 08:17:11 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id w1so26292305edd.10 for <sidrops@ietf.org>; Thu, 11 Nov 2021 08:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1HftDecbyITDR+xuDgil1YvxuF77ldS1uE59E8REW60=; b=XARWM64i9iKv3bxXE9dyIA3J9ktqU52H9tEfMEVTnS9uXjOGWeb15z8NzLbqxriX3U XFC979R4Qojezm0Z9lQC5buQHGVIj7dztTw+nYn7k+ifSFhItrky00WO6LwFyCW0Odp+ fVBV5Di9/avM26ASt1cpsqczRU0d9bf6m+eJA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1HftDecbyITDR+xuDgil1YvxuF77ldS1uE59E8REW60=; b=yb2frQ3pCiKzrOGduNc06tp2NeFlof6XAlTHM8PDq6QqLbaNLL5ObwfGFnW5IaVR7Z VXAqoFFHBDShJE/Mk5/dneKmI3U0hMtJhJ7CSmRJHFglnjZZXeKOrINkPLZ4rglV0cQp Z/iYvTbQIC6Axjpfu+rUGDJj1IjaxGZwV8AmK08rGEM6yyEb9+Q4G5rA97VpD/wcBopr v7zJtTqbBi+h5egkloiTHKVrd2Nv4ny/EY5/C2v/qHN10wyRcAJIsdUFpPeoLsZ1QN7P yssLKGFk4IpZwDgoWNhbT189hGUgIPHSSNi9n5O3YbfY7lTO0ySBwmYgIZb5AX5n4kXJ Favg==
X-Gm-Message-State: AOAM5323rWIzAimxZ94OHl9EPbABY8clUq3h4EDQqutdqcTwD8C/GNUn M0wDXKM8OywGLgXyUhEkZbqvxw==
X-Google-Smtp-Source: ABdhPJw7PwmnNaLCqQRmvhvpI5eRcUjyJJ9Wmna63s9QyWauC5cuXuyYUDHWYFhyRY3I6CT2McDwgg==
X-Received: by 2002:a17:907:90c3:: with SMTP id gk3mr11114644ejb.282.1636647424476;  Thu, 11 Nov 2021 08:17:04 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id q2sm1835510edh.44.2021.11.11.08.17.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 08:17:04 -0800 (PST)
Date: Thu, 11 Nov 2021 17:17:02 +0100
From: 'Job Snijders' <job@fastly.com>
To: k.w.vanhove@student.utwente.nl
Cc: sidrops@ietf.org, gih@apnic.net
Message-ID: <YY1B/vwyhNNrLibZ@snel>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3FBlMDxQdnGBieahgZ-lGljOnXY>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 16:17:16 -0000

Hi,

On Thu, Nov 11, 2021 at 04:09:36PM +0100, k.w.vanhove@student.utwente.nl wrote:
> I can have 900 of them, thus 360 TB. 

Ah, another limit interested parties should be aware of: rpki-client
disconnects from RRDP servers which try to send more than 4 gigabytes.

error message: "parse failed - content too big"

> These considerations are why I believe a dynamic approach might be
> more suitable, and more futureproof, than fixed limits based on future
> predictions. 

Noted!

Kind regards,

Job


From nobody Thu Nov 11 08:57:47 2021
Return-Path: <jeroen@massar.ch>
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 07EC93A0CD0 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 08:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=massar.ch
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 GuvV9xNivseu for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 08:57:41 -0800 (PST)
Received: from citadel.ch.unfix.org (citadel.ch.unfix.org [213.144.131.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C6A3A0CCB for <sidrops@ietf.org>; Thu, 11 Nov 2021 08:57:40 -0800 (PST)
Received: from [IPv6:2a10:fc42:a:1042:ca2a:14ff:fe1f:2b7b] (unknown [IPv6:2a10:fc42:a:1042:ca2a:14ff:fe1f:2b7b]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen@massar.ch) by citadel.ch.unfix.org (Postfix) with ESMTPSA id C190022B056B9; Thu, 11 Nov 2021 16:57:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1636649856; bh=Xj5xjDoScLIIknOFOcZZCSvPhozsew6ApDVXSYGHp8M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=i5uI2jRhRysXoK6ygEbMv/Jeoq9s+wOR4cB+9Q8j/Vd4MjlnGUFdOtr/ySSBstE9+ NyCoBbfhrKMAvIXJ5VBMCgbfM1ngrbdDWyKSYEk4/K8uKBQezSJj2w7lIdCmXw6C0r rbZtVnqJVABONBnwrg4GX3rWOnzX7UsWjMtFkh8DBgmdQ33SdQjdIAbkhK+zVsFxXz 4jNzfqSVWWTIbe2FtPK7bDpLU3tzOCDROSi7EuD5YkLOO/eREyLX0bNeLSkCttlEAu FhKW5aIzPhCi7S+zjw5FHANhEU1ML8TGSST9kXLMMovcgDxhbAblkUiyYIZhMTpue2 JE2W7MchzdUgQ==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jeroen Massar <jeroen@massar.ch>
In-Reply-To: <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
Date: Thu, 11 Nov 2021 17:57:34 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
To: k.w.vanhove@student.utwente.nl
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/kvOX3Zz9kZ_-ocbjQL-Co-izRVE>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 16:57:46 -0000

> On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
>=20
> This is an interesting approach. To me it feels like there might be an
> implicit assumption that the deeper down the tree one goes, the less
> important the objects become.

The tree will never really be that deep anyway.

If you take IPv6:

IANA -> RIR -> LIR -> End-User

Thus even if there is "PI" involved, much more, even more than double, =
will unlikely happen, especially as we are talking about routes in the =
DFZ.

> This seems to me as limiting the freedom that

Please note that these limits have to be added because of your =
disclosure...

Greets,
 Jeroen
>=20


From nobody Thu Nov 11 09:07:07 2021
Return-Path: <job@fastly.com>
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 8554C3A0D28 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=fastly.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 6IbGJs-c-10N for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:07:02 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 112583A109F for <sidrops@ietf.org>; Thu, 11 Nov 2021 09:06:36 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id o8so26697375edc.3 for <sidrops@ietf.org>; Thu, 11 Nov 2021 09:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ff3V2J3X77i+ezVIbSkrZ/0edSrSC+V34+B+LN3FeTU=; b=f5N5U135lPgSoo7sUVh95XLIn7lYCEu+DF87eRu7+UdqShQybrpKjV3RIOTliWpj7j hZiF9qNBKEPwC2fatnn68U6bN0SkcMy4iXoP0fO5A0NsxCqe8cx9FLg8vfdXgkx5j6ec 58Hu79uLcbxlobGDGwvB9H6z7cpBX/RTyxCPo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ff3V2J3X77i+ezVIbSkrZ/0edSrSC+V34+B+LN3FeTU=; b=rbgpo1l3VakGdg+Qq7RBFwWOpuAV33O4+Epx65yK5vYw5W690Q8jZvHN1Rgyy3o5Wd qk8+NEY2pWsv2vVYnLgdDu5LrSKkzGLoSfUMBL+TmW2FYAOh7VSPrWLavkKEmfcM49Ae CIzdp/1jYrgmIYGVsl0+L85yw0KR00Qp9HVpPDLhflpwBMJacjYUuFs2rIMZBfrbrvsc /H6TgjoyL9MFcxjF4WExLRMI/sLMO4riAkCyLoxhwO/pgGCdNclI2dvEkDf5Q+cnLUaz d73nB9lG5W174Bb1yuXUkU7pALCTSpNHfdijJvJxHQEdYU7dPXuB3+DDWb7ZHlDX3vu3 tePA==
X-Gm-Message-State: AOAM530wItSHLZC7rLR1I1UoiP0sOJSr6G/Fx9mgSRqs8my0zsjZQhc9 N5dTqAeOrMCrzQCIF8c7rqCVBg==
X-Google-Smtp-Source: ABdhPJxD8mtPO+XDaeOwDcRW0X1g8gQrEhStowL7sl1gSQq+LfMtafyL9H25e4m5KpWW+3uCNuL0/w==
X-Received: by 2002:a17:906:af1a:: with SMTP id lx26mr11338383ejb.44.1636650389395;  Thu, 11 Nov 2021 09:06:29 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id og38sm1650015ejc.5.2021.11.11.09.06.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 09:06:29 -0800 (PST)
Date: Thu, 11 Nov 2021 18:06:27 +0100
From: Job Snijders <job@fastly.com>
To: Jeroen Massar <jeroen=40massar.ch@dmarc.ietf.org>
Cc: k.w.vanhove@student.utwente.nl, sidrops@ietf.org
Message-ID: <YY1Nkwt8HdKUKW71@snel>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/vA5qyqDx10DCRSXjPP6cFpNnOx8>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 17:07:07 -0000

On Thu, Nov 11, 2021 at 05:57:34PM +0100, Jeroen Massar wrote:
> > On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
> > This is an interesting approach. To me it feels like there might be
> > an implicit assumption that the deeper down the tree one goes, the
> > less important the objects become.
> 
> The tree will never really be that deep anyway.

We cannot differentiate maliciously deep data hierarchies and
non-maliciously deep data hierarchies. This means that people building
non-maliciously deep trees... are being maliciously silly.

We must discourage them from doing so. That discouragement comes in the
form of their ROAs not being generated, because heuristic considers that
part of the subtree too costly.

Kind regards,

Job


From nobody Thu Nov 11 09:14:56 2021
Return-Path: <benm@workonline.africa>
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 5A13E3A0D60 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=workonline.africa
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 2H9PuZgnWRvx for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:14:48 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130074.outbound.protection.outlook.com [40.107.13.74]) (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 1946F3A0D5A for <sidrops@ietf.org>; Thu, 11 Nov 2021 09:14:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VfO0r9Pq7wNfaZpOuOYEfcgy5PpE0PgKLDOWvu3kPSckfmHDAgxzEL43d63V51XNgSNr36pxYT9q2yL0e5P13u5rWiZQ8eLJLH01Wkiu3hfCerz2wCoj6uhezqpSuqPobWehEbTOTWjont4zpPCnQMdMMNyOnpMu2f3LKX8niQzYsKb6nqA0YMdQuufm2rJAPeAxcvuR6+tLMD+f7BrqgegS8Dh5uOqZ8uZbEXu4ayBgS4ORRz1f9xgIrzgeVZRWhE9wryqNHevYWDgqD4ScAEl0GCEFSmTOuomUZlUP21dZJMIckjowgHrTP1Bu5xpITpJ5QMtH/XWEmEVRFwIDDA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bBCeU0K3w6V15mx3/vNTZBpdolroj5QOKfd1d3b988M=; b=Fnz2Bf4gQcN6rPbo19W6DP1E2zrckJosLpjAfnen2iet1AB+IKAS4LxMSBnsRFJsxCgztWBzrLwy2LuYFhn49terDba9AJ9JBZ4csvx0YZKh97v/oB3MRrOVuq+ACxA+Ro6g/+hrjBSPxuMzMFEI7QMhP7WIJKJfN+jx4bP10ZK+CtOqdn5fCTfAeSkO+c+zve8aXIFR/hXMGosQnI8Ky1LYVfPeJAifhxSm4HOgVX4q3qHA/K/CmZOIix563Y5SbqX3GZaLHdZ25Ybo2EtlZrOFEYFX28nLclv6aCXT8hB4fQUvvwydEkYuHQGYQrqdljGW4TMeEVj5D9RNYwdF8Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bBCeU0K3w6V15mx3/vNTZBpdolroj5QOKfd1d3b988M=; b=fh3izcDikdLtTvxQ++eDSzy0vb68Hv1JSeqAsr66SRlWc/exvFGgiDDTB8cFlxlq6m4FErKykcS8f2TTqswOfQvMnKxguMcEebrNKkrrvt6GH393x8vJ7nGLVkTw4VsnAEYQBCaXb3/rB5omKYZm6seFtK5oIG6PTntp5/y6jHQ=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa;
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AM7P190MB0694.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:11e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Thu, 11 Nov 2021 17:14:43 +0000
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%6]) with mapi id 15.20.4669.018; Thu, 11 Nov 2021 17:14:43 +0000
Date: Thu, 11 Nov 2021 19:14:34 +0200
From: Ben Maddison <benm@workonline.africa>
To: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20211111171434.nlkcu5s2hlzi4z2l@benm-laptop>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qqstas2xlcwkur2b"
Content-Disposition: inline
X-ClientProxiedBy: CTXP275CA0014.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::26) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13)
MIME-Version: 1.0
Received: from localhost (105.233.97.54) by CTXP275CA0014.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.15 via Frontend Transport; Thu, 11 Nov 2021 17:14:42 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 54bad394-ef16-4669-bd66-08d9a536c0c8
X-MS-TrafficTypeDiagnostic: AM7P190MB0694:
X-Microsoft-Antispam-PRVS: <AM7P190MB06949E15ED809750B1C192F4C0949@AM7P190MB0694.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: EmRSIwF6bNjpASJxeFVa922JesHQHx5vG00wtJSpIUWbOm2rlyzv9hH/9e7FZUsbeN0t/68hvcYhwsCobCLNsSJR5nU8iC6VKRkOlAnp8H48ulNsU+YARt11kul1s3oGj9Cj4Y7ky4JYaWMUZjr5xtW7nolp2NzCDQr5P0is4JQCGkPT9ru7Hyn16qubo5fvWXsMXrTOPwVPIa2HSo2trU3J9ZuazyIWCf/R6CnIFLllQi6wFrFRtRRb5bV/7YTBY+lnqf79trVNx4Vg0Giw+COk8IQzFhbdYIDqT3j+Ayj6WtS16FHUiCxn3rric31z7hzv5+4sA4FZdtVNea6NgrTPzqa7mnoGfTG4fNuEXV3bGtpiYES4Uwy6GNjFGeEKLaoMnyC0Sh3M+QCEt36RxD6mL9T9PXg/jM2FopFg93TcYC+MNTcsWLTsNIv/VlZ9+EVBjaiF1LUOnj7E9mVJpkMj64gCHcdR3r91icr6LuSsMTxQfxw9fjqdYvuHtYKwA48+Frtx/Aei2Y5kX8w9ifEDHeJ31zQZcQJ20qRMvdzd+iBF4fpcQPL5bXyifEQssaC1Ji8i8AeJYGoJ0Abcs1ZkrjSHOAQk6Tk/DO9SiUIsr+qVrFNe5LH1+VZG+4ElHhHq6rsON5wSgHhMSwNJ6fCZOc+l5/9Ir+flw6fIbQJOdUV9QHLfX/3XAU70rJ8qs9PupvfDnBpklX8P3zNmeE1C58T7UZCzTJQmL6ptpftDDq9UoAzjEzBCCbQDf0yT
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(7916004)(366004)(136003)(346002)(376002)(39840400004)(396003)(5660300002)(21480400003)(8676002)(38350700002)(33716001)(2906002)(1076003)(316002)(508600001)(966005)(66476007)(956004)(6486002)(6666004)(66556008)(83380400001)(52116002)(9686003)(26005)(66946007)(86362001)(186003)(6496006)(38100700002)(6916009)(8936002)(44144004)(46492013)(2700100001); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?b3UfqSlRSxAvANEobHLEmuRd1WhTfO04BRUerw/zEBNgHp5Ka/9ScnVt5qwf?= =?us-ascii?Q?ranxJX1SobzEDgw4Vr/rR8aO/3HSa608ZswXB89W9OBP9bzCoqwh4paX0Pvf?= =?us-ascii?Q?HBn8DBgit4UjsiwanEeQTkNIRGNNC+Bmb4a+fI0kliLtJctY4GWd9qoLYnyg?= =?us-ascii?Q?NEgmBHOji9T1ZPta1HKT5uYxJ+8VROK8LZ+Io2SYclES950IbEm7iNEK4z+W?= =?us-ascii?Q?4pjkiqRAd7FOI1rDG7GS1UAwY8MhEfjX8XMR8GDJN3CjbRaqdN/sHmfNmsFi?= =?us-ascii?Q?xRul1rmmRHqk9JooyequH2CPYv2/qpyhi0RTuFsPUzaNfdVzABa6SCJ63lUK?= =?us-ascii?Q?Zj2fGftdKD0VKwL1qajO+RwEdXgEreNRRQ54MqemI6Mx2ftk849NxLJYZo9m?= =?us-ascii?Q?LTkKlAnk7C38rDklswInSUkjiJVTACI2n9NWbEQtkqDSLREFUZycC/D5wp54?= =?us-ascii?Q?MyVJahb2gLPRl/bjHRULclIVDyi94fDmJJbToVfj0Jbz5Uu7Oian8Zu0Pzj1?= =?us-ascii?Q?LdGTaAFtkry6XaBIyJ+VdYmiCdy2UncPyYTrjwV3M+h61cfHqaZIE4aIhvGN?= =?us-ascii?Q?nVhLi5iMlIExA+bENSOKpD77rhSGdUcGgyk880v4Nl1p5hNJ3Vmb7EqvMbO7?= =?us-ascii?Q?3wCHd9Y4kWzgjSyX8PwBjo4cFwcHXKbT+E84gza0t6e44EZAZGwksssGwfDT?= =?us-ascii?Q?oFAdotGi+oEQBd6X6ak+uCERFoK1Q8IS983KW9Traros5MkeidBbqWxo4hRv?= =?us-ascii?Q?hsqUxcpNeg1mJzEGLPMaSv9F+6ciTSLto5R3C1kgU8tHvf+YcrZhFc1fElWN?= =?us-ascii?Q?+m5MzJpzan4h2LiVv0UB8Tnv5gtfbKmUbxdprXMfKMz8/CUIyLNwTmpHXwyl?= =?us-ascii?Q?4VWPtBCZz51O7xecJ1vdOnN6bzcGv1B1DPnegNwU8nwbbdcIbtG/ITcMvWGA?= =?us-ascii?Q?9QjE7LHsr6E7shfG08mJaDMkJ4xk115U2rTcA6pDgIgio7qcULbDqYXKCh/c?= =?us-ascii?Q?pU/0VIvL3ylsye5P/BaDMzGmmIowI6m9XqfaY4/qc0nHtHW5O5F3Wvwz2pyF?= =?us-ascii?Q?hsuQE/JEBP0twW8RGlQ6H7DBHbKMd3zLnwxaAJs7gbdAxTSOeI7b5vhNv/3b?= =?us-ascii?Q?HMkDaXVNdaG6GmpJSQ2EAre8u0EdQkhZqo6KAgAcI0+x1EOgJ833EIIX8CyJ?= =?us-ascii?Q?LzBZlYigEsvdxTy3qTeqgBZBm4p4SIHEIITlvvpQmv3XE0TUA5Jk4VtzNwQe?= =?us-ascii?Q?FBH7G7RopRpH/W0AWI90wGEGZvN35dEvY9nOipvs6sfIdyqAGyXVMPlcU/4A?= =?us-ascii?Q?fBDVjLueKMZpsy9Fvp1kwUqAk1Oi4JeoM4lscS2rdJfcRkDg8ajAC9gI7R4d?= =?us-ascii?Q?utYjcEGH6a1rKHcIdVxIubolPVqHuGub189VrYFAmDyvwBj6R4GPO/FJeozR?= =?us-ascii?Q?71AcgOFvOdjP4ntLx6aL8YA/n4cokUNS049NPlrqWjO0dcEWllWUXFkV+7RP?= =?us-ascii?Q?QNOPwCBJGFk+wNgoMIgahNUS4jBK85whWR4jpKae9pMmEJzZrW1/1mxbJRbC?= =?us-ascii?Q?D7yZgUsOQ96ONtgQkik0rRvEgLfvaaVp6Ruver3XnCxH+UZbtAiSvTcU/Pu8?= =?us-ascii?Q?XHzmvRZ85hmRP9FOG/dR1Hk=3D?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: 54bad394-ef16-4669-bd66-08d9a536c0c8
X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2021 17:14:43.1988 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rJFMymqv+ZTph/v45WHrMtVuGr5cFO8EkIDT5Hl7cl/VmZz9ajkHErcJS6IecE2H0qfO/fuIx96vKx6ugouXqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0694
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/HNFN9n39p_FSd1VNWCMQDDpQSV4>
Subject: [Sidrops] Extra-early-allocation OIDs for I-Ds
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 17:14:54 -0000

--qqstas2xlcwkur2b
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi all,

We have seen several instances recently of authors and implementors of
RPKI signed object drafts wishing to publish code and prototype objects
before early-allocation of OIDs from IANA had been completed.

In order to avoid a situation where we have implementations of
early-stage drafts out in the wild that squat on unallocated
code-points, I have carved of an arc from under the Workonline PEN, to
be made available as interim codepoints.

The registry for this arc is inside the rpkimancer repo.
Details here:
https://benmaddison.github.io/rpkimancer/main/oids.html

To request an allocation please submit a PR or email me.

Hope this ends up being helpful.

Cheers,

Ben

--qqstas2xlcwkur2b
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmGNT3oACgkQOkYk/rSL
aGDq6RAAgLZgHrysWMR+eCSMvo17YBQpMJiuA1kyXtecRH2JddLAmjiwZSlSQV3b
ScDnj7BYVrFHhhxCuXqxWrndVzhrvcp+mDKPL1/qy33zEzgU5QFHWFpNzm5YUVRk
6dbC1FEgxL7j0iQ+eYpEbt46X3IQP/EuZsGeykivz4appdctKYAeGOpRGhS0O4i5
mlimC0hvk8HNc1YwhnXsVtAX/cTmAd9qytUe9lbALRn1nLNTfiWm1+Fcd4hYQNPY
IAcy7Vlu0FvyDzLuyRWSEArMZINgyiepg2lp2df6an6ZIp3Lu+eMtb1kFQOl8vdY
conRKSnqjM48JVsXRLmZGWso4bKgX1kWV3cV6P2wPTkMatZqWk08/4WvetLk3Hks
bcfMunbT46spHgb6GTw7916EaTICnA9q20REaPhcMX3SWX3lRBmvisNhUC63NRZH
QuWOaRiiALWPKD9I+zeiyIvTW5kv8JVAyyFgYsoqsIeXFedQrWUxm4ymcGKJZyHd
jINZKSnQGDiTi88ZeZt6iCTdCo62MrRyNxmTkdeC9iUvL4cSVz1baYIUIzOF+9WH
P5fB2LFnD3poKSFhUhO9DzCg8GZogv8ycVQyK95koy8a+1Y3t83kDNdFy0xeuq1x
ZwPhGxI3BK8727NupgshjFSU/DyPOqokqhNfMmEVkhzE8O+kia0=
=EWOa
-----END PGP SIGNATURE-----

--qqstas2xlcwkur2b--


From nobody Thu Nov 11 09:48:50 2021
Return-Path: <benm@workonline.africa>
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 C17E63A0DF6 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=workonline.africa
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 ALrZJIrA6Xqj for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 09:48:43 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2088.outbound.protection.outlook.com [40.107.21.88]) (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 5683B3A0EB5 for <sidrops@ietf.org>; Thu, 11 Nov 2021 09:48:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=accqVd3K6JxFPUcpSP7+eN8QgjJo3TxAQeDe0N5uHvdJiU28LDlvO3VBKp7hne8o2LItVV2PBqZjVPRLrueHZqGdHet+A7nykLyK31nXhov/DpQCzklnZ5WfoOd2qdyqyFzxf9UzLGuMZ0bq9f90WfuIn2JkAT20M56tX4uN3TTU3O9Eyt0X2355f73gz1P1ZB7xGg97NVjE/UbkWT+sUy56A3yhSt+VYlAgO03uI15Bz8jXJ1ZudTGp1BmzyVv/JL0HF67PKBRx6OSx11uL/UoI6gn9Ws6yR30/baw+69lnm5Vcgdclnpv84KkIX9IBMv3dWd9BZt9oZvN32hDLag==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wbRQatEXVrVr6icFYMqL8KGhsZqcG84C7wLCQ5qI7fk=; b=MTDk1nQ+M5/ostOBA8g1gfcAtz0y1Yd3/iWDt/MhKauVd3uFX8KkVp/kxyFsH3eUt0acs6cktRr96GPm4Wsi51K55VNTz87Wdakb9Hsln87qQwyHEV1WPe3Va3Fjd6B7v+v4AUuqiQWpl0L6aof+8L8pKz6Xeivx0UoNnmWM1ODwHD1yP2fjAm4aybE8SvvuvVG3m2a2BRN/nQnoRLuqc7N4xi4UfAxArfW+G8se7binWevHE74cA9uZBMwnyXVeV7q34qBzut7cTzy7Kcyy0Shi6WZZGzV8ivcXpUYRylIbe/nmKxycDVCMtBkX46FAeA0xR8UlAj0P6l47iRHY5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wbRQatEXVrVr6icFYMqL8KGhsZqcG84C7wLCQ5qI7fk=; b=Tp9NnyXOIW8Vlt9ylfAoDfj089nmJhAKAHn+q6TL2HqtZTQIRjn91M43EOQ72c7dKJQI4cJuuYYIYYDIS5lIkmdLpmjzKG5onyRCIYunhBLMGPiquxQkykOl19wTtVyfmPX3u9QuCzGvD5adUVGLSFh2v7FHx4zQmVQK/Q3TAHo=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa;
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1351.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e3::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Thu, 11 Nov 2021 17:48:30 +0000
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%6]) with mapi id 15.20.4669.018; Thu, 11 Nov 2021 17:48:30 +0000
Date: Thu, 11 Nov 2021 19:48:23 +0200
From: Ben Maddison <benm@workonline.africa>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20211111174823.lpt5t4yctroxtb4c@benm-laptop>
References: <4427CFCB-D170-4B25-A5C3-E5614F04BACD@nlnetlabs.nl>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uugq5zwnge3dbf4m"
Content-Disposition: inline
In-Reply-To: <4427CFCB-D170-4B25-A5C3-E5614F04BACD@nlnetlabs.nl>
X-ClientProxiedBy: CT2P275CA0006.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::18) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13)
MIME-Version: 1.0
Received: from localhost (105.233.97.54) by CT2P275CA0006.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11 via Frontend Transport; Thu, 11 Nov 2021 17:48:29 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 489b52a8-b0c8-4e81-8760-08d9a53b78e6
X-MS-TrafficTypeDiagnostic: AS8P190MB1351:
X-Microsoft-Antispam-PRVS: <AS8P190MB1351393F6CCD35ECB9823C53C0949@AS8P190MB1351.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 6ghPxdCI9Fig/OKzjS33gDxWc8UAzv0ZKATzgAKXZ+o83QLecSU8oKRlae7WipLLrPN+7Z5prwdPocVtZUClMoc7UG4ebKy/3y645Ws7FN5lhSU00VrZTS3J9ZuygGbkDtTbLvzsWuZ2p1Whk5qfYWeL6I61eYjvZ+9fKyKBvTPodZRE5fjWaWC0IUOTRJSVkXmSgYu5OXp6y7zKakjX6CGfawbV8yNDijl2G1tczRj1YvFyicpwbpZwIR+hMd2RSNCnemxw3W1LRMsvF257el/lOv1vrl12PVmd3P4CmgnLGsxF+fqTDzc6umvJnLWfd5j6vSMVxJVBPnYQK8AUQSpmjYDPrwl/bUmoqM33Gmn76crrwaTWaRY0Epdyuhgx9q1Qeu5gyWnaa7J7ni353vY3/ZRFX1OrQ9uOX66k6hEXkQf2mDaPWGBKxli3FvjwqoYibO48zUs2pslPsKllzLuwRR6n2fMmOELXDnUOhYacHge4qoGV1Verg/D6qiszK1eGOq+5PHxiTbmH2z4wCtu6bj1gCxCKME7VPo/omCdW/VRXcp/m1pF67P1UTdsdW+SuSB++HX9jGspLpN3wZ46RGjqkFnC1jqsyG5bFMvqf/EDMekcZRPHkgfQlOuARXpw7wpQmJqFcjBPvMlZiwT08tYLKVAKwUg5E7KKcW35PBNwUwxuZ+p/hg6NKbA+7VzXDDWeLVK+v++5uQCj3VPsCyF1xQABzpXamWa3jg4MVU9d6+W+RNGfeHvB85Id0ZIFsgsDafG2UfTkFdi1ZwjJUOBGvLo3NMIu7j4JBnKTr23GDUXQmGpDGSmiuhdEzFMJP5LjUZL+fKXMtmEq54qPADht+rzc5uXQevlfjUmxq084Q/C/UjjaxR7GVGXDc
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(7916004)(346002)(376002)(136003)(396003)(39840400004)(366004)(19627235002)(66556008)(1076003)(5660300002)(8936002)(186003)(66476007)(8676002)(33716001)(66946007)(2906002)(26005)(6486002)(6496006)(52116002)(316002)(9686003)(21480400003)(508600001)(83380400001)(4326008)(956004)(38350700002)(6916009)(6666004)(44144004)(966005)(38100700002)(86362001)(46492013)(71440200001)(2700100001); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xu40RCihXUCjJGWChyIQYtvZH2bYG0bJTB0fi0rXTNja4ikfW4Ane6ril3iU?= =?us-ascii?Q?k6t+tBtX34vX3z4KK8/q+q8trmveQ7gkd541rLuQUb86sZwd1exI0PWJzYoI?= =?us-ascii?Q?Hxv7NG2SXarkHjuxB0P84kKc0DtGzNUPAWq22wmyjVDsudbf6Fvs4ReDQvhS?= =?us-ascii?Q?yaKmtrBWjnFOWeNRx/Iv91jx21mTmBCoa0yw+Z43pofEIOo20Ewi3EzIm0IR?= =?us-ascii?Q?XWqSU/V3yIiWrWIEMcXQAQbpN8niEd+VeNm+u+V5520copW3dzY5ZmwamQjt?= =?us-ascii?Q?zZpdvh0Qa+vsDk9JZu1Hsz+MI6tVSl+Z2CFkCQ5TraPQjlLHQushwleX36em?= =?us-ascii?Q?yBUkDOF3qxt2WRR9vFunc41A52FzVvOFnE5z5fiCagypzxWR2Adp8MG6NsEM?= =?us-ascii?Q?qINC6tW7ukzA2A171k0PTwqparW8+coJKWccy4XAsRdQLZdrEHSjvV8B7Vly?= =?us-ascii?Q?6jdOvVtQjQ7cbK9b6OSj+JLnKDvzagFwlGNcVl5zqUkW5fod00dUhxAr1GX1?= =?us-ascii?Q?X9/JesLuk16P12N4C20FPfV97zy69m+J9NlGJu6jZGQ9H84HodBBjFgOGzms?= =?us-ascii?Q?2SrhoZfETsMzFlWCH/fbipd3ne+3uKaNdlQe5mkM+30eupnPTr67baddpcBX?= =?us-ascii?Q?f2yCMldZAnVITjz7HFgLmFVuyA/7bAZoPoSr2t/OckXw6N8Ns/9j9MSoU85r?= =?us-ascii?Q?qJnqFWRQ0DG7UA3EiFGPstlXnsBex7yjZ7mnCCHWLyvAx37buDweryxcy5y+?= =?us-ascii?Q?vnYlsuSEogoT2/Y6zjPYWNI8YS33mdGx6g09+jdR4gRBEcP6w6F4WJArT54X?= =?us-ascii?Q?oMvV3kcrdAg5wyNPyL04Oo3/XFY0L4kjG6TnZbHwGsDrg9nKF4qhoaBHlct7?= =?us-ascii?Q?7ozY2d5UJvLENX9bM5tDk0gLZFqnNJ57D6RKcAnYFFy2mBs4tKSLdKehzyC3?= =?us-ascii?Q?oQYcbi1Cu4w+4mE4SQ1SfzeNSTbtBE7enxqaY2Wl2sjzRTvPGqLdJ4fnYCIR?= =?us-ascii?Q?O+Wgsgs1EsrSqipbY7i++GPPq+91TbXhEcM+p3SAS3XGfec/dsNxK8Ooh6y/?= =?us-ascii?Q?lOasUPkB3oc9DiNOVQPMjFAF49e5CBwdix19pwc9YhzXsvDhsO+0G1zXJpaP?= =?us-ascii?Q?92y2pgsvLNGbHgpRfYfdTTxMwqESwXGTMSz69SvcqlAZb11S7CscrVW6l1UK?= =?us-ascii?Q?f5NqVpyqH55IJkE2/A14f5ZAyOEydZI14tn0d0YenYhJipX2aPXk2/4DHn3F?= =?us-ascii?Q?T5U3LHfbpYPQsB5bYYES2LvQbd56sGaemCcQHMvf4ypANMLFxPsNMmd+41Lr?= =?us-ascii?Q?NfCW8OSWKxSAL4Hjl3tu8u8F3LYzEt9B/zINtgyK7yzDtEynO1iDxyCA1Fci?= =?us-ascii?Q?2EbRZn5inYtpeYBejl6cK1kfnQhD3pbx8XuPtET/xfEeC4iYC66A0ILP94pY?= =?us-ascii?Q?G3znkyCMPgZZUIbovlSvW+nQqtJUUDRTYzwxM3wJngPnhZ0iD5cN3nxWFpRC?= =?us-ascii?Q?xLx/X/T8NpZL7yNHb1tF8aCHF0bOGcE4I/zbr9OI8Cpj/UusJ7WAA4W5GJQr?= =?us-ascii?Q?cgelsuDUdY3ORveqfDCwIJ0ht3VLh25ePlxhjQ3C/6MNtYUd3vEErjsN5qfn?= =?us-ascii?Q?6iJgv9CcfRuvnxurYHvbuqU=3D?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: 489b52a8-b0c8-4e81-8760-08d9a53b78e6
X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2021 17:48:30.5846 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: mx4QZMvLpJ35Aoh2A/we+ElPec+Fv+X0sgMMNFm3DkuM6fHvnifHQXjRBfqJ298XXJK88vvGMQWcCU/ayUmO5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1351
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/oZqEFK4PBfolj_W6iBlAvlX-SlA>
Subject: Re: [Sidrops] Experimental ASPA object published in testbed
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 17:48:48 -0000

--uugq5zwnge3dbf4m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

On 11/05, Tim Bruijnzeels wrote:
> Dear all,
>=20
> It's not my habit to announce new Krill releases here, but... we added
> experimental ASPA support to the new release candidate (0.9.3-rc2).
>=20
> We are running this version in our acceptance environment as a child under
> the RIPE NCC Test environment:
>=20
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-te=
st-environment
>=20
> We have created an ASPA object, based on the latest proposed profile on
> the list, at the following location:
>=20
> rsync://rsync.accept.krill.cloud/repo/accept/0/AS211321.asa
>=20
This object can be successfully decoded by rpkimancer-aspa (using the
"tim-revised-profile" branch), using the following ASN.1 module:

    RPKI-ASPA-2020
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2020(TBD) }

    DEFINITIONS IMPLICIT TAGS ::=3D
    BEGIN
    IMPORTS

    CONTENT-TYPE
    FROM CryptographicMessageSyntax-2010  -- RFC 6268
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

    ContentSet CONTENT-TYPE ::=3D { ct-ASPA, ... }

    --
    -- ASPA Content Type
    --

    id-smime OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

    id-ct OBJECT IDENTIFIER ::=3D { id-smime 1 }

    id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct 49 }

    ct-ASPA CONTENT-TYPE ::=3D
        { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA }

    ASProviderAttestation ::=3D SEQUENCE {
      version [0]   ASPAVersion DEFAULT v0,
      customerASID  ASID,
      providers     ProviderASSet
    }

    ASPAVersion ::=3D INTEGER  { v0(0) }

    ProviderASSet ::=3D SEQUENCE (SIZE(1..MAX)) OF ProviderAS

    ProviderAS ::=3D SEQUENCE {
      providerASID  ASID,
      afiLimit      AddressFamilyIdentifier OPTIONAL
    }

    ASID ::=3D INTEGER

    AddressFamilyIdentifier ::=3D OCTET STRING (SIZE (2))

    END

There are several issues I have with this module, most of which have
been discussed previously. It would be great to finish off the
discussion on these so that implementations can stabilise:

1.  Should we keep the enumerations of ASPAVersion, or use a simple
    INTEGER?
    My preference is the latter.

2.  Should we keep the "AS0" method of asserting transit-free-ness, or
    use an empty SEQUENCE OF?
    Again, my preference is the latter.

3.  Should AddressFamilyIdentifier be defined as SIZE(2) (as above), or
    SIZE(2..3) for consistency with 3779?
    I think that the current definition is preferable.

4.  (New, I think) The ContentSet information object set definition does
    not seem to serve any useful purpose.
    I assume the intention is to "extend" the ContentSet defined in
    CryptographicMessageSyntax-2010, but I don't believe that is what
    the above construction means.
    Russ, I think your input is necessary here.

Cheers,

Ben

--uugq5zwnge3dbf4m
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmGNV2YACgkQOkYk/rSL
aGBu/w//Z5TkfDaKjzQOZfYGJvJ9MDbNMA0qBc2QCFKyf+KmpbhBMUDOGJh6/EPX
sNdYe8y/dorVtBVJ/3R5meZ6iiufD3HtpozY2jYq3AQfP4AL0XbWnofti5jJeQk3
43fPIdd79GCcRkXS3ICaiHOuZgaF8x0gn7JKznQNxu47plOM02Eo5uyAADrmwfSr
lecxpqS0pPEGNZTuI8pnWBOMlaU6jB59Exo6DI8CM9gJqAMffiH0bXFes2rGNDq0
Xq3kEbXvjlVuUgeLukJVG8FSDzks6OUsVjGw0iXvAxKmkrEPOLLvBS9nosvZ3SXo
AstTFuDPGxGap5AOTVDPfFJaXVHVW1a4hSbNjioiniWp63gZg54yIzQOzQJJBdVq
7QFi0hGdmDDVNMOpXTmFn/SlA6XrKAN883k3WmYDJ3GcW7kynHylQb3oiSpfTK01
tB/uOG3b7N9WyRfc43ark9Q9wrZxE6BdfX63YnM84OEfNx45bhwWMxAL4lXWDKQw
As5j006aKaydPHVUYh5fN+VcMmMY18MIQXX+LruYoxD7mQWAx5WrCHXsBqKc3mzd
RHh93BF7ydNDP9o5K7D1duMyynPthM5FDnLat2UrL4A9W9XRCiVOHHqdyS2v8qNa
wQFS9VKYesn3TJ/mhuOdlgmdM+/cIwfFW8jxNwnC+tcWMm6cZjw=
=9KBG
-----END PGP SIGNATURE-----

--uugq5zwnge3dbf4m--


From nobody Thu Nov 11 15:16:30 2021
Return-Path: <job@fastly.com>
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 A69073A100F for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 15:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 esWfjUgJmtgg for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 15:16:24 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 0D3D03A1009 for <sidrops@ietf.org>; Thu, 11 Nov 2021 15:16:23 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id c8so29887591ede.13 for <sidrops@ietf.org>; Thu, 11 Nov 2021 15:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=c5KqBbX4bA29faY2sg+l6UKNAg6DDKa8mJIUSIapUrY=; b=NGBsF3cvw1tr8brQOievvjRPMsY9Yh7bNIe1gaI5zKYcpHZNrooch0z+nx5eho4Yii KwkpmIzcjwKYU1pYHYy3swWTbW+c7dOUImqmqDkuf/dJhUOt0Hp3xI/E2dVaZjDJFwCD 10ZOT+F1Q6W9vezGDiRGfoqxUwpYzxhPxKT8Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=c5KqBbX4bA29faY2sg+l6UKNAg6DDKa8mJIUSIapUrY=; b=HDkDK6UkuLPgUAUE5M8zgVoCnyC0nuqo8/KkjUT3QVUTFPvvR6HdSHweCvwjTFgXyr gWqTen36w/AFCwVvz6k3ajixsYmakuiqvW+PtDVhqMzpslCNjqscrm8m4jqgPcPAbVSI Nwv+5V5R8mKUzPE3q9gaPWz8C7X6CItZNOzAROZoiJ3w+D5F520qH1NXt+LRGd1Q0hYt Ap0cLBjKiG3m1HvBx8Md1ACIiFZ579BuRdUpDXYySaDgIciRrDUyPyhblKabxmCVsNEm 2sucUJ8vmEpYdbga/H1Uwd9ERJrlVatCndKS/arTwaiSz74jzT42BrWCwSwiej9/sPrq LJ7A==
X-Gm-Message-State: AOAM5316GCLPZ1xzr28oIqsMWfujfHqYs7792jDZ07trEjVxDbfFtk2d owzyrKtao9sR0UgOnjZpQgTDwQ==
X-Google-Smtp-Source: ABdhPJxIfAqXvjzGpLX26FdME3JxjVVHNrLue36VlbmV+Ef+rw75UNpaqarw1O0YVqbZhk3UifK2zw==
X-Received: by 2002:a17:907:7f11:: with SMTP id qf17mr13610423ejc.196.1636672580456;  Thu, 11 Nov 2021 15:16:20 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id hz15sm1996530ejc.63.2021.11.11.15.16.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 15:16:20 -0800 (PST)
Date: Fri, 12 Nov 2021 00:16:18 +0100
From: Job Snijders <job@fastly.com>
To: Robert Kisteleki <robert@ripe.net>
Cc: sidrops@ietf.org
Message-ID: <YY2kQsJIPw5Q7j3a@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ZPlHPQdgruudrQj_HyT-aBYyTBk>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 23:16:29 -0000

Dear all,

I share Robert's perspective: the "Tree Hints" approach is fatally flawed.

Anyone who disagrees: try implementing it in a RP yourself. :-)

Kind regards,

Job

On Wed, Nov 10, 2021 at 11:40:58AM +0100, Robert Kisteleki wrote:
> On 2021-11-09 17:48, Koen van Hove wrote:
> > Recently there have been a couple discussions about limits. I found
> > two issues regarding limits that may be problematic for the
> > availability of RPKI, and to kill two birds with one stone, I propose
> > the "RPKI Tree Hints" draft, which can act as a framework for future
> > limits in RPKI. Here is a direct link:
> > https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
> 
> I'm not a fan of this approach. I believe enforcing such limits in a
> hierarchical fashion is a ticking time bomb. For example restricting the
> size of *all descendants* may work well for a while, but at some point in
> time a (grand)child naturally grows beyond it and will just be automatically
> rejected because of these restrictions.
> 
> In addition, what should operators *do* in this situation, particularly if
> the limit was specified some levels above in the hierarchy? Change requires
> the (manual) cooperation of multiple levels - while the "suffering" repo
> owner may not even have a direct relation to the "enforcing" CA.
> 
> Similarly, prescribing minimum bandwidth requirements between essentially
> random hosts on the network is unlikely to work in practice.
> 
> I believe such limits should be specified / enforced in client software,
> where the operator has direct control in case something is amiss. And as
> others mentioned CAs do have the power to deal with deliberately abusive
> clients anyway.


From nobody Thu Nov 11 16:24:51 2021
Return-Path: <gih@apnic.net>
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 C6B023A0D58 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 16:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=apnic.net
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 fpvmpzimCqvA for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 16:24:45 -0800 (PST)
Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2073.outbound.protection.outlook.com [40.107.107.73]) (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 E7C0C3A0D56 for <sidrops@ietf.org>; Thu, 11 Nov 2021 16:24:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HxhFsKaLwdHzcUeNrIYvDvlMpWtKzspDk+CuVoCCZ3z1RmfjWaCLf7L9Eoyk+eny8vcZhDxH3kyI+d4P5zNmtWc5KsN5PQm24jKv4UDiICskloHV3/og3wDr/7D9YBtbTOkLns4qQyG2UZ3bssKyo6H0s+iwzGGSmjKA9C0Phzn2ql8Z/geM/HuDx9uB1m4M5hX0nVyy1qR04C2YoQ7/yYK5v861dPlhQD4s5uNJaaanzikRPtXPlkHQ1qr5XzSepZyTvByBhaeMsBSqffFPjF8VV5X64d/2t9N/0EK8dBHtYES1W0Vszv2blLGiBAuwL9xRTtC15i1FMfYXLLO3mA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MbKEw4Qepb1YElJa0RGH5vdWmb7lRFiYOtntTq6vgeA=; b=lGmpR5mfDfpfU86ZfiMd+Qd7SqgzwEu36ThRkKsksEgufy79iYI6K/zzaUdwYnThtAAje+11t8EXI36lcEtId0f7kzDwXv1CbDvZhlzwNzNPL/9a6WhIVSvyWXtxKbmy2tIFdIzQVV4HdSFjOvlMWf81NLc0xDcx94p4vkGJeN6pb322OLS+nJvbEBSiG6sTSEoIWROPqld1vi4L7MdEoY30v8x3Y5dSlODgi66DMf7irDcSCEQAKXIzrsr1RClU6m9rbO0gNBUHlO8sqsv7rG+Fsjh6FwycE6Xa9pI/GkFBlaNxmPLqLP9IOS7TdQvMqvwsYu3d/VA1mQdWZAk/1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MbKEw4Qepb1YElJa0RGH5vdWmb7lRFiYOtntTq6vgeA=; b=b81MU0ZwFW8m8MJugHFbYlg+Ujj66v0DCXViNtAVfsVIUA78FVxINI4djIVur2ELX//S7Pu25L7ih9STM92eVVUu+Z3DLXVEHGeqG9Kq/btuqAXQnRVQkcNTa55kg+qOQPtvEsZBZVX3RG+Qj/WvDW9Nr0lbARU6+8BX2kqrZlk=
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY7P282MB3913.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:1e8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.18; Fri, 12 Nov 2021 00:24:34 +0000
Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::49b5:db43:82f9:faa2]) by SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM ([fe80::49b5:db43:82f9:faa2%2]) with mapi id 15.20.4669.016; Fri, 12 Nov 2021 00:24:33 +0000
From: Geoff Huston <gih@apnic.net>
To: Job Snijders <job@fastly.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>, "k.w.vanhove@student.utwente.nl" <k.w.vanhove@student.utwente.nl>
Thread-Topic: [Sidrops] RPKI fencing limits (was: Tree Hints)
Thread-Index: AQHX1jo7hiN7BqXF5kCBsEvb+H0dD6v+b9MAgACbDYA=
Date: Fri, 12 Nov 2021 00:24:33 +0000
Message-ID: <0C096B6F-074C-4B2C-A2C0-CEAD6FA2C20B@apnic.net>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
In-Reply-To: <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3693.20.0.1.32)
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 25379db5-bfc5-400e-3408-08d9a572cd58
x-ms-traffictypediagnostic: SY7P282MB3913:
x-microsoft-antispam-prvs: <SY7P282MB3913A5C614DE558E72D5E626B8959@SY7P282MB3913.AUSP282.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G12nqL1JT846K2p7RHnMrSokYFabw9NYPP8NBb49BEC1zwVmrHZi6jomhKXsRa07DGr8tw5LeiGg6OWNRjLlr6l4gaEN99I9K+G0ND8Pm5z5sfjw3Rlwx9SV4rB8RjsITB5Q03bXn+0hiNrevtOirukvJzImxjq7CvYS9eLwdCI072adJ+f9rwXRnR7TWyC0jXk0hGFkcYqK48aIIkny7AhI/o60OXBhgKWYbzW/X/KtKZYDMziX2uM+JgiwSXJquSjkzKTaU4hk1XgMjF+gZoa8e2+ySn8210Vra3g9u7C86lX/6cwQug6Uqve5g+T2hpEe83O06AvYftxCpaeqnjIAiDiQTltU+22vTRMgEeyD/r9C8x0CXs8x5oyqskme/ydF26wM/C0T+y6OlRUQ5Yd9vzItOu8SxvQdj9JH130LnYppQLziAFf7CSgFLSDHBOAPtA06gjQ9ClD8CtB+FiZwIvhs75Rsm9WCSKPg/arD7wLhtL2rbvlOqP22ZBaXhYpnNnHncuduybi2ovtXoh595xCIQOFxdgVyz3Gg23oNdFoko2jMDibDqK2OgF9/IlpzFyXRtYyn+eTTMV6bFvFC5FkvTqRGfh2h6Wcl58CD7PvZy3AjO/Na6VzR8CfriiKv7L3p5AVXjcrTdp3xHRqo8UFp0kq0/q+KB0iip1yeNvVFFHgtKIqG5/GoUQdGjeLppGTC57LtmXaMIRiBVy+hcr+w3/EkczN6/R6vSW5jRhhNGFepKuFvaEeXHBAHCx7rp5YlqvHKnHmRnDbDxGMPxPIXwMdr31WhsIRGA+QIVEIW/5f8OpbN3GGXctsV
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(4636009)(39840400004)(396003)(136003)(366004)(346002)(376002)(8676002)(66556008)(33656002)(66446008)(64756008)(6512007)(2616005)(6506007)(6486002)(2906002)(38070700005)(8936002)(186003)(66476007)(76116006)(66946007)(83380400001)(5660300002)(66574015)(122000001)(54906003)(316002)(38100700002)(966005)(4326008)(71200400001)(36756003)(6916009)(508600001)(86362001)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EJqr++RAzK1oHlglhJgr7h/bkz74jucokkTh8fVcZPdyUGdECIm9oFhahUPS?= =?us-ascii?Q?2i7aWEDpuUDMLrvAjXK52l6TQy9Q3gfQ0KkaV9bw9eT7EfjOT29A+7eOs9x+?= =?us-ascii?Q?sEkyGK9CELJJw3HPQPTeJSHIcMZoq5EtQJQ7Oeln6GO5mINqq1/lMuRmMra9?= =?us-ascii?Q?c4zCfppUsUAT0XzqIeGyv8FQB6CqZcjpi+S6BYSkvV2NYzCQSBKwKdUsYEHx?= =?us-ascii?Q?2ciFbs7loJ5Zj7G+nEd9ChQM3b0uI6VHItrIkoEbDDO1/3ceTKnsEI+e+/EW?= =?us-ascii?Q?An5qWq0bN3MyQcEQ/f8Q/XO79QriHeF+UmJ2f1unBpWx2aFnZP8oi1SLmqPJ?= =?us-ascii?Q?m2/OCuPNxcDcDee+gXuqdBy0MYYe+Yk1FfC8fyFm1xMimzxjUbX/PeQsNhXz?= =?us-ascii?Q?Zw1vRPBa9X6jesJM0nxTCft+9HlCIWkFiO93oyUcb5p6mGJfPHiVBY5Gch3w?= =?us-ascii?Q?Q3lsZU6bZVUJzFmINAc0s9EOq+JDd4o4pNDmHrzBXOJgIHl3b/iLlQfycBvk?= =?us-ascii?Q?vwzO0OeG5/5uXANSMo8XJ8Mu6UIr5q+CDPSJKoMumGzujPVsZ3O9+18ZNyt2?= =?us-ascii?Q?aLgNlfO2pUoKgTjJVO4XXkI76UUvgLPlsBL5NSQHLfZFsajTL79ZtrwIfyJW?= =?us-ascii?Q?jTN0M94Lcgw9yv3RpkhCU3EwyEFRvgeFBxSdJfl9i7zT4Gz2qrS3xwrs2dzx?= =?us-ascii?Q?8XuNcwQDav5cKwnWT0sXoqz0lWm4LKkikru4VSGnrQKV9nn6Abm2tpdBPimm?= =?us-ascii?Q?99J6aKGeMsd2FLYI/e9huzbPBHLV7i9Uf7sb2T0IBuIW/DGaRBfvC2zg/cYs?= =?us-ascii?Q?alJveAZ5qkydcsMsHaQJojnCGfNlwa6tJV/qOmY02LPY8JATOiVR5hxemGf3?= =?us-ascii?Q?SfecKhU7CT+pxPi0KIW0t/3bUuSi/ew8vTA8xaMBz77DHefMkYO5fjKnpyaO?= =?us-ascii?Q?jKmAdK/WfbdgbZ4IIjbLyVsjdK7DLbIwIKCxVgipKfBC53WMXVSdajEcj7dl?= =?us-ascii?Q?KmSjAH2GoVGHbVg8LM1Vxqwt9vi6GKLaS7rRCbkdoz9KlVdVntXpo84ivq1P?= =?us-ascii?Q?AUNb7RYyko4+GxJ5HIfLAv2deYMIFXBxBmSTWCI9+HaKJ7qcLkDasEaAG/h/?= =?us-ascii?Q?OlFrCcCPI8IVV6x7hKQsz0N/tEUb69ig8Gbh4wGp7aaEc+rz8QNOhWgsRz/b?= =?us-ascii?Q?rhFROaWaVQozSRVlpLbpNNE5x3qPn0pLn1Z06XRPJM0d4+MBrWEsT+6+1fiU?= =?us-ascii?Q?GorMxsElZJDS3zccRXb8+oApOwJNLncAAMYlqh2RXKsognnpwtN/mZdrOkiw?= =?us-ascii?Q?214dxLmN0f/zQVY1K1oPsuf2EtYqQzs0G1jJVZeWhVYhZBHa5MScmc4RipeC?= =?us-ascii?Q?qHbGIpydEskKKPZa/2rOf0WM+7aIwt+oUViS7uSFL98fwH6Yg0DI4Z9z4zBN?= =?us-ascii?Q?LFHqAYqY14JzB5z4n2EHoSCSBP55gdWIgaDP5HsDAh4xEThqbokHagKHx4Xm?= =?us-ascii?Q?J5oCYLTJQSRxUy1ZkSlc5YrYfYx3qBknYyq1jdz3YczfH98fcfw723l6e57F?= =?us-ascii?Q?5DxgylvvZNsO3r1/5bzVUgC/Co0UWmUEZuERscIN4Is7kQBa0prB7Mz6p9TS?= =?us-ascii?Q?L3WizK9UDGBXxqfvOlxDLCqg41BYsJHVDcUHi3Xyzd/o?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DE364F8A2CC94F40BE6E05354FA1DE97@AUSP282.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 25379db5-bfc5-400e-3408-08d9a572cd58
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2021 00:24:33.9142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GXSHDENSg55thz/Ntn3OdohfR4Te6vG8vQzKHMo7CIdGaS6kvmEptUyCgHchRVaK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7P282MB3913
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/wzITxFKkMGQWD6Xd23s_vvgcxBI>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 00:24:50 -0000

I hear you Job. It is something I will look at further in the coming weeks =
- thanks for the suggestion / hint!=20

In the meantime, you are probably already aware of https://grafana.wikimedi=
a.org/d/UwUa77GZk/rpki?from=3Dnow-30d&orgId=3D1&to=3Dnow&viewPanel=3D59, bu=
t for other WG members who have not seen this URL, I find this a fascinatin=
g timeseries on the time spent performing a pass across the RPKI publicatio=
n point system to check for and gather updates from the perspective of one =
relying party.

regards,

Geoff

>=20
> (Geoff, NIST - suggested todo items at the bottom of this email :-)
>=20
> Looking forward
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> When 'fencing in the RPKI' (restricting the RPKI) - there are many
> dimensions to consider (wall clock time, file sizes, width, depth, etc).
> If we operate under the assumption that RPs are upgraded once a year, it
> would be very helpful to establish growth projections for the next 1, 2 a=
nd
> 3 years.
>=20
> Geoff - perhaps you'd be willing to look in your crystal ball, just like =
you
> seem to enjoy predicting internet-scale FIB sizing? :-)
>=20
> NIST, perhaps your team can also produce projections based on the RPKI
> Deployment Monitor data, so that we have two sources to help set course?
>=20
> The strategy here is to make an inventory of all aspects of the RPKI that
> can 'balloon up', and then impose a limit on those things which permit
> organic growth (in the next 18 months), but not much more than that.
>=20
> This working group has the right people to make this approach work.
>=20
> Kind regards,
>=20
> Job
>=20



From nobody Thu Nov 11 23:52:16 2021
Return-Path: <tdekock@ripe.net>
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 B81DE3A133C for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 23:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=ripe.net
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 iygWyx64ZQYP for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 23:52:09 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 CC76C3A1340 for <sidrops@ietf.org>; Thu, 11 Nov 2021 23:52:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=UYfuj9SWRPmL9QHJdYvawQLdbwSn9txwx3u5MLeSVXE=; b=sxRHTAC8YzBTm58TQtwG1CuB XqTbZyK5D+roz2ycNwrV+wUuLY69nLuoBySpjoYkwFn2xfBzly5Mz9rrEquWWAqOhtNf5ObwvRcL2 LBb0BioBBPJTaxMypoEm8vhW2UoWsvJRwxDilA+ShbzW9y4oWop87Odq0NFt562GqdJFF4gTAoWCa D6UzHXELr4ga11R915+tntqtjZijbGDlAjHymD85Vx1OIAoEDIeFe4IwkE7js+ejwxR9+QbpXyFDm BuzfKiOvC2F8tOVATUd2YCm44ez1L3BfUTszeUWxGTJ4I9G0Fvkukr0Fgq4l6z7WpIxVHKVb9+VcA mZyNlpzhuQ==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:34408) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mlRLv-0009qC-Q9; Fri, 12 Nov 2021 08:52:03 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mlRLv-0001ZE-NS; Fri, 12 Nov 2021 08:52:03 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch>
Date: Fri, 12 Nov 2021 08:52:03 +0100
Cc: k.w.vanhove@student.utwente.nl, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch>
To: Jeroen Massar <jeroen=40massar.ch@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1fabaf362d2ef6cc2b8bddcd9046cb755
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/e7BsLw_1eyCh0vai4WizmOCQdms>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 07:52:15 -0000

> On 11 Nov 2021, at 17:57, Jeroen Massar =
<jeroen=3D40massar.ch@dmarc.ietf.org> wrote:
>=20
>=20
>> On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
>>=20
>> This is an interesting approach. To me it feels like there might be =
an
>> implicit assumption that the deeper down the tree one goes, the less
>> important the objects become.
>=20
> The tree will never really be that deep anyway.
>=20
> If you take IPv6:
>=20
> IANA -> RIR -> LIR -> End-User
>=20
> Thus even if there is "PI" involved, much more, even more than double, =
will unlikely happen, especially as we are talking about routes in the =
DFZ.

The tree gets deeper in practice because there are internal levels of =
CAs at
RIRs (and other locations).

For example, for the RIPE NCC tal:
  1: RIR 'tal' 0/0 offline certificate
	2: 0/0 online certificate
	3: CA containing members
	4: Member CA.

I see multiple reasons for this number of levels to increase. If an RIR =
were to
add the possibility for a member to have both a hosted + delegated CA, =
this would
likely add a level (or potentially hit the object size limit with it's =
manifest
during a key-roll). There are also reasons to structure the "CA =
containing
members"  as multiple CAs. For easier processing and updating (less =
objects),
or because the CA is structured based on where the resources originated.

But the critical realisation is that in the tree, for RIRs with NIRs, =
NIRs
"look like" yet another CA under the "CA containing members". If you =
perform a
breadth-first traversal, an abusive CA that is a direct member is as =
important
as a CA under an NIR.

If the order is unlucky (how is the order determined? alphabetical by =
filename?),
the abuser can prevent the NIR from being processed.


>=20
>> This seems to me as limiting the freedom that
>=20
> Please note that these limits have to be added because of your =
disclosure...

These limits have been added as a stopgap to fix vulnerabilities. I =
would
welcome work from a researcher. Irregardless of you how you look at the =
handling
of the CVD by the party running it (NCSC) - this is better than finding =
about
these issues at Monday morning 3AM.

Kind regards,
Ties

>=20
> Greets,
> Jeroen
>>=20
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Fri Nov 12 00:56:13 2021
Return-Path: <cjeker@diehard.n-r-g.com>
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 BD4D13A0A7B for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 00:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 t1u4vqznxURf for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 00:55:57 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ED53A053E for <sidrops@ietf.org>; Fri, 12 Nov 2021 00:55:56 -0800 (PST)
Received: (qmail 75103 invoked by uid 1000); 12 Nov 2021 08:55:52 -0000
Date: Fri, 12 Nov 2021 09:55:52 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Ties de Kock <tdekock@ripe.net>
Cc: k.w.vanhove@student.utwente.nl, sidrops@ietf.org
Message-ID: <YY4sGOlIXW9ax7g/@diehard.n-r-g.com>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch> <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9ddmOdYDIhof3Lb7eoLe3aQDG5w>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 08:56:11 -0000

On Fri, Nov 12, 2021 at 08:52:03AM +0100, Ties de Kock wrote:
> 
> 
> > On 11 Nov 2021, at 17:57, Jeroen Massar <jeroen=40massar.ch@dmarc.ietf.org> wrote:
> > 
> > 
> >> On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
> >> 
> >> This is an interesting approach. To me it feels like there might be an
> >> implicit assumption that the deeper down the tree one goes, the less
> >> important the objects become.
> > 
> > The tree will never really be that deep anyway.
> > 
> > If you take IPv6:
> > 
> > IANA -> RIR -> LIR -> End-User
> > 
> > Thus even if there is "PI" involved, much more, even more than double, will unlikely happen, especially as we are talking about routes in the DFZ.
> 
> The tree gets deeper in practice because there are internal levels of CAs at
> RIRs (and other locations).
> 
> For example, for the RIPE NCC tal:
>   1: RIR 'tal' 0/0 offline certificate
> 	2: 0/0 online certificate
> 	3: CA containing members
> 	4: Member CA.

These extra CAs are just adding a constant offset to the depth of the
tree. They do not really matter.
 
> I see multiple reasons for this number of levels to increase. If an RIR were to
> add the possibility for a member to have both a hosted + delegated CA, this would
> likely add a level (or potentially hit the object size limit with it's manifest
> during a key-roll). There are also reasons to structure the "CA containing
> members"  as multiple CAs. For easier processing and updating (less objects),
> or because the CA is structured based on where the resources originated.

Even with this you would end up with 2 CAs per delegation.
So the math is something like 3 + 2*delegations. For rpki-client the max
depth is 12. Which in turn would be 4-5 additional member delegations. This
should be plenty to do NIR, LIR, PI delegation. Especially since using 2 CAs
per delegation is not the common case.
 
> But the critical realisation is that in the tree, for RIRs with NIRs, NIRs
> "look like" yet another CA under the "CA containing members". If you perform a
> breadth-first traversal, an abusive CA that is a direct member is as important
> as a CA under an NIR.
> 
> If the order is unlucky (how is the order determined? alphabetical by filename?),
> the abuser can prevent the NIR from being processed.
 
The order does not matter in a breadth first scheme all resources of level
n+1 are downloaded before resources of level n+2.
So the bad CA will not stop the NIR from loading.
The only problem is that because of parallel processing the bad CA may run
ahead of slow CAs and hit the limit before the other CAs finished. That is
not good but it only stops the sync of repositories.
So even then, all ROAs directly referenced from those NIR will be validated
and added to the VRP tree. The external CAs form that tree may not have
been able to sync but the system will fallback to its cached data and
validate with that. So in the end most ROAs will be added to the VRP tree.
So no, the abuser can not prevent the NIR from being processed.
Also since this is a limit per TAL all other TALs are not affected.
 
> >> This seems to me as limiting the freedom that
> > 
> > Please note that these limits have to be added because of your disclosure...
> 
> These limits have been added as a stopgap to fix vulnerabilities. I would
> welcome work from a researcher. Irregardless of you how you look at the handling
> of the CVD by the party running it (NCSC) - this is better than finding about
> these issues at Monday morning 3AM.

It was Wednesday 3AM for some people when the CVD was released so how
does that change anything? You run important infrastructure you better
monitor it and keep it up to date.

The problem here is that RP software needs to download untrusted data to
do its work. This is an inherent design issue of RPKI and it opens a large
attack surface to all of RPKI.

-- 
:wq Claudio


From nobody Fri Nov 12 01:32:40 2021
Return-Path: <tdekock@ripe.net>
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 106A93A0B83 for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 01:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=ripe.net
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 O2nm1nTQixts for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 01:32:26 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 62A6E3A0A71 for <sidrops@ietf.org>; Fri, 12 Nov 2021 01:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=YlZfFLpfAYUQWxmZ3BylN5EtF109HzhQRJpPle8Mr8o=; b=Jm9M6ihkP6QLllGRasoEIZtC PML145khIf1Ew78F4gGfdCz3UdDT/PXzZ2xAcVdQ2Pqa7mftjwzendKxaMdZvG8PWtuOGK11B5tOr SOBx39Erd/65Y6zUoQXmlvDyCMieXT7453/mX2mqAEF84r9RX6X+PBhNS5xA4afGcjMjge6C2tINn jXypN/LfGFIxMEsKDsPVPDbhlSZIKwheYHYJJo02RmM81tB71C7oTI0Dm1GLXijv0cC1FjeLfMNR0 PyoarOqmRNLoeyPzqcn+0TgADu3RWu/HvbrQsJ5iFyw4xABs/cR0XCCSVpTxRrjNQRrKDZQnT/MU1 WIg0pN4KfA==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:43726) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mlSuy-000CY3-Iv; Fri, 12 Nov 2021 10:32:20 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mlSuy-0001HA-E7; Fri, 12 Nov 2021 10:32:20 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <YY2kQsJIPw5Q7j3a@snel>
Date: Fri, 12 Nov 2021 10:32:19 +0100
Cc: Robert Kisteleki <robert@ripe.net>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <90D49131-F83C-4713-803F-8FC216B1A3FD@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15a389b8b4dc13b26097823da5a552b3f
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/W94w8qoMiV6N_9B_2oUfLAFXpIw>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 09:32:38 -0000

Hi Job,

> On 12 Nov 2021, at 00:16, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>=20
> Dear all,
>=20
> I share Robert's perspective: the "Tree Hints" approach is fatally =
flawed.

Could you elaborate more on why you think it is fatally flawed?

Robert names specific limits he has concerns with, as well as the need =
for
manual cooperation to raise limits.

I think the latter is a _good_ property. A CA wants to use an unsafe =
level of
resources. You need person-to-person interaction (c.f., =
machine-to-machine) to
ensure that it is legitimate instead of a malicious repository trying to
break the whole tree.

> Anyone who disagrees: try implementing it in a RP yourself. :-)

I agree that it should be shown that the type of limits proposed in this =
draft
can be implemented.

At an abstract level, this draft proposes to evaluate these limits =
during tree
traversal. I think that showing that (some of) these limits can be =
evaluated
during tree -traversal and -processing is enough. Do you agree?=20

If you can show that this is possible during tree traversal it shows =
that you
can apply it in an RP.

Kind regards,
Ties
>=20
> Kind regards,
>=20
> Job
>=20
> On Wed, Nov 10, 2021 at 11:40:58AM +0100, Robert Kisteleki wrote:
>> On 2021-11-09 17:48, Koen van Hove wrote:
>>> Recently there have been a couple discussions about limits. I found
>>> two issues regarding limits that may be problematic for the
>>> availability of RPKI, and to kill two birds with one stone, I =
propose
>>> the "RPKI Tree Hints" draft, which can act as a framework for future
>>> limits in RPKI. Here is a direct link:
>>> =
https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/
>>=20
>> I'm not a fan of this approach. I believe enforcing such limits in a
>> hierarchical fashion is a ticking time bomb. For example restricting =
the
>> size of *all descendants* may work well for a while, but at some =
point in
>> time a (grand)child naturally grows beyond it and will just be =
automatically
>> rejected because of these restrictions.
>>=20
>> In addition, what should operators *do* in this situation, =
particularly if
>> the limit was specified some levels above in the hierarchy? Change =
requires
>> the (manual) cooperation of multiple levels - while the "suffering" =
repo
>> owner may not even have a direct relation to the "enforcing" CA.
>>=20
>> Similarly, prescribing minimum bandwidth requirements between =
essentially
>> random hosts on the network is unlikely to work in practice.
>>=20
>> I believe such limits should be specified / enforced in client =
software,
>> where the operator has direct control in case something is amiss. And =
as
>> others mentioned CAs do have the power to deal with deliberately =
abusive
>> clients anyway.
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Fri Nov 12 07:11:52 2021
Return-Path: <stkent@verizon.net>
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 BF18E3A08B6 for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 07:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.431
X-Spam-Level: 
X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 UKdRkEM0Vk4T for <sidrops@ietfa.amsl.com>; Thu, 11 Nov 2021 07:28:25 -0800 (PST)
Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (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 2CB523A085C for <sidrops@ietf.org>; Thu, 11 Nov 2021 07:28:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1636644504; bh=qlGmA6pB36CbMwhcE8ddj74uu4FXae8knwZImrxJQuI=;  h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To;  b=Zobw6l9B3cbyTlOzyXhi1Wz5l+SwovQ6FsuEY9jfbNMJxGiAP0+Eup/kdFEu29yssUdbjGbyDc1Hsre3ojX5NnvlUeFLB10yJuf9F04RSm37lxrhhN6fUoZ/gsdfHEGzrXjUGgKmN0ct2OKzP2qImTMa6pGxo7QUfaFnlgA2pmzEZXmQaOmdJpKthrlFKWomeIyTAEwI00ezdioWetesyvTJRHpFyn4/wUVqlv45OsZNS2Vd7/Qp65VV9wwNathM6F950LG4QLAsZDkHaJSgpL62FYZ06C9qwzw/IJWIvAL4WvpFVf1mT+p5cBCdcxpNtPxhWUBDA2VP6/XQoTMMRg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1636644504; bh=fIr/2jU1FkVvOv9AQV4kkUIA2AuTdTfFhDVyaTG8tTp=;  h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=pq1jyCfbA2l36YlAaXbFw8yYDrmZGzkTybQLdv3TewlUnjEQH3vgGXVQj1lEt2ASAsLQXzryL8iw1ShEJozd10YdpXL/f9rI14L+BGNSyk/Ulv+UpZJuXzGpttzqFylKFcbRqKdoQPSFB0F6wvWdwZVFxKJF6FRCqD0RdUfV8LsQvfUCziY6nNDmG5n+/csz16t1fLuFua6yDUMTdeE92pbATVRdsKRnABUclg/54J66+6PgNDWQV6O/WXNOWN6+ZA2oCnN3uLuW9d6buOG4AmyjWc1O5t7Cr4hqahVwUVfnPd2+V7OVzWdZiTYNW/X3m3d63mT1VWYcPeDrRGQ4hA==
X-YMail-OSG: 9QOwkH0VM1l.9kgc_LAs9J0LPOSqX2KQXFofJv.BpEqDthxySbNKkNiiQYffeYV XLPb2tdjv5Xr3ICRwr835bsLKsnmhCRF2zk3Fyp2XFkJssY9BgjoNbdzSqLkXT.k6p2v9cEMHufa 85b6IIkGZhMcBO_KGXwfhFloR3BmnzUhZz3WGVJELk26qP7DoMtDR8qCmO9tefCyOU1trKOMf0kd 1NRoIREqDdIDJj4bmCo5cUPp4HpQYyCjoBqAznAEgQHXQWjUhDfkLNFE6yd6ynoZsiSYboIw4z9j FcWDvZYR7194aWaTKtVQKrZ4SAJEJKmXkNKa7oA1UxZFcd_5SdoGxpovfaf95rC7vVSuLAmUBOu0 9j7RHsBDoBfvJuy1tM4v9AirZLKj80b340oW_84dJ27CPB893Kx5URwGrZx2_cbGTt_At8jAlfL_ hJ3nPoHp8RcUZ.i2MTOS9eAwVJcLFrL7Zj4XbljZ7a2oNzsKwKrH4H6CdcnK0eM7S7.qL86oOmDL DXuex2cyQ04hCRIT0MA7EF4Yqz4.peXoT2L.ZsPDCGryhHQyP47vmsiVg1PBS7Hh0JnU..5vr.h8 xtS3cTaZEhoXC5.K9ec32ThB3uBvjaP2kGqr5qidcx_0xoc2zB938uyj2mDR7wpmdmaRO4b58O0z eBtHgxaio.hBeHrbGXuJdVntNR8OYGsEDnybQp1aLN.sAZU00mGy2nqp1fBooSvj9kPcLzhj0QeY KHBJ5NUIchq4jZ2Nm3E1xMfLThdyg4fmyzdpYstjTZlqMggqKA1E6enZKFwAV1mQV_f7Hzud_URV XGjtPJpYt7SNxPdlH0jM.BD0Irfstboz_ZEKZRb3kZWCWD1vIwG3_NQM1Y.NlRk2HXwg_2MYJXDl LaebVPDfXMYidIkogNqBkazfZxk0ubpeV4xds8lZ9sNh7sW00.89HaFJ_qKQfZCkOAnH6Oe_NC3. idNxfsuomIiWB1D5nho4xRddSE.v6coDFcMAmy3ZL8Z49lUm6bh48dUEO_S80vr.U_z8SfvNrUJH 7J8zC2LNxUCeha7DQGNMd0rCoWPw9QGQ7MShDrD2jKjFrGauz5x_MAhDPSg8ncMtKUyB_IxjZJJy ctx2evUj.cgcciFseqbJW6KeIGckVP7eH6vbB55C8qL37a7K6Jz7llKGnbe8xIpqg3czb1B_nIK. ClvYDgcw6z0z9E4NFId7HEZAV2tacDrZJxD5PvoPw7CqdZwcnmhjtbMEC0ctmAxEfzcHIJeYNajD _Ue2Md8yGYt58MdxqiuYPUkcocwTZWB7OOrdJoWxIKecvzfl.AlqKAt4BPiQflwnoA9KGdcL5SO2 uL0SC5ZtiyDC_yNS_zX1jCDUI3_H668e8eNsrPr86sNyeObXINt7oj6U9jjHElfAtkutk_3wrgcU KUqAIzi6WNGzO6wtDLKMPssqGPmv3NfzTPO_krkLwMn2eKMt89o5GiuuxolJx35_gyrDXjEFyvdC W9AIp1S28OXZssapOGhmSAktJgxmMbCv._j7SoZDp3.LAIfqXvWndgqH6GKwirSZC_zrURs3_lHo tTxz18n5tG_2oVYaty.g2QwHrWKJl_rK2oMmbOnlf.8Urdv83Fi.FAIT6IrbmuIX9GiPK9rdTOYy iF6SniPxgw3b2uvYipumBJp8chZ_jkj1p6yv2XWNngrWo35s7SW7TlI83q.ohGKqZWrKtekyCf.T 5xpRCzzrHmHDC6Pvmf6UhUn4_DPnKylKS.xjv0kAlBr84CvY5CxzDIJmUcPu6CnUU2OwVXmthFb8 6okw6iXb29iMgOP19BtZAd0M4DmeUtS.0B7eofkGK3NDzCyIlbCkLocZP8RCdJQQFerqnxvXNyOh 23Fc8SS6g7iKr_oc9rAYxlWUEqC6RmSv_3j_C27rwA0pudY4Sa0pqJbnjPKJFktttGkyn2hRrHBS 7o92TggrbLyfJQC0m1EwcN5p83a6.LeMElwLQPI8FrQA3GHO2v2d3fQ.8ZOmTTQC6Tntsi22_WOG kUTvujkGnIAt27yjS2zDetJq2MZf4w.QJyDSnOaOpx2zCUrn_MMULIMLAFs1TcQ3E4p_2vK6zYu_ pMOJ2zIfCYfg_1euhGbNOedOY5QYiLgmnglMTc2d3ljEvnsAZBtECxG3MpRuGWP3BPsPhAC6tz3M B_OyxmFbHd7ThSg--
X-Sonic-MF: <stkent@verizon.net>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Thu, 11 Nov 2021 15:28:24 +0000
Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c4e8a9da3b758f40b1c441910aa97314;  Thu, 11 Nov 2021 15:28:19 +0000 (UTC)
Message-ID: <6b1e4ee2-aa5a-5e65-35c8-95abdb88cc94@verizon.net>
Date: Thu, 11 Nov 2021 10:28:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: sidrops@ietf.org
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
From: Stephen Kent <stephen.kent@verizon.net>
In-Reply-To: <000501d7d70e$247f3770$6d7da650$@student.utwente.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sXxw4ZBhzuCESQZ7IJv3a5y_-4Y>
X-Mailman-Approved-At: Fri, 12 Nov 2021 07:11:51 -0800
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 15:28:28 -0000

Koen,
> This is an interesting approach. To me it feels like there might be an
> implicit assumption that the deeper down the tree one goes, the less
> important the objects become.
"important' is not a meaningful term here. However, it is accurate to 
say that as one descends further down the RPKI tree, the address space 
range available to allocate becomes smaller, relative to the cert path 
in question. That's a security feature.
> This seems to me as limiting the freedom that
> RPKI provides, which, especially in the advent of IPv6, is a choice that, I
> believe, if it were to be made, should be consciously made with wide
> consensus, rather than be the consequence of an implementation.
"freedom" also seems like an odd term here. what do you mean?

Steve


From nobody Fri Nov 12 07:11:57 2021
Return-Path: <alex@nlnetlabs.nl>
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 78FE03A08F3 for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 05:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 js9RLF7tYA0U for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 05:23:10 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 3F4573A08EB for <sidrops@ietf.org>; Fri, 12 Nov 2021 05:23:09 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id BDC11D1; Fri, 12 Nov 2021 13:23:07 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1636723386; bh=yi9Vfb5OKhy+yFteut6+ScuW2eMza8STo42B7FHjM8E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IkQnCxQHbKqX1JhiJAK4hScfHMQ3d9zboReh4xV0CwWg3ly9At5lzfRgKItl9l2gC bwBX9/zQ2lEWAg9WaFcEvgWM3HP+fU/bfEe7y0VIX4EO0ZclpiHjaHo/8m6ZtFWnqH S0fSf7g63kdAfai+d/84f9uxIF4dxZEsolXhkG/TYe7Vv+abWe9qe0UvTUMd6O1Xm1 Kdks+PPJBi4wOhMo+gd5DkLuZQlZKZmkzsch/R+Me3DVGRMeJnAZ3QhG7A5OysgpIz asAkV4mQ8xQznxyZ14HJNTk9lHbzHvN1tWekHWT69/nhYSanP3mdedkeMfDpJ/KZVB NtWoRmeKZ1oLA==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Alex Band <alex@nlnetlabs.nl>
In-Reply-To: <0C096B6F-074C-4B2C-A2C0-CEAD6FA2C20B@apnic.net>
Date: Fri, 12 Nov 2021 14:23:02 +0100
Cc: Job Snijders <job@fastly.com>, "k.w.vanhove@student.utwente.nl" <k.w.vanhove@student.utwente.nl>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <97F99F97-4329-48CC-8080-BF3530208170@nlnetlabs.nl>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <0C096B6F-074C-4B2C-A2C0-CEAD6FA2C20B@apnic.net>
To: Geoff Huston <gih@apnic.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/HMuJJTGVRoy7Jl3n8xmye6Qdg2U>
X-Mailman-Approved-At: Fri, 12 Nov 2021 07:11:51 -0800
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 13:23:17 -0000

Hi Geoff,

> On 12 Nov 2021, at 01:24, Geoff Huston <gih@apnic.net> wrote:
>=20
> I hear you Job. It is something I will look at further in the coming =
weeks - thanks for the suggestion / hint!=20
>=20
> In the meantime, you are probably already aware of =
https://grafana.wikimedia.org/d/UwUa77GZk/rpki?from=3Dnow-30d&orgId=3D1&to=
=3Dnow&viewPanel=3D59, but for other WG members who have not seen this =
URL, I find this a fascinating timeseries on the time spent performing a =
pass across the RPKI publication point system to check for and gather =
updates from the perspective of one relying party.

I look at these time series pretty religiously. I=E2=80=99m happy to see =
that when everything is humming along normally, even today validation =
runs take less than 50 seconds to complete, even though there are now 43 =
repositories to traverse.=20

While the graph on Wikimedia is certainly interesting, I recently =
updated the Grafana template for Routinator to include all the metrics =
added in v0.9 so you can easily get these views yourself. In addition to =
the original Trust Anchor metrics, there are now also per-repository =
metrics to allow an in-depth look and troubleshooting, as well as =
separate metrics for every RTR client.

https://routinator.docs.nlnetlabs.nl/en/stable/monitoring.html#metrics

https://grafana.com/grafana/dashboards/11922

Cheers,

Alex

>=20
> regards,
>=20
> Geoff
>=20
>>=20
>> (Geoff, NIST - suggested todo items at the bottom of this email :-)
>>=20
>> Looking forward
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> When 'fencing in the RPKI' (restricting the RPKI) - there are many
>> dimensions to consider (wall clock time, file sizes, width, depth, =
etc).
>> If we operate under the assumption that RPs are upgraded once a year, =
it
>> would be very helpful to establish growth projections for the next 1, =
2 and
>> 3 years.
>>=20
>> Geoff - perhaps you'd be willing to look in your crystal ball, just =
like you
>> seem to enjoy predicting internet-scale FIB sizing? :-)
>>=20
>> NIST, perhaps your team can also produce projections based on the =
RPKI
>> Deployment Monitor data, so that we have two sources to help set =
course?
>>=20
>> The strategy here is to make an inventory of all aspects of the RPKI =
that
>> can 'balloon up', and then impose a limit on those things which =
permit
>> organic growth (in the next 18 months), but not much more than that.
>>=20
>> This working group has the right people to make this approach work.
>>=20
>> Kind regards,
>>=20
>> Job
>>=20
>=20
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Fri Nov 12 13:46:25 2021
Return-Path: <randy@psg.com>
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 5F3093A124B for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 13:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 kos_mYO9WrOU for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 13:46:19 -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 14A353A1248 for <sidrops@ietf.org>; Fri, 12 Nov 2021 13:46:19 -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 <randy@psg.com>) id 1mleND-0008MT-6C for sidrops@ietf.org; Fri, 12 Nov 2021 21:46:15 +0000
Date: Fri, 12 Nov 2021 13:46:14 -0800
Message-ID: <m2lf1tujx5.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/lfYSDnCqEYT_vQ-56q3x48vju9o>
Subject: [Sidrops] draft-ymbk-sidrops-rov-no-rr
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 21:46:23 -0000

the authors recommend

    https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-01.txt

for your reading and amusement, and request wg adoption.

randy


From nobody Fri Nov 12 15:54:41 2021
Return-Path: <randy@psg.com>
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 AF4273A0BB1 for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 15:54:39 -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, 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 6xAXyQtKfy61 for <sidrops@ietfa.amsl.com>; Fri, 12 Nov 2021 15:54:38 -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 8D2CE3A0BAE for <sidrops@ietf.org>; Fri, 12 Nov 2021 15:54:38 -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 <randy@psg.com>) id 1mlgNP-0000AL-Ke for sidrops@ietf.org; Fri, 12 Nov 2021 23:54:35 +0000
Date: Fri, 12 Nov 2021 15:54:34 -0800
Message-ID: <m2ilwxudz9.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <m2lf1tujx5.wl-randy@psg.com>
References: <m2lf1tujx5.wl-randy@psg.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/W_zdg-5xfgERvdU3APMm5vTjvXs>
Subject: Re: [Sidrops] draft-ymbk-sidrops-rov-no-rr
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2021 23:54:40 -0000

fwiw there is discussion among the authors on that last MUST

      If the router has insufficient resources to support this, it
      MUST not be used for Route Origin Validation.

with at least one author thinking it should be a SHOULD.

additionally, we could consider putting one or more of the horror
stories in an appendix or whatever.  but it would not be much fun
if we we polite and anonymized. :)

randy


From nobody Sat Nov 13 05:33:58 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 B5FE93A1586 for <sidrops@ietfa.amsl.com>; Sat, 13 Nov 2021 05:33:56 -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, 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=student.utwente.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 PL9EjVL4J7xN for <sidrops@ietfa.amsl.com>; Sat, 13 Nov 2021 05:33:51 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 509D73A0EB2 for <sidrops@ietf.org>; Sat, 13 Nov 2021 05:33:51 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id m14so49851523edd.0 for <sidrops@ietf.org>; Sat, 13 Nov 2021 05:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=hGt2Nc7ZGWOHjRaAt4dgqL1CebwkinkqN5lz+Gw/jqQ=; b=Rb7ido1NbsQow4UXLJpePOQmtDNJRlhZtgLNApzUlgzvVl/9/4hdC8vVkV6FSNoLuS US/z6Q+Kpgi0a5CCQAWg7ydGUyIZlRQuzWIDbrZn/A9VmrxBveGiVik26mE7D+4wRpuG qNB+hxhK7kv/p88nO62EvwmUfd2BWDgdyTEVxEalspj5lbx/ERw1xec6+PTiDJb8dxvr 3AcFJ5zIpiMBQXEChvCJrUyspNjqFqqwXSeG3y7s61+OEB/x/Bd5+X5mhrUFVxVDoL0Q 8dYQD+e/jlL7ZeZe+phL3C21kdjN8h+XmYqytTIBIOR/49RuLempgD2AfYn4GuGEo4zE 8CPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=hGt2Nc7ZGWOHjRaAt4dgqL1CebwkinkqN5lz+Gw/jqQ=; b=ai+RY24K7er8NjGeSOgNTB+LjPLC/qBNUFPcs92AJ9U33Nrot0zcJyuljGzxzPNKOT 90nuuZ27Gj8Yxgq/rovilojSBecYqYqLuiDszYAun7oVb3SSb0S78T3FGNmEt5gm13fN nfAnmLdmm+eQohDxa7aPrL+YkzqkdAbNBJkpFwsdBwyjF4MnJQ9OwdgLgwV3drgKwM+g eOI/DFQz/POSQRm8FkuC2QEAiwXh3ayk4U7HtLA7TH/DfPGg/kHOWk9uJO272MTSVE5i uSmeLcTNXJKis3v/pVUDqtb5a8pKCddu++kx/Y+b6JWjuzoc06FEXYcn/i8LJeuD3Zf4 Anuw==
X-Gm-Message-State: AOAM532xPeT6QGmxwWHtbXqFgszN648mEDxVoYEzqDSiNKRNE6BinaD4 TvoBwMvXplQwCUMQ4mDZLeiuyt10lsk5k8pUJr6He02QGcCHwtAc+Cj0BJF8dqfXut+EbnTHyDK f8tXo2tm+mT9lUTAHcRClcVYH4O7iPgTk1lmvcE8BlzwXupIq8zsAWpJvvZMLk625NqxR8DhE7M 6U
X-Google-Smtp-Source: ABdhPJymQ3poImYkOC1VXqmU9J/+TaVZE0T2q9C2/BxyCoUEY4v5wSqIuR2B3hHnydLjT7nfO/TRDw==
X-Received: by 2002:a17:907:3f18:: with SMTP id hq24mr29431871ejc.506.1636810424476;  Sat, 13 Nov 2021 05:33:44 -0800 (PST)
Received: from Epsilon (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id g12sm4552410edz.68.2021.11.13.05.33.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Nov 2021 05:33:43 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'Stephen Kent'" <stephen.kent@verizon.net>, <sidrops@ietf.org>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <6b1e4ee2-aa5a-5e65-35c8-95abdb88cc94@verizon.net>
In-Reply-To: <6b1e4ee2-aa5a-5e65-35c8-95abdb88cc94@verizon.net>
Date: Sat, 13 Nov 2021 14:33:42 +0100
Message-ID: <000801d7d893$13c049c0$3b40dd40$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFyWdSzoQig0DwblVC7L9ouDcgmDQEKLrpsAdeWk6WstWJdwA==
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Pwc9EzQvWU8yn25pd7jt_gTTm7s>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Nov 2021 13:33:57 -0000

Steve,

Perhaps my wording was not optimal - let me try to show my point by =
means of example.

Imagine the following structure: A RIR at level 0, my CA directly below =
it at level 1, and my children at level 2. With the current limits I can =
easily create 1000 children with different repositories at level 2, =
thereby exceeding the limit and stopping the further exploring of other =
repositories within this TAL. With the current traversal order, this =
means that if your repository is at level 0 or 1, it will be included. =
If it is at level 2, it may be included, if it is visited before my =
children. If it is at level 3, you can be sure that it will not be =
included, as my children at level 2 already exhausted the repository =
limit.

Currently if you manage a /32 (IPv6), and you host your own repository, =
you have a choice. You can decide to have all ROAs in one large =
repository (at level 1), but you can also delegate parts to other =
organisations who host their own repositories (at level 2+). With these =
limits, that latter option becomes risky, as with an attack as described =
above you risk those delegations to other organisations, as they are at =
the same level as my malicious children. Even worse, if your repository =
is not directly below the RIR, but instead below, e.g., a NIR, then =
hosting your own repository already happens at level 2. This is what I =
meant with "freedom" - the ability to structure your part of the tree in =
a way that suits your organisational needs.

If we decide that every layer below layer 2 may be ignored when an =
attack like this happens, then I do believe we can consider those =
objects to be less "important" (for the lack of a better wording).

Koen van Hove

-----Oorspronkelijk bericht-----
Van: Stephen Kent <stephen.kent@verizon.net>=20
Verzonden: donderdag 11 november 2021 16:28
Aan: sidrops@ietf.org
Onderwerp: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)

Koen,
> This is an interesting approach. To me it feels like there might be an =

> implicit assumption that the deeper down the tree one goes, the less=20
> important the objects become.
"important' is not a meaningful term here. However, it is accurate to =
say that as one descends further down the RPKI tree, the address space =
range available to allocate becomes smaller, relative to the cert path =
in question. That's a security feature.
> This seems to me as limiting the freedom that RPKI provides, which,=20
> especially in the advent of IPv6, is a choice that, I believe, if it=20
> were to be made, should be consciously made with wide consensus,=20
> rather than be the consequence of an implementation.
"freedom" also seems like an odd term here. what do you mean?

Steve




From nobody Sat Nov 13 06:10:07 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 23E273A159E for <sidrops@ietfa.amsl.com>; Sat, 13 Nov 2021 06:10:07 -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, 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=student.utwente.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 GVkBgERS9g5r for <sidrops@ietfa.amsl.com>; Sat, 13 Nov 2021 06:10:01 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 A1F403A15A0 for <sidrops@ietf.org>; Sat, 13 Nov 2021 06:10:01 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id z10so23395132edc.11 for <sidrops@ietf.org>; Sat, 13 Nov 2021 06:10:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=ubOluAQ30Cw5wb9Ev6zw0zJk5JR2+KgbQ2iAxB2VKIw=; b=p7mElaj9NzXNZhLJ+OKZj6BuS09cb2aDhNdRsHenIf9lpsjo4riTSxNL5nYHXn9/GC /MC2dTph3Ci3yhJXtqHJjgiFvaBkHkFhkVUB0gPwIiMPqmWwGjzS/HdkcYHkv3UcOhuM JRe7qZqFlg+wcgg7dlhlpLtazoBQzMAFrjwlWynj5eDRauFIokK5ZQP9zdur8vBkQyLM 0AM/PB7AZcVVTxCJMSdnerGR0jl/L9cD12sZN17yLF+R3hcu9dhVGwOMRYkP3ZqBg0fQ /EeGc9tbAN501EUC8x7pZfGZbhIAH3HOjtxJMoNruSTwFOKbrseUbgmmCV4FzwS5Q9J0 ctXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ubOluAQ30Cw5wb9Ev6zw0zJk5JR2+KgbQ2iAxB2VKIw=; b=Xdc5BXQEf0+yj6smv4W13ByvbGcd8oFHocTG0R0fQ/QrYrf1kDso4qI9VWvA/gqqrx GLnpp0derkcGj3zh201qTONLDozdkbdc+tnKpgdhc3/gVckRmhvaa2FR6fM1C5YlmGp4 ohFpDixFgBexge/NJLq5lWAEc159sCHacftCIkuhasZGi1OhLtlVYavlYZ5lbtxe53VZ rDo1QYepAN0bMuhapjbqZcPJAhkc1B1YVOK6nhmCIAJ9TVACnpTwlZ4a7AGfGpGz/Fo/ k43dbSI3iEO1LRSTtqNAef2Cj3nZnh8A2j4MHuJPDecfkKL2iM5AZGX5bswhR+NiVxcI gFcw==
X-Gm-Message-State: AOAM5316SdvXtqnh3yY+CmLVFVpU14ottsBgh8cI/EfNdbhlZuzMaaaq IbFQo1wqy2ryrUZagb9eUzyxjQ==
X-Google-Smtp-Source: ABdhPJyhULSKZxO851mKAluhjsMHm8P2fftU4/KL5N2W3I9/8uuaCU862QyBT1Tx1RBhVLFdYQirPQ==
X-Received: by 2002:a17:907:72c2:: with SMTP id du2mr30182807ejc.155.1636812598350;  Sat, 13 Nov 2021 06:09:58 -0800 (PST)
Received: from Epsilon (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id a20sm3720824ejd.112.2021.11.13.06.09.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Nov 2021 06:09:57 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'Job Snijders'" <job@fastly.com>, "'Robert Kisteleki'" <robert@ripe.net>
Cc: <sidrops@ietf.org>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel>
In-Reply-To: <YY2kQsJIPw5Q7j3a@snel>
Date: Sat, 13 Nov 2021 15:09:56 +0100
Message-ID: <001501d7d898$23951380$6abf3a80$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG7WjUlhTlYjtt+Vnt4JWaZods+RgIeKrurAcOeePesG2PgIA==
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/lbzTEgY-ShVvTWWCtroTNErO4x0>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Nov 2021 14:10:07 -0000

Dear Job, all,

Before submitting the draft, I consulted several RP software developers
whether they considered it feasible to implement - they do not think it will
be a walk in the park, but do not consider infeasible; I agree that a
standard that cannot be implemented has little use. To show how the
maxDescendants works in practice, as per Ties' suggestion, I created a
little model in Python, which can be found here:
https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19 It creates
DOT graphs for each step, so you can see how an RP could process tree hints
in the case of maxDescendants - other limits can be implemented in similar
fashion. The code can be optimised, but I mainly want to show how the
process could work. I do not see any major problems for RPs to implement it
in a similar fashion.

There are some open questions, mainly: how does a parent inform a child of
what their limits are? And what if those limits change (especially: become
stricter)? How and when do these limits change?

More generally, I want to point out that these are Tree *Hints*, not Tree
Rules. They give hints to operators (both of RP software and of CAs) what
they may reasonably expect, hence the scope states: "Following the
information in the Tree Hint object is RECOMMENDED. However, local policy
may prevail over the data in a Tree Hint object.". In the bandwidth example,
if you are using FORT Validator then any repository that does not manage
200KB/s is already excluded using the default configuration, thus that
requirement is already in place in practice. The same applies to all limits
mentioned in 6.2-6.8. The main difference is that if included in Tree Hints,
both parties know what "safe" values they can use, rather than having to
keep up with all limits individual implementations impose.

Koen van Hove


-----Oorspronkelijk bericht-----
Van: Job Snijders <job@fastly.com> 
Verzonden: vrijdag 12 november 2021 00:16
Aan: Robert Kisteleki <robert@ripe.net>
CC: sidrops@ietf.org
Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key
Infrastructure (RPKI)

Dear all,

I share Robert's perspective: the "Tree Hints" approach is fatally flawed.

Anyone who disagrees: try implementing it in a RP yourself. :-)

Kind regards,

Job

On Wed, Nov 10, 2021 at 11:40:58AM +0100, Robert Kisteleki wrote:
> On 2021-11-09 17:48, Koen van Hove wrote:
> > Recently there have been a couple discussions about limits. I found 
> > two issues regarding limits that may be problematic for the 
> > availability of RPKI, and to kill two birds with one stone, I 
> > propose the "RPKI Tree Hints" draft, which can act as a framework 
> > for future limits in RPKI. Here is a direct link:
> > https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-h
> > ints/
> 
> I'm not a fan of this approach. I believe enforcing such limits in a 
> hierarchical fashion is a ticking time bomb. For example restricting 
> the size of *all descendants* may work well for a while, but at some 
> point in time a (grand)child naturally grows beyond it and will just 
> be automatically rejected because of these restrictions.
> 
> In addition, what should operators *do* in this situation, 
> particularly if the limit was specified some levels above in the 
> hierarchy? Change requires the (manual) cooperation of multiple levels 
> - while the "suffering" repo owner may not even have a direct relation to
the "enforcing" CA.
> 
> Similarly, prescribing minimum bandwidth requirements between 
> essentially random hosts on the network is unlikely to work in practice.
> 
> I believe such limits should be specified / enforced in client 
> software, where the operator has direct control in case something is 
> amiss. And as others mentioned CAs do have the power to deal with 
> deliberately abusive clients anyway.




From nobody Mon Nov 15 00:18:05 2021
Return-Path: <tdekock@ripe.net>
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 6814F3A103A for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 00:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=ripe.net
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 eckobg-bbKwc for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 00:17:59 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 131943A0BEE for <sidrops@ietf.org>; Mon, 15 Nov 2021 00:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=qJZXuXnvKADprjRbHrILdw6e0WSSmdjAtRA12+tPBKo=; b=j5hcz17X2sFr4mrA4KNmT2DS X69M6rTmhQYrKDj7gCpIhaw65o5BONu4ssoTdRnxnpzkLA/5N73GBUn8H3pkXjxvlfYr7wVBPawoz WLZ1RI2IwwAdeNnwD+lUsgBtgCdX9mOHlUwHxTx8ijG9YlcyR4M2W4R0lH9cd9WZdA9/Prj4ljFuw uhnIPyUBCtuK41jfj3wpU0/vnB+Eygd9s+dmeLlQFowE2yk2kzZh7MBGj+PaY8PqPBHeV9u5WP8NJ 3NpUI3i+/9UkUPZx82vFPVGZc+oXwm9/bXHE9dbnk6ijhN//8DyTxXUtqNggoDPNNcfwdlSwnl0O3 3poWCfSSFw==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:40888) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mmXBc-000CRU-4T; Mon, 15 Nov 2021 09:17:56 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mmXBc-0003d1-1L; Mon, 15 Nov 2021 09:17:56 +0100
From: Ties de Kock <tdekock@ripe.net>
Message-Id: <8E4A438D-1041-4002-A922-B17CD32783C4@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BD684E8D-2917-48A6-A3B4-89F0FC6B4C12"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 15 Nov 2021 09:17:55 +0100
In-Reply-To: <YY4sGOlIXW9ax7g/@diehard.n-r-g.com>
Cc: Koen van Hove <k.w.vanhove@student.utwente.nl>, SIDR Operations WG <sidrops@ietf.org>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch> <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net> <YY4sGOlIXW9ax7g/@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e14d8a5013d4b1fde0704c60b497c177d0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xTaSBIhLWrpbzoPq8mcDn_yNGhc>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 08:18:05 -0000

--Apple-Mail=_BD684E8D-2917-48A6-A3B4-89F0FC6B4C12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Claudio,

> On 12 Nov 2021, at 09:55, Claudio Jeker <cjeker@diehard.n-r-g.com> =
wrote:
>=20
> On Fri, Nov 12, 2021 at 08:52:03AM +0100, Ties de Kock wrote:
>>=20
>>=20
>>> On 11 Nov 2021, at 17:57, Jeroen Massar =
<jeroen=3D40massar.ch@dmarc.ietf.org> wrote:
>>>=20
>>>=20
>>>> On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
>>>>=20
>>>> This is an interesting approach. To me it feels like there might be =
an
>>>> implicit assumption that the deeper down the tree one goes, the =
less
>>>> important the objects become.
>>>=20
>>> The tree will never really be that deep anyway.
>>>=20
>>> If you take IPv6:
>>>=20
>>> IANA -> RIR -> LIR -> End-User
>>>=20
>>> Thus even if there is "PI" involved, much more, even more than =
double, will unlikely happen, especially as we are talking about routes =
in the DFZ.
>>=20
>> The tree gets deeper in practice because there are internal levels of =
CAs at
>> RIRs (and other locations).
>>=20
>> For example, for the RIPE NCC tal:
>>  1: RIR 'tal' 0/0 offline certificate
>> 	2: 0/0 online certificate
>> 	3: CA containing members
>> 	4: Member CA.
>=20
> These extra CAs are just adding a constant offset to the depth of the
> tree. They do not really matter.
>=20
>> I see multiple reasons for this number of levels to increase. If an =
RIR were to
>> add the possibility for a member to have both a hosted + delegated =
CA, this would
>> likely add a level (or potentially hit the object size limit with =
it's manifest
>> during a key-roll). There are also reasons to structure the "CA =
containing
>> members"  as multiple CAs. For easier processing and updating (less =
objects),
>> or because the CA is structured based on where the resources =
originated.
>=20
> Even with this you would end up with 2 CAs per delegation.
> So the math is something like 3 + 2*delegations. For rpki-client the =
max
> depth is 12. Which in turn would be 4-5 additional member delegations. =
This
> should be plenty to do NIR, LIR, PI delegation. Especially since using =
2 CAs
> per delegation is not the common case.
>=20
>> But the critical realisation is that in the tree, for RIRs with NIRs, =
NIRs
>> "look like" yet another CA under the "CA containing members". If you =
perform a
>> breadth-first traversal, an abusive CA that is a direct member is as =
important
>> as a CA under an NIR.
>>=20
>> If the order is unlucky (how is the order determined? alphabetical by =
filename?),
>> the abuser can prevent the NIR from being processed.
>=20
> The order does not matter in a breadth first scheme all resources of =
level
> n+1 are downloaded before resources of level n+2.
> So the bad CA will not stop the NIR from loading.
> The only problem is that because of parallel processing the bad CA may =
run
> ahead of slow CAs and hit the limit before the other CAs finished. =
That is
> not good but it only stops the sync of repositories.
> So even then, all ROAs directly referenced from those NIR will be =
validated
> and added to the VRP tree. The external CAs form that tree may not =
have
> been able to sync but the system will fallback to its cached data and
> validate with that. So in the end most ROAs will be added to the VRP =
tree.
> So no, the abuser can not prevent the NIR from being processed.
> Also since this is a limit per TAL all other TALs are not affected.

I think we meant the same thing: Dependant on the order of exploration, =
a
malicious repository at the level _above_ the NIR can prevent delegated
repositories _below_ the NIR from being explored.

Is the approach taken by rpki-client documented somewhere? Details =
matter here.
For example, I assume we are talking about _repositories_ here (c.f. =
CAs) when
talking about fetching. But about CAs when discussing depths. And that =
repositories
are not sorted by in-degree. When that is clear we can discuss scenarios =
better.

Note that I would assume and recommend that a RIR or NIR uses use =
(multiple)
_different_ repositories for the children to publish in for =
security/engineering
reasons (but I would not discuss those details on-list at the moment).

>=20
>>>> This seems to me as limiting the freedom that
>>>=20
>>> Please note that these limits have to be added because of your =
disclosure...
>>=20
>> These limits have been added as a stopgap to fix vulnerabilities. I =
would
>> welcome work from a researcher. Irregardless of you how you look at =
the handling
>> of the CVD by the party running it (NCSC) - this is better than =
finding about
>> these issues at Monday morning 3AM.
>=20
> It was Wednesday 3AM for some people when the CVD was released so how
> does that change anything? You run important infrastructure you better
> monitor it and keep it up to date.

Better to wake up to patch then when a vulnerability is being abused!

RPs being less tolerant to untrusted data/oddly behaving/"test" =
repositories is
a good thing overall. Many of the false positive alerts that I have seen =
are due
to repositories not being fetched. This was why I added a wrapper for =
rsync
(calculate time left, run timeout -k [time_left] rsync)  with a =
"deadline" for
rsync to finish by in my rpki-client wrapper.

In this distributed system one person's test to see how many RPs fetch =
over IPv6
only may be another person's 24x7 alert.

Kind regards,
Ties
>=20
> The problem here is that RP software needs to download untrusted data =
to
> do its work. This is an inherent design issue of RPKI and it opens a =
large
> attack surface to all of RPKI.
>=20
> --=20
> :wq Claudio


--Apple-Mail=_BD684E8D-2917-48A6-A3B4-89F0FC6B4C12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Claudio,<br class=3D""><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On 12 Nov 2021, at 09:55, Claudio Jeker =
&lt;<a href=3D"mailto:cjeker@diehard.n-r-g.com" =
class=3D"">cjeker@diehard.n-r-g.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
charset=3D"UTF-8" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">On Fri, Nov 12, 2021 at 08:52:03AM +0100, Ties de Kock =
wrote:</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">On 11 Nov =
2021, at 17:57, Jeroen Massar &lt;<a =
href=3D"mailto:jeroen=3D40massar.ch@dmarc.ietf.org" =
class=3D"">jeroen=3D40massar.ch@dmarc.ietf.org</a>&gt; wrote:<br =
class=3D""><br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">On 20211111, at 16:09, <a =
href=3D"mailto:k.w.vanhove@student.utwente.nl" =
class=3D"">k.w.vanhove@student.utwente.nl</a> wrote:<br class=3D""><br =
class=3D"">This is an interesting approach. To me it feels like there =
might be an<br class=3D"">implicit assumption that the deeper down the =
tree one goes, the less<br class=3D"">important the objects become.<br =
class=3D""></blockquote><br class=3D"">The tree will never really be =
that deep anyway.<br class=3D""><br class=3D"">If you take IPv6:<br =
class=3D""><br class=3D"">IANA -&gt; RIR -&gt; LIR -&gt; End-User<br =
class=3D""><br class=3D"">Thus even if there is "PI" involved, much =
more, even more than double, will unlikely happen, especially as we are =
talking about routes in the DFZ.<br class=3D""></blockquote><br =
class=3D"">The tree gets deeper in practice because there are internal =
levels of CAs at<br class=3D"">RIRs (and other locations).<br =
class=3D""><br class=3D"">For example, for the RIPE NCC tal:<br =
class=3D"">&nbsp;1: RIR 'tal' 0/0 offline certificate<br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>2: 0/0 =
online certificate<br class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>3: CA containing members<br =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>4: Member CA.<br class=3D""></blockquote><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">These extra CAs are just adding a constant offset to the =
depth of the</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">tree. They do =
not really matter.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><blockquote type=3D"cite" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D"">I see multiple reasons for this =
number of levels to increase. If an RIR were to<br class=3D"">add the =
possibility for a member to have both a hosted + delegated CA, this =
would<br class=3D"">likely add a level (or potentially hit the object =
size limit with it's manifest<br class=3D"">during a key-roll). There =
are also reasons to structure the "CA containing<br class=3D"">members" =
&nbsp;as multiple CAs. For easier processing and updating (less =
objects),<br class=3D"">or because the CA is structured based on where =
the resources originated.<br class=3D""></blockquote><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">Even with this you would end up =
with 2 CAs per delegation.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">So the math is something like 3 + 2*delegations. For =
rpki-client the max</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">depth is 12. Which in turn would be 4-5 additional member =
delegations. This</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">should be plenty to do NIR, LIR, PI delegation. Especially =
since using 2 CAs</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">per delegation is not the common case.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">But =
the critical realisation is that in the tree, for RIRs with NIRs, =
NIRs<br class=3D"">"look like" yet another CA under the "CA containing =
members". If you perform a<br class=3D"">breadth-first traversal, an =
abusive CA that is a direct member is as important<br class=3D"">as a CA =
under an NIR.<br class=3D""><br class=3D"">If the order is unlucky (how =
is the order determined? alphabetical by filename?),<br class=3D"">the =
abuser can prevent the NIR from being processed.<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">The order does not matter in a breadth first scheme all =
resources of level</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">n+1 are downloaded before resources of level n+2.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">So the bad CA will not stop the =
NIR from loading.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">The only problem is that because of parallel processing the =
bad CA may run</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">ahead of slow CAs and hit the limit before the other CAs =
finished. That is</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">not good but it only stops the sync of =
repositories.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">So even then, =
all ROAs directly referenced from those NIR will be validated</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">and added to the VRP tree. The =
external CAs form that tree may not have</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">been able to sync but the system will fallback to its cached =
data and</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">validate with =
that. So in the end most ROAs will be added to the VRP tree.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">So no, the abuser can not =
prevent the NIR from being processed.</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Also since this is a limit per TAL all other TALs are not =
affected.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""></div></blockquote><div><br class=3D""></div><div>I =
think we meant the same thing: Dependant on the order of exploration, =
a</div><div>malicious repository at the level _above_ the NIR can =
prevent delegated</div><div>repositories _below_ the NIR from being =
explored.</div><div><br class=3D""></div><div>Is the approach taken by =
rpki-client documented somewhere? Details matter here.</div><div>For =
example, I assume we are talking about _repositories_ here (c.f. CAs) =
when</div><div>talking about fetching. But about CAs when discussing =
depths. And that repositories</div><div>are not sorted by in-degree. =
When that is clear we can discuss scenarios better.</div><div><br =
class=3D""></div><div>Note that I would assume and recommend that a RIR =
or NIR uses use (multiple)</div><div>_different_ repositories for the =
children to publish in for security/engineering</div><div>reasons (but I =
would not discuss those details on-list at the moment).</div><div =
class=3D""><br class=3D""></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">This seems to me as limiting the freedom that<br =
class=3D""></blockquote><br class=3D"">Please note that these limits =
have to be added because of your disclosure...<br =
class=3D""></blockquote><br class=3D"">These limits have been added as a =
stopgap to fix vulnerabilities. I would<br class=3D"">welcome work from =
a researcher. Irregardless of you how you look at the handling<br =
class=3D"">of the CVD by the party running it (NCSC) - this is better =
than finding about<br class=3D"">these issues at Monday morning 3AM.<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">It was Wednesday 3AM for some people when the CVD was =
released so how</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">does that change anything? You run important infrastructure =
you better</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">monitor it =
and keep it up to date.</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div><div>Better to wake up to patch then when a =
vulnerability is being abused!</div><div><br class=3D""></div><div>RPs =
being less tolerant to untrusted data/oddly behaving/"test" repositories =
is</div><div>a good thing overall. Many of the false positive alerts =
that I have seen are due</div><div>to repositories not being fetched. =
This was why I added a wrapper for rsync</div><div>(calculate time left, =
run timeout -k [time_left] rsync) &nbsp;with a "deadline" =
for</div><div>rsync to finish by in my rpki-client =
wrapper.</div><div><br class=3D""></div><div>In this distributed system =
one person's test to see how many RPs fetch over IPv6</div><div>only may =
be another person's 24x7 alert.</div></div><div class=3D""><br =
class=3D""></div><div class=3D"">Kind regards,</div><div =
class=3D"">Ties</div><blockquote type=3D"cite" class=3D""><div =
class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">The problem =
here is that RP software needs to download untrusted data to</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">do its work. This is an inherent =
design issue of RPKI and it opens a large</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">attack surface to all of RPKI.</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">--<span class=3D"Apple-converted-space">&nbsp;</span></span><br=
 style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">:wq =
Claudio</span></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_BD684E8D-2917-48A6-A3B4-89F0FC6B4C12--


From nobody Mon Nov 15 02:48:04 2021
Return-Path: <job@fastly.com>
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 97C353A094B for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 02:48:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 8Xnc3UU7GsXK for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 02:47:58 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 196F53A0944 for <sidrops@ietf.org>; Mon, 15 Nov 2021 02:47:58 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id e3so33423082edu.4 for <sidrops@ietf.org>; Mon, 15 Nov 2021 02:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1jJAr7I5+lfgkoiAalHeDjJV9M8tnEVqyTK0C9ZA8pA=; b=xkrsR8fEgIMVD8JNcpp2Bm2EilbpMs3zKJ/9z5OxXU163MKwsWMHxTmgvrVHD8Fa7t iYnIlasCRr/wyQJ54zaz2Qdmpn4Yf4qVLY3mFEPlGa/gaBtO8ygu901yaBrFRCUpQwRt yvZ0Bs8NNcKIQc0wteYinCU/nojb8ltkN84QQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1jJAr7I5+lfgkoiAalHeDjJV9M8tnEVqyTK0C9ZA8pA=; b=zfNsqKiIXODvTLZ+MyyxTrD7hqCR/hjMLOEEC4g2w4XIt3EUNILAAhhLOXzKiyIDoU +CPV/F9k6k5cX+VKb5E6ZZkZodX7xaAYlX1qXRf11mifVgiWxRtB36H7WsM70loHBTBw BYEa/QhWJ5+BJ8eddRBp3PVtAjqm37DHu4JiI9wo4E92UPalpPFRJs7YhiI6IoBURTkO 1O6rkMuzzfNfLl2/WW9qRpopqe/rtzWKb8r2TXhioEgiCx88KbYDIqoIhVrt6RJmmXZy nTzIFMKTt2UA50SmXzjttxo4tpKZcG4Kg7lGp9rLDJ2LqPUaFCX2eKLT1DIMEFCvH5wO Vusg==
X-Gm-Message-State: AOAM532a/54HtolP44o6sPkfCrqxGKLQnsHy2/hjZVXWP0Shtbm49387 qmz9yjX7ealMlTioq71boixOMjjwfUczFw==
X-Google-Smtp-Source: ABdhPJwMY29YEAAu4Q/u0AEksIp8/yuoBhYL6nYGwwsKpYs9e/Etp982wVm+an+JukSAEsIH5zJTBA==
X-Received: by 2002:a17:907:3e22:: with SMTP id hp34mr24295253ejc.491.1636973275686;  Mon, 15 Nov 2021 02:47:55 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id yd13sm713988ejb.39.2021.11.15.02.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 02:47:55 -0800 (PST)
Date: Mon, 15 Nov 2021 11:47:53 +0100
From: Job Snijders <job@fastly.com>
To: Randy Bush <randy@psg.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <YZI62d92d3pMDHE1@snel>
References: <m2lf1tujx5.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2lf1tujx5.wl-randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/zDZfZEjmNIdmcgeo-JGewIFFldk>
Subject: Re: [Sidrops] draft-ymbk-sidrops-rov-no-rr
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 10:48:03 -0000

On Fri, Nov 12, 2021 at 01:46:14PM -0800, Randy Bush wrote:
> the authors recommend
> 
>     https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-01.txt
> 
> for your reading and amusement, and request wg adoption.

I support WG adoption.

I too observe how some BGP implementations impose a CONSIDERABLE TOLL on
their EBGP peers, even though they have ample memory to avoid sending
ROUTE REFRESH messages following every change in the RPKI.

Imagine the protocol chatter noise between two EBGP peers if RPs
refreshed as frequently as every single minute ;-)

Kind regards,

Job


From nobody Mon Nov 15 04:10:27 2021
Return-Path: <cjeker@diehard.n-r-g.com>
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 911863A0A55 for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 04:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 YYXkPgcG0U6k for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 04:10:20 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A62E3A0A4A for <sidrops@ietf.org>; Mon, 15 Nov 2021 04:10:19 -0800 (PST)
Received: (qmail 19189 invoked by uid 1000); 15 Nov 2021 12:10:11 -0000
Date: Mon, 15 Nov 2021 13:10:11 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Ties de Kock <tdekock@ripe.net>
Cc: SIDR Operations WG <sidrops@ietf.org>
Message-ID: <YZJOI16JCCFtzn/H@diehard.n-r-g.com>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch> <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net> <YY4sGOlIXW9ax7g/@diehard.n-r-g.com> <8E4A438D-1041-4002-A922-B17CD32783C4@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8E4A438D-1041-4002-A922-B17CD32783C4@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/U6OJkp8jGtzi3qqf5WvWlqIaHzM>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 12:10:26 -0000

On Mon, Nov 15, 2021 at 09:17:55AM +0100, Ties de Kock wrote:
> Hi Claudio,
> 
> > On 12 Nov 2021, at 09:55, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> > 
> > On Fri, Nov 12, 2021 at 08:52:03AM +0100, Ties de Kock wrote:
> >> 
> >> 
> >>> On 11 Nov 2021, at 17:57, Jeroen Massar <jeroen=40massar.ch@dmarc.ietf.org> wrote:
> >>> 
> >>> 
> >>>> On 20211111, at 16:09, k.w.vanhove@student.utwente.nl wrote:
> >>>> 
> >>>> This is an interesting approach. To me it feels like there might be an
> >>>> implicit assumption that the deeper down the tree one goes, the less
> >>>> important the objects become.
> >>> 
> >>> The tree will never really be that deep anyway.
> >>> 
> >>> If you take IPv6:
> >>> 
> >>> IANA -> RIR -> LIR -> End-User
> >>> 
> >>> Thus even if there is "PI" involved, much more, even more than double, will unlikely happen, especially as we are talking about routes in the DFZ.
> >> 
> >> The tree gets deeper in practice because there are internal levels of CAs at
> >> RIRs (and other locations).
> >> 
> >> For example, for the RIPE NCC tal:
> >>  1: RIR 'tal' 0/0 offline certificate
> >> 	2: 0/0 online certificate
> >> 	3: CA containing members
> >> 	4: Member CA.
> > 
> > These extra CAs are just adding a constant offset to the depth of the
> > tree. They do not really matter.
> > 
> >> I see multiple reasons for this number of levels to increase. If an RIR were to
> >> add the possibility for a member to have both a hosted + delegated CA, this would
> >> likely add a level (or potentially hit the object size limit with it's manifest
> >> during a key-roll). There are also reasons to structure the "CA containing
> >> members"  as multiple CAs. For easier processing and updating (less objects),
> >> or because the CA is structured based on where the resources originated.
> > 
> > Even with this you would end up with 2 CAs per delegation.
> > So the math is something like 3 + 2*delegations. For rpki-client the max
> > depth is 12. Which in turn would be 4-5 additional member delegations. This
> > should be plenty to do NIR, LIR, PI delegation. Especially since using 2 CAs
> > per delegation is not the common case.
> > 
> >> But the critical realisation is that in the tree, for RIRs with NIRs, NIRs
> >> "look like" yet another CA under the "CA containing members". If you perform a
> >> breadth-first traversal, an abusive CA that is a direct member is as important
> >> as a CA under an NIR.
> >> 
> >> If the order is unlucky (how is the order determined? alphabetical by filename?),
> >> the abuser can prevent the NIR from being processed.
> > 
> > The order does not matter in a breadth first scheme all resources of level
> > n+1 are downloaded before resources of level n+2.
> > So the bad CA will not stop the NIR from loading.
> > The only problem is that because of parallel processing the bad CA may run
> > ahead of slow CAs and hit the limit before the other CAs finished. That is
> > not good but it only stops the sync of repositories.
> > So even then, all ROAs directly referenced from those NIR will be validated
> > and added to the VRP tree. The external CAs form that tree may not have
> > been able to sync but the system will fallback to its cached data and
> > validate with that. So in the end most ROAs will be added to the VRP tree.
> > So no, the abuser can not prevent the NIR from being processed.
> > Also since this is a limit per TAL all other TALs are not affected.
> 
> I think we meant the same thing: Dependant on the order of exploration, a
> malicious repository at the level _above_ the NIR can prevent delegated
> repositories _below_ the NIR from being explored.

In my understanding above the NIR is the RIR and with that the holder of
the TAL. If we can't trust the RIR then that TAL should be removed from
the set of TRUST anchors.

If the bad repo is on the same level as the NIR, the NIR will sync without
issues. They are on the same level. Repositories hanging of that NIR may
get more into trouble. One way to solve this if for the two RIR that
actually use NIR repositories to put direct 3rd party repos on an extra
repositoriy. Again, the assumption being that on can trust the RIR and NIR
repos.
 
> Is the approach taken by rpki-client documented somewhere? Details matter here.
> For example, I assume we are talking about _repositories_ here (c.f. CAs) when
> talking about fetching. But about CAs when discussing depths. And that repositories
> are not sorted by in-degree. When that is clear we can discuss scenarios better.

Because of the way RPKI works in real live there are two different trees to
consider. The obvious one is what you get following the certificates. This
is the CA depth.

The more complicated on is the hierarchy of repositories. Many
certificates share the same base repository and are synced all together.
Whenever a new repository is detected during tree traversal a new sync
operation starts. Right now thanks to breadth first traversal all
repositories on the same level will be fetched before any repository on
level n+1 is fetched. What we did not implement is a barrier that forbids
repositories of leveln n+2 or higher to be fetched before n+1 is finished.
For now we don't think this is needed. Especially if the RP falls back to
cached data most of the data will be validated just fine. Since the
repositories were synced on the previous run (which was hopefully not too
long ago).

We did not fully document our approach because we will refine it further
in the near future.
 
> Note that I would assume and recommend that a RIR or NIR uses use (multiple)
> _different_ repositories for the children to publish in for security/engineering
> reasons (but I would not discuss those details on-list at the moment).

I would generally agree but different repositories also come at a cost.
More servers to contact, more failures that can happen. On the other hand
failures affect smaller bits of the tree. A good balance needs to be
found.
 
-- 
:wq Claudio


From nobody Mon Nov 15 06:15:17 2021
Return-Path: <randy@psg.com>
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 9D2923A0C86 for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 06:15:15 -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, 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 t0SxN1iqTZIX for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 06:15:13 -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 41CAE3A0C80 for <sidrops@ietf.org>; Mon, 15 Nov 2021 06:15:13 -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 <randy@psg.com>) id 1mmclL-0007ZG-AF for sidrops@ietf.org; Mon, 15 Nov 2021 14:15:11 +0000
Date: Mon, 15 Nov 2021 06:15:10 -0800
Message-ID: <m2czn1tsi9.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <8E4A438D-1041-4002-A922-B17CD32783C4@ripe.net>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <C8046962-8E8F-44FA-A2E6-8399F2136ADA@massar.ch> <0890071E-EF03-4EB6-B400-9A5F0493599D@ripe.net> <YY4sGOlIXW9ax7g/@diehard.n-r-g.com> <8E4A438D-1041-4002-A922-B17CD32783C4@ripe.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/a7DLa_T6Ltb8kp-QvglA-PtBi04>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 14:15:16 -0000

this discussion reminds me of an incident from my compiler years.

in '80 or so, someone on the arpa complers list asked if they should
limit variable identifiers to 8 or 12 characters.  david moon (lisp,
emacs, ...) replied along the lines that there was clearly a bug in the
su-ai mail system, as messages from the '60s were being regenerated but
with current dates.

randy


From nobody Mon Nov 15 06:22:20 2021
Return-Path: <randy@psg.com>
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 5DA843A0C9C for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 06:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, 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 o6SLqTA9b7Z4 for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 06:22:14 -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 59EFC3A0C99 for <sidrops@ietf.org>; Mon, 15 Nov 2021 06:22:14 -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 <randy@psg.com>) id 1mmcs7-0007bR-P1 for sidrops@ietf.org; Mon, 15 Nov 2021 14:22:11 +0000
Resent-Message-Id: <E1mmcs7-0007bR-P1@ran.psg.com>
Resent-From: Randy Bush <randy@psg.com>
Resent-Date: Mon, 15 Nov 2021 06:22:11 -0800
Resent-To: sidrops@ietf.org
Received: from psg.com ([2001:418:1::62]) by ran.psg.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <internet-drafts@ietf.org>) id 1mmcq8-0007aX-2I for randy@ran.psg.com; Mon, 15 Nov 2021 14:20:08 +0000
Received: from [4.31.198.44] (helo=mail.ietf.org) by psg.com with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from <internet-drafts@ietf.org>) id 1mmcq7-0005hq-DE for randy@psg.com; Mon, 15 Nov 2021 14:20:07 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 103B43A0D0B; Mon, 15 Nov 2021 06:19:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: "Keyur Patel" <keyur@arrcus.com>, "Mark Tinka" <mark@tinka.africa>, "Philip Smith" <pfsinoz@gmail.com>, "Randy Bush" <randy@psg.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163698598804.11555.15212500653590059045@ietfa.amsl.com>
Date: Mon, 15 Nov 2021 06:19:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1mHFNXC9MzZ1fepa1eYwl-2tlec>
Subject: [Sidrops] New Version Notification for draft-ymbk-sidrops-rov-no-rr-02.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 14:22:19 -0000

A new version of I-D, draft-ymbk-sidrops-rov-no-rr-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-sidrops-rov-no-rr
Revision:	02
Title:		RPKI-Based Policy Without Route Refresh
Document date:	2021-11-15
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/archive/id/draft-ymbk-sidrops-rov-no-rr-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-sidrops-rov-no-rr/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-rov-no-rr-02

Abstract:
   A BGP Speaker performing RPKI-based policy should not issue Route
   Refresh to its neighbors when receiving new RPKI data.  A method for
   avoiding doing so is described.


                                                                                  


The IETF Secretariat



From nobody Mon Nov 15 07:39:14 2021
Return-Path: <job@fastly.com>
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 9BACA3A0D6F for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 07:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 MOM5xbBNpqJO for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 07:39:08 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C4C463A0D6D for <sidrops@ietf.org>; Mon, 15 Nov 2021 07:39:07 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id z10so47331018edc.11 for <sidrops@ietf.org>; Mon, 15 Nov 2021 07:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UPmZGCS9aNErhFs48FY76FxZNrB+VW8zMecsCuLOLAg=; b=cU00UtBEid8GZ4lu6ePZe2bKabPokcvxHxbeDWhlxQnOIKwPPNSOOj1kJ8S/QMaqbj a/i5tjVtAYWgSXW1a6d4nGixgJMKyfmDWmgT3QbBxf1cnYy5K48H5VEA33xjnhYYiQLr C1pwS2ylfKupBlOQqBZkjXfW9z4heRu/P5mHQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UPmZGCS9aNErhFs48FY76FxZNrB+VW8zMecsCuLOLAg=; b=PH3RNNdXqcLKZmiyhHLXZDJ1LhCL02REpY9CDKab1ve2vNBw0UO5cNcN3zNBBJTBdm gf1rhTPgbdxwH2GZYgqNylHPe5xy9RZzQrV/ntE/Ny/2Jj+5bFL0xvIm2zwwvADzBmCQ bSiOHJLKop7/opxEM5bVAOM5eurdXkrRQUfUJqm2TbU98e8aPMbfLWlY1uol7Vmjlpj2 K5H++zjab2shXm3OaPYowx4Q8D+NLG4U6hs7kiZz8gQx53UfdULW5KTU5yezqUNi6VJK 6QHV57dLWPU08eQTGfUN+oX+sGxpGIM8pu94l9GKBBPHPzp1C+auVf209GIvqj3AbakH DCFg==
X-Gm-Message-State: AOAM533yY4P9yF1L0O2brXOyEKX0hmiO2OXHdUhaQ3yT4CAbadYv0x8q iM5YvFE7I6+krw1qd7OtlmkivY8D75s4N4E98WP9sfAOPvm6jp/SFxvfx5SQnsj3+WTbj0zvYTE Qkt8nAEC3rq1vUm8EpXn0J6BKbr5P+Gemj20CDXhBtdsnCBe7FucvhV0=
X-Google-Smtp-Source: ABdhPJzs/c4vEyOTlcVfLiqMvzE0Sw01cyGwkCwt6oQsWcZeuLUTINeh0uWjWWHkBqkJ5E04l5I3Hw==
X-Received: by 2002:a17:906:f44:: with SMTP id h4mr45765785ejj.113.1636990741656;  Mon, 15 Nov 2021 07:39:01 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id h10sm7832612edb.59.2021.11.15.07.39.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 07:39:01 -0800 (PST)
Date: Mon, 15 Nov 2021 16:38:59 +0100
From: 'Job Snijders' <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YZJ/E/zFNEgNtk32@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001501d7d898$23951380$6abf3a80$@student.utwente.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2uvH4itUKwVMIZzp52MdjUCTO70>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 15:39:13 -0000

On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
> Before submitting the draft, I consulted several RP software
> developers whether they considered it feasible to implement

I question the soundness of your consultation, knowing that "Several RP
software developers" also failed to understand the purpose of RPKI
manifests [1], needed a year and lots of hand-holding to recognize the
true situation ([2] -> [3]); or happily violated CA intent by ignoring
missing CRLs and CRL staleness [4], [5]; or failed to see an issue with
certificate malleability [6], [7], [8].

How can this be explained? Groupthink is a psychological phenomenon that
can occur within groups of people in which the desire for conformity
results in an irrational or dysfunctional decision-making outcome. Or
perhaps it is lack of ever experiencing consequences, who knows! :-)

For everyone's amusement: https://sobornost.net/~job/should_vs_must.jpg

> To show how the maxDescendants works in practice, as per Ties'
> suggestion, I created a little model in Python, which can be found
> here: https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
> It creates DOT graphs for each step, so you can see how an RP could
> process tree hints in the case of maxDescendants - other limits can be
> implemented in similar fashion. 

It seems you implemented something that takes a Python dictionary and
outputs a DOT graph. This is not the same as ingesting potentially
hostile data from an untrusted network input, parsing the data according
to the X.509 and RPKI specifications, building validation paths, and
generating a set of validated ROA payloads.

It also should be recognize that "maxDescendants set to zero" is the
same as "pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
This begs the question, why is pathLenConstraint not used in the RPKI?
Was it an oversight? Or was it recognized that pathLenConstraint is not
a security feature, but rather a "product differentiator"? I consider
maxDescendants to be in the latter category.

> There are some open questions, mainly: how does a parent inform a
> child of what their limits are? And what if those limits change
> (especially: become stricter)? How and when do these limits change?

Great questions indeed. Perhaps the parent can inform the child by
sending an invoice, and only adjust limits after having received payment?

> More generally, I want to point out that these are Tree *Hints*, not
> Tree Rules.

Interesting how a set of 'hints' can be an effective mitigation against
Issue H, J, and K. It was my understanding that you propose - only when
these hints are applied as if they are rules - safety can be achieved.
But you now appear water down the applicability? Which is it?

More importantly: already two different RP implementers recognized that
"each RP implementation *will* have to apply limits" [9]. Unfortunately
only one implementer took action so far. The problems you documented
have to be solved irregardless of the existence of "Tree Hints", because
an RP can't rely on Tree Hints being reasonable, or even existing.

My suggestion would be everyone gets a move on and focuses on
immediately resolving their issues, because at present H, J & K are not
mitigated in multiple implemenations. Hint: accepting chains up to 32
long is ludicrous. After having implemented sane limits, implementers
are likely to come to understand there is no need for "Tree Hints". 

> In the bandwidth example, if you are using FORT Validator then any
> repository that does not manage 200KB/s is already excluded using the
> default configuration, thus that requirement is already in place in
> practice. The same applies to all limits mentioned in 6.2-6.8. The
> main difference is that if included in Tree Hints, both parties know
> what "safe" values they can use, rather than having to keep up with
> all limits individual implementations impose.

You correctly place "safe" between quotation marks. Merely labeling
something "safe" does not intrincically make it "safe". Fun to read that
FORT now doubles as a general purpose network speedtest. However, from
there it doesn't follow that "the requirement is already in place in
practise".

I remain skeptical about your proposal, as I find its merit lacking.

Kind regards,

Job

[1]: https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents/
[2]: https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
[3]: https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
[4]: https://github.com/NLnetLabs/routinator/issues/274
[5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
[6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
[7]: https://github.com/NLnetLabs/routinator/issues/365
[8]: https://github.com/cloudflare/cfrpki/issues/66
[9]: https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScAvjQ/


From nobody Mon Nov 15 18:11:19 2021
Return-Path: <morrowc@ops-netman.net>
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 DEE973A02D0 for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 18:11:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-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 TADzfQtsGCCI for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 18:11:15 -0800 (PST)
Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF3A3A02BB for <sidrops@ietf.org>; Mon, 15 Nov 2021 18:11:14 -0800 (PST)
Received: from mail.ops-netman.net (mail.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 5BB5F3C1EC6 for <sidrops@ietf.org>; Tue, 16 Nov 2021 02:11:13 +0000 (UTC)
Received: from mailserver.ops-netman.net.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 28296245 for <sidrops@ietf.org>; Tue, 16 Nov 2021 02:11:13 +0000 (UTC)
Date: Tue, 16 Nov 2021 02:11:12 +0000
Message-ID: <87k0h8svcv.wl-morrowc@ops-netman.net>
From: Chris Morrow <morrowc@ops-netman.net>
To: sidrops@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
Organization: Operations Network Management, Ltd.
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-2022-JP
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/_cycL90_8RyCyqJdbnWPF-kD_WQ>
Subject: [Sidrops] Draft Statuses from the F2F meeting slides
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 02:11:18 -0000

Standards Track:

signed-tal-07 - Seems to have gotten stuck

rpki-rsc-04 - Implementation Report pending - job

has-no-identity-02 - ready for WGLC - will issue post meeting

prefer-rrdp - v2.0 published - pending WG review

6486-bis - Off to IESG

Aspa-verification-08 - revision received - ready to move forward?

Standards Track: (cont$B!D(B)

aspa-profile-06 - Pending Editor Information

8210-bis - Time for WGLC?


Informational Track:

rpki-rov-timing - WGLC Pending

roa-considerations-01 - received / discussion pending

lta-use-cases - IESG Review - pending DISCUSS work

Best Current Practices:

rpkimaxen-06 - WGLC pending decsion


Experimental:

rpki-rta-00 - Hold, pending author/editor information


From nobody Mon Nov 15 19:26:02 2021
Return-Path: <randy@psg.com>
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 A4E6D3A05DF for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 19:26:00 -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, 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 hEAyV4BzHSrn for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 19:25:59 -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 86F6B3A03EB for <sidrops@ietf.org>; Mon, 15 Nov 2021 19:25:59 -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 <randy@psg.com>) id 1mmp6a-00019V-Dt; Tue, 16 Nov 2021 03:25:56 +0000
Date: Mon, 15 Nov 2021 19:25:55 -0800
Message-ID: <m2wnl8rdbw.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Chris Morrow <morrowc@ops-netman.net>
Cc: sidrops@ietf.org
In-Reply-To: <87k0h8svcv.wl-morrowc@ops-netman.net>
References: <87k0h8svcv.wl-morrowc@ops-netman.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/n9EUMiDJKlCqUB2inRLDA_iQ76A>
Subject: Re: [Sidrops] Draft Statuses from the F2F meeting slides
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 03:26:01 -0000

> has-no-identity-02 - ready for WGLC - will issue post meeting

thanks

> 8210-bis - Time for WGLC?

oh alexander?

and now draft-ymbk-sidrops-rov-no-rr waiting for adoption call

thanks

randy


From nobody Mon Nov 15 23:19:43 2021
Return-Path: <tdekock@ripe.net>
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 1548E3A0990 for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 23:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=ripe.net
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 RKXuTkXdsDgi for <sidrops@ietfa.amsl.com>; Mon, 15 Nov 2021 23:19:37 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 00E3C3A0991 for <sidrops@ietf.org>; Mon, 15 Nov 2021 23:19:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=HykinIRTJ1o+1Z8fFgdp9uY+JbwbZGH01RXI1Dq6QnM=; b=gNBXkiUZ35aW8G2QH3kvPt49 uDBFDb+zzujrSda5RRP4T+5sfBuYT+QZrD0daed8MJ1bWEwiPgTTesUWYZpfN9rb/18Cw3oprLYEU 0PBhS0Mzh0DPval9p/BhGLkTJ1YD5Mz/uzGULK4wo007UPXWqD/qQRzhb1eYe2cLrQnXKRIcjpsV+ KEvaurGc9br9y7diY1LOMDlNq6B+mcawLEdEU9uV5tXOD6SM9m3OhqHIlRg2sqCypweBch/1800cO mr4QxP7AXhy2YbIMvdS8G7i32tUcC5T1vkeSXEdlB8FDA9j5RHHUONedgq5B5HJ0FERDB8BuM4MTP w4T66s6W0Q==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:45580) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mmska-0001X0-Ln; Tue, 16 Nov 2021 08:19:28 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mmska-0006Cg-FV; Tue, 16 Nov 2021 08:19:28 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <YZJ/E/zFNEgNtk32@snel>
Date: Tue, 16 Nov 2021 08:19:27 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <16195D72-C292-4EE5-8827-E2AA5B8D0547@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e101f3822fc6cf51f98bf140265478e7be
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WSdD-cFnVR0Db8sOiPbD6cOfbxw>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 07:19:42 -0000

Hi Job,

> On 15 Nov 2021, at 16:38, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>=20
> On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
>> Before submitting the draft, I consulted several RP software
>> developers whether they considered it feasible to implement
>=20
> I question the soundness of your consultation, knowing that "Several =
RP
> software developers" also failed to understand the purpose of RPKI
> manifests [1], needed a year and lots of hand-holding to recognize the
> true situation ([2] -> [3]); or happily violated CA intent by ignoring
> missing CRLs and CRL staleness [4], [5]; or failed to see an issue =
with
> certificate malleability [6], [7], [8].

A constructive point that I can take from this is that we should strive =
for a
testbed with various constraints used to evaluate the implementation of =
the
constraints. A BBN conformance but with repositories, not objects.

> How can this be explained? Groupthink is a psychological phenomenon =
that
> can occur within groups of people in which the desire for conformity
> results in an irrational or dysfunctional decision-making outcome. Or
> perhaps it is lack of ever experiencing consequences, who knows! :-)
>=20
> For everyone's amusement: =
https://sobornost.net/~job/should_vs_must.jpg
>=20
>> To show how the maxDescendants works in practice, as per Ties'
>> suggestion, I created a little model in Python, which can be found
>> here: =
https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
>> It creates DOT graphs for each step, so you can see how an RP could
>> process tree hints in the case of maxDescendants - other limits can =
be
>> implemented in similar fashion.=20
>=20
> It seems you implemented something that takes a Python dictionary and
> outputs a DOT graph. This is not the same as ingesting potentially
> hostile data from an untrusted network input, parsing the data =
according
> to the X.509 and RPKI specifications, building validation paths, and
> generating a set of validated ROA payloads.

For me, as a software engineer, proving that you can apply this in any =
tree
generalises to the RPKI tree. And this meets the burden of proof I =
proposed.

> It also should be recognize that "maxDescendants set to zero" is the
> same as "pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
> This begs the question, why is pathLenConstraint not used in the RPKI?
> Was it an oversight? Or was it recognized that pathLenConstraint is =
not
> a security feature, but rather a "product differentiator"? I consider
> maxDescendants to be in the latter category.
>=20
>> There are some open questions, mainly: how does a parent inform a
>> child of what their limits are? And what if those limits change
>> (especially: become stricter)? How and when do these limits change?
>=20
> Great questions indeed. Perhaps the parent can inform the child by
> sending an invoice, and only adjust limits after having received =
payment?

That is already possible=E2=80=94no change by this proposal.

A parent can (already, hypothetically) enforce additional commercial =
conditions
depending on how RPKI is being used (e.g. change a charging scheme). =
Remember
that the objects published by a legitimate repository are already =
visible to all
participants (and a parent can thus monitor and revoke if commercial =
conditions
are not met).

Yet, the objects of a malicious repository are not always visible.

Furthermore, the PoCs for the =E2=80=9CPossibility to DOS the whole =
ecosystem=E2=80=9D exist.
Without additional evidence, your scenario is a hypothetical that =
appeals to the
fears of network operators. Can you provide additional evidence for this =
intent?

>=20
>> More generally, I want to point out that these are Tree *Hints*, not
>> Tree Rules.
>=20
> Interesting how a set of 'hints' can be an effective mitigation =
against
> Issue H, J, and K. It was my understanding that you propose - only =
when
> these hints are applied as if they are rules - safety can be achieved.
> But you now appear water down the applicability? Which is it?
>=20
> More importantly: already two different RP implementers recognized =
that
> "each RP implementation *will* have to apply limits" [9]. =
Unfortunately
> only one implementer took action so far. The problems you documented
> have to be solved irregardless of the existence of "Tree Hints", =
because
> an RP can't rely on Tree Hints being reasonable, or even existing.
>=20
> My suggestion would be everyone gets a move on and focuses on
> immediately resolving their issues, because at present H, J & K are =
not
> mitigated in multiple implemenations. Hint: accepting chains up to 32
> long is ludicrous. After having implemented sane limits, implementers
> are likely to come to understand there is no need for "Tree Hints".=20

The effective branching factor we see in the RPKI is ~15K. With this =
lower bound
on the branching factor, just three levels can build a tree that is =
orders of
magnitude larger than what can reasonably be processed. Both 10 and 32 =
are
thresholds that offer no protection.

I do believe that cutting off exploration could improve the situation. I =
hope we
can have a productive and civil discussion in the WG about the =
short-term
bandaids and structural fixes for these issues.

Kind regards,
Ties
>=20
>> In the bandwidth example, if you are using FORT Validator then any
>> repository that does not manage 200KB/s is already excluded using the
>> default configuration, thus that requirement is already in place in
>> practice. The same applies to all limits mentioned in 6.2-6.8. The
>> main difference is that if included in Tree Hints, both parties know
>> what "safe" values they can use, rather than having to keep up with
>> all limits individual implementations impose.
>=20
> You correctly place "safe" between quotation marks. Merely labeling
> something "safe" does not intrincically make it "safe". Fun to read =
that
> FORT now doubles as a general purpose network speedtest. However, from
> there it doesn't follow that "the requirement is already in place in
> practise".
>=20
> I remain skeptical about your proposal, as I find its merit lacking.
>=20
> Kind regards,
>=20
> Job
>=20
> [1]: =
https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents=
/
> [2]: =
https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
> [3]: =
https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
> [4]: https://github.com/NLnetLabs/routinator/issues/274
> [5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
> [6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
> [7]: https://github.com/NLnetLabs/routinator/issues/365
> [8]: https://github.com/cloudflare/cfrpki/issues/66
> [9]: =
https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScAvjQ/=

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


From nobody Tue Nov 16 00:22:47 2021
Return-Path: <andrei.robachevsky@gmail.com>
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 B51113A00B1 for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 00:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level: 
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-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 cnza0hZJySf4 for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 00:22:42 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 D7EDC3A00B0 for <sidrops@ietf.org>; Tue, 16 Nov 2021 00:22:41 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id w1so18016534edc.6 for <sidrops@ietf.org>; Tue, 16 Nov 2021 00:22:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=UTo9A6/bjL1pkX8Wf8KzQ/ylHiHV608RBT85kVBWdw4=; b=neYb6U5bQ1TgrSPs9yGWcs7s9DrCqEAUpm9/a/EPjizwKFtzFWv5UofCKkII60h8MV 5IGMXN0Ovfpf2mdNXaeaLgZBX9EqM5qiJZB9v1ZKrXetQemSpsNUmgMAEzWzmwB0gAha VdD24BNpvNBZcWoN3smMzvaFVcthgvmz0endWPtdoOP3vhvQ35x0oQ8iRKn/vrB4AGQ+ pZPa9VMERrzklEXRsgHvHxBP6X/Bomqrl5VSXV0vl6lDt5T1+GvjY+Kb8I4NM1qFny/T auqmKkm7U8qTCbVYAFKdW39v1niWOgNSUnxsWIaHOgQSQOmB977VPMPtQ+iq/sOzlu8b ydBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=UTo9A6/bjL1pkX8Wf8KzQ/ylHiHV608RBT85kVBWdw4=; b=JEoo0/aMXIIPunR2Rzs6odcKTY6TjQ/5PTlRL5ruNml4nNKAmlYV1PmzfDXk8kTHjy PXb2ZeZ9bGxFnixDFXrCKYEEfbjd5zy3f/AFhSCwUgtdg3/4P8Mgx3mS08y0urmZV7hl wcM0InyJH+o3IiWWyUf3uGPNpsJy0QO2WOpVyLq7PuVRPIcgqlykuWY/GIAkc5bm2/82 9HsxmyWygpAgZ1sbssbMLGXnC4fPsf7c9lnng6aUBYigyrpc5o+vaLXchudP+JqLEB6R VAiXOX5s32/x9wYebSajqWB2lWjwyOvKnZ2RIKRMfAYhFaCEzlV64wPkSb888brTwbKc R6ow==
X-Gm-Message-State: AOAM530GPhNzDpFSs14nzeFCKX7e2+o/z0J99YYYy5tAscIsm0jklHmo jOJK4WgNZr6XSXHD49szlbE=
X-Google-Smtp-Source: ABdhPJxRuDUcp65pcVzIwIYaePxM40svHA5Yc3xhCCRzLizfMvz7RoArGmF/MThI3HPTfyk1VS9m1g==
X-Received: by 2002:a17:906:4c95:: with SMTP id q21mr7356193eju.485.1637050959770;  Tue, 16 Nov 2021 00:22:39 -0800 (PST)
Received: from [192.168.178.20] (f189051.upc-f.chello.nl. [80.56.189.51]) by smtp.gmail.com with ESMTPSA id y22sm667944edi.8.2021.11.16.00.22.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Nov 2021 00:22:39 -0800 (PST)
Message-ID: <3f81805e-c616-6d9e-e602-7b02f9befe0e@gmail.com>
Date: Tue, 16 Nov 2021 09:22:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: Chris Morrow <morrowc@ops-netman.net>, sidrops@ietf.org
References: <87k0h8svcv.wl-morrowc@ops-netman.net>
From: Andrei Robachevsky <andrei.robachevsky@gmail.com>
In-Reply-To: <87k0h8svcv.wl-morrowc@ops-netman.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Tj_DhZ4EiHr_zzAujJ_PMcs228Q>
Subject: Re: [Sidrops] Draft Statuses from the F2F meeting slides
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 08:22:46 -0000

Chris Morrow wrote on 16/11/2021 03:11:
> Aspa-verification-08 - revision received - ready to move forward?

I made comments on -08, but I understand that -09 is expected very soon, 
so looking forward to it.

Thanks,

Andrei


From nobody Tue Nov 16 10:00:22 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 732BF3A02BE for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 10:00:20 -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, 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=student.utwente.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 gBVFRfnOoRuz for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 10:00:15 -0800 (PST)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 C75153A0140 for <sidrops@ietf.org>; Tue, 16 Nov 2021 10:00:14 -0800 (PST)
Received: by mail-ed1-x52e.google.com with SMTP id y12so35148074eda.12 for <sidrops@ietf.org>; Tue, 16 Nov 2021 10:00:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=nqmunocC3EhAvK9o1P6kOyxQVy4fNH1sgbzehPPlmyc=; b=kk1wwj4ZiFplolThqPJa+sPnyAL6AE4Ad16ZzHSCIf7yWMcTffn+hIFs0GNJ6DSsrS TIgWAbJthbjazNzjwEYcNGqTv6+KJirQWC9f6XMnw5k0z2afUP2cLkr+pVEY8PZunSgK lATXQHzwjsHuY6lNYbw/jdIPTiyg77VZ8bEZe9TPb60SQ0JX3QAGEKGHldeK3vAwj9Yl O7KdM41Z6NlC62DCBNox+h2W0hkJmYzwqRYSpLwkHa7AqvhrYKu4q6nLyCRb2vF53WS2 PvURgNMsRDvS5JcpvgLPgxU7SrgXTDC1QToCjZovs4xsVR5ivwMlMD4MFHa4pQLSuYwU z97Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=nqmunocC3EhAvK9o1P6kOyxQVy4fNH1sgbzehPPlmyc=; b=WxWfe5ep15U6BXOxfJf2IKqI6+8Pt5wgbeilcrQrohw3IP8iQK/SPPSGL4dL9aGrO4 2WjsQ9l+NtXNmBtKwMdGFtIyAORqyyyWmi1gd4NV74IyGtEYBioLOfPQALJ6w3C13kXw TdfnhkuJiA4i4YGC1s/bYovVZMYlZ4o1dYaGfSqztSYNvXroOSztHufKNuHWSr4T/wbK rKH1KI1eSfn3ZoZs3O0G1uyZXIbhPFAEMr7fNpOEwIajLK0WFZ0Ey/R8mYeyjCyMWrJ9 v//sGc04nnwtZ5xk/m/Nelb32qhUrGVYGEoOF9yrCj4ND/1DGbF6J8nbRcSQgQMKEWCO R7Gg==
X-Gm-Message-State: AOAM532Hg9x+jiLD3ImGXfehAJVbeF0WJBCfM7FZDnse7at71U78aN0+ v41x4yMjp4SLJp4JIoNODLhHwgBPS5iB7Q==
X-Google-Smtp-Source: ABdhPJw78h+QOfLU6rSYUggTVwiwywGb9GE6jQBdh0mosXPEzSAWlBdrt2J7wcO0v+vOKdmv+x5BbA==
X-Received: by 2002:a05:6402:524b:: with SMTP id t11mr13191453edd.98.1637085611757;  Tue, 16 Nov 2021 10:00:11 -0800 (PST)
Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id gs17sm8851706ejc.28.2021.11.16.10.00.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Nov 2021 10:00:11 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'Job Snijders'" <job@fastly.com>, <sidrops@ietf.org>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel>
In-Reply-To: <YZJ/E/zFNEgNtk32@snel>
Date: Tue, 16 Nov 2021 19:00:10 +0100
Message-ID: <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG7WjUlhTlYjtt+Vnt4JWaZods+RgIeKrurAcOeePcA3cZsDgIi3ifjrAdK7pA=
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/EX_ZmOhstZeRuKrwnEz8BICj0TU>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 18:00:20 -0000

Dear Job, all,

I am afraid I do not quite follow you. Could you clarify what you meant by
"fatally flawed"? What merit is lacking?

For those unaware, I have been looking into the question "Can I disrupt RPKI
RP software by introducing a malicious CA/repository into the tree?". A
summary of what I tested can be found here:
https://labs.ripe.net/author/koen-van-hove/improving-the-resiliency-of-rpki-
relying-party-software/, but the long story short is that CAs and
repositories can attempt to use malicious behaviour (e.g., creating many
descendants) to make RP software take unreasonably long to process. To back
this up, I created proof of concepts, which have the letters A to O. Using
heuristics to exclude the malicious nodes without collateral damage (ergo
also excluding non-malicious nodes) is difficult, if not impossible. The
Tree Hints draft is a proposal to solve this issue, by providing the RP
software the information it needs to determine when a node is malicious.

> My suggestion would be everyone gets a move on and focuses on immediately
resolving their issues, because at present H, J & K are not mitigated in
multiple implemenations. Hint: accepting chains up to 32 long is ludicrous.
After having implemented sane limits, implementers are likely to come to
understand there is no need for "Tree Hints".

Sane limits would be great - I am just not sure whether there are static
limits that exclude malicious nodes without also excluding non-malicious
nodes, and that can ensure that the RP software can continue working as it
should within a reasonable timeframe. Feel free to propose sane limits, then
I will run the numbers to see if that effectively solves the problem. I have
already done so for the limits posted in the RPKI fencing thread and shown
that they do not suffice to effectively stop the attack, as well as possibly
causing collateral damage, but I am happy to run the numbers again for any
other proposals you may have.

The problem still exists and is in need for a solution. Tree Hints can be a
solution, but I invite you to come up with a different solution to solve
this problem. Then I will try to find out if an attacker can find a way
around those limits.

Koen van Hove

-----Oorspronkelijk bericht-----
Van: 'Job Snijders' <job@fastly.com> 
Verzonden: maandag 15 november 2021 16:39
Aan: sidrops@ietf.org
Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key
Infrastructure (RPKI)

On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
> Before submitting the draft, I consulted several RP software 
> developers whether they considered it feasible to implement

I question the soundness of your consultation, knowing that "Several RP
software developers" also failed to understand the purpose of RPKI manifests
[1], needed a year and lots of hand-holding to recognize the true situation
([2] -> [3]); or happily violated CA intent by ignoring missing CRLs and CRL
staleness [4], [5]; or failed to see an issue with certificate malleability
[6], [7], [8].

How can this be explained? Groupthink is a psychological phenomenon that can
occur within groups of people in which the desire for conformity results in
an irrational or dysfunctional decision-making outcome. Or perhaps it is
lack of ever experiencing consequences, who knows! :-)

For everyone's amusement: https://sobornost.net/~job/should_vs_must.jpg

> To show how the maxDescendants works in practice, as per Ties'
> suggestion, I created a little model in Python, which can be found
> here: https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
> It creates DOT graphs for each step, so you can see how an RP could 
> process tree hints in the case of maxDescendants - other limits can be 
> implemented in similar fashion.

It seems you implemented something that takes a Python dictionary and
outputs a DOT graph. This is not the same as ingesting potentially hostile
data from an untrusted network input, parsing the data according to the
X.509 and RPKI specifications, building validation paths, and generating a
set of validated ROA payloads.

It also should be recognize that "maxDescendants set to zero" is the same as
"pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
This begs the question, why is pathLenConstraint not used in the RPKI?
Was it an oversight? Or was it recognized that pathLenConstraint is not a
security feature, but rather a "product differentiator"? I consider
maxDescendants to be in the latter category.

> There are some open questions, mainly: how does a parent inform a 
> child of what their limits are? And what if those limits change
> (especially: become stricter)? How and when do these limits change?

Great questions indeed. Perhaps the parent can inform the child by sending
an invoice, and only adjust limits after having received payment?

> More generally, I want to point out that these are Tree *Hints*, not 
> Tree Rules.

Interesting how a set of 'hints' can be an effective mitigation against
Issue H, J, and K. It was my understanding that you propose - only when
these hints are applied as if they are rules - safety can be achieved.
But you now appear water down the applicability? Which is it?

More importantly: already two different RP implementers recognized that
"each RP implementation *will* have to apply limits" [9]. Unfortunately only
one implementer took action so far. The problems you documented have to be
solved irregardless of the existence of "Tree Hints", because an RP can't
rely on Tree Hints being reasonable, or even existing.

My suggestion would be everyone gets a move on and focuses on immediately
resolving their issues, because at present H, J & K are not mitigated in
multiple implemenations. Hint: accepting chains up to 32 long is ludicrous.
After having implemented sane limits, implementers are likely to come to
understand there is no need for "Tree Hints". 

> In the bandwidth example, if you are using FORT Validator then any 
> repository that does not manage 200KB/s is already excluded using the 
> default configuration, thus that requirement is already in place in 
> practice. The same applies to all limits mentioned in 6.2-6.8. The 
> main difference is that if included in Tree Hints, both parties know 
> what "safe" values they can use, rather than having to keep up with 
> all limits individual implementations impose.

You correctly place "safe" between quotation marks. Merely labeling
something "safe" does not intrincically make it "safe". Fun to read that
FORT now doubles as a general purpose network speedtest. However, from there
it doesn't follow that "the requirement is already in place in practise".

I remain skeptical about your proposal, as I find its merit lacking.

Kind regards,

Job

[1]:
https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents/
[2]: https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
[3]: https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
[4]: https://github.com/NLnetLabs/routinator/issues/274
[5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
[6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
[7]: https://github.com/NLnetLabs/routinator/issues/365
[8]: https://github.com/cloudflare/cfrpki/issues/66
[9]:
https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScAvjQ/




From nobody Tue Nov 16 10:18:45 2021
Return-Path: <jsnijders@fastly.com>
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 9C8E33A048B for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 10:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=fastly.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 BEKfoPSFt2XH for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 10:18:39 -0800 (PST)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 172473A047D for <sidrops@ietf.org>; Tue, 16 Nov 2021 10:18:39 -0800 (PST)
Received: by mail-il1-x130.google.com with SMTP id i9so67396ilu.8 for <sidrops@ietf.org>; Tue, 16 Nov 2021 10:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ayb0Yr8D0u/8mkkgkPi2UN3oNc7QW/wInLNQqye+jM=; b=A7lY0JbRR96MZJgvuQbfTrCH/UlsnpBY+JrNc3JiIdip01lLNCUuk031S1cmrKwnT8 xRAlOeLpq2Yv1CJvKrj7MgWWLonlcFGD7bEmg2UG7akOugff2sdwsMd3CAcub2a7AWMz JkgSdfhR0vb+DIVRXcVTNXXhCuDuVt8HNqVx4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ayb0Yr8D0u/8mkkgkPi2UN3oNc7QW/wInLNQqye+jM=; b=cGMA7bQRPVLwEA7v4tmvjvYfNYd8NpxvfreJUBMDnPC/HKLNYeJOIXMl4Pg7VLQQSJ Tv8b/pZbFWtQYYVJwIuRaFatoQ8Dtuetwl3+gk2wjm4RCsg6ib0LQFPwsUByryn+cd0n To+Bvl3sE12kSTj4/EmBdsw4MTSzVlXV07y7xDfGHdd2b5k1v4Fx9YkHQqpW0PqeZixI EvfulVsD2cwEyt+kj7eVt+F24vAmwEuLPiclpHJ79gIM/iXHagicITDuhj8j4x4X5l5h Afr7kE/k9wRQzRBBsBfV76VJ/84gjolqITiEOna3A5CP+FvnoL9v6tyrzd1ISalCH5iP kqJg==
X-Gm-Message-State: AOAM531tZG+VgUhYige5Es8X3f+X3Z9YcicV3VmN1pPbCTeOQo/2no7q BDbT7x6a9OAAtF1ldTecgTgmyldrLdx85JkAfa2VaQ==
X-Google-Smtp-Source: ABdhPJxuHrUgKQJX30BTsnBI7I8qIQwgRAixpqbC0plri7PGXi+bNMu/WSMUu/aiAqyvWHKa2cNqqPlKJW74tkI7sg0=
X-Received: by 2002:a05:6e02:1546:: with SMTP id j6mr6146794ilu.223.1637086717396;  Tue, 16 Nov 2021 10:18:37 -0800 (PST)
MIME-Version: 1.0
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
In-Reply-To: <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
From: Job Snijders <job@fastly.com>
Date: Tue, 16 Nov 2021 19:18:26 +0100
Message-ID: <CAMFGGcB98p9-XU+tYOXZ7_VKVPCb+hxTtTU5VyrA=3bpeJ2RQA@mail.gmail.com>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: sidrops@ietf.org
Content-Type: multipart/alternative; boundary="00000000000041df2405d0ebf4f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/q2fMN4dR8dz5MZqiMrz6oxYRduM>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 18:18:44 -0000

--00000000000041df2405d0ebf4f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Koen,

On Tue, 16 Nov 2021 at 19:00, Koen van Hove <k.w.vanhove@student.utwente.nl=
>
wrote:

Sane limits would be great - I am just not sure whether there are static
> limits that exclude malicious nodes without also excluding non-malicious
> nodes, and that can ensure that the RP software can continue working as i=
t
> should within a reasonable timeframe. Feel free to propose sane limits,
> then
> I will run the numbers to see if that effectively solves the problem. I
> have
> already done so for the limits posted in the RPKI fencing thread and show=
n
> that they do not suffice to effectively stop the attack, as well as
> possibly
> causing collateral damage, but I am happy to run the numbers again for an=
y
> other proposals you may have.



When you say =E2=80=9Crun the numbers=E2=80=9D, do you mean you input the s=
uggested limits
in something like a spreadsheet, then derive a pass / fail based on some
calculation?


Kind regards,

Job

--00000000000041df2405d0ebf4f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Koen,</div><div dir=3D"auto"><br></div><div>On Tue, 16=
 Nov 2021 at 19:00, Koen van Hove &lt;<a href=3D"mailto:k.w.vanhove@student=
.utwente.nl">k.w.vanhove@student.utwente.nl</a>&gt; wrote:</div><div dir=3D=
"auto"><br><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex" dir=3D"auto">
Sane limits would be great - I am just not sure whether there are static<br=
>
limits that exclude malicious nodes without also excluding non-malicious<br=
>
nodes, and that can ensure that the RP software can continue working as it<=
br>
should within a reasonable timeframe. Feel free to propose sane limits, the=
n<br>
I will run the numbers to see if that effectively solves the problem. I hav=
e<br>
already done so for the limits posted in the RPKI fencing thread and shown<=
br>
that they do not suffice to effectively stop the attack, as well as possibl=
y<br>
causing collateral damage, but I am happy to run the numbers again for any<=
br>
other proposals you may have.</blockquote><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">When you say =E2=80=9Crun the numb=
ers=E2=80=9D, do you mean you input the suggested limits in something like =
a spreadsheet, then derive a pass / fail based on some calculation?</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Kin=
d regards,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Job</div></di=
v></div>

--00000000000041df2405d0ebf4f3--


From nobody Tue Nov 16 11:19:55 2021
Return-Path: <stkent@verizon.net>
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 568D03A07E2 for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 11:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level: 
X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 c3VTbfWGJOtn for <sidrops@ietfa.amsl.com>; Tue, 16 Nov 2021 11:19:51 -0800 (PST)
Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (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 69EFC3A07DD for <sidrops@ietf.org>; Tue, 16 Nov 2021 11:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1637090389; bh=lKOOPRl4jBsdo+oHPRICX967E2b0xVqDpgERnSS/X6o=;  h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To;  b=pQ6uo9oI1SU+15ffOB30tMj04mAbAkpUyLfcynEVj56hoUV22Oi2+4Ayi7D6rqJPlJNItP66X1WulEPcGLwbWKsmk2nPCsoXn8p4Lajih7uwFAj/0u5OlokU1qvcZcO3mooxAUHKxqRIJPyrkEFrGZlHuN1gt5TB4aXeWEOkCSGPtsBOJiWPJcOPy0SYPc3/Pi4OaFGdNM/ZxcyyctgLYQBRu00ICVA5dTbT/SwVAg/lYd+DHPPFZpN1WBa33bsd8uDuc6Df78Pi9yjqXdIZYAwH+hgH93DsQ5iStj4mjzGJWINA5eIxEqRjSTYGwIolf/sobuuzMBzrn6vP/ESVFA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1637090389; bh=y28mWiksKwATYQbLq2xQAEzgx4KBWaayCtHMbBGwopv=;  h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=NhZPn0PVPn7i+0pAXimVbHvHDdIRC0SiLp68vn/36wkNyOQZLtIfS2XFZTrpgSxTkwG0ptRXV4Y5Kng8CdLJVaIjvvSrbr8+fBlliaWuFo3ODlzZVeJH+G/2CHuduVa7/CaDiTNlTeXz/gMcxf7x8fM+C6Inu6TC7c7oHap2KrU/Id4W1m7CGF/ngW5heN9aEYNMJHeD99fRLzCiPqwR3Ox0DBBZ5A+iyfGcQETxsxsvg/07WJ98EyaS+tzKOP24yvCof6wQ/GfPe+Sc16TenK0RInvBhC2aZ973rXGV1PNnYGI3FVtLWC9oHKaj9rVOM0TZcLN0AjM5Lp/xXUJLlA==
X-YMail-OSG: YDQ7nLQVM1mrlhLHwt1JWYJm68bqZh.P2Oafi77L5xKNAlQn.AF4syUrWyoJ5sz jskQZeSK0XzLGnBfcATPzVpJxW39gLbR9uBI1UoD9FGNsY..RbO6MHwtsYrnig6e3k.oSit9DHws LVPYktzcK8lgaYx9iaIQOwNGmJLAEVXp3AmJlmxqitcCIPAG8sFCeXzAtV54k.8vObIC7wNawj0m 6rs25Z_.5TJMK1AMoT14epxqJRj5TiUzqg9nV4ekZ_XqVwNdcfQQ_0wv9kXM8bBuNiyPHm6B2jMy GBb7_NeW2F74dlBgXibKjDsfJcMIFcoXSmgtnj3G3alyQZtkN7gddd_dv1HpBAlfKdaExIdP0C83 _lSkpXUktZNwi5NbyqbgYQFwRJnhFYDgNmZK0wZZG3iWwvGwUKoQl6TKZLzKJUJh2KuVqyraHLcI CVof7CjB5uA.gzL3VrOaCoyfHV4OCtcvebyFSUk1NPvIRyFCLRjl37iigGyEwqXDxKfXapyHpRCd SR.JKMzkPWzaVBV9CsA3d7u4QGB0zPT5k8EFdQmS5E.bhO62jJvWNoQWGK4EXi8n2LcJ50S3awdS s2qVcNW2W8aTZDVWkC.DKItGK6NTS04_UOMaFDM9Xn_PYFtWIzeyO9KeX9qInuTjyaZeCkiHSVpw URIfsQD.eerNRZfFCZ5yajK68tpT.hPIPUa2aEU5js7IWFXXbJLPn3WKuO72RmGvDzE.zYxz8gK0 KGoxTdpIt2L8LN25tOY4PAWmzanabNe310kLjsnTGZPDLP2wdM.Z7.AeSQbdl1a6QU1.s3mhs3NL sZpLk5FImiSRhDKxlToGE9M5CC8tE4j0R79yOl2tWJe5uRNPNZgDfJHI9ehKEhl4h3Hs8xiGdNjB mex4OQo5aeqpH6.8Gk69aGdfoXPnmseNgagQ9FLhWotCqQpi0G.s.5rmMSnhxbZ6irHRMDoxMU9V 2_.XF4zUG8oVeONSdWw_l.vGfG1rTinRyjdb3LYbyx9MLyp9KnTogFpTB6KULy1yJh8q5lD5vCIm 8HMab.uwkipS667.rGnIfn_eTALvRY9sgAU1ec2UArpWTUGnFyQEuEmSO_M3vnoDkbqSgqjcisuX RAZ6nl4lmU9ERLlytlH_ux95uKRj_dA2.8Bn4oPjwhDEEktpA1YbSQDhuJak680NN6d02QU4Xegq RpH5ZQe60fyXxaq64ZOz_xOIAolObly6tDqo4gEjgbTkQVQ0pdABSRAMrm4O2oFUUD_CKnyU2nFP w_LHyV9hF3N07_lZddkNTJ5Qr_mR_4qucpQNVxhxoeH10b4LRgOjv7YDCyy3COwlzl5wf5HXNZ.K X6jtaEcSr36tobKOCHaMzM6VqzqQyjNjsmYFVCpJGECIIPA.xYSUQKtjwTM9iitX48._mPA24pNy veffIhV4Zac6VFElLQsJ3cJXGpAK.zoS2Pp.ZtUkbl6FUfjRz7LW0SnZwEyySaYds0grAc4CKV5V SW1MrK_LVNUN3ADi2vJLEC8O2ExtzvIhH7BTJnby_6F1L0bmzMpQsHyIvodRoWmOr8SoH1qYxPIt 8tI3KWqevM77r4eqrdwJYXRR4iIoiFGAd0r2bYxU1QIKPjAMMbs0D8paL0v1F.VJi0ZJnhCI0IqB ijDyByBNEY.Ms5AWJhG7SR101DoNmrPAXRToeFYTHmHIH.HlUVhj9Gn03lecAxmqOEN7YYeXauwH .AkjAC.Bt9C68l3xjdlgL65hS7FQtObcfwJM51QrlYAKlLD1wF73mcfq7aITb_FNlp0wtUmycbue wf.x2k_IQ5P1_PLSnlpNz5DtIdb8t0pN.mt0l4fTJwkJFDbHgt2We2iJ1E8rgwiW5TztwoO1C6zw BAhdxixeyPJOCbvniO8CpeMQNCwUOtDVq2VimzxUs_jzKYypjjMk0V.2SRMA56u8ljKMsHrYFRVG zYetqQmmspFHyHY8nAqk0steBNhI3vMoIsXCFV4dxNmcPT57D2PhS8uSm_AFMmhjVXmefc7YTatc 0USGLARcc0uIfPi8D3r.KcSBTvkvg90KUNBe2cCmPq7kdFYCGubl5DXU.kNFFibBkOj1Zqhc0jYV h.u_c3LiLxcVBNdMCOgRo2q6Tm1YfQGSTcvegVjs7xQXG7f5YqemydVqHjFAd7jHfIxJtpHRRScl 1Didtk5yZdCE-
X-Sonic-MF: <stkent@verizon.net>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Tue, 16 Nov 2021 19:19:49 +0000
Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6eb5403867a0027c7aa4129a13e65f5b;  Tue, 16 Nov 2021 19:19:48 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------BFmfwDk0t0brvnL5cZzHW9j6"
Message-ID: <a468a25a-f825-92fb-a2eb-54555b5efaaa@verizon.net>
Date: Tue, 16 Nov 2021 14:19:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: sidrops@ietf.org
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <6b1e4ee2-aa5a-5e65-35c8-95abdb88cc94@verizon.net> <000801d7d893$13c049c0$3b40dd40$@student.utwente.nl>
From: Stephen Kent <stephen.kent@verizon.net>
In-Reply-To: <000801d7d893$13c049c0$3b40dd40$@student.utwente.nl>
X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/eapCrvUOMr3ipBVzCiV9Mb1RCTk>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 19:19:53 -0000

This is a multi-part message in MIME format.
--------------BFmfwDk0t0brvnL5cZzHW9j6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

OKoen,
> Steve,
>
> Perhaps my wording was not optimal - let me try to show my point by means of example.
>
> Imagine the following structure: A RIR at level 0, my CA directly below it at level 1, and my children at level 2. With the current limits I can easily create 1000 children with different repositories at level 2, thereby exceeding the limit and stopping the further exploring of other repositories within this TAL. With the current traversal order, this means that if your repository is at level 0 or 1, it will be included. If it is at level 2, it may be included, if it is visited before my children. If it is at level 3, you can be sure that it will not be included, as my children at level 2 already exhausted the repository limit.
>
> Currently if you manage a /32 (IPv6), and you host your own repository, you have a choice. You can decide to have all ROAs in one large repository (at level 1), but you can also delegate parts to other organisations who host their own repositories (at level 2+). With these limits, that latter option becomes risky, as with an attack as described above you risk those delegations to other organisations, as they are at the same level as my malicious children. Even worse, if your repository is not directly below the RIR, but instead below, e.g., a NIR, then hosting your own repository already happens at level 2. This is what I meant with "freedom" - the ability to structure your part of the tree in a way that suits your organisational needs.
>
> If we decide that every layer below layer 2 may be ignored when an attack like this happens, then I do believe we can consider those objects to be less "important" (for the lack of a better wording).
>
The "freedom" to arrange subordinate pub points is what I would call 
flexibility, but that's not the real issue. The fact is that decisions, 
e.g., delegating subordinate pub points, carry risks, which seems pretty 
obvious to me.

You say that "If _we_ decide that every layer below layer 2 may be 
ignored ..." I doubt that it is attractive to establish a uniform layer 
below which all RPs will ignore subordinate pub points. If I were 
developing RP software, and if I worried about  the sort of DoS attacks 
you describe, I might employ heuristics to mitigate such attacks. For 
example, if I seem to be spending too much time retrieving objects from 
a pub point, I might skip that pub point for now, and come back later. 
If the problem persists, I would notify an operator, and let him/her 
decide whether to skip the pub point because it seems to be an attack 
vector (or just very badly provisioned, or ...).

Steve


--------------BFmfwDk0t0brvnL5cZzHW9j6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">OKoen,<br>
    </div>
    <blockquote type="cite"
      cite="mid:000801d7d893$13c049c0$3b40dd40$@student.utwente.nl">
      <pre class="moz-quote-pre" wrap="">Steve,

Perhaps my wording was not optimal - let me try to show my point by means of example.

Imagine the following structure: A RIR at level 0, my CA directly below it at level 1, and my children at level 2. With the current limits I can easily create 1000 children with different repositories at level 2, thereby exceeding the limit and stopping the further exploring of other repositories within this TAL. With the current traversal order, this means that if your repository is at level 0 or 1, it will be included. If it is at level 2, it may be included, if it is visited before my children. If it is at level 3, you can be sure that it will not be included, as my children at level 2 already exhausted the repository limit.

Currently if you manage a /32 (IPv6), and you host your own repository, you have a choice. You can decide to have all ROAs in one large repository (at level 1), but you can also delegate parts to other organisations who host their own repositories (at level 2+). With these limits, that latter option becomes risky, as with an attack as described above you risk those delegations to other organisations, as they are at the same level as my malicious children. Even worse, if your repository is not directly below the RIR, but instead below, e.g., a NIR, then hosting your own repository already happens at level 2. This is what I meant with "freedom" - the ability to structure your part of the tree in a way that suits your organisational needs.

If we decide that every layer below layer 2 may be ignored when an attack like this happens, then I do believe we can consider those objects to be less "important" (for the lack of a better wording).

</pre>
    </blockquote>
    <p><font face="Monaco">The "freedom" to arrange subordinate pub
        points is what I would call flexibility, but that's not the real
        issue. The fact is that decisions, e.g., delegating subordinate
        pub points, carry risks, which seems pretty obvious to me. <br>
      </font></p>
    <p><font face="Monaco">You say that "If <u>we</u> decide that every
        layer below layer 2 may be ignored ..." I doubt that it is
        attractive to establish a uniform layer below which all RPs will
        ignore subordinate pub points. If I were developing RP software,
        and if I worried about  the sort of DoS attacks you describe, I
        might employ heuristics to mitigate such attacks. For example,
        if I seem to be spending too much time retrieving objects from a
        pub point, I might skip that pub point for now, and come back
        later. If the problem persists, I would notify an operator, and
        let him/her decide whether to skip the pub point because it
        seems to be an attack vector (or just very badly provisioned, or
        ...).</font></p>
    <p><font face="Monaco">Steve<br>
      </font></p>
    <p><br>
    </p>
  </body>
</html>
--------------BFmfwDk0t0brvnL5cZzHW9j6--


From nobody Tue Nov 16 13:05:48 2021
Return-Path: <randy@psg.com>
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 F05BE3A0929; Tue, 16 Nov 2021 13:05:46 -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, 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 Z0UMPCNTXOtk; Tue, 16 Nov 2021 13:05: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 3575F3A0926; Tue, 16 Nov 2021 13:05: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 <randy@psg.com>) id 1mn5e4-0003g1-Vf; Tue, 16 Nov 2021 21:05:37 +0000
Date: Tue, 16 Nov 2021 13:05:36 -0800
Message-ID: <m2zgq3q09r.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Stephen Kent <stephen.kent=40verizon.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
In-Reply-To: <a468a25a-f825-92fb-a2eb-54555b5efaaa@verizon.net>
References: <YYvOop1mWMNc9tCG@snel> <000501d7d70e$247f3770$6d7da650$@student.utwente.nl> <6b1e4ee2-aa5a-5e65-35c8-95abdb88cc94@verizon.net> <000801d7d893$13c049c0$3b40dd40$@student.utwente.nl> <a468a25a-f825-92fb-a2eb-54555b5efaaa@verizon.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/8-TPSVqPCN0IWt0wMnFKDzJ7Gfo>
Subject: Re: [Sidrops] RPKI fencing limits (was: Tree Hints)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 21:05:47 -0000

> if I seem to be spending too much time retrieving objects from a pub
> point, I might skip that pub point for now, and come back later.

some swengs might set a marker/flag and fork before descending into
*any* pp; protect with a counter; and eventually check for rusty forks.

randy


From nobody Wed Nov 17 04:42:02 2021
Return-Path: <mpuzanov@ripe.net>
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 B8ED43A0CB9 for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 04:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=ripe.net
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 YhNdpZ5ecirT for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 04:41:54 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 B4C583A0C43 for <sidrops@ietf.org>; Wed, 17 Nov 2021 04:41:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=ryyB28dUx9pZp7qyIUJl7LXD+4CUwXLL75CystvXzuE=; b=g09O+p9td9eut+mlXj+WlCgh 0JwYchsFYpBHAJCmrdtnNle+e0hx6FQktMKTlwDUjxI+jUPO3l2OML7JPrGuPheglVuaAxGyRHU9j r/hVc24U0ocw7gcUODJI8packRfA4ymGoQ7YRo/IGHTOfQX71rUC3FYZfP0wWBwmPyLC25CDiutzA wpgrREt5vFeonuApmdtVTWZowxEsoUq2se+IgzxKy07MfcvUgUjVHZlUBdojV+JIYbcG4Sa9xcVfq mT0skOhMDr9tj3wmpEFwMb/haLnbMF44FQ5TIbPBlQReV1xTezrdFiU1L4ZlYBHpP3Mj0J+kKo7yf HjHorQ2QhA==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:58054) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mpuzanov@ripe.net>) id 1mnKG6-000B0M-Vd; Wed, 17 Nov 2021 13:41:50 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mpuzanov@ripe.net>) id 1mnKG6-00074h-So; Wed, 17 Nov 2021 13:41:50 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mikhail Puzanov <mpuzanov@ripe.net>
In-Reply-To: <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
Date: Wed, 17 Nov 2021 13:41:50 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <50B00643-684D-4012-933B-05557F4F02E6@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e0f61a4e02323ba05c376d74249246a3c2
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/s2WRi4dvqLyOHRlJaWti0fMkQFs>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 12:42:01 -0000

Hi Koen, all

I would like to add my 2 cents about the draft.

1) Some sort of limits will have to be forced in RPs regardless of=20
"Tree Hints=E2=80=9D implemented or not since an RP can not rely on =
these hints
always present. I would imagine that a reasonable RP implementation uses=20=

some default limits and policies and adjusts them according with the =
hint=20
objects if it finds them on a manifest. =46rom that viewpoint the draft=20=

would benefit from  describing these default limits and, probably,=20
the approaches to enforcing them.

Something along the lines of "RP SHOULD traverse the CA tree in such a =
way=20
that a malicious CA/repository does not stop well-behaving CA to be =
processed=E2=80=9D=20
or =E2=80=9CRP MUST set a timeout on TA tree processing and SHOULD =
process all the CAs=20
that fit into this timeout even if the whole tree does not finish in =
time=E2=80=9D=20
would make it more solid.

It may be, of course, that it is better to mention these RP limits in =
RFC 6486=20
and 6487 and refer from this draft.

Setting such hard limits would automatically impose a lot of constraints =
on RP=20
implementation such as using timeouts pretty much everywhere, limiting =
CPU time=20
and memory allocations on some per-subtree basis, running concurrent =
processes=20
instead of sequential processing, etc.=20

I can imagine that it probably was not your intention when writing this =
draft,=20
just want to point out that every RP-implementor has to answer the =
question
=E2=80=9Cwhat do I do if there are no hint objects?=E2=80=9D so some =
solid ground needs be set=20
here first before starting to use these hints.


2) I have a feeling that it is not very easy to implement the backend=20
part of it, for non-technical reasons. How does, for example, RIPE NCC =
set these=20
limits, based on what? Some reasonable default for everybody? But then =
it can still=20
be too low or too high for a particular CA/NIR. Does it imply some sort =
of=20
application procedure when an LIR says =E2=80=9CI am planning to have a =
child CA and=20
not more than 100 ROAs=E2=80=9D? I have a hunch that there are legal =
implications to=20
this, so RIRs need to change their disclaimers, CPS, even contracts(?) =
in order to=20
incorporate something like =E2=80=9CBy setting this checkbox you agree =
to get you CA revoked=20
if you (or any of your child CAs) publish more than 1GB of objects=E2=80=9D=
.=20

Legal issues, of course, should not be your concern when proposing a =
technical=20
draft, but if the draft goes on, this topic will pop up a lot and maybe =
it would=20
make sense to add something about realistically setting these hints to =
the draft
or at least have a more detailed discussion about it.

--
Misha



> On 16 Nov 2021, at 19:00, Koen van Hove =
<k.w.vanhove@student.utwente.nl> wrote:
>=20
> Dear Job, all,
>=20
> I am afraid I do not quite follow you. Could you clarify what you =
meant by
> "fatally flawed"? What merit is lacking?
>=20
> For those unaware, I have been looking into the question "Can I =
disrupt RPKI
> RP software by introducing a malicious CA/repository into the tree?". =
A
> summary of what I tested can be found here:
> =
https://labs.ripe.net/author/koen-van-hove/improving-the-resiliency-of-rpk=
i-
> relying-party-software/, but the long story short is that CAs and
> repositories can attempt to use malicious behaviour (e.g., creating =
many
> descendants) to make RP software take unreasonably long to process. To =
back
> this up, I created proof of concepts, which have the letters A to O. =
Using
> heuristics to exclude the malicious nodes without collateral damage =
(ergo
> also excluding non-malicious nodes) is difficult, if not impossible. =
The
> Tree Hints draft is a proposal to solve this issue, by providing the =
RP
> software the information it needs to determine when a node is =
malicious.
>=20
>> My suggestion would be everyone gets a move on and focuses on =
immediately
> resolving their issues, because at present H, J & K are not mitigated =
in
> multiple implemenations. Hint: accepting chains up to 32 long is =
ludicrous.
> After having implemented sane limits, implementers are likely to come =
to
> understand there is no need for "Tree Hints".
>=20
> Sane limits would be great - I am just not sure whether there are =
static
> limits that exclude malicious nodes without also excluding =
non-malicious
> nodes, and that can ensure that the RP software can continue working =
as it
> should within a reasonable timeframe. Feel free to propose sane =
limits, then
> I will run the numbers to see if that effectively solves the problem. =
I have
> already done so for the limits posted in the RPKI fencing thread and =
shown
> that they do not suffice to effectively stop the attack, as well as =
possibly
> causing collateral damage, but I am happy to run the numbers again for =
any
> other proposals you may have.
>=20
> The problem still exists and is in need for a solution. Tree Hints can =
be a
> solution, but I invite you to come up with a different solution to =
solve
> this problem. Then I will try to find out if an attacker can find a =
way
> around those limits.
>=20
> Koen van Hove
>=20
> -----Oorspronkelijk bericht-----
> Van: 'Job Snijders' <job@fastly.com>=20
> Verzonden: maandag 15 november 2021 16:39
> Aan: sidrops@ietf.org
> Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key
> Infrastructure (RPKI)
>=20
> On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
>> Before submitting the draft, I consulted several RP software=20
>> developers whether they considered it feasible to implement
>=20
> I question the soundness of your consultation, knowing that "Several =
RP
> software developers" also failed to understand the purpose of RPKI =
manifests
> [1], needed a year and lots of hand-holding to recognize the true =
situation
> ([2] -> [3]); or happily violated CA intent by ignoring missing CRLs =
and CRL
> staleness [4], [5]; or failed to see an issue with certificate =
malleability
> [6], [7], [8].
>=20
> How can this be explained? Groupthink is a psychological phenomenon =
that can
> occur within groups of people in which the desire for conformity =
results in
> an irrational or dysfunctional decision-making outcome. Or perhaps it =
is
> lack of ever experiencing consequences, who knows! :-)
>=20
> For everyone's amusement: =
https://sobornost.net/~job/should_vs_must.jpg
>=20
>> To show how the maxDescendants works in practice, as per Ties'
>> suggestion, I created a little model in Python, which can be found
>> here: =
https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
>> It creates DOT graphs for each step, so you can see how an RP could=20=

>> process tree hints in the case of maxDescendants - other limits can =
be=20
>> implemented in similar fashion.
>=20
> It seems you implemented something that takes a Python dictionary and
> outputs a DOT graph. This is not the same as ingesting potentially =
hostile
> data from an untrusted network input, parsing the data according to =
the
> X.509 and RPKI specifications, building validation paths, and =
generating a
> set of validated ROA payloads.
>=20
> It also should be recognize that "maxDescendants set to zero" is the =
same as
> "pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
> This begs the question, why is pathLenConstraint not used in the RPKI?
> Was it an oversight? Or was it recognized that pathLenConstraint is =
not a
> security feature, but rather a "product differentiator"? I consider
> maxDescendants to be in the latter category.
>=20
>> There are some open questions, mainly: how does a parent inform a=20
>> child of what their limits are? And what if those limits change
>> (especially: become stricter)? How and when do these limits change?
>=20
> Great questions indeed. Perhaps the parent can inform the child by =
sending
> an invoice, and only adjust limits after having received payment?
>=20
>> More generally, I want to point out that these are Tree *Hints*, not=20=

>> Tree Rules.
>=20
> Interesting how a set of 'hints' can be an effective mitigation =
against
> Issue H, J, and K. It was my understanding that you propose - only =
when
> these hints are applied as if they are rules - safety can be achieved.
> But you now appear water down the applicability? Which is it?
>=20
> More importantly: already two different RP implementers recognized =
that
> "each RP implementation *will* have to apply limits" [9]. =
Unfortunately only
> one implementer took action so far. The problems you documented have =
to be
> solved irregardless of the existence of "Tree Hints", because an RP =
can't
> rely on Tree Hints being reasonable, or even existing.
>=20
> My suggestion would be everyone gets a move on and focuses on =
immediately
> resolving their issues, because at present H, J & K are not mitigated =
in
> multiple implemenations. Hint: accepting chains up to 32 long is =
ludicrous.
> After having implemented sane limits, implementers are likely to come =
to
> understand there is no need for "Tree Hints".=20
>=20
>> In the bandwidth example, if you are using FORT Validator then any=20
>> repository that does not manage 200KB/s is already excluded using the=20=

>> default configuration, thus that requirement is already in place in=20=

>> practice. The same applies to all limits mentioned in 6.2-6.8. The=20
>> main difference is that if included in Tree Hints, both parties know=20=

>> what "safe" values they can use, rather than having to keep up with=20=

>> all limits individual implementations impose.
>=20
> You correctly place "safe" between quotation marks. Merely labeling
> something "safe" does not intrincically make it "safe". Fun to read =
that
> FORT now doubles as a general purpose network speedtest. However, from =
there
> it doesn't follow that "the requirement is already in place in =
practise".
>=20
> I remain skeptical about your proposal, as I find its merit lacking.
>=20
> Kind regards,
>=20
> Job
>=20
> [1]:
> =
https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents=
/
> [2]: =
https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
> [3]: =
https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
> [4]: https://github.com/NLnetLabs/routinator/issues/274
> [5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
> [6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
> [7]: https://github.com/NLnetLabs/routinator/issues/365
> [8]: https://github.com/cloudflare/cfrpki/issues/66
> [9]:
> =
https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScAvjQ/=

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


From nobody Wed Nov 17 06:32:05 2021
Return-Path: <jeroen@massar.ch>
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 77F983A0D3A for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 06:32:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=massar.ch
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 Msf2RTgZAaK0 for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 06:31:59 -0800 (PST)
Received: from citadel.ch.unfix.org (citadel.ch.unfix.org [213.144.131.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FD03A0D36 for <sidrops@ietf.org>; Wed, 17 Nov 2021 06:31:57 -0800 (PST)
Received: from yomi.ch.unfix.org (adsl-130-212.dsl.init7.net [213.144.130.212]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen@massar.ch) by citadel.ch.unfix.org (Postfix) with ESMTPSA id 8DA3B22B056B9; Wed, 17 Nov 2021 14:31:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1637159513; bh=K9/iX+z624AGNEYyJ706FmCApgLotXwZDg1bTVRCLow=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GD14DuGIoEQdzXRwSYRlSTwxlAd+XwpIFIJmn8KKcfvsUMt/tD9lACJ0qR0+U+rVP X+TZXT7kR1sjPsf7m0HoWYh3/ttGsl8urjcHgMrfNZBE19u0Hxz71nf+56m58+1mMh +s0xbCjZjOSLh8XSHDa0x+5CFxU7l9Xfbx69t/NaM9MUXJCVvjV6GQvk1yHIhD6VFn fiqFpaTtY1w6ye+HrmewSjZN1FLyrJ3YHb/6P313eRSuAdmv5MMnPCktqeix8yXv4P B0Z6O/z6MKYW7Sze7dXUh5NG/spqrd/Wbilh/SHNjKsKTcBFOypLsuosTwhJ97odqL VPsEwk4hrSORw==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jeroen Massar <jeroen@massar.ch>
In-Reply-To: <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
Date: Wed, 17 Nov 2021 15:31:52 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <08548B4B-CAFE-4FBB-8F1C-5607944AB929@massar.ch>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2bU4pDyi50Gv_kbJcRXFzfDtR-I>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 14:32:04 -0000

Hi Koen et al,

I went through =
https://www.ietf.org/archive/id/draft-kwvanhove-sidrops-rpki-tree-hints-00=
.html and the major thing I am wondering is: which CA will even bother =
with this?

If you take a RIR, do you think they will define for each LIR how much a =
LIR can do, as it becomes rather hard to define who is 'big' and others =
who are 'small', especially as that can change on an hourly basis.

Just that classification will be tricky and very error-prone and quick =
to time out.

If we are talking NIRs in the APNIC region, do you think CNNIC (the =
Chinese NIR) wants to be regulated/limited that way at that level?
They definitely hold enough power to let APNIC configure anything, and =
so do many large corporations in the US.

What about CERNET, who run all the universities in China, their limit =
would have to be set very very large, APNIC won't know and even CNNIC =
would have a hard time guessing what CERNET will do.

Similar take a Google, Facebook, Comcast or even a one of many transit =
providers and their customers.


What if a LIR did not deploy much RPKI yet, then the number of objects =
will be low, while moments later they might automatically do it for all =
their prefixes it will explode going over the limits the CA set.


Thus a CAs limit's will either be too low and thus hurtful, or too high =
and useless.

Your proposal would also imply that every CA that implements limits =
would have to run an analysis of the complete tree to see if any limits =
might be tripped at one point or another. But, that would mean they have =
to do it from a variety of unknown vantage points, as a malicious CA =
would just return different data. But even if such a mechanism would =
exist, due to the rapidly changing of the internet, the limit might =
already be tripped before you realize, and if these are automated limit =
changes without verification, then what is the value: malicious CA =
slowly just adds objects so the CA automatically raises the limits.

The CA would thus also have to spend significant resources into =
verifying this.
Thus why would they bother being the shepard of that?

Thus your proposal means that very few will apply them, which will =
likely be in the wrong places.

Note also that in the largest PKI system we have in the world, the one =
from SSL/TLS, there are no such limits in place in the CA tree, even =
though there are billions of objects (https://ct.cloudflare.com, and no =
you don't easily run that checker yourself, requires a bit of decent =
hardware).
(RPKI is akin to Cert Transparency as one has to fetch all objects from =
a variety of untrusted locations and then parse them).


In the end, having the limits imposed by the software, means you are =
trusting the information of the vendor that you chose.

Fortunately you agree with that in the end of section 3:

"By using reasonable values at the top level, it can be assumed that the =
tree can be traversed in reasonable time, whilst keeping the flexibility =
of the tree structure as it is currently."

The complete top level is not the TAL, but the software, which you trust =
to have implemented code correctly (as they could circumvent any limit a =
TAL or CA would set).

This does imply, like many other systems, that the software has to be =
maintained. monitored and updated regularly (both vendor releases and =
people upgrading their systems), but hopefully for a system as important =
as RPKI people take care of it.


TLDR:
 - Letting the CAs define limits will be error prone or just won't =
happen, while it would require extra code with more possible failures.
 - Letting RP software that you control, configure, trust and update =
define these limits is a much more resilient and better approach.

Greets,
 Jeroen


From nobody Wed Nov 17 15:06:51 2021
Return-Path: <randy@psg.com>
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 29BF83A0824 for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 15:06:50 -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, 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 FVT8_ULeHhZv for <sidrops@ietfa.amsl.com>; Wed, 17 Nov 2021 15:06:47 -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 D806D3A0820 for <sidrops@ietf.org>; Wed, 17 Nov 2021 15:06:47 -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 <randy@psg.com>) id 1mnU0p-0006xn-U9 for sidrops@ietf.org; Wed, 17 Nov 2021 23:06:44 +0000
Date: Wed, 17 Nov 2021 15:06:43 -0800
Message-ID: <m2czmypekc.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <50B00643-684D-4012-933B-05557F4F02E6@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-2022-JP
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7IyqS8dXAXouYFLpCBdf86ac3MU>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 23:06:50 -0000

continuing my resistance to being dragged down this rathole ...  and my
penchant for metaphor

    "I think there is a world market for maybe five computers."
    Thomas Watson, president of IBM, 1943

along with simplicity, a major skill of protocol design is scale, both
horizontal and vertical.

    $B!H(BThe only real problem in the Internet is scaling$B!I(B
    Mike O$B!G(BDell (CTO UUNET)

and

    Ettore Bugatti, maker of the finest cars of his day, was once asked
    why his cars had less than perfect brakes.  He replied, "I make my
    cars to go, not to stop."

randy


From nobody Thu Nov 18 08:01:55 2021
Return-Path: <tim@nlnetlabs.nl>
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 EEE473A08F4 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 08:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 x3-X2H8w1reW for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 08:01:47 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 49D903A08ED for <sidrops@ietf.org>; Thu, 18 Nov 2021 08:01:46 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id F0B591E2; Thu, 18 Nov 2021 16:01:41 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1637251300; bh=zKEpJdZ2hNqLEdGLm0y3eqtOmk/n6BvK+lyrdCRFoIc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FYiT61Bw+k2EVgplFyb0vg/dJpw8KzB3E0bzcy8NEOhSk9L+P1g3oYRU41qiOFwPY BYjhNsfUo2flKDgXzNlFvFFHHXL9+0VFBZ4GlrdrERWVrmffJWcQnjUhZzcozA73Dz Qzu9rGAeuv8/wCzphhnMD9evFjoKIfpJaKiTE3V/jlQDYsKO/nKaalOtiU/WWPk2yQ /+m+ZvEb3fz8kkWVRp3e18XnyR7dice+Zl73iR1uPxsisVkh36IQ1kAxRfJILE/5ql 8a59eo0y/vdxVOZi/EkZJtXar/IbWTXnllLJJKrWHOuAtzG/teOxmXjAL4Mo5QQOFJ Q579ZkUZVrT3A==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <20211111174823.lpt5t4yctroxtb4c@benm-laptop>
Date: Thu, 18 Nov 2021 17:01:36 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0D86237-3F8E-4118-85E4-E669DEB07B2D@nlnetlabs.nl>
References: <4427CFCB-D170-4B25-A5C3-E5614F04BACD@nlnetlabs.nl> <20211111174823.lpt5t4yctroxtb4c@benm-laptop>
To: Ben Maddison <benm@workonline.africa>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/m8odVMOTEAZAdsCX6Qg6GJM4Dzw>
Subject: Re: [Sidrops] Experimental ASPA object published in testbed
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 16:01:53 -0000

Hi,

in-line

> On 11 Nov 2021, at 18:48, Ben Maddison <benm@workonline.africa> wrote:
>=20
> Hi all,
>=20
> On 11/05, Tim Bruijnzeels wrote:
>> Dear all,
>>=20
>> It's not my habit to announce new Krill releases here, but... we =
added
>> experimental ASPA support to the new release candidate (0.9.3-rc2).
>>=20
>> We are running this version in our acceptance environment as a child =
under
>> the RIPE NCC Test environment:
>>=20
>> =
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-tes=
t-environment
>>=20
>> We have created an ASPA object, based on the latest proposed profile =
on
>> the list, at the following location:
>>=20
>> rsync://rsync.accept.krill.cloud/repo/accept/0/AS211321.asa
>>=20
> This object can be successfully decoded by rpkimancer-aspa (using the
> "tim-revised-profile" branch), using the following ASN.1 module:
>=20
>    RPKI-ASPA-2020
>      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2020(TBD) }
>=20
>    DEFINITIONS IMPLICIT TAGS ::=3D
>    BEGIN
>    IMPORTS
>=20
>    CONTENT-TYPE
>    FROM CryptographicMessageSyntax-2010  -- RFC 6268
>        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>          pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
>=20
>    ContentSet CONTENT-TYPE ::=3D { ct-ASPA, ... }
>=20
>    --
>    -- ASPA Content Type
>    --
>=20
>    id-smime OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)
>         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
>=20
>    id-ct OBJECT IDENTIFIER ::=3D { id-smime 1 }
>=20
>    id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct 49 }
>=20
>    ct-ASPA CONTENT-TYPE ::=3D
>        { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA }
>=20
>    ASProviderAttestation ::=3D SEQUENCE {
>      version [0]   ASPAVersion DEFAULT v0,
>      customerASID  ASID,
>      providers     ProviderASSet
>    }
>=20
>    ASPAVersion ::=3D INTEGER  { v0(0) }
>=20
>    ProviderASSet ::=3D SEQUENCE (SIZE(1..MAX)) OF ProviderAS
>=20
>    ProviderAS ::=3D SEQUENCE {
>      providerASID  ASID,
>      afiLimit      AddressFamilyIdentifier OPTIONAL
>    }
>=20
>    ASID ::=3D INTEGER
>=20
>    AddressFamilyIdentifier ::=3D OCTET STRING (SIZE (2))
>=20
>    END
>=20
> There are several issues I have with this module, most of which have
> been discussed previously. It would be great to finish off the
> discussion on these so that implementations can stabilise:
>=20
> 1.  Should we keep the enumerations of ASPAVersion, or use a simple
>    INTEGER?
>    My preference is the latter.

I have no strong preference - as it amounts to the same on the wire.

> 2.  Should we keep the "AS0" method of asserting transit-free-ness, or
>    use an empty SEQUENCE OF?
>    Again, my preference is the latter.

I have a slight preference for the latter, because I like explicit. But,
in the end what is important is that it's well understood.

If the empty list is used, then it may be needed to cover this case more
explicitly in validation. =10As in: an explicit empty list would be =
different
from no ASPA exists for the customer AS. This may also impact 8210-bis.

In that sense AS0 as the only provider, where AS0 cannot naturally occur
in the wild as a real AS, may allow for an easier validation algorithm - =
similar
to how things are done with ROAs and AS0 as the only ROA for a given =
prefix.

I realise this seemingly contradicts what I said about preferring =
explicit,
but what I am trying to say is.. given the impact on other documents I =
can
live with either.

It would be good to hear what others think.

> 3.  Should AddressFamilyIdentifier be defined as SIZE(2) (as above), =
or
>    SIZE(2..3) for consistency with 3779?
>    I think that the current definition is preferable.

I agree. In the end the possible values are restricted, so 2-3 always =
results
in 2 because only 00 01 (v4) and 00 02 (v6) are allowed. But it takes =
more
parsing of text by RP implementers.

>=20
> 4.  (New, I think) The ContentSet information object set definition =
does
>    not seem to serve any useful purpose.
>    I assume the intention is to "extend" the ContentSet defined in
>    CryptographicMessageSyntax-2010, but I don't believe that is what
>    the above construction means.
>    Russ, I think your input is necessary here.
>=20
> Cheers,
>=20
> Ben


From nobody Thu Nov 18 09:16:34 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 E5FBD3A064A for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:16:27 -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, 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=student.utwente.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 zy4WKmamg6Ge for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:16:22 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 1927C3A05A9 for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:16:21 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id z5so30261164edd.3 for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=lXHn0XiEbyvxJzX9FIzeGJCu/ORVSbX3D8TutGVMxOg=; b=mKEfIUIr6oA0kNKga3pvwDUxXqNTP84JC0Ci3WiCWsrpnovpO4SPO+ox/g7gXtoOdD Fh8TzlYMmnZm2JbITYSSyv7EFxZXPu79O7XzHn/kYZXDoyiEY1Z3BkBJi1AbggXeAFfW lBlOt9j1Rp04tFkedTa+R4ViNsJhol3zXlTI/FNzIruFeqUiLSzVp+L8ijx6aLQTKWDd P1VqWI9kS7xQot+1yTycBoXhKOU2etAqytijcOLPcHbmSZQG8I/nH/t9wKFfccVHYJT3 dLa6rYH9M23F9TfNfKXqEWG5lXO16M5rIKjF4n5e7W+eTdF0zg6wvZ2nozFRAsB+dEnn aDUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lXHn0XiEbyvxJzX9FIzeGJCu/ORVSbX3D8TutGVMxOg=; b=PqVAYsHSHtX71RSuYwvpUXz1VxmQ0T/2sGyPPg/y3Kb4jd00QtvioOyDAiQsMlADqj kITPkngZiqdgw9HwCucxqVcphWAF+OSCl+9QAGyMJHfc8Hclq+XUGLh/yLV2gSpy93pR XQN5qdLY3Y4tGotNSpFFjdwT3/xsOQPv3sII8nkCFUw6+yLlow/v8pl39qGBli04Bw/f 8ubjRm65mzP8sKFkGOT5yr2YEuO1do6K1wNECUjFzVNT58BjfCZVkJ9yl6c3j9HZjnfx KnUvaEu5Cr0tvUPdBlRu63Nwi91v7/9J6++4GEm6y5+jjpOBMFjQFo+C7l5EzOMUr6bf SuNg==
X-Gm-Message-State: AOAM5331kBO0zsytyRUrXgVaCmYm7yX5ds9Pp2tN61HsMNFkHF1+W3Pp uVHdZBCBbqYMw3qPAMeToHHKr2ugpTLTYg==
X-Google-Smtp-Source: ABdhPJwwTFpTQVPeP0y/bsWo9RUsLct/L3GJ/NyGf5jyJQpKu4D97+aYEeVyhHxOA5oYgC8pL16TOQ==
X-Received: by 2002:a50:e0c9:: with SMTP id j9mr13776779edl.336.1637255775072;  Thu, 18 Nov 2021 09:16:15 -0800 (PST)
Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id r13sm225986edo.71.2021.11.18.09.16.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Nov 2021 09:16:14 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'Mikhail Puzanov'" <mpuzanov@ripe.net>
Cc: <sidrops@ietf.org>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net>
In-Reply-To: <50B00643-684D-4012-933B-05557F4F02E6@ripe.net>
Date: Thu, 18 Nov 2021 18:16:13 +0100
Message-ID: <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG7WjUlhTlYjtt+Vnt4JWaZods+RgIeKrurAcOeePcA3cZsDgIi3ifjAuakxugBOwv/Z6vqNC8w
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/iAD7aOQMLKRn7ZprxV4mhYc2i0k>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 17:16:33 -0000

Dear Misha, all,

Regarding point 1: I believe that is a good idea, although I am not sure =
whether this draft is necessarily the right place for it. RFC 6486 and =
6487 may be more suitable for it, or as its own RFC, especially as it =
might be a (fast) moving target.=20

Regarding point 2: Regarding the limits themselves: I would expect that =
a general limit would work for 99% in practice. For there where it does =
not work currently, an exception can be made, by opening a ticket, =
making a call, sending a facsimile, or whatever the conventional way is =
to reach your CA. The legal aspect is an interesting one. Perhaps =
someone else could provide more insight into this? I would assume they =
already have the means (from a policy perspective) to revoke the =
certificate for abuse, and that this would be an extension to that =
policy.=20

Koen van Hove

-----Oorspronkelijk bericht-----
Van: Mikhail Puzanov <mpuzanov@ripe.net>=20
Verzonden: woensdag 17 november 2021 13:42
Aan: Koen van Hove <k.w.vanhove@student.utwente.nl>
CC: sidrops@ietf.org
Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key =
Infrastructure (RPKI)

Hi Koen, all

I would like to add my 2 cents about the draft.

1) Some sort of limits will have to be forced in RPs regardless of "Tree =
Hints=E2=80=9D implemented or not since an RP can not rely on these =
hints always present. I would imagine that a reasonable RP =
implementation uses some default limits and policies and adjusts them =
according with the hint objects if it finds them on a manifest. From =
that viewpoint the draft would benefit from  describing these default =
limits and, probably, the approaches to enforcing them.

Something along the lines of "RP SHOULD traverse the CA tree in such a =
way that a malicious CA/repository does not stop well-behaving CA to be =
processed=E2=80=9D=20
or =E2=80=9CRP MUST set a timeout on TA tree processing and SHOULD =
process all the CAs that fit into this timeout even if the whole tree =
does not finish in time=E2=80=9D=20
would make it more solid.

It may be, of course, that it is better to mention these RP limits in =
RFC 6486 and 6487 and refer from this draft.

Setting such hard limits would automatically impose a lot of constraints =
on RP implementation such as using timeouts pretty much everywhere, =
limiting CPU time and memory allocations on some per-subtree basis, =
running concurrent processes instead of sequential processing, etc.=20

I can imagine that it probably was not your intention when writing this =
draft, just want to point out that every RP-implementor has to answer =
the question =E2=80=9Cwhat do I do if there are no hint =
objects?=E2=80=9D so some solid ground needs be set here first before =
starting to use these hints.


2) I have a feeling that it is not very easy to implement the backend =
part of it, for non-technical reasons. How does, for example, RIPE NCC =
set these limits, based on what? Some reasonable default for everybody? =
But then it can still be too low or too high for a particular CA/NIR. =
Does it imply some sort of application procedure when an LIR says =
=E2=80=9CI am planning to have a child CA and not more than 100 =
ROAs=E2=80=9D? I have a hunch that there are legal implications to this, =
so RIRs need to change their disclaimers, CPS, even contracts(?) in =
order to incorporate something like =E2=80=9CBy setting this checkbox =
you agree to get you CA revoked if you (or any of your child CAs) =
publish more than 1GB of objects=E2=80=9D.=20

Legal issues, of course, should not be your concern when proposing a =
technical draft, but if the draft goes on, this topic will pop up a lot =
and maybe it would make sense to add something about realistically =
setting these hints to the draft or at least have a more detailed =
discussion about it.

--
Misha



> On 16 Nov 2021, at 19:00, Koen van Hove =
<k.w.vanhove@student.utwente.nl> wrote:
>=20
> Dear Job, all,
>=20
> I am afraid I do not quite follow you. Could you clarify what you=20
> meant by "fatally flawed"? What merit is lacking?
>=20
> For those unaware, I have been looking into the question "Can I=20
> disrupt RPKI RP software by introducing a malicious CA/repository into =

> the tree?". A summary of what I tested can be found here:
> https://labs.ripe.net/author/koen-van-hove/improving-the-resiliency-of
> -rpki- relying-party-software/, but the long story short is that CAs=20
> and repositories can attempt to use malicious behaviour (e.g.,=20
> creating many
> descendants) to make RP software take unreasonably long to process. To =

> back this up, I created proof of concepts, which have the letters A to =

> O. Using heuristics to exclude the malicious nodes without collateral=20
> damage (ergo also excluding non-malicious nodes) is difficult, if not=20
> impossible. The Tree Hints draft is a proposal to solve this issue, by =

> providing the RP software the information it needs to determine when a =
node is malicious.
>=20
>> My suggestion would be everyone gets a move on and focuses on=20
>> immediately
> resolving their issues, because at present H, J & K are not mitigated=20
> in multiple implemenations. Hint: accepting chains up to 32 long is =
ludicrous.
> After having implemented sane limits, implementers are likely to come=20
> to understand there is no need for "Tree Hints".
>=20
> Sane limits would be great - I am just not sure whether there are=20
> static limits that exclude malicious nodes without also excluding=20
> non-malicious nodes, and that can ensure that the RP software can=20
> continue working as it should within a reasonable timeframe. Feel free =

> to propose sane limits, then I will run the numbers to see if that=20
> effectively solves the problem. I have already done so for the limits=20
> posted in the RPKI fencing thread and shown that they do not suffice=20
> to effectively stop the attack, as well as possibly causing collateral =

> damage, but I am happy to run the numbers again for any other =
proposals you may have.
>=20
> The problem still exists and is in need for a solution. Tree Hints can =

> be a solution, but I invite you to come up with a different solution=20
> to solve this problem. Then I will try to find out if an attacker can=20
> find a way around those limits.
>=20
> Koen van Hove
>=20
> -----Oorspronkelijk bericht-----
> Van: 'Job Snijders' <job@fastly.com>
> Verzonden: maandag 15 november 2021 16:39
> Aan: sidrops@ietf.org
> Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key=20
> Infrastructure (RPKI)
>=20
> On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
>> Before submitting the draft, I consulted several RP software=20
>> developers whether they considered it feasible to implement
>=20
> I question the soundness of your consultation, knowing that "Several=20
> RP software developers" also failed to understand the purpose of RPKI=20
> manifests [1], needed a year and lots of hand-holding to recognize the =

> true situation ([2] -> [3]); or happily violated CA intent by ignoring =

> missing CRLs and CRL staleness [4], [5]; or failed to see an issue=20
> with certificate malleability [6], [7], [8].
>=20
> How can this be explained? Groupthink is a psychological phenomenon=20
> that can occur within groups of people in which the desire for=20
> conformity results in an irrational or dysfunctional decision-making=20
> outcome. Or perhaps it is lack of ever experiencing consequences, who=20
> knows! :-)
>=20
> For everyone's amusement:=20
> https://sobornost.net/~job/should_vs_must.jpg
>=20
>> To show how the maxDescendants works in practice, as per Ties'
>> suggestion, I created a little model in Python, which can be found
>> here:=20
>> https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
>> It creates DOT graphs for each step, so you can see how an RP could=20
>> process tree hints in the case of maxDescendants - other limits can=20
>> be implemented in similar fashion.
>=20
> It seems you implemented something that takes a Python dictionary and=20
> outputs a DOT graph. This is not the same as ingesting potentially=20
> hostile data from an untrusted network input, parsing the data=20
> according to the
> X.509 and RPKI specifications, building validation paths, and=20
> generating a set of validated ROA payloads.
>=20
> It also should be recognize that "maxDescendants set to zero" is the=20
> same as "pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
> This begs the question, why is pathLenConstraint not used in the RPKI?
> Was it an oversight? Or was it recognized that pathLenConstraint is=20
> not a security feature, but rather a "product differentiator"? I=20
> consider maxDescendants to be in the latter category.
>=20
>> There are some open questions, mainly: how does a parent inform a=20
>> child of what their limits are? And what if those limits change
>> (especially: become stricter)? How and when do these limits change?
>=20
> Great questions indeed. Perhaps the parent can inform the child by=20
> sending an invoice, and only adjust limits after having received =
payment?
>=20
>> More generally, I want to point out that these are Tree *Hints*, not=20
>> Tree Rules.
>=20
> Interesting how a set of 'hints' can be an effective mitigation=20
> against Issue H, J, and K. It was my understanding that you propose -=20
> only when these hints are applied as if they are rules - safety can be =
achieved.
> But you now appear water down the applicability? Which is it?
>=20
> More importantly: already two different RP implementers recognized=20
> that "each RP implementation *will* have to apply limits" [9].=20
> Unfortunately only one implementer took action so far. The problems=20
> you documented have to be solved irregardless of the existence of=20
> "Tree Hints", because an RP can't rely on Tree Hints being reasonable, =
or even existing.
>=20
> My suggestion would be everyone gets a move on and focuses on=20
> immediately resolving their issues, because at present H, J & K are=20
> not mitigated in multiple implemenations. Hint: accepting chains up to =
32 long is ludicrous.
> After having implemented sane limits, implementers are likely to come=20
> to understand there is no need for "Tree Hints".
>=20
>> In the bandwidth example, if you are using FORT Validator then any=20
>> repository that does not manage 200KB/s is already excluded using the =

>> default configuration, thus that requirement is already in place in=20
>> practice. The same applies to all limits mentioned in 6.2-6.8. The=20
>> main difference is that if included in Tree Hints, both parties know=20
>> what "safe" values they can use, rather than having to keep up with=20
>> all limits individual implementations impose.
>=20
> You correctly place "safe" between quotation marks. Merely labeling=20
> something "safe" does not intrincically make it "safe". Fun to read=20
> that FORT now doubles as a general purpose network speedtest. However, =

> from there it doesn't follow that "the requirement is already in place =
in practise".
>=20
> I remain skeptical about your proposal, as I find its merit lacking.
>=20
> Kind regards,
>=20
> Job
>=20
> [1]:
> https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-cont
> ents/
> [2]:=20
> https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
> [3]:=20
> https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
> [4]: https://github.com/NLnetLabs/routinator/issues/274
> [5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
> [6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
> [7]: https://github.com/NLnetLabs/routinator/issues/365
> [8]: https://github.com/cloudflare/cfrpki/issues/66
> [9]:
> https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScA
> vjQ/
>=20
>=20
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops



From nobody Thu Nov 18 09:18:25 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 2298C3A0656 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:18:23 -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, 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=student.utwente.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 GFhbYdD8_It4 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:18:16 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 74C0C3A0650 for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:18:16 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id g14so30209899edb.8 for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:18:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=C24DYFnpObyXTd0UHp02o8DaIk4Z1mHSDE3bCl64S4k=; b=Simuuovz+FayzidrNu2aJ/Bjuim/Q8zuA4tI0kefbgfny+rpn1kRs0YHl5gJkOJJ23 cHFNy0c+cRf+hjO+qAkVZwldALHRPxHn6MdsPHsj2nxvsTqMJm1ZnfQySm4rDza8Ey5N 2FYitgFitpfxMDPklzCp0OwnaNx/SMj+/oUW61qcuobFuKc4sizRPTIehhZOVD05Ikaa unD+r2d3I4mjBBay4dE48ZXm0kpar0qf+wn/PVPryNMy/APHdJDnB+xv8y+FgDgC7Bq4 2z0JSb/Fpfvau5ABToeSF6DMT5xBjGtUiVwtO71n20y3yKoVdNpbhKk3Sj56nMjuOvuT qXqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=C24DYFnpObyXTd0UHp02o8DaIk4Z1mHSDE3bCl64S4k=; b=bks11+ikdSDmwbGSbQaTz3Buwo0BAwxE9W5jnos5pR8Ejb2yf56/bxwE0IaSOhSCNH A2rSuWMvWOXFypLB1GH1qixxNQl6QOPwZna+v9hvHTGeuzSLJJJfbXLPF7ptjKUl32UN QFClYAh6Rc48r2vk46qnwWB0LSu8o+mdYZd69J5O4X7zaoREuMwVN5QDvWiGjmF6fE2i auwDayd+10+538gHROonMRvlwYjA8vru74TrWoB4DDvO9hxFwOLkgWcNcvX1MCdtrg6f jbK/l5ZIdqVO07gWhQi7Vys4GVjEwAu5eIqiR+d3Vn1P+gXf4JCRciM6yGTfsiZCTt0t Mi+w==
X-Gm-Message-State: AOAM533btQ33Oe4kwzNjxBBQURHL2cm25eZH+nJEqu6BzOm673p1/E30 sxyvK4TIzkKH+bdIJEX9+E5Ucp85Q5EUcQ==
X-Google-Smtp-Source: ABdhPJyFBZm3U/+4WV25X3fwDBYTPrmGeoxKdjisbYZ8LbL+P+VmJnrr9hOuX1IUKt9ClEf5Sw9rFQ==
X-Received: by 2002:aa7:d748:: with SMTP id a8mr13384082eds.21.1637255893109;  Thu, 18 Nov 2021 09:18:13 -0800 (PST)
Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id t6sm250463edj.27.2021.11.18.09.18.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Nov 2021 09:18:12 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'Jeroen Massar'" <jeroen@massar.ch>
Cc: <sidrops@ietf.org>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <08548B4B-CAFE-4FBB-8F1C-5607944AB929@massar.ch>
In-Reply-To: <08548B4B-CAFE-4FBB-8F1C-5607944AB929@massar.ch>
Date: Thu, 18 Nov 2021 18:18:11 +0100
Message-ID: <002801d7dca0$43c68240$cb5386c0$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG7WjUlhTlYjtt+Vnt4JWaZods+RgIeKrurAcOeePcA3cZsDgIi3ifjAuakxugBOxkN66vqOnHg
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/NxXkWnOhlL-vCjzTAyFdaK1--_E>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 17:18:23 -0000

Dear Jeroen, all,

The cases you name are a great example of why I believe heuristics are
difficult. I am not claiming the politics will be easy. To take your example
of APNIC and CNNIC: there is already some relation between the two (APNIC
signed the certificate of CNNIC), thus they can also create an exception for
CNNIC in the Tree Hints to allow them to use a "very large number" (I do not
believe ASN.1 integers support infinity, but operationally it would be
equivalent) to bypass them entirely. From a security perspective this may
not be the wisest, but it may be a political compromise.

Regarding having to ask your parent for more resources: I do not think this
is an issue, rather, I think this is a feature. The "a CAs limit's will
either be too low and thus hurtful, or too high and useless." is the same
problem RP software faces, or at least their operators face. How this
process of requesting more resources is shaped is outside the scope of Tree
Hints.

The alternative seems to be that the RP software decides these limits
instead, and if then a small LIR suddenly creates a lot of objects, it must
wait for everyone to update their RP software for it to work. I am not sure
whether that is a better compromise. I do as well hope that people regularly
update their RPKI software, but that unfortunately does not seem to be the
case.

Koen van Hove

-----Oorspronkelijk bericht-----
Van: Jeroen Massar <jeroen@massar.ch> 
Verzonden: woensdag 17 november 2021 15:32
Aan: Koen van Hove <k.w.vanhove@student.utwente.nl>
CC: sidrops@ietf.org
Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key
Infrastructure (RPKI)

Hi Koen et al,

I went through
https://www.ietf.org/archive/id/draft-kwvanhove-sidrops-rpki-tree-hints-00.h
tml and the major thing I am wondering is: which CA will even bother with
this?

If you take a RIR, do you think they will define for each LIR how much a LIR
can do, as it becomes rather hard to define who is 'big' and others who are
'small', especially as that can change on an hourly basis.

Just that classification will be tricky and very error-prone and quick to
time out.

If we are talking NIRs in the APNIC region, do you think CNNIC (the Chinese
NIR) wants to be regulated/limited that way at that level?
They definitely hold enough power to let APNIC configure anything, and so do
many large corporations in the US.

What about CERNET, who run all the universities in China, their limit would
have to be set very very large, APNIC won't know and even CNNIC would have a
hard time guessing what CERNET will do.

Similar take a Google, Facebook, Comcast or even a one of many transit
providers and their customers.


What if a LIR did not deploy much RPKI yet, then the number of objects will
be low, while moments later they might automatically do it for all their
prefixes it will explode going over the limits the CA set.


Thus a CAs limit's will either be too low and thus hurtful, or too high and
useless.

Your proposal would also imply that every CA that implements limits would
have to run an analysis of the complete tree to see if any limits might be
tripped at one point or another. But, that would mean they have to do it
from a variety of unknown vantage points, as a malicious CA would just
return different data. But even if such a mechanism would exist, due to the
rapidly changing of the internet, the limit might already be tripped before
you realize, and if these are automated limit changes without verification,
then what is the value: malicious CA slowly just adds objects so the CA
automatically raises the limits.

The CA would thus also have to spend significant resources into verifying
this.
Thus why would they bother being the shepard of that?

Thus your proposal means that very few will apply them, which will likely be
in the wrong places.

Note also that in the largest PKI system we have in the world, the one from
SSL/TLS, there are no such limits in place in the CA tree, even though there
are billions of objects (https://ct.cloudflare.com, and no you don't easily
run that checker yourself, requires a bit of decent hardware).
(RPKI is akin to Cert Transparency as one has to fetch all objects from a
variety of untrusted locations and then parse them).


In the end, having the limits imposed by the software, means you are
trusting the information of the vendor that you chose.

Fortunately you agree with that in the end of section 3:

"By using reasonable values at the top level, it can be assumed that the
tree can be traversed in reasonable time, whilst keeping the flexibility of
the tree structure as it is currently."

The complete top level is not the TAL, but the software, which you trust to
have implemented code correctly (as they could circumvent any limit a TAL or
CA would set).

This does imply, like many other systems, that the software has to be
maintained. monitored and updated regularly (both vendor releases and people
upgrading their systems), but hopefully for a system as important as RPKI
people take care of it.


TLDR:
 - Letting the CAs define limits will be error prone or just won't happen,
while it would require extra code with more possible failures.
 - Letting RP software that you control, configure, trust and update define
these limits is a much more resilient and better approach.

Greets,
 Jeroen



From nobody Thu Nov 18 09:49:26 2021
Return-Path: <alex@nlnetlabs.nl>
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 8FEA13A0913 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 SxM4wn65VV49 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:49:19 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 203873A090B for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:49:18 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 3BA2D3D9; Thu, 18 Nov 2021 17:49:12 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1637257751; bh=dU+ZvIiXBjj2uOQBO0lItyLbjrsIvDeCNBovdtZw+rA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=h29apyTUiz8xz98UNe5J9AjfmMUnIykubbXDhMdtxZwYScjbxFOLWI8E2iEvOhCmG tF8aSH3UOdNYwHFHMZg9Rj27PAex3jKa5xoAX6B0jZy/aVYwDB2a0ReDR3GCX/WKuI zWnwQPXMWTaBk06vXj64AzsWK/w14RTGR2nHmLuK4f51rWcaYMEHi8ewqjvBcTOdiX ays9pnszEz74Cs2th61w1KEwJR+N/XZVo07vx6sTZxCiVKimCpyEJXlNtpxokBKMLG z4nEPawr9Usw6gZ36oxVk7NEgD5YjrZJkD0Pc4ChAMX4hX8HD46T1VFOhw6+IlTCBj m+gflhsSjYZbQ==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Alex Band <alex@nlnetlabs.nl>
In-Reply-To: <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
Date: Thu, 18 Nov 2021 18:49:07 +0100
Cc: Mikhail Puzanov <mpuzanov@ripe.net>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F6FE177-0485-4FCD-9AB0-AA1A13F41323@nlnetlabs.nl>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/SZItFAYyR1h9highhRS0UAJfeMM>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 17:49:25 -0000

Hi Koen,

> On 18 Nov 2021, at 18:16, Koen van Hove =
<k.w.vanhove@student.utwente.nl> wrote:
>=20
> Dear Misha, all,
>=20
> Regarding point 1: I believe that is a good idea, although I am not =
sure whether this draft is necessarily the right place for it. RFC 6486 =
and 6487 may be more suitable for it, or as its own RFC, especially as =
it might be a (fast) moving target.=20
>=20
> Regarding point 2: Regarding the limits themselves: I would expect =
that a general limit would work for 99% in practice. For there where it =
does not work currently, an exception can be made, by opening a ticket, =
making a call, sending a facsimile, or whatever the conventional way is =
to reach your CA. The legal aspect is an interesting one. Perhaps =
someone else could provide more insight into this? I would assume they =
already have the means (from a policy perspective) to revoke the =
certificate for abuse, and that this would be an extension to that =
policy.=20

Taking the RIPE NCC as an example, I=E2=80=99m sure there are some =
interesting things to be found in the two sets of Terms and Conditions =
they have for this.

The RPKI service itself:
=
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ri=
pe-ncc-certification-service-terms-and-conditions

The repository:
=
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ri=
pe-ncc-certification-repository-terms-and-conditions

-Alex


>=20
> Koen van Hove
>=20
> -----Oorspronkelijk bericht-----
> Van: Mikhail Puzanov <mpuzanov@ripe.net>=20
> Verzonden: woensdag 17 november 2021 13:42
> Aan: Koen van Hove <k.w.vanhove@student.utwente.nl>
> CC: sidrops@ietf.org
> Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key =
Infrastructure (RPKI)
>=20
> Hi Koen, all
>=20
> I would like to add my 2 cents about the draft.
>=20
> 1) Some sort of limits will have to be forced in RPs regardless of =
"Tree Hints=E2=80=9D implemented or not since an RP can not rely on =
these hints always present. I would imagine that a reasonable RP =
implementation uses some default limits and policies and adjusts them =
according with the hint objects if it finds them on a manifest. =46rom =
that viewpoint the draft would benefit from  describing these default =
limits and, probably, the approaches to enforcing them.
>=20
> Something along the lines of "RP SHOULD traverse the CA tree in such a =
way that a malicious CA/repository does not stop well-behaving CA to be =
processed=E2=80=9D=20
> or =E2=80=9CRP MUST set a timeout on TA tree processing and SHOULD =
process all the CAs that fit into this timeout even if the whole tree =
does not finish in time=E2=80=9D=20
> would make it more solid.
>=20
> It may be, of course, that it is better to mention these RP limits in =
RFC 6486 and 6487 and refer from this draft.
>=20
> Setting such hard limits would automatically impose a lot of =
constraints on RP implementation such as using timeouts pretty much =
everywhere, limiting CPU time and memory allocations on some per-subtree =
basis, running concurrent processes instead of sequential processing, =
etc.=20
>=20
> I can imagine that it probably was not your intention when writing =
this draft, just want to point out that every RP-implementor has to =
answer the question =E2=80=9Cwhat do I do if there are no hint =
objects?=E2=80=9D so some solid ground needs be set here first before =
starting to use these hints.
>=20
>=20
> 2) I have a feeling that it is not very easy to implement the backend =
part of it, for non-technical reasons. How does, for example, RIPE NCC =
set these limits, based on what? Some reasonable default for everybody? =
But then it can still be too low or too high for a particular CA/NIR. =
Does it imply some sort of application procedure when an LIR says =E2=80=9C=
I am planning to have a child CA and not more than 100 ROAs=E2=80=9D? I =
have a hunch that there are legal implications to this, so RIRs need to =
change their disclaimers, CPS, even contracts(?) in order to incorporate =
something like =E2=80=9CBy setting this checkbox you agree to get you CA =
revoked if you (or any of your child CAs) publish more than 1GB of =
objects=E2=80=9D.=20
>=20
> Legal issues, of course, should not be your concern when proposing a =
technical draft, but if the draft goes on, this topic will pop up a lot =
and maybe it would make sense to add something about realistically =
setting these hints to the draft or at least have a more detailed =
discussion about it.
>=20
> --
> Misha
>=20
>=20
>=20
>> On 16 Nov 2021, at 19:00, Koen van Hove =
<k.w.vanhove@student.utwente.nl> wrote:
>>=20
>> Dear Job, all,
>>=20
>> I am afraid I do not quite follow you. Could you clarify what you=20
>> meant by "fatally flawed"? What merit is lacking?
>>=20
>> For those unaware, I have been looking into the question "Can I=20
>> disrupt RPKI RP software by introducing a malicious CA/repository =
into=20
>> the tree?". A summary of what I tested can be found here:
>> =
https://labs.ripe.net/author/koen-van-hove/improving-the-resiliency-of
>> -rpki- relying-party-software/, but the long story short is that CAs=20=

>> and repositories can attempt to use malicious behaviour (e.g.,=20
>> creating many
>> descendants) to make RP software take unreasonably long to process. =
To=20
>> back this up, I created proof of concepts, which have the letters A =
to=20
>> O. Using heuristics to exclude the malicious nodes without collateral=20=

>> damage (ergo also excluding non-malicious nodes) is difficult, if not=20=

>> impossible. The Tree Hints draft is a proposal to solve this issue, =
by=20
>> providing the RP software the information it needs to determine when =
a node is malicious.
>>=20
>>> My suggestion would be everyone gets a move on and focuses on=20
>>> immediately
>> resolving their issues, because at present H, J & K are not mitigated=20=

>> in multiple implemenations. Hint: accepting chains up to 32 long is =
ludicrous.
>> After having implemented sane limits, implementers are likely to come=20=

>> to understand there is no need for "Tree Hints".
>>=20
>> Sane limits would be great - I am just not sure whether there are=20
>> static limits that exclude malicious nodes without also excluding=20
>> non-malicious nodes, and that can ensure that the RP software can=20
>> continue working as it should within a reasonable timeframe. Feel =
free=20
>> to propose sane limits, then I will run the numbers to see if that=20
>> effectively solves the problem. I have already done so for the limits=20=

>> posted in the RPKI fencing thread and shown that they do not suffice=20=

>> to effectively stop the attack, as well as possibly causing =
collateral=20
>> damage, but I am happy to run the numbers again for any other =
proposals you may have.
>>=20
>> The problem still exists and is in need for a solution. Tree Hints =
can=20
>> be a solution, but I invite you to come up with a different solution=20=

>> to solve this problem. Then I will try to find out if an attacker can=20=

>> find a way around those limits.
>>=20
>> Koen van Hove
>>=20
>> -----Oorspronkelijk bericht-----
>> Van: 'Job Snijders' <job@fastly.com>
>> Verzonden: maandag 15 november 2021 16:39
>> Aan: sidrops@ietf.org
>> Onderwerp: Re: [Sidrops] Tree Hints for the Resource Public Key=20
>> Infrastructure (RPKI)
>>=20
>> On Sat, Nov 13, 2021 at 03:09:56PM +0100, Koen van Hove wrote:
>>> Before submitting the draft, I consulted several RP software=20
>>> developers whether they considered it feasible to implement
>>=20
>> I question the soundness of your consultation, knowing that "Several=20=

>> RP software developers" also failed to understand the purpose of RPKI=20=

>> manifests [1], needed a year and lots of hand-holding to recognize =
the=20
>> true situation ([2] -> [3]); or happily violated CA intent by =
ignoring=20
>> missing CRLs and CRL staleness [4], [5]; or failed to see an issue=20
>> with certificate malleability [6], [7], [8].
>>=20
>> How can this be explained? Groupthink is a psychological phenomenon=20=

>> that can occur within groups of people in which the desire for=20
>> conformity results in an irrational or dysfunctional decision-making=20=

>> outcome. Or perhaps it is lack of ever experiencing consequences, who=20=

>> knows! :-)
>>=20
>> For everyone's amusement:=20
>> https://sobornost.net/~job/should_vs_must.jpg
>>=20
>>> To show how the maxDescendants works in practice, as per Ties'
>>> suggestion, I created a little model in Python, which can be found
>>> here:=20
>>> https://gist.github.com/Koenvh1/49c7fdaeb042fdcc9dd189f03348fd19
>>> It creates DOT graphs for each step, so you can see how an RP could=20=

>>> process tree hints in the case of maxDescendants - other limits can=20=

>>> be implemented in similar fashion.
>>=20
>> It seems you implemented something that takes a Python dictionary and=20=

>> outputs a DOT graph. This is not the same as ingesting potentially=20
>> hostile data from an untrusted network input, parsing the data=20
>> according to the
>> X.509 and RPKI specifications, building validation paths, and=20
>> generating a set of validated ROA payloads.
>>=20
>> It also should be recognize that "maxDescendants set to zero" is the=20=

>> same as "pathLenConstraint set to zero" (RFC 5280 Section 4.2.1.9).
>> This begs the question, why is pathLenConstraint not used in the =
RPKI?
>> Was it an oversight? Or was it recognized that pathLenConstraint is=20=

>> not a security feature, but rather a "product differentiator"? I=20
>> consider maxDescendants to be in the latter category.
>>=20
>>> There are some open questions, mainly: how does a parent inform a=20
>>> child of what their limits are? And what if those limits change
>>> (especially: become stricter)? How and when do these limits change?
>>=20
>> Great questions indeed. Perhaps the parent can inform the child by=20
>> sending an invoice, and only adjust limits after having received =
payment?
>>=20
>>> More generally, I want to point out that these are Tree *Hints*, not=20=

>>> Tree Rules.
>>=20
>> Interesting how a set of 'hints' can be an effective mitigation=20
>> against Issue H, J, and K. It was my understanding that you propose -=20=

>> only when these hints are applied as if they are rules - safety can =
be achieved.
>> But you now appear water down the applicability? Which is it?
>>=20
>> More importantly: already two different RP implementers recognized=20
>> that "each RP implementation *will* have to apply limits" [9].=20
>> Unfortunately only one implementer took action so far. The problems=20=

>> you documented have to be solved irregardless of the existence of=20
>> "Tree Hints", because an RP can't rely on Tree Hints being =
reasonable, or even existing.
>>=20
>> My suggestion would be everyone gets a move on and focuses on=20
>> immediately resolving their issues, because at present H, J & K are=20=

>> not mitigated in multiple implemenations. Hint: accepting chains up =
to 32 long is ludicrous.
>> After having implemented sane limits, implementers are likely to come=20=

>> to understand there is no need for "Tree Hints".
>>=20
>>> In the bandwidth example, if you are using FORT Validator then any=20=

>>> repository that does not manage 200KB/s is already excluded using =
the=20
>>> default configuration, thus that requirement is already in place in=20=

>>> practice. The same applies to all limits mentioned in 6.2-6.8. The=20=

>>> main difference is that if included in Tree Hints, both parties know=20=

>>> what "safe" values they can use, rather than having to keep up with=20=

>>> all limits individual implementations impose.
>>=20
>> You correctly place "safe" between quotation marks. Merely labeling=20=

>> something "safe" does not intrincically make it "safe". Fun to read=20=

>> that FORT now doubles as a general purpose network speedtest. =
However,=20
>> from there it doesn't follow that "the requirement is already in =
place in practise".
>>=20
>> I remain skeptical about your proposal, as I find its merit lacking.
>>=20
>> Kind regards,
>>=20
>> Job
>>=20
>> [1]:
>> =
https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-cont
>> ents/
>> [2]:=20
>> https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
>> [3]:=20
>> https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
>> [4]: https://github.com/NLnetLabs/routinator/issues/274
>> [5]: https://github.com/RIPE-NCC/rpki-validator-3/issues/162
>> [6]: https://github.com/RIPE-NCC/rpki-validator-3/issues/255
>> [7]: https://github.com/NLnetLabs/routinator/issues/365
>> [8]: https://github.com/cloudflare/cfrpki/issues/66
>> [9]:
>> =
https://mailarchive.ietf.org/arch/msg/sidrops/aeM_IAyZ0XZ2luho_FEewScA
>> vjQ/
>>=20
>>=20
>>=20
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>=20
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Thu Nov 18 09:55:42 2021
Return-Path: <jsnijders@fastly.com>
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 D931A3A0914 for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=fastly.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 0Myt6zp0bz4E for <sidrops@ietfa.amsl.com>; Thu, 18 Nov 2021 09:55:35 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 9F9423A08ED for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:55:35 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id w15so7401624ill.2 for <sidrops@ietf.org>; Thu, 18 Nov 2021 09:55:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lNB4Aq/3rZXMA55V+Bfw2iMJkWKqdUbcWzSHPfC7cNc=; b=MmRIolD+lBok/F12F9Q12b3qovd0yMXnXNFgWCkk16Qrt0WZC++jkFyiVzGXu2MOeV yzfv3sgwoa8c0GrwzcnaQD3xgG/hPbzd/slEmgG44N8wfEVnxc4mXmlygfTQKYr97QBs j1Egi5FmBfS6AjPopQvWV2mY8ERiGQ6T+5e14=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lNB4Aq/3rZXMA55V+Bfw2iMJkWKqdUbcWzSHPfC7cNc=; b=7USbd3JkwEVwv9dCT2+mUGOuxe7uQbmoIupyA1vVUXMRqkQlb864rI+zOC0PRXh2n2 ICQCV+JtD3N06iilTvaaUqgIcC3XYe3G9egKQ6M8r9rgBLAEM2TDSB9amKO7VC326AnH 8GQnO3MHVBk6AdtpD1ISoXLbQEcM2V9zkg6mdQ1PUqwhBpJOGsEdpuX0qVaCw71w1Q2X eQpj+zAcoEoTH+ykWefi3uIEbhn0RTXsZtWTjM+DI1KkzHBjfoug9wv5fVLU5rktZ2ts 0vatkvFVZnujA6mKOyTxQAkaukWddO9whjnewiZhsZpWPGOuZ5/e6crgu+h08XO1XY9n KhAg==
X-Gm-Message-State: AOAM530nch/mHfXJ+cMl4zNb8VsvPhZk6qXyG3PWYMkZMTjw1PO9kSbI GnwquO+AwohV6l11u75jPKQRxznm5W2iz132uoSB2NFEaoQ=
X-Google-Smtp-Source: ABdhPJx8KE0Raglf/DhvQ+QGNqLCvmhoMFzOa7jny7Qx18pPpb6yEJa6lU2u24yu8lVD6aNdWlxuw38+QpA8SKY8t5A=
X-Received: by 2002:a92:130d:: with SMTP id 13mr603224ilt.187.1637258133891; Thu, 18 Nov 2021 09:55:33 -0800 (PST)
MIME-Version: 1.0
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <3F6FE177-0485-4FCD-9AB0-AA1A13F41323@nlnetlabs.nl>
In-Reply-To: <3F6FE177-0485-4FCD-9AB0-AA1A13F41323@nlnetlabs.nl>
From: Job Snijders <job@fastly.com>
Date: Thu, 18 Nov 2021 18:55:23 +0100
Message-ID: <CAMFGGcCXSMUf+mcGx562iL_1CJfMj0X3nHJXKVC_raa=Q3X+SA@mail.gmail.com>
To: Alex Band <alex@nlnetlabs.nl>
Cc: Koen van Hove <k.w.vanhove@student.utwente.nl>, Mikhail Puzanov <mpuzanov@ripe.net>, sidrops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007a40f805d113ddd9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/N50pXtGz4xtP_KoO6WO2w6rRHw0>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 17:55:40 -0000

--0000000000007a40f805d113ddd9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 18 Nov 2021 at 18:49, Alex Band <alex@nlnetlabs.nl> wrote:

> > On 18 Nov 2021, at 18:16, Koen van Hove <k.w.vanhove@student.utwente.nl=
>
> wrote:
> >
> > Regarding point 1: I believe that is a good idea, although I am not sur=
e
> whether this draft is necessarily the right place for it. RFC 6486 and 64=
87
> may be more suitable for it, or as its own RFC, especially as it might be=
 a
> (fast) moving target.
> >
> > Regarding point 2: Regarding the limits themselves: I would expect that
> a general limit would work for 99% in practice. For there where it does n=
ot
> work currently, an exception can be made, by opening a ticket, making a
> call, sending a facsimile, or whatever the conventional way is to reach
> your CA. The legal aspect is an interesting one. Perhaps someone else cou=
ld
> provide more insight into this? I would assume they already have the mean=
s
> (from a policy perspective) to revoke the certificate for abuse, and that
> this would be an extension to that policy.
>
> Taking the RIPE NCC as an example, I=E2=80=99m sure there are some intere=
sting
> things to be found in the two sets of Terms and Conditions they have for
> this.
>
> The RPKI service itself:
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/r=
ipe-ncc-certification-service-terms-and-conditions
>
> The repository:
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/r=
ipe-ncc-certification-repository-terms-and-conditions



RIPE NCC=E2=80=99s Certification Practise Statement (CPS) also bears releva=
nce in
this context:

https://www.ripe.net/publications/docs/ripe-751

The above statement is modelled after RFC 7382 / BCP 173

Kind regards,

Job

--0000000000007a40f805d113ddd9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div>On Thu, 18 Nov 2021 at 18:49, Alex Band &lt;<a href=3D"mailto:ale=
x@nlnetlabs.nl" target=3D"_blank">alex@nlnetlabs.nl</a>&gt; wrote:</div></d=
iv><div><div><div class=3D"gmail_quote"></div></div></div><div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,2=
04)" dir=3D"auto">
&gt; On 18 Nov 2021, at 18:16, Koen van Hove &lt;<a href=3D"mailto:k.w.vanh=
ove@student.utwente.nl" target=3D"_blank">k.w.vanhove@student.utwente.nl</a=
>&gt; wrote:<br>
&gt; <br>
&gt; Regarding point 1: I believe that is a good idea, although I am not su=
re whether this draft is necessarily the right place for it. RFC 6486 and 6=
487 may be more suitable for it, or as its own RFC, especially as it might =
be a (fast) moving target. <br>
&gt; <br>
&gt; Regarding point 2: Regarding the limits themselves: I would expect tha=
t a general limit would work for 99% in practice. For there where it does n=
ot work currently, an exception can be made, by opening a ticket, making a =
call, sending a facsimile, or whatever the conventional way is to reach you=
r CA. The legal aspect is an interesting one. Perhaps someone else could pr=
ovide more insight into this? I would assume they already have the means (f=
rom a policy perspective) to revoke the certificate for abuse, and that thi=
s would be an extension to that policy. <br>
<br>
Taking the RIPE NCC as an example, I=E2=80=99m sure there are some interest=
ing things to be found in the two sets of Terms and Conditions they have fo=
r this.<br>
<br>
The RPKI service itself:<br>
<a href=3D"https://www.ripe.net/manage-ips-and-asns/resource-management/rpk=
i/legal/ripe-ncc-certification-service-terms-and-conditions" rel=3D"norefer=
rer" target=3D"_blank">https://www.ripe.net/manage-ips-and-asns/resource-ma=
nagement/rpki/legal/ripe-ncc-certification-service-terms-and-conditions</a>=
<br>
<br>
The repository:<br>
<a href=3D"https://www.ripe.net/manage-ips-and-asns/resource-management/rpk=
i/legal/ripe-ncc-certification-repository-terms-and-conditions" rel=3D"nore=
ferrer" target=3D"_blank">https://www.ripe.net/manage-ips-and-asns/resource=
-management/rpki/legal/ripe-ncc-certification-repository-terms-and-conditio=
ns</a></blockquote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>=
</div><div><div dir=3D"auto">RIPE NCC=E2=80=99s Certification Practise Stat=
ement (CPS) also bears relevance in this context:</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><div><a href=3D"https://www.ripe.net/publications=
/docs/ripe-751" target=3D"_blank">https://www.ripe.net/publications/docs/ri=
pe-751</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">The above sta=
tement is modelled after RFC 7382 / BCP 173</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Kind regards,</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Job</div></div>
</div>

--0000000000007a40f805d113ddd9--


From nobody Fri Nov 19 00:56:21 2021
Return-Path: <robert@ripe.net>
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 7F54F3A0CA5 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 00:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level: 
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=ripe.net
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 XvWPrQD5a4H5 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 00:56:14 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 A503E3A0CA9 for <sidrops@ietf.org>; Fri, 19 Nov 2021 00:56:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:Subject:From:Cc:To:MIME-Version:Date:Message-ID ; bh=pjUjgp7DraCFd87+fCJ5Yh63TgUsPWd7jUxQY5Mo6pg=; b=YOITmkFH3d8BzP176dIkQ16J 7cx9fApvk4ORM4PYlC+S/cdgcls3+ExUy0zB2BQPS23u4yJMto3VvE9y+0vODiOdzQywY+6psLvfc /a2a5FR/v2P3JVgYAi+j08oyXcbPnFmU4WtkkG4Q9REJQ9S5na93/2KeJ1ZeIJpeDUFF+OR8plNI7 diqgyFfiCCYi6k0LTs2s7203s2mmx3r7AwKx4Qgd1/yMn7Xcr7HoNOKJcPbm5hFw4cDA7SWgoBOMK 5vm/AmDEgd7pdpGlrCND2567HZOUBVLhHptgpVg6RI7K8QlhcwNQoD5OzHW2g9VyGLrUbzf0GqQKq oTe9dI2fMA==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:51674) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <robert@ripe.net>) id 1mnzgm-00014O-Tj; Fri, 19 Nov 2021 09:56:08 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPV6:2001:67c:2e8:1200::4ba]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <robert@ripe.net>) id 1mnzgm-00055L-Ql; Fri, 19 Nov 2021 09:56:08 +0100
Message-ID: <221a1da9-424e-d218-d9bb-383e53a4cea8@ripe.net>
Date: Fri, 19 Nov 2021 09:56:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1
Content-Language: en-GB
To: Koen van Hove <k.w.vanhove@student.utwente.nl>
Cc: sidrops@ietf.org
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
From: Robert Kisteleki <robert@ripe.net>
Organization: RIPE NCC
In-Reply-To: <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274de356bb6fe6e5e2064d82de05ccc5ef1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/gdMJNc83aF8yo086p4fz1Dn9mDQ>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 08:56:20 -0000

Hi,

> Regarding point 2: Regarding the limits themselves: I would expect
> that a general limit would work for 99% in practice. For there where
> it does not work currently, an exception can be made, by opening a
> ticket, making a call, sending a facsimile, or whatever the
> conventional way is to reach your CA. The legal aspect is an

Except, as I said before, when it's not your parent who prescribes that, 
but your grandparent or above. Then you have no business relation and 
likely no contact either. So from one day to the next your repo can just 
disappear in all RP implementations and the only thing you can do is ask 
you parent to ask their parent to ... make an exception. It doesn't 
sound like a fun exercise.

To reiterate: I don't think the specification of these limits and 
controls belong inside the protocol. Making a BCP or such, if really 
needed, is much preferred.

Cheers,
Robert


From nobody Fri Nov 19 01:16:30 2021
Return-Path: <job@fastly.com>
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 2BD133A0CBE for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 01:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 M2vb0SFq_UUT for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 01:16:24 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 F298F3A080B for <sidrops@ietf.org>; Fri, 19 Nov 2021 01:16:23 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id v1so6551540edx.2 for <sidrops@ietf.org>; Fri, 19 Nov 2021 01:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lbQDrsBz8IC0cusE2BshCgytDsb3GBqKBPsCycjl2M4=; b=loN0cCI+Cj5DwazgOFzY2GmXIRqid2hPmVMQaYpV44NzZqwcyDl3BS5b3qUIBT9MPu WJ36S2SECTfg6/1ImHEg9c5BeN6KwTHI+kqc6Pxy/Mow32Xe4FElzbkzKqrEn/7mak9f V8MPE72+bv6pTDVd1d4wFIyl/qCDCDYi56TQs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lbQDrsBz8IC0cusE2BshCgytDsb3GBqKBPsCycjl2M4=; b=rWg+Oot7ncEQa60VwLbEMTKmR8podx1DWDSdtgKHY+h4pxWYbQfF9m1BiN3boK4sfI zI5fziL3dFkFaTSr3euPJH1IV21VqmMuR2P+fDyPTEErNIPRbmvvBelfZLiTXMoZaqTL f2QdW3l9/yKtFj5YS59wbHgXRG6kjunCbCybAbpIXeHpe0FRgurF0vF65pI/byjk0mCy jdKWfBgP01ADrXCIB9gPuPKbcy0fP0A2/+oiyy0I/pVd1SyVykb25s/KSmHpVpayoUQU O8VIma8pF61Y85g8r4lryrrNrqj+xWBxqwTTnWKA7eiUbtc34onUfxC8cE24y/2YptIE kHqw==
X-Gm-Message-State: AOAM532An+oTZnGlPMeYCLidTdGKlyULxhzJJAsjDKNa8jecJNpZFJQA +/6G3U5cJgzXr97qwbCdwGr4pCIwYqdmHHbzbuFUX5zr/t039jMmp25dlSfPx+VA5NV5i/4I9Ny vdn5nim0jhAykRSyf7e2nWVAe/tM5f9RRlbsexKC1G9Mr7YXGBvK6eYA=
X-Google-Smtp-Source: ABdhPJzu5xwr6q6tq2PxmgKha9qG08larsai6D70/2Z8hL7Fli7q6WGJwLS0r+vJbQFwVkuPSRCx6Q==
X-Received: by 2002:a17:906:2f10:: with SMTP id v16mr5768647eji.434.1637313376970;  Fri, 19 Nov 2021 01:16:16 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id j4sm1124389edk.64.2021.11.19.01.16.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Nov 2021 01:16:16 -0800 (PST)
Date: Fri, 19 Nov 2021 10:16:14 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <YZdrXniwdgO+uttl@snel>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sVYNKpItb1HKk66JHFvnsSFKopk>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 09:16:28 -0000

On Thu, Nov 18, 2021 at 06:16:13PM +0100, Koen van Hove wrote:
> Regarding point 1: I believe that is a good idea, although I am not
> sure whether this draft is necessarily the right place for it. RFC
> 6486 and 6487 may be more suitable for it, or as its own RFC,
> especially as it might be a (fast) moving target. 

A simple wiki page is sufficient to keep track of such numbers.

https://trac.ietf.org/trac/sidrops/wiki/FencingLimits

Kind regards,

Job


From nobody Fri Nov 19 01:38:10 2021
Return-Path: <tdekock@ripe.net>
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 702883A0CDD for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 01:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=ripe.net
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 Vtpp8llWE9iQ for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 01:38:04 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 1DD2F3A0CCF for <sidrops@ietf.org>; Fri, 19 Nov 2021 01:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=EfoHj8FCjoMXChV7w5yhcfMQZ0AT+iSp72v0epvC0yM=; b=XCjz9dKPKRc1jZ+5a2GiUi9E 9/t1acHFSIqj0ifXWHn0cUChbPDuDrDsLOx1ojKbn+AbnY+V5N1Cb4gR9OMNU23b5osUoFj5iUTp+ f0DaWzurcOLBtY3lhYMqZBA18usSCdx2Zqi4nlXGCW6JMB4uBnQNzoAp61JwkVzuxr12FpWi4Mq7v G9G2Aojd6bQSpCkEQf4iz3JeU9coAg6/I0hjOsmZdoPCmPLPU+OxcjF5wR4ANfW/TWS6x1raQGRh9 RE9diaEqgN2IH7bQR+1k1dur573R8JAnKoqPSNXAJvBwigkdfknIF3M+yZGAOqKiXNXSqrSUxzIWB yzvcU2bPSw==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:56772) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mo0LI-0003Dy-5c; Fri, 19 Nov 2021 10:38:00 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mo0LI-0007dI-20; Fri, 19 Nov 2021 10:38:00 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <YZdrXniwdgO+uttl@snel>
Date: Fri, 19 Nov 2021 10:37:59 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <YZdrXniwdgO+uttl@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1316590c0effd2b2785ea0333596a29ef
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/fOnRm_Z427aF-Mkl7ZLvkLD4Guw>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 09:38:09 -0000

Hi Job,

> On 19 Nov 2021, at 10:16, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>=20
> On Thu, Nov 18, 2021 at 06:16:13PM +0100, Koen van Hove wrote:
>> Regarding point 1: I believe that is a good idea, although I am not
>> sure whether this draft is necessarily the right place for it. RFC
>> 6486 and 6487 may be more suitable for it, or as its own RFC,
>> especially as it might be a (fast) moving target.=20
>=20
> A simple wiki page is sufficient to keep track of such numbers.
>=20
> https://trac.ietf.org/trac/sidrops/wiki/FencingLimits

Quick clarifying questions:

Is there a global transfer timeout, or is the 15 minutes per repository? =
Which
could take 9*15 minutes in the worst case?
(My need for quick rpki-client runs made me implement a global rsync =
timeout=20
using a deadline and coreutils timeout in [0])

Does rpki-client apply the same limit at all levels of the tree (both =
for the
repository and ca-manifest tree)?

So the 100K children is possible at any level of the tree:
  * RIPE NCC member CA can have >50K objects on it: good, needed.
  * A delegated CA below a delegated CA can have 100K objects on it that =
refer
    to CAs on it (and nest that 4+ times, >2^66 objects): bad?

Note that a dangerously low limit of 20K objects, that would be hit in =
practice
during a keyroll, would would still allow >2^57 objects.

Are there any limits on the number of files retrieved per repository =
(for rsync
and rrdp)? I have created a rsync repository in a testing setup which =
needed
multiple orders of magnitude more inodes than the 300000 rpki-client =
recommends.

Kind regards,
Ties

[0]: https://github.com/ties/rpki-client-web

>=20
> Kind regards,
>=20
> Job
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Fri Nov 19 04:50:58 2021
Return-Path: <cjeker@diehard.n-r-g.com>
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 113123A0886 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 04:50:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 x-GLzyvkO1OD for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 04:50:51 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC2D3A087E for <sidrops@ietf.org>; Fri, 19 Nov 2021 04:50:49 -0800 (PST)
Received: (qmail 38460 invoked by uid 1000); 19 Nov 2021 12:50:46 -0000
Date: Fri, 19 Nov 2021 13:50:46 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Ties de Kock <tdekock@ripe.net>
Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>, sidrops@ietf.org
Message-ID: <YZedpvrjh6lqk4RH@diehard.n-r-g.com>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <YZdrXniwdgO+uttl@snel> <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5gEhhaye_L0U3bRaVDWiAFxxsxE>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 12:50:57 -0000

On Fri, Nov 19, 2021 at 10:37:59AM +0100, Ties de Kock wrote:
> Hi Job,
> 
> > On 19 Nov 2021, at 10:16, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> > 
> > On Thu, Nov 18, 2021 at 06:16:13PM +0100, Koen van Hove wrote:
> >> Regarding point 1: I believe that is a good idea, although I am not
> >> sure whether this draft is necessarily the right place for it. RFC
> >> 6486 and 6487 may be more suitable for it, or as its own RFC,
> >> especially as it might be a (fast) moving target. 
> > 
> > A simple wiki page is sufficient to keep track of such numbers.
> > 
> > https://trac.ietf.org/trac/sidrops/wiki/FencingLimits
> 
> Quick clarifying questions:
> 
> Is there a global transfer timeout, or is the 15 minutes per repository? Which
> could take 9*15 minutes in the worst case?

The worst case does not matter because rpki-client stops after 60min of
runtime. We had to use 15min because some real life repositories take a
long time to sync. The limit is selected based on real life data and not
on some worst case scenario. It makes no sense to be overly aggressive
here.

> (My need for quick rpki-client runs made me implement a global rsync timeout 
> using a deadline and coreutils timeout in [0])

In other words you accept bad output in preference of faster execution
time.
 
> Does rpki-client apply the same limit at all levels of the tree (both for the
> repository and ca-manifest tree)?

It applies the timeout to all sync actions. So 15min for RRDP and 15min
for rsync. So worst case a repository may only be validated after 30min
but that is fine.
 
> So the 100K children is possible at any level of the tree:
>   * RIPE NCC member CA can have >50K objects on it: good, needed.
>   * A delegated CA below a delegated CA can have 100K objects on it that refer
>     to CAs on it (and nest that 4+ times, >2^66 objects): bad?

You have this the wrong way around. We need to have this stupid 100k limit
because of RIPE NCC and AS0 tal from APNIC. If these repositories would
split their mft into multiple ones with e.g. 1000 entries max that limit
could be reduced and everyone would win.

Also this deep and wide issue is far less of an issue then it is pushed by
Koen van Hove. The CA repos are all run by well known institutions
(enforced by the RIRs and the way IP delegation works). So it is rather
clear who needs to be prosecuted in the case of an attack. This is not a
traffic DDoS case where the source is unknown.
 
> Note that a dangerously low limit of 20K objects, that would be hit in practice
> during a keyroll, would would still allow >2^57 objects.

Why are you rolling all keys at once? Also why is the repository not setup
in a way that does not require to have everything in a single MFT?
What is the reason for this and why can't it be changed?
 
> Are there any limits on the number of files retrieved per repository (for rsync
> and rrdp)? I have created a rsync repository in a testing setup which needed
> multiple orders of magnitude more inodes than the 300000 rpki-client recommends.

This is hard to implement. Neither rsync or rrdp allow this to implement
in an easy way. It requires that the number of files is tracked and in the
rsync case this can only done post factum.

-- 
:wq Claudio


From nobody Fri Nov 19 06:03:55 2021
Return-Path: <tim@nlnetlabs.nl>
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 636D53A0878 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 06:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 FpSAH1OwGpTg for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 06:03:49 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 4C1B33A093D for <sidrops@ietf.org>; Fri, 19 Nov 2021 06:03:48 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 1E9A02DC; Fri, 19 Nov 2021 14:03:44 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1637330622; bh=dCavQTqnWuw1lgLx5BecPpdlrsAbg4LmfXe6LtzVPQs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=KCDrjFsG0onlRqoHnCusQ2SkuR8hD+062FhqhkbGNv97KoLl5r8Nbpr8iEYRzDIh5 gqix+IWjxzk2717mvB1YuTTw/qBWACLO9B581VLy+ce3XujcSa0/pRQ8FBDlJpQlVX 94Ro+DRbsLOXzLsjWESEJR3eH2WO0CTSwP1NbSpylWYjgLYnojzOebf1/ZTdK/Jpx6 R2EaHFJJeepFwmyE3y0fXWwxB3lIcRu05qJ0JvXWFf6seBIEziOVVK+JezKler12ko rm0XJGzWoRU+7cGysYOPZsUqVEgHDZ+y9sH8ROfFLkYi262+mwkIP8d1tExMcJt2pA rUMECka2Ef5yg==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <YZedpvrjh6lqk4RH@diehard.n-r-g.com>
Date: Fri, 19 Nov 2021 15:03:39 +0100
Cc: Ties de Kock <tdekock@ripe.net>, sidrops@ietf.org, Job Snijders <job=40fastly.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7202C5D1-1E9F-46F6-83A9-BADD84115F8F@nlnetlabs.nl>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <YZdrXniwdgO+uttl@snel> <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net> <YZedpvrjh6lqk4RH@diehard.n-r-g.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/DDX4kzqELIiEHEPrWeasAxENfns>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 14:03:54 -0000

> On 19 Nov 2021, at 13:50, Claudio Jeker <cjeker@diehard.n-r-g.com> =
wrote:
>=20
>> Are there any limits on the number of files retrieved per repository =
(for rsync
>> and rrdp)? I have created a rsync repository in a testing setup which =
needed
>> multiple orders of magnitude more inodes than the 300000 rpki-client =
recommends.
>=20
> This is hard to implement. Neither rsync or rrdp allow this to =
implement
> in an easy way. It requires that the number of files is tracked and in =
the
> rsync case this can only done post factum.

slightly on a tangent, but triggered by the inodes..

It may, or may not - just a thought I wanted to share - be useful to =
store objects
in a different way - e.g. some key value store where you do not need a =
file per object.

This is somewhat hard / impossible when using rsync as an external tool =
because it will
expect things on disk - but may be an option if you have native rsync =
client code. It is
pretty easy to use this storage strategy when doing rrdp.

Of course this is only one small piece of the puzzle, and I will leave =
it to RP
implementers to judge what works for them.

Tim=


From nobody Fri Nov 19 06:46:16 2021
Return-Path: <tdekock@ripe.net>
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 446843A0120 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 06:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=ripe.net
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 OyVJVO-PHar2 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 06:46:08 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 14C473A0115 for <sidrops@ietf.org>; Fri, 19 Nov 2021 06:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=GGfUBug1WL6FY1DKwkR8nblpvO3D+McB0nlZdwZZSk0=; b=k1zyAvdfFSlewA/jIokIZJOq ROu7g3vrB8wXihDuZUQqowIhUytgM7nFcJaitOwR9/yaGapRmohnAjGpQA2BsKiAXcIK4Jfrcg3fG HgOyybOFU4gGNSnBNY0NLtB29OVrjCa13qkGf6kzAqETnecj7R6dMbgcxbVCxo6Zgx+Mkys4qZDHn Va8+Z3/cRe9yQ6bAK2aXIjB3qs8uEuacYyryP/nDEdeJoIX714hMM3owycwcO3CpJORGx4OjVfV89 J9fwJRR765u9rbx2xZE1oj9h776lU+txFTVDz8sIIHnTtbcWrGoxldklgJTTq32A3yihDf7O0DL/m Ds0moQvtuA==;
Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:58470) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mo59P-0001tu-Fk; Fri, 19 Nov 2021 15:46:03 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mo59P-0007qD-CC; Fri, 19 Nov 2021 15:46:03 +0100
From: Ties de Kock <tdekock@ripe.net>
Message-Id: <DF448C26-2EB8-4EE3-8812-92C27A29EA57@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD6DCEC8-A50C-4423-900B-C6677B30E74E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 19 Nov 2021 15:46:02 +0100
In-Reply-To: <YZedpvrjh6lqk4RH@diehard.n-r-g.com>
Cc: sidrops@ietf.org, Job Snijders <job=40fastly.com@dmarc.ietf.org>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <YZdrXniwdgO+uttl@snel> <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net> <YZedpvrjh6lqk4RH@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1d8b1c069f8fca075737660dde32903a4
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6WPeONdbwXBpOO3XryeeuGoZZRE>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 14:46:14 -0000

--Apple-Mail=_FD6DCEC8-A50C-4423-900B-C6677B30E74E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Claudio,

> On 19 Nov 2021, at 13:50, Claudio Jeker <cjeker@diehard.n-r-g.com> =
wrote:
>=20
> On Fri, Nov 19, 2021 at 10:37:59AM +0100, Ties de Kock wrote:
>> Hi Job,
>>=20
>>> On 19 Nov 2021, at 10:16, Job Snijders =
<job=3D40fastly.com@dmarc.ietf.org> wrote:
>>>=20
>>> On Thu, Nov 18, 2021 at 06:16:13PM +0100, Koen van Hove wrote:
>>>> Regarding point 1: I believe that is a good idea, although I am not
>>>> sure whether this draft is necessarily the right place for it. RFC
>>>> 6486 and 6487 may be more suitable for it, or as its own RFC,
>>>> especially as it might be a (fast) moving target.=20
>>>=20
>>> A simple wiki page is sufficient to keep track of such numbers.
>>>=20
>>> https://trac.ietf.org/trac/sidrops/wiki/FencingLimits
>>=20
>> Quick clarifying questions:
>>=20
>> Is there a global transfer timeout, or is the 15 minutes per =
repository? Which
>> could take 9*15 minutes in the worst case?
>=20
> The worst case does not matter because rpki-client stops after 60min =
of
> runtime. We had to use 15min because some real life repositories take =
a
> long time to sync. The limit is selected based on real life data and =
not
> on some worst case scenario. It makes no sense to be overly aggressive
> here.

Earlier empirical data from Job showed that 90 minutes is needed for =
slow RPs.
If I recall correctly some rpki-client instantices on NLNOG ring nodes =
in China
hit this. Which is why repositories support rsync clients that take up =
to 120
minutes.

Completely agree that it does not make sense to be overly agressive =
here.

>=20
>> (My need for quick rpki-client runs made me implement a global rsync =
timeout=20
>> using a deadline and coreutils timeout in [0])
>=20
> In other words you accept bad output in preference of faster execution
> time.

Indeed. It's a bias towards liveliness and provides a bounded time for =
the
sync to terminate. I disabled it by default but it made sense for my use =
case.

I have experimented with very low execution timeouts. For rsync I =
observed that
an aborted rsync run syncs part of files. In practice, after multiple =
aborted
rsync runs, the RP can fetch the complete repository.

>=20
>> Does rpki-client apply the same limit at all levels of the tree (both =
for the
>> repository and ca-manifest tree)?
>=20
> It applies the timeout to all sync actions. So 15min for RRDP and =
15min
> for rsync. So worst case a repository may only be validated after =
30min
> but that is fine.

What happens if you have chained slow repositories? Is the total =
duration
(depth)*(15+15 minutes)?

>> So the 100K children is possible at any level of the tree:
>>  * RIPE NCC member CA can have >50K objects on it: good, needed.
>>  * A delegated CA below a delegated CA can have 100K objects on it =
that refer
>>    to CAs on it (and nest that 4+ times, >2^66 objects): bad?
>=20
> You have this the wrong way around. We need to have this stupid 100k =
limit
> because of RIPE NCC and AS0 tal from APNIC. If these repositories =
would
> split their mft into multiple ones with e.g. 1000 entries max that =
limit
> could be reduced and everyone would win.

There are two limits at play:
  * large number of VRPs per ROA: needed for AS0
  * large number of objects per CA: Used by many of the larger CAs (or =
if some
    resource holders follow the "one VRP per ROA advice")

Since it is exponential growth any realistic threshold that you apply is =
bound
to become intractable when used by a malicious repo. 1000^6 =3D large as =
well.

> Also this deep and wide issue is far less of an issue then it is =
pushed by
> Koen van Hove. The CA repos are all run by well known institutions
> (enforced by the RIRs and the way IP delegation works). So it is =
rather
> clear who needs to be prosecuted in the case of an attack. This is not =
a
> traffic DDoS case where the source is unknown.

There are > 25K CAs that can create a delegated CA at a moments notice. =
I would
not claim these are well known institutions. This is many more than when =
the EFF
ran their SSL observatory experiments. Luckily, unlike for the web, =
these CAs
have limited resources they can sign for.

web ca:
  * High barrier to entry.
  * High stakes.
  * Compliance/auditing schemes.
  * Can sign for anything.
rpki:
  * Low barrier to entry.
  * Low stakes.
  * No compliance required.
  * Can sign for their own resources.

In my opinion, the main risk is that if a malicious (or incompetent) =
repository
operator breaks many relying party instances, many will not recover.

>> Note that a dangerously low limit of 20K objects, that would be hit =
in practice
>> during a keyroll, would would still allow >2^57 objects.
>=20
> Why are you rolling all keys at once? Also why is the repository not =
setup
> in a way that does not require to have everything in a single MFT?
> What is the reason for this and why can't it be changed?

The implementation follows https://datatracker.ietf.org/doc/html/rfc6489

I do not recall there being questions about restructure the CA hierarchy =
to have
less objects per manifest before. Can you explain how changing this =
would
mitigate "wide and deep" and what branching factor you would propose?

>> Are there any limits on the number of files retrieved per repository =
(for rsync
>> and rrdp)? I have created a rsync repository in a testing setup which =
needed
>> multiple orders of magnitude more inodes than the 300000 rpki-client =
recommends.
>=20
> This is hard to implement. Neither rsync or rrdp allow this to =
implement
> in an easy way. It requires that the number of files is tracked and in =
the
> rsync case this can only done post factum.

In the RIPE validator this would have been easy to implement for RRDP, =
hard for
rsync. The latter likely needs a custom binary.

Kind regards,
Ties

>=20
> --=20
> :wq Claudio
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org <mailto:Sidrops@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidrops =
<https://www.ietf.org/mailman/listinfo/sidrops>

--Apple-Mail=_FD6DCEC8-A50C-4423-900B-C6677B30E74E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Claudio,<br class=3D""><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On 19 Nov 2021, at 13:50, Claudio Jeker =
&lt;<a href=3D"mailto:cjeker@diehard.n-r-g.com" =
class=3D"">cjeker@diehard.n-r-g.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
charset=3D"UTF-8" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">On Fri, Nov 19, 2021 at 10:37:59AM +0100, Ties de Kock =
wrote:</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">Hi =
Job,<br class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">On =
19 Nov 2021, at 10:16, Job Snijders &lt;<a =
href=3D"mailto:job=3D40fastly.com@dmarc.ietf.org" =
class=3D"">job=3D40fastly.com@dmarc.ietf.org</a>&gt; wrote:<br =
class=3D""><br class=3D"">On Thu, Nov 18, 2021 at 06:16:13PM +0100, Koen =
van Hove wrote:<br class=3D""><blockquote type=3D"cite" =
class=3D"">Regarding point 1: I believe that is a good idea, although I =
am not<br class=3D"">sure whether this draft is necessarily the right =
place for it. RFC<br class=3D"">6486 and 6487 may be more suitable for =
it, or as its own RFC,<br class=3D"">especially as it might be a (fast) =
moving target.<span class=3D"Apple-converted-space">&nbsp;</span><br =
class=3D""></blockquote><br class=3D"">A simple wiki page is sufficient =
to keep track of such numbers.<br class=3D""><br class=3D""><a =
href=3D"https://trac.ietf.org/trac/sidrops/wiki/FencingLimits" =
class=3D"">https://trac.ietf.org/trac/sidrops/wiki/FencingLimits</a><br =
class=3D""></blockquote><br class=3D"">Quick clarifying questions:<br =
class=3D""><br class=3D"">Is there a global transfer timeout, or is the =
15 minutes per repository? Which<br class=3D"">could take 9*15 minutes =
in the worst case?<br class=3D""></blockquote><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">The worst case does not matter because rpki-client stops =
after 60min of</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">runtime. We had to use 15min because some real life =
repositories take a</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">long time to sync. The limit is selected based on real life =
data and not</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">on some worst =
case scenario. It makes no sense to be overly aggressive</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">here.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote><div><br class=3D""></div><div>Earlier =
empirical data from Job showed that 90 minutes is needed for slow =
RPs.</div><div>If I recall correctly some rpki-client instantices on =
NLNOG ring nodes in China</div><div>hit this. Which is why repositories =
support rsync clients that take up to =
120</div><div>minutes.</div><div><br class=3D""></div><div>Completely =
agree that it does not make sense to be overly agressive here.</div><div =
class=3D""><br class=3D""></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><blockquote type=3D"cite" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">(My =
need for quick rpki-client runs made me implement a global rsync =
timeout<span class=3D"Apple-converted-space">&nbsp;</span><br =
class=3D"">using a deadline and coreutils timeout in [0])<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">In other words you accept bad output in preference of faster =
execution</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">time.</span><br=
 style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote><div><br class=3D""></div><div>Indeed. =
It's a bias towards liveliness and provides a bounded time for =
the</div><div>sync to terminate. I disabled it by default but it made =
sense for my use case.</div><div><br class=3D""></div><div>I have =
experimented with very low execution timeouts. For rsync I observed =
that</div><div>an aborted rsync run syncs part of files. In practice, =
after multiple aborted</div><div>rsync runs, the RP can fetch the =
complete repository.</div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><blockquote type=3D"cite" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D"">Does rpki-client apply the same limit =
at all levels of the tree (both for the<br class=3D"">repository and =
ca-manifest tree)?<br class=3D""></blockquote><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">It applies the timeout to all sync actions. So 15min for RRDP =
and 15min</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">for rsync. So =
worst case a repository may only be validated after 30min</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">but that is fine.</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote><div><br class=3D""></div><div>What =
happens if you have chained slow repositories? Is the total =
duration</div><div>(depth)*(15+15 minutes)?</div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">So =
the 100K children is possible at any level of the tree:<br =
class=3D"">&nbsp;* RIPE NCC member CA can have &gt;50K objects on it: =
good, needed.<br class=3D"">&nbsp;* A delegated CA below a delegated CA =
can have 100K objects on it that refer<br class=3D"">&nbsp;&nbsp;&nbsp;to =
CAs on it (and nest that 4+ times, &gt;2^66 objects): bad?<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">You have this the wrong way around. We need to have this =
stupid 100k limit</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">because of RIPE NCC and AS0 tal from APNIC. If these =
repositories would</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">split their mft into multiple ones with e.g. 1000 entries max =
that limit</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">could be =
reduced and everyone would win.</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div>There are two limits at play:</div><div>&nbsp; * =
large number of VRPs per ROA: needed for AS0</div><div>&nbsp; * large =
number of objects per CA: Used by many of the larger CAs (or if =
some</div><div>&nbsp; &nbsp; resource holders follow the "one VRP per =
ROA advice")</div><div><br class=3D""></div><div>Since it is exponential =
growth any realistic threshold that you apply is bound</div><div>to =
become intractable when used by a malicious repo. 1000^6 =3D large as =
well.</div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><span style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Also this deep and wide issue is far less of an issue then it =
is pushed by</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">Koen van =
Hove. The CA repos are all run by well known institutions</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">(enforced by the RIRs and the =
way IP delegation works). So it is rather</span><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">clear who needs to be prosecuted in the case of an attack. =
This is not a</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">traffic DDoS =
case where the source is unknown.</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div>There are &gt; 25K CAs that can create a delegated =
CA at a moments notice. I would</div><div>not claim these are well known =
institutions. This is many more than when the EFF</div><div>ran their =
SSL observatory experiments. Luckily, unlike for the web, these =
CAs</div><div>have limited resources they can sign for.</div><div><br =
class=3D""></div><div>web ca:</div><div>&nbsp; * High barrier to =
entry.</div><div>&nbsp; * High stakes.</div><div>&nbsp; * =
Compliance/auditing schemes.</div><div>&nbsp; * Can sign for =
anything.</div><div>rpki:</div><div>&nbsp; * Low barrier to =
entry.</div><div>&nbsp; * Low stakes.</div><div>&nbsp; * No compliance =
required.</div><div>&nbsp; * Can sign for their own =
resources.</div><div><div><br class=3D""></div><div>In my opinion, the =
main risk is that if a malicious (or incompetent) =
repository</div><div>operator breaks many relying party instances, many =
will not recover.</div><div class=3D""><br =
class=3D""></div></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">Note =
that a dangerously low limit of 20K objects, that would be hit in =
practice<br class=3D"">during a keyroll, would would still allow =
&gt;2^57 objects.<br class=3D""></blockquote><br style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">Why are you rolling all keys at once? Also why is the =
repository not setup</span><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">in a way that does not require to have everything in a single =
MFT?</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">What is the =
reason for this and why can't it be changed?</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" =
class=3D""></div></blockquote><div><br class=3D""></div><div><div>The =
implementation follows <a =
href=3D"https://datatracker.ietf.org/doc/html/rfc6489" =
class=3D"">https://datatracker.ietf.org/doc/html/rfc6489</a></div><div><br=
 class=3D""></div><div>I do not recall there being questions about =
restructure the CA hierarchy to have</div><div>less objects per manifest =
before. Can you explain how changing this would</div><div>mitigate "wide =
and deep" and what branching factor you would propose?</div><div =
class=3D""><br class=3D""></div></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><blockquote type=3D"cite" style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">Are =
there any limits on the number of files retrieved per repository (for =
rsync<br class=3D"">and rrdp)? I have created a rsync repository in a =
testing setup which needed<br class=3D"">multiple orders of magnitude =
more inodes than the 300000 rpki-client recommends.<br =
class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">This is hard to implement. Neither rsync or rrdp allow this =
to implement</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">in an easy =
way. It requires that the number of files is tracked and in =
the</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;" class=3D""><span style=3D"caret-color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; float: none; display: inline !important;" class=3D"">rsync case =
this can only done post factum.</span><br style=3D"caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;" class=3D""></div></blockquote><div><br =
class=3D""></div><div><div>In the RIPE validator this would have been =
easy to implement for RRDP, hard for</div><div>rsync. The latter likely =
needs a custom binary.</div></div><div><br class=3D""></div><div>Kind =
regards,</div><div>Ties</div><div class=3D""><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">--<span =
class=3D"Apple-converted-space">&nbsp;</span></span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">:wq Claudio</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" =
class=3D"">_______________________________________________</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">Sidrops mailing list</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"mailto:Sidrops@ietf.org" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D"">Sidrops@ietf.org</a><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/sidrops" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" =
class=3D"">https://www.ietf.org/mailman/listinfo/sidrops</a></div></blockq=
uote></div><br class=3D""></body></html>=

--Apple-Mail=_FD6DCEC8-A50C-4423-900B-C6677B30E74E--


From nobody Fri Nov 19 08:25:36 2021
Return-Path: <kotikalapudi.sriram@nist.gov>
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 431CE3A08D1; Fri, 19 Nov 2021 08:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, 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 mYREPo0LFWmM; Fri, 19 Nov 2021 08:25:26 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::70d]) (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 66E363A0892; Fri, 19 Nov 2021 08:25:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Puxlu7EBv76r/EZkBbPJaiCycXMKvQwhDLD/58jN2LmGBrgqnyre4kzp3ecjLsrMdkZTkCAcp+RZzWHBxAHWFsNlobjqpscqncIq9BsLrsqbFxt2YZGs71UJxrBQT1ZZaHkfUfEZzMz6YsZt3caPOnD64Lv6QIPpsu1zvetg3OQrMczZ7RIbRjGYEGF/Qtw1V+pmCuWJFNXSxYZh3mOtK6YqqdclCNm6PnoEuhA+gi6qq6T/tEIm/iblPhiuCiEf+VUnADKYKcl/Xad0Bu9qHSZYHVIQQdZaqFdNpPXK0XwphvJdvkOlSLMKojTlTn1x6Wec7+oLw/SOPWuX77TCpg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=COrMLq8M0kc/ltURsPejBWZLmcFEK7hXCRPyCDbxD5M=; b=hI/TBvBDijXuP151AQnNGHyRvS3FV6Paio24oK8hH3i4meNwXiss5JljtuLkIecXefsW7K8U9lvOEf0dj7zSlRJBtNBMa6y3XP476xndKrcj1vyItkoF7e3EsAO92Gi+oG0i7pl2LHAKmDdXcaYMPJMRsQpUYUspjKgi+OkTG7jtpCXUClfsFukZWfbaGELao7sUCRI+bcJJk21cszEo90nR6gHpi6d+p/sTAK/gnXVdBXFFVU2sghXcoxfz0koUQbGCuSIBkE9N5pwEKvoDcfdXv57r98R1iv6hTc0SZ7w6LiAleFv4sJAdtlr2s2FTBMTln/52slI9kzAgiJ6nPg==
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=COrMLq8M0kc/ltURsPejBWZLmcFEK7hXCRPyCDbxD5M=; b=W18dutDWQ0KRvbh4pqgjZ55B5e8UYVk/3UaroWyVpQu6EOBraM1/BA+2RAEgKTqNVV32OnfAhEujgIikLHjldYr1KRQb9kY74sVyELWvpfqFqzvwWD73PbP/2LZVfai9drj0W/x5i0vcDI/OrCGqnSnEvED+1h/NOdiPISLnYxo=
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB8686.namprd09.prod.outlook.com (2603:10b6:806:173::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Fri, 19 Nov 2021 16:25:15 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::bd9a:9a9e:82de:1b3b]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::bd9a:9a9e:82de:1b3b%3]) with mapi id 15.20.4713.022; Fri, 19 Nov 2021 16:25:15 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Chris Morrow <morrowc@ops-netman.net>, "keyur@arrcus.com" <keyur@arrcus.com>
CC: Amreesh Phokeer <amreesh.phokeer@gmail.com>, "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Re: [Sidrops] Draft Statuses from the F2F meeting slides
Thread-Index: AdfdWuwYg3a60coHQG6yERlupGt7wQ==
Date: Fri, 19 Nov 2021 16:25:15 +0000
Message-ID: <SA1PR09MB81421709B1DC9AE142930A13849C9@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 73f26233-1bb8-49b0-1639-08d9ab792b75
x-ms-traffictypediagnostic: SA1PR09MB8686:
x-microsoft-antispam-prvs: <SA1PR09MB8686DF0CB486E5E2AFCCDBF6849C9@SA1PR09MB8686.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gNRU1kVs/tfrqZuRWDBCAGXNB6jrBg+UKAblT+e3W1uKcdODWQlAi+w73ynpn/bZ3/kYvFmhDqBuEOI/k7hgVWfhj8CbDiZMq7WTMPn3+7BwNFmY7CsrlX+4xqJ/ZO6qXWJuN+6GHV6mNKYJC8hsoCoDAyi6BFNxLJ0dq+bgnBuHGgAfmvIHPdvTSnXJZ+A5JJjdfQtgRVByFM9KdhnFSlvsE1ypn7v12Co7mJSZsmuiZTQMywOBd08Sxit5dpvB0MZ8zCTsNtGFKA0RsC8S5JSOLi5zXyKXnEZotYm/Qs+uUTjkwkdKJ/rWbCge8V5wH5bcmfz9T4K9nXNCksnVPCZnRcbsHlcbxEVlVVzM1bXjb60FMVHj9I+Un/EIQXIS27odmuuD/Vjju/KC3/Yr8H6p5EUdCv9nBo2QK3PEgVYF8E5P6Y4MSdVDkvY3xn+2sGkiJjSSxx3LXR0gtLKCJNL+v6Y4pQUB5qlMfSsWU3JKTmVBCOVWLMzsCate5nghzVr/pvc/SiIPg/OXJrONz/wbnz9UHKmucBCYH40JdLHcXy2upkGxZnTXe7obK73DiCcK8Lpk54docMdss/mALcpDHC7frb4s0SBY+Ky9eticbnUocVjpI+zpNtUP53pL3rn6vLu5ow3FLuymcJGlipQ556OimvkKOfir9BUJ+GLALKHz8cW3KBrO1y4mY3HaWhfEobk2w1PtcUDmT+cMtXcCsmz6RW41fMIXhnpAlzv5SNeZOwYGz4fsB5JNM9BAtNGuDVwUudE5uGYMyr2u7tF7nz03dr7ZREvE9Ia8TLU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(55016002)(508600001)(52536014)(66946007)(38070700005)(54906003)(110136005)(82960400001)(9686003)(66476007)(66446008)(64756008)(71200400001)(4326008)(6506007)(66556008)(316002)(4744005)(8676002)(186003)(2906002)(26005)(7696005)(966005)(76116006)(83380400001)(8936002)(122000001)(5660300002)(86362001)(166002)(33656002)(38100700002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xEehWh3UIOAymg4QALnr+aBpvZOxrMWDhVoDs3nq9OYyv0iNCw9xlejpqxel?= =?us-ascii?Q?k+PIeku+cW0OL8YvOFIfygGI66BnmdJrpIOSfVNNK7hYp3T4Gokl3KYW0ntv?= =?us-ascii?Q?qgKQGoDm0mXmwrPizjeG2+8klXSwpVkAXqxxBLgMo4QaJMDd0Kk8faxcX91m?= =?us-ascii?Q?aJXtYgzFRzf8E/mP7TORhSWyMu4TEkbUsNXfheXh1ipTaiYS2qxDSvmwL+ic?= =?us-ascii?Q?GUYn2jpC2hmfJGTZ/Kg5Bcw9rX1bDWyieL9FTOxWpMKeksGrR+NWRsgG0gFb?= =?us-ascii?Q?7Q+Dkx7xIFRiRb+8DBtMO/2EfvpOs35qb6M3aSgEB1uwb+wyjVsCfcZAt5Q1?= =?us-ascii?Q?AtRHhiHlE9n4GnhhLYDCAtw+M1/aYUfhhpL6TporVxmwziiY6FPxBGnzm/fS?= =?us-ascii?Q?IyWGJwRKyR2O8L6EEo0Hs3oYVu7w5GYoRhA77Sk76ZMGGIZBT2K1noAj7lgG?= =?us-ascii?Q?6GXfnImoHRO97nnEqbnj3cGwjiwaZ15lo/MnsMhH5tlNfLNO7IuMXivFPben?= =?us-ascii?Q?jdzDwhVI2i26nP5Ss49Zont6I6VuSe2OEPfg2/3TZ1id0z1pIfudvZkW+vyh?= =?us-ascii?Q?kF4w2jufEeA08jFiHyJvbPRXdiiQt3aCsj6+ftcZfLar5unV9K6mSvuDmW1A?= =?us-ascii?Q?tXMPcYDbEu86u2ugep+UKvNjMP2p5rmgYMUQqXeIz2YXReGZo4ynIpjnfkVl?= =?us-ascii?Q?mM/YR23xz19Wga1XcExxGg/WFmkcBDMzt6v0uunSpoGqHfJl+UHQkWHG4f44?= =?us-ascii?Q?EkOX4y+fnb4MGrVhOG78iFgXsHcFZX1dl1+0I3v/15XcXCIVgIol8WHflUNf?= =?us-ascii?Q?9sDE4S2OP4sN6EjCbndWjjbBajcVVFBFroa59u/56436cGiYu7+vRq+R9iKy?= =?us-ascii?Q?wknHg36MYPkTQeuC2SmE/l0UtfoYhbXQB1V0odf+Un8Bz15J/8dVM8o52QbL?= =?us-ascii?Q?AGxrLW5tr6Z8zI1AsybOphnynWhSKRCSxVBysZwxsGN6V78JpzZgmEpTBelv?= =?us-ascii?Q?BDEqcyVPp+JbHfw3L65s0n7dglVh9hVCO/67utoOj1jtKodgqYlAQOahsBnb?= =?us-ascii?Q?V7Vlg7l6fp54+5DAzZ37DYBlxx7FwNg16/3hOlNpsxmlHDwgZm9AkMELj7XR?= =?us-ascii?Q?3P+9WbYGerAwB32VRHlQfyN2R3Bw5NlHagpTuq6et1Yxs/ZlK6X7zjy0yz8z?= =?us-ascii?Q?37TF/YhzCj4JpHhgCTqtJOQ5S+Pk1+UbaomNtgaD3XH/5jRr9IPMviFZKwDf?= =?us-ascii?Q?6tBFkf/8jZIZ5M8EYkTWTJTv4f5YJO1FJoSOeiL51lLxxmQpoZRhTI4SHUj2?= =?us-ascii?Q?VrE=3D?=
Content-Type: multipart/alternative; boundary="_000_SA1PR09MB81421709B1DC9AE142930A13849C9SA1PR09MB8142namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73f26233-1bb8-49b0-1639-08d9ab792b75
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2021 16:25:15.6867 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB8686
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/n8ZQk3PLn6k0TIETFVtVlIaBaHk>
Subject: Re: [Sidrops] Draft Statuses from the F2F meeting slides
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 16:25:35 -0000

--_000_SA1PR09MB81421709B1DC9AE142930A13849C9SA1PR09MB8142namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Chris, Keyur:

>rpkimaxen-06 - WGLC pending decision

The WGLC comments thread is here:
https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=3D1&index=3Ds7qljIu-w=
VlRmsyE-7EgCSfqJPk
plus
https://mailarchive.ietf.org/arch/msg/sidrops/xDLy47k0NpMwFp_caPA4qPXXv_I/

Amreesh suggested we include a Security Considerations section and move som=
e of the existing text into that section. We (authors) will work on it and =
publish a new version soon.

Thank you.

Sriram




--_000_SA1PR09MB81421709B1DC9AE142930A13849C9SA1PR09MB8142namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Mangal;
	panose-1:0 0 4 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"var\(--bs-font-monospace\)";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>Chris, Keyur:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>&gt;rpkimaxen-06 - WGLC pending decision<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>The WGLC comments thread is here:<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><a href=3D"https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=3D1&amp;i=
ndex=3Ds7qljIu-wVlRmsyE-7EgCSfqJPk">https://mailarchive.ietf.org/arch/brows=
e/sidrops/?gbt=3D1&amp;index=3Ds7qljIu-wVlRmsyE-7EgCSfqJPk</a></span><span =
style=3D"font-size:9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,s=
erif"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:black">p=
lus</span><span style=3D"font-size:9.5pt;font-family:&quot;var(--bs-font-mo=
nospace)&quot;,serif"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><a href=3D"https://mailarchive.ietf.org/arch/msg/sidrops/xDLy47k0NpMwFp_ca=
PA4qPXXv_I/">https://mailarchive.ietf.org/arch/msg/sidrops/xDLy47k0NpMwFp_c=
aPA4qPXXv_I/</a><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>Amreesh suggested we include a Security Considerations section and move so=
me of the existing text into that section. We (authors)
 will work on it and publish a new version soon. <o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>Thank you.<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
>Sriram<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.5pt;font-family:&quot;var(--bs-font-monospace)&quot;,serif;color:#212529"=
><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:20.0pt"><o:p>&nbsp;</o:p></=
span></p>
</div>
</body>
</html>

--_000_SA1PR09MB81421709B1DC9AE142930A13849C9SA1PR09MB8142namp_--


From nobody Fri Nov 19 10:08:55 2021
Return-Path: <randy@psg.com>
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 B50883A0915 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 10:08:53 -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, 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 NwKLFhFeo6gc for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 10:08:52 -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 B5E033A0914 for <sidrops@ietf.org>; Fri, 19 Nov 2021 10:08:52 -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 <randy@psg.com>) id 1mo8Jd-0004J8-8y; Fri, 19 Nov 2021 18:08:49 +0000
Date: Fri, 19 Nov 2021 10:08:48 -0800
Message-ID: <m2bl2gnhlb.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Ties de Kock <tdekock@ripe.net>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <DF448C26-2EB8-4EE3-8812-92C27A29EA57@ripe.net>
References: <CAEgZXjF_ZTb7Z+pe+X6MG_L7khW2reMHVQTgDWpwwC2-JvUNtA@mail.gmail.com> <4b8619bb-e95b-1466-1b46-708ad437293d@ripe.net> <YY2kQsJIPw5Q7j3a@snel> <001501d7d898$23951380$6abf3a80$@student.utwente.nl> <YZJ/E/zFNEgNtk32@snel> <002501d7db13$cc8e5320$65aaf960$@student.utwente.nl> <50B00643-684D-4012-933B-05557F4F02E6@ripe.net> <002701d7dc9f$fd5cff00$f816fd00$@student.utwente.nl> <YZdrXniwdgO+uttl@snel> <DE823CBF-E8D2-40CE-8E76-0582396B9C59@ripe.net> <YZedpvrjh6lqk4RH@diehard.n-r-g.com> <DF448C26-2EB8-4EE3-8812-92C27A29EA57@ripe.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/F0pxzKnOQljOs2p3ylwmYaJIGlU>
Subject: Re: [Sidrops] Tree Hints for the Resource Public Key Infrastructure (RPKI)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 18:08:54 -0000

> Earlier empirical data from Job showed that 90 minutes is needed for
> slow RPs.  If I recall correctly some rpki-client instantices on NLNOG
> ring nodes in China hit this. Which is why repositories support rsync
> clients that take up to 120 minutes.

folk, you are coming up with magic numbers which might work today on odd
numbered fridays and might look embarrassing and break things in five
years.

640k syndrome

and, btw, are folk taking into consideration that CAs may have multiple
parents; and those parents might be at quite different depths in
disjoint (thank you RIR egos) trees?

randy


From nobody Fri Nov 19 14:18:48 2021
Return-Path: <Rich.Compton@charter.com>
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 7E4783A0139 for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 14:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Level: 
X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, 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 nKY9vYvqjs8W for <sidrops@ietfa.amsl.com>; Fri, 19 Nov 2021 14:18:41 -0800 (PST)
Received: from mail.chartercom.com (nce.mail.chartercom.com [142.136.234.134]) (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 7AEF43A012B for <sidrops@ietf.org>; Fri, 19 Nov 2021 14:18:41 -0800 (PST)
X-Ironport-Dmarc-Check-Result: validskip
IronPort-SDR: j4a2yJ/pLlSrVZNA2gPjcnHp1r6q2OnqfFuKqmvcjWuyXeyEjSuZkzIxjE++xGXOganPC3DkMM 3JOC374t8eNA==
IronPort-Data: =?us-ascii?q?A9a23=3ANvDSB67hoKOsFCTTlK6/vgxRtN7FchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmEXWWvTPP+CZmvwKtoia4ng9B9Xv57Wz9A1SgQ//i02Q?= =?us-ascii?q?iMRo6IpJzg4wmQcnc+qw0SqoHtPt63yUfGdapBrJpPgjk31aOG49CAtjfvgq?= =?us-ascii?q?ofUU4YoBAggHWeIdw980XqPq8Zh6mJZqYDR7zGl4LsekOWDULOR4AOYB0pPg?= =?us-ascii?q?061RLKDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vf9BooB8Oqiu6nKAshZYTqeyOuo0BqdpKJpT0ErSs3uko5HKNAMwEO0GvPx?= =?us-ascii?q?YstjogS3XCzYV5B0qnkouUWU19zFCRmIapA0LTHKGKjvNbVxErDG5fp66w/U?= =?us-ascii?q?x9pYddBo46bBkkRpKxCdljhdCurnOO62rWjUcFti9gtas7xM+siVttI2WmMV?= =?us-ascii?q?7B5VcmWG+OS8YUNhHFr3Z0TCa2LP4xEfWU6RQrmTx1pLg5PXch6xPPAamLXd?= =?us-ascii?q?TZVrV+FqrJvvzKVxwtryP7mMNPPZtGQTsJQ2E2fowr7E63CKklyHLSiJfCtr?= =?us-ascii?q?hpAXtPyoB4=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AL0ID9620lrDCbHkJoAhWHAqjBJIkLtp133?= =?us-ascii?q?Aq2lEZdPUMSL37qyncpoV/6faUskdqZJhOo7C90cW7LE80lqQFnLX5X43SPz?= =?us-ascii?q?UO0VHAROoJ0WKI+VLd8ljFl9K1op0PT0ERMrHN5BNB/KLHCUGDYrEdKJPsyt?= =?us-ascii?q?HPuQ/0p00dND2Dfclbnn9E4yigYzZLeDU=3D?=
X-IronPort-AV: E=Sophos;i="5.87,248,1631595600";  d="png'149?scan'149,208,217,149";a="197674211"
Received: from ncemexgp042.corp.chartercom.com ([142.136.234.57]) by mail.chartercom.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 19 Nov 2021 16:18:39 -0600
Received: from ncemexgp039.CORP.CHARTERCOM.COM (2002:8e88:ea36::8e88:ea36) by ncemexgp042.CORP.CHARTERCOM.com (2002:8e88:ea39::8e88:ea39) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Fri, 19 Nov 2021 16:18:38 -0600
Received: from ncemexgp039.CORP.CHARTERCOM.COM ([fe80::45d2:589b:ee5b:a546]) by ncemexgp039.CORP.CHARTERCOM.com ([fe80::45d2:589b:ee5b:a546%21]) with mapi id 15.00.1497.024; Fri, 19 Nov 2021 16:18:38 -0600
From: "Compton, Rich A" <Rich.Compton@charter.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Grammatical errors in ASPA doc
Thread-Index: AQHX3ZNmWPDzv77l5EWwS4pwDniouw==
Date: Fri, 19 Nov 2021 22:18:38 +0000
Message-ID: <5152F9BB-039C-40C5-9BBB-2DCACCB65575@charter.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.54.21101001
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [142.136.234.122]
Content-Type: multipart/related; boundary="_004_5152F9BB039C40C59BBB2DCACCB65575chartercom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/_ru-rceMJWKamxwcMkv7fXTm5VY>
Subject: [Sidrops] Grammatical errors in ASPA doc
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Nov 2021 22:18:47 -0000

--_004_5152F9BB039C40C59BBB2DCACCB65575chartercom_
Content-Type: multipart/alternative;
 boundary="_000_5152F9BB039C40C59BBB2DCACCB65575chartercom_"

--_000_5152F9BB039C40C59BBB2DCACCB65575chartercom_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SSB3YXMganVzdCByZWFkaW5nIHRocm91Z2ggdGhlIOKAnFZlcmlmaWNhdGlvbiBvZiBBU19QQVRI
IFVzaW5nIHRoZSBSZXNvdXJjZSBDZXJ0aWZpY2F0ZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJl
IGFuZCBBdXRvbm9tb3VzIFN5c3RlbSBQcm92aWRlciBBdXRob3JpemF0aW9u4oCdIGRvYyAoaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVy
aWZpY2F0aW9uLykgYW5kIEkgbm90aWNlZCB0aGUgZm9sbG93aW5nIGdyYW1tYXRpY2FsIGVycm9y
czoNCg0KSW4gc2VjdGlvbiAxIOKAnFdoaWxlIHN1Y2ggYW4gYXBwcm9hY2ggaGFzIHJlYXNvbmFi
bGUgY29tcHV0YXRpb25hbCBjb3N0LCB0aGUgdHdvIHNpZGUgYWRqYWNlbmNpZXMgZG9uJ3QgcHJv
dmlkZSBhIHdheSB0byBhdXRvbWF0ZSBhbm9tYWx5IGRldGVjdGlvbiB3aXRob3V0IGhpZ2ggYWRv
cHRpb24gcmF0ZS4u4oCdIHRoYXQgbGFzdCBwaHJhc2Ugc2hvdWxkIGJlIOKAnHdpdGhvdXQgYSBo
aWdoIGFkb3B0aW9uIHJhdGXigJ0uDQoNCkluIHNlY3Rpb24gMSDigJwgVGhpcyBwcm9jZWR1cmVz
IHVzZXMgYSBzaGFyZWQgc2lnbmVkIGRhdGFiYXNl4oCm4oCdIHNob3VsZCBiZSDigJxUaGlzIHBy
b2NlZHVyZSB1c2Vz4oCdIG9yIGlmIHBsdXJhbCBpdCBzaG91bGQgYmUg4oCcVGhlc2UgcHJvY2Vk
dXJlcyB1c2XigJ0NCg0KSW4gc2VjdGlvbiAzIOKAnEFTUEEgaXMgZGlnaXRhbGx5IHNpZ25lZCBv
YmplY3QgdGhhdCBiaW5k4oCm4oCdIHNob3VsZCBiZSDigJxBU1BBIGlzIGEgZGlnaXRhbGx5IHNp
Z25lZCBvYmplY3QgdGhhdCBiaW5kc+KAnQ0KDQpJbiBzZWN0aW9uIDMg4oCcRm9yIGEgc2VsZWN0
ZWQgQ3VzdG9tZXIgQVMgU0hPVUxEIGV4aXN0IG9ubHkgc2luZ2xlIEFTUEHigKbigJ0gc2hvdWxk
IGJlIOKAnEZvciBhIHNlbGVjdGVkIEN1c3RvbWVyIEFTIFNIT1VMRCBleGlzdCBvbmx5IGEgc2lu
Z2xlIEFTUEHigJ0NCg0KSW4gc2VjdGlvbiAzIOKAnEluIHRoaXMgZG9jdW1lbnQgd2Ugd2lsbCB1
c2UgQVNQQShBUzEsIEFGSSwgW0FTMiwgLi4uXSkgYXMgbm90YXRpb24gdG8gcmVwcmVzZW50IEFT
UEEgb2JqZWN0Li4u4oCdIHNob3VsZCBiZSDigJxJbiB0aGlzIGRvY3VtZW50IHdlIHdpbGwgdXNl
IEFTUEEoQVMxLCBBRkksIFtBUzIsIC4uLl0pIGFzIG5vdGF0aW9uIHRvIHJlcHJlc2VudCBhbiBB
U1BBIG9iamVjdOKAnQ0KDQpJbiBzZWN0aW9uIDQg4oCcVGhlIHNlbWFudGljcyBvZiBpdHMgdXNl
IGlzIGRlZmluZWQgaW4gbmV4dCBzZWN0aW9uLuKAnSBzaG91bGQgYmUg4oCcVGhlIHNlbWFudGlj
cyBvZiBpdHMgdXNlIGlzIGRlZmluZWQgaW4gdGhlIG5leHQgc2VjdGlvbi7igJ0NCg0KSW4gc2Vj
dGlvbiA0IOKAnFNpbmNlIGFuIEFTMSBtYXkgaGF2ZSBkaWZmZXJlbnQgc2V0IG9mIHByb3ZpZGVy
cyBpbiBkaWZmZXJlbnQgQUZJ4oCm4oCdIHNob3VsZCBiZSDigJxTaW5jZSBBUzEgbWF5IGhhdmUg
YSBkaWZmZXJlbnQgc2V0IG9mIHByb3ZpZGVycyBpbiBhIGRpZmZlcmVudCBBRknigJ0NCg0KSW4g
c2VjdGlvbiA1IOKAnFdlIHdpbGwgdXNlIGluZGV4IG9mIEFTX1BBVEggc2VnbWVudHPigKbigJ0g
c2hvdWxkIGJlIOKAnFdlIHdpbGwgdXNlIGFuIGluZGV4IG9mIEFTX1BBVEggc2VnbWVudHPigJ0N
Cg0KSW4gc2VjdGlvbiA1LjIg4oCcV2hlbiByb3V0ZSBpcyByZWNlaXZlZCBmcm9tIHByb3ZpZGVy
4oCm4oCdIHNob3VsZCBiZSDigJxXaGVuIGEgcm91dGUgaXMgcmVjZWl2ZWQgZnJvbSBhIHByb3Zp
ZGVy4oCdDQoNCkluIHNlY3Rpb24gNS4yIOKAnElmIElfTUlOIGRvZXNuJ3QgZXhpc3QgcHV0IHRo
ZSBsZW5ndGggb2YgQVNfUEFUSCBpbiBJX01JTiB2YXJpYWJsZeKApuKAnSBzaG91bGQgYmUg4oCc
SWYgSV9NSU4gZG9lc24ndCBleGlzdCBwdXQgdGhlIGxlbmd0aCBvZiBBU19QQVRIIGluIHRoZSBJ
X01JTiB2YXJpYWJsZeKAnQ0KDQpJbiBzZWN0aW9uIDUuMyDigJxBIHJvdXRlIHJlY2VpdmVkIGZy
b20gYSBSUyBhdCBJWCBoYXMgbXVjaCBpbiBjb21tb24gd2l0aCByb3V0ZSByZWNlaXZlZCBmcm9t
IGEgcHJvdmlkZXIu4oCdIHNob3VsZCBiZSDigJxBIHJvdXRlIHJlY2VpdmVkIGZyb20gYSBSUyBh
dCBJWCBoYXMgbXVjaCBpbiBjb21tb24gd2l0aCBhIHJvdXRlIHJlY2VpdmVkIGZyb20gYSBwcm92
aWRlci7igJ0NCg0KSW4gc2VjdGlvbiA1LjMg4oCcQSB2YWxpZCByb3V0ZSBmcm9tIFJTIGNvbnRh
aW5zIFVwZmxvdyBmcmFnbWVudCBhbmQgTUFZIGNvbnRhaW4gRG93bmZsb3cgZnJhZ21lbnQgdGhh
dCBjb250YWlucyBJWCBBU+KAnSBzaG91bGQgYmUg4oCcQSB2YWxpZCByb3V0ZSBmcm9tIFJTIGNv
bnRhaW5zIGFuIFVwZmxvdyBmcmFnbWVudCBhbmQgTUFZIGNvbnRhaW4gYSBEb3duZmxvdyBmcmFn
bWVudCB0aGF0IGNvbnRhaW5zIElYIEFT4oCdDQoNCkluIHNlY3Rpb24gNS4zIOKAnEluIHRoaXMg
Y2FzZSwgYSByb3V0ZSB3aWxsIGhhdmUgb25seSBVcGZsb3cgc2VnbWVudCzigJ0gc2hvdWxkIGJl
IOKAnEluIHRoaXMgY2FzZSwgYSByb3V0ZSB3aWxsIGhhdmUgb25seSBhbiBVcGZsb3cgc2VnbWVu
dCzigJ0NCg0KSW4gc2VjdGlvbiA2IOKAnEF1dGhvcml6YWlvbuKAnSBzaG91bGQgYmUg4oCcQXV0
aG9yaXphdGlvbuKAnQ0KDQpJbiBzZWN0aW9uIDYg4oCcQnkgY3JlYXRpbmcgYW4gQVNQQSB3aXRo
IHByb3ZpZGVycyBzZXQgb2YgWzBdLOKAnSBzaG91bGQgYmUg4oCcQnkgY3JlYXRpbmcgYW4gQVNQ
QSB3aXRoIGEgcHJvdmlkZXJzIHNldCBvZiBbMF0s4oCdDQoNCkluIHNlY3Rpb24gOSDigJxXaGls
ZSBpdCBtYXkgaGFwcGVuIGluIHRoZW9yeSwgaXQncyBkb2Vzbid0IHNlZW0gdG8gYmUgYSByZWFs
IHNjZW5hcmlv4oCdIHNob3VsZCBiZSDigJxXaGlsZSBpdCBtYXkgaGFwcGVuIGluIHRoZW9yeSwg
aXQgZG9lc24ndCBzZWVtIHRvIGJlIGEgcmVhbCBzY2VuYXJpb+KAnQ0KDQpJbiBzZWN0aW9uIDEw
IOKAnFRoZSBhdXRob3JzIHdpc2ggdG8gdGhhbmsgYXV0aG9ycyBvZuKApuKAnSBzaG91bGQgYmUg
4oCcVGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayB0aGUgYXV0aG9ycyBvZuKAnQ0KDQpJbiBzZWN0
aW9uIDEwIOKAnFRoZSBhbHNvIGF1dGhvcnMgd2lzaCB0byB0aGFua+KApuKAnSBzaG91bGQgYmUg
4oCcVGhlIGF1dGhvcnMgYWxzbyB3aXNoIHRvIHRoYW5r4oCdDQoNCg0KW3NpZ25hdHVyZV8xMDA1
OTMwMzU4XQ0KDQpSaWNoIENvbXB0b24gICAgfCAgICAgUHJpbmNpcGFsIEVuZyAgICAgfCAgICAz
MTQuNTk2LjI4MjgNCjg1NjAgVXBsYW5kIERyaXZlLCAgIFN1aXRlIEIgIHwgIEVuZ2xld29vZCwg
Q08gODAxMTINClBHUCBLZXk8aHR0cHM6Ly9rZXlzLm9wZW5wZ3Aub3JnL3Zrcy92MS9ieS1maW5n
ZXJwcmludC8zNDc5NkM5NzgwRjVBNDUxMTBDMkU3NTcwNThEMzgzNjE2QUY5NDk3Pg0KDQpFLU1B
SUwgQ09ORklERU5USUFMSVRZIE5PVElDRTogDQpUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwg
bWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBh
ZGRyZXNzZWUocykgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBw
cml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50IG9mIHRoaXMgbWVzc2FnZSBvciBpZiB0aGlzIG1lc3NhZ2UgaGFzIGJlZW4gYWRkcmVzc2Vk
IHRvIHlvdSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFsZXJ0IHRoZSBzZW5kZXIgYnkg
cmVwbHkgZS1tYWlsIGFuZCB0aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht
ZW50cy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3Rp
ZmllZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywg
b3Igc3RvcmFnZSBvZiB0aGlzIG1lc3NhZ2Ugb3IgYW55IGF0dGFjaG1lbnQgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4K

--_000_5152F9BB039C40C59BBB2DCACCB65575chartercom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1488B0947433284E8B77A203C8109470@charter.com>
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+
PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y
OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N
Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t
LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy
IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4g
XChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl
OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i
Izk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+SSB3YXMganVzdCByZWFkaW5nIHRocm91Z2ggdGhlIOKAnFZlcmlmaWNhdGlvbiBvZiBB
U19QQVRIIFVzaW5nIHRoZSBSZXNvdXJjZSBDZXJ0aWZpY2F0ZSBQdWJsaWMgS2V5IEluZnJhc3Ry
dWN0dXJlIGFuZCBBdXRvbm9tb3VzIFN5c3RlbSBQcm92aWRlciBBdXRob3JpemF0aW9u4oCdIGRv
YyAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z
aWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtaWV0Zi1zaWRyb3BzLWFzcGEtdmVyaWZpY2F0aW9uLzwvYT4pDQogYW5kIEkgbm90
aWNlZCB0aGUgZm9sbG93aW5nIGdyYW1tYXRpY2FsIGVycm9yczo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHNlY3Rpb24gMSDigJw8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMjIyMjIyIj5XaGlsZSBzdWNoIGFuIGFwcHJvYWNoIGhhcyByZWFzb25hYmxl
IGNvbXB1dGF0aW9uYWwgY29zdCwgdGhlIHR3byBzaWRlIGFkamFjZW5jaWVzIGRvbid0IHByb3Zp
ZGUgYSB3YXkgdG8gYXV0b21hdGUNCiBhbm9tYWx5IGRldGVjdGlvbiB3aXRob3V0IGhpZ2ggYWRv
cHRpb24gcmF0ZS4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ0gdGhh
dCBsYXN0IHBocmFzZSBzaG91bGQgYmUg4oCcd2l0aG91dCBhIGhpZ2ggYWRvcHRpb24gcmF0ZeKA
nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHNlY3Rpb24g
MSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj4mbmJzcDtUaGlzIHByb2Nl
ZHVyZXMgdXNlcyBhIHNoYXJlZCBzaWduZWQgZGF0YWJhc2XigKbigJ0gc2hvdWxkIGJlIOKAnFRo
aXMgcHJvY2VkdXJlIHVzZXPigJ0gb3IgaWYgcGx1cmFsIGl0IHNob3VsZCBiZSDigJxUaGVzZQ0K
IHByb2NlZHVyZXMgdXNl4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIi
PkluIHNlY3Rpb24gMyDigJxBU1BBIGlzIGRpZ2l0YWxseSBzaWduZWQgb2JqZWN0IHRoYXQgYmlu
ZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCm4oCdIHNob3VsZCBiZSDi
gJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5BU1BBDQogaXMgYSBkaWdpdGFs
bHkgc2lnbmVkIG9iamVjdCB0aGF0IGJpbmRz4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMyMjIyMjIiPkluIHNlY3Rpb24gMyDigJxGb3IgYSBzZWxlY3RlZCBDdXN0b21lciBBUyBT
SE9VTEQgZXhpc3Qgb25seSBzaW5nbGUgQVNQQTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+4oCm4oCdIHNob3VsZCBiZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MjIyMjIyIj5Gb3INCiBhIHNlbGVjdGVkIEN1c3RvbWVyIEFTIFNIT1VMRCBleGlzdCBvbmx5IGEg
c2luZ2xlIEFTUEHigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+SW4g
c2VjdGlvbiAzIOKAnEluIHRoaXMgZG9jdW1lbnQgd2Ugd2lsbCB1c2UgQVNQQShBUzEsIEFGSSwg
W0FTMiwgLi4uXSkgYXMgbm90YXRpb24gdG8gcmVwcmVzZW50IEFTUEEgb2JqZWN0Li4u4oCdIHNo
b3VsZCBiZSDigJxJbiB0aGlzIGRvY3VtZW50IHdlIHdpbGwgdXNlIEFTUEEoQVMxLA0KIEFGSSwg
W0FTMiwgLi4uXSkgYXMgbm90YXRpb24gdG8gcmVwcmVzZW50IGFuIEFTUEEgb2JqZWN04oCdPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPkluIHNlY3Rpb24gNCDigJxUaGUg
c2VtYW50aWNzIG9mIGl0cyB1c2UgaXMgZGVmaW5lZCBpbiBuZXh0IHNlY3Rpb24uPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ0gc2hvdWxkIGJlIOKAnDwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPlRoZQ0KIHNlbWFudGljcyBvZiBpdHMgdXNlIGlzIGRl
ZmluZWQgaW4gdGhlIG5leHQgc2VjdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4g
c2VjdGlvbiA0IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPlNpbmNlIGFu
IEFTMSBtYXkgaGF2ZSBkaWZmZXJlbnQgc2V0IG9mIHByb3ZpZGVycyBpbiBkaWZmZXJlbnQgQUZJ
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igKbigJ0gc2hvdWxkDQogYmUg
4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+U2luY2UgQVMxIG1heSBoYXZl
IGEgZGlmZmVyZW50IHNldCBvZiBwcm92aWRlcnMgaW4gYSBkaWZmZXJlbnQgQUZJ4oCdPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPkluIHNlY3Rpb24gNSDigJw8c3BhbiBz
dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+V2Ugd2lsbCB1c2UgaW5kZXggb2YgQVNfUEFUSCBzZWdt
ZW50czwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKApuKAnSBz
aG91bGQgYmUg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5k
OndoaXRlIj5XZQ0KIHdpbGwgdXNlIGFuIGluZGV4IG9mIEFTX1BBVEggc2VnbWVudHPigJ08bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tn
cm91bmQ6d2hpdGUiPkluIHNlY3Rpb24gNS4yIOKAnFdoZW4gcm91dGUgaXMgcmVjZWl2ZWQgZnJv
bSBwcm92aWRlcuKApuKAnSBzaG91bGQgYmUg4oCcV2hlbiBhIHJvdXRlIGlzIHJlY2VpdmVkIGZy
b20gYSBwcm92aWRlcuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+SW4gc2VjdGlvbiA1LjIg4oCcSWYgSV9N
SU4gZG9lc24ndCBleGlzdCBwdXQgdGhlIGxlbmd0aCBvZiBBU19QQVRIIGluIElfTUlOPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gdmFyaWFibGXigKbigJ0gc2hvdWxkIGJl
IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+
SWYNCiBJX01JTiBkb2Vzbid0IGV4aXN0IHB1dCB0aGUgbGVuZ3RoIG9mIEFTX1BBVEggaW4gdGhl
IElfTUlOIHZhcmlhYmxl4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHNlY3Rpb24gNS4z
IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+
QSByb3V0ZSByZWNlaXZlZCBmcm9tIGEgUlMgYXQgSVggaGFzIG11Y2ggaW4gY29tbW9uIHdpdGgg
cm91dGUgcmVjZWl2ZWQgZnJvbSBhIHByb3ZpZGVyLuKAnQ0KIHNob3VsZCBiZSDigJxBIHJvdXRl
IHJlY2VpdmVkIGZyb20gYSBSUyBhdCBJWCBoYXMgbXVjaCBpbiBjb21tb24gd2l0aCBhIHJvdXRl
IHJlY2VpdmVkIGZyb20gYSBwcm92aWRlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4g
c2VjdGlvbiA1LjMg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3Jv
dW5kOndoaXRlIj5BIHZhbGlkIHJvdXRlIGZyb20gUlMgY29udGFpbnMgVXBmbG93IGZyYWdtZW50
IGFuZCBNQVkgY29udGFpbiBEb3duZmxvdyBmcmFnbWVudCB0aGF0IGNvbnRhaW5zDQogSVggQVPi
gJ0gc2hvdWxkIGJlIOKAnEEgdmFsaWQgcm91dGUgZnJvbSBSUyBjb250YWlucyBhbiBVcGZsb3cg
ZnJhZ21lbnQgYW5kIE1BWSBjb250YWluIGEgRG93bmZsb3cgZnJhZ21lbnQgdGhhdCBjb250YWlu
cyBJWCBBU+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+SW4gc2VjdGlvbiA1LjMg4oCcSW4gdGhpcyBjYXNl
LCBhIHJvdXRlIHdpbGwgaGF2ZSBvbmx5IFVwZmxvdyBzZWdtZW50LOKAnSBzaG91bGQgYmUg4oCc
SW4gdGhpcyBjYXNlLCBhIHJvdXRlIHdpbGwgaGF2ZSBvbmx5IGFuIFVwZmxvdyBzZWdtZW50LOKA
nTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+SW4gc2VjdGlvbiA2IOKAnEF1dGhvcml6YWlvbuKAnSBzaG91bGQgYmUg4oCcQXV0aG9yaXph
dGlvbuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4gc2Vj
dGlvbiA2IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3
aGl0ZSI+QnkgY3JlYXRpbmcgYW4gQVNQQSB3aXRoIHByb3ZpZGVycyBzZXQgb2YgWzBdLDwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCdIHNob3VsZA0KIGJlIOKAnDwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+QnkgY3JlYXRp
bmcgYW4gQVNQQSB3aXRoIGEgcHJvdmlkZXJzIHNldCBvZiBbMF0s4oCdPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIy
O2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRl
Ij5JbiBzZWN0aW9uIDkg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+V2hp
bGUgaXQgbWF5IGhhcHBlbiBpbiB0aGVvcnksIGl0J3MgZG9lc24ndCBzZWVtDQogdG8gYmUgYSBy
ZWFsIHNjZW5hcmlvPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ0gc2hv
dWxkIGJlIOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPldoaWxlIGl0IG1h
eSBoYXBwZW4gaW4gdGhlb3J5LCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUgYSByZWFsIHNjZW5hcmlv
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJ08bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHNlY3Rpb24gMTAg4oCcPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+VGhlIGF1dGhvcnMgd2lzaCB0byB0aGFuayBhdXRob3Jz
IG9m4oCm4oCdIHNob3VsZCBiZSDigJxUaGUgYXV0aG9ycyB3aXNoIHRvIHRoYW5rIHRoZSBhdXRo
b3JzIG9m4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+SW4gc2Vj
dGlvbiAxMCDigJxUaGUgYWxzbyBhdXRob3JzIHdpc2ggdG8gdGhhbms8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKApuKAnSBzaG91bGQgYmUg4oCcPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzIyMjIyMiI+VGhlDQogYXV0aG9ycyBhbHNvIHdpc2ggdG8gdGhhbmvigJ08
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE0NiIgaGVpZ2h0PSI0NiIgc3R5bGU9
IndpZHRoOjEuNTIwOGluO2hlaWdodDouNDc5MWluIiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9
ImNpZDppbWFnZTAwMS5wbmdAMDFEN0RENTguQkExNTdEMzAiIGFsdD0ic2lnbmF0dXJlXzEwMDU5
MzAzNTgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyRjU1OTciPlJpY2ggQ29t
cHRvbiAmbmJzcDsmbmJzcDsgfCAmbmJzcDsgJm5ic3A7IFByaW5jaXBhbCBFbmcmbmJzcDs8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzJGNTU5NyI+Jm5ic3A7Jm5i
c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5NyI+Jm5ic3A7DQogfCAmbmJzcDsg
Jm5ic3A7MzE0LjU5Ni4yODI4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv
bG9yOiMyRjU1OTciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5NyI+ODU2MCBVcGxhbmQgRHJpdmUsICZuYnNwOyBT
dWl0ZSBCJm5ic3A7IHwgJm5ic3A7RW5nbGV3b29kLCBDTyA4MDExMjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzJGNTU5NyI+
PGEgaHJlZj0iaHR0cHM6Ly9rZXlzLm9wZW5wZ3Aub3JnL3Zrcy92MS9ieS1maW5nZXJwcmludC8z
NDc5NkM5NzgwRjVBNDUxMTBDMkU3NTcwNThEMzgzNjE2QUY5NDk3Ij48c3BhbiBzdHlsZT0iY29s
b3I6IzA1NjNDMSI+UEdQIEtleTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2NvbG9yOiMyRjU1OTciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQpUaGUgY29udGVudHMg
b2YgdGhpcyBlLW1haWwgbWVzc2FnZSBhbmQgPGJyPmFueSBhdHRhY2htZW50cyBhcmUgaW50ZW5k
ZWQgc29sZWx5IGZvciB0aGUgPGJyPmFkZHJlc3NlZShzKSBhbmQgbWF5IGNvbnRhaW4gY29uZmlk
ZW50aWFsIDxicj5hbmQvb3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3U8
YnI+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgbWVzc2FnZTxicj5vciBp
ZiB0aGlzIG1lc3NhZ2UgaGFzIGJlZW4gYWRkcmVzc2VkIHRvIHlvdSA8YnI+aW4gZXJyb3IsIHBs
ZWFzZSBpbW1lZGlhdGVseSBhbGVydCB0aGUgc2VuZGVyPGJyPmJ5IHJlcGx5IGUtbWFpbCBhbmQg
dGhlbiBkZWxldGUgdGhpcyBtZXNzYWdlIDxicj5hbmQgYW55IGF0dGFjaG1lbnRzLiBJZiB5b3Ug
YXJlIG5vdCB0aGUgPGJyPmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0
IDxicj5hbnkgdXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsPGJyPm9y
IHN0b3JhZ2Ugb2YgdGhpcyBtZXNzYWdlIG9yIGFueSBhdHRhY2htZW50IDxicj5pcyBzdHJpY3Rs
eSBwcm9oaWJpdGVkLjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_5152F9BB039C40C59BBB2DCACCB65575chartercom_--

--_004_5152F9BB039C40C59BBB2DCACCB65575chartercom_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=23502;
 creation-date="Fri, 19 Nov 2021 22:18:38 GMT";
 modification-date="Fri, 19 Nov 2021 22:18:38 GMT"
Content-ID: <image001.png@01D7DD58.BA157D30>
Content-Transfer-Encoding: base64

TU0AKgAATrz////9//7//v/////+//3//f78///+//3//v/+//////31+v3A3Oqax9yDuth+utaF
vNqbyN+/3Or29/v+///+/v/////////+/vz+///+/v+/3ecAcrAAcrAAc7AAcq7f7vX/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////9//z/////////////
///+/v7+///////+/v7///////////////3+/////f78////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////+///+///////+
/////////////v///f7+/vyt0uVHm8AFdrAAc7AAca0BdbABcbAAcq4Ac6wAc64EdbFAmcGey+D3
+/r//v////v+/vz////A2+4Ac6wAc6wBcqoAc67f7vX/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////v/9/v/+///+///+/vz//v////////////39/v//
//39//7///v//f///v////3/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////9//7///3///3////////+//3//f662ukqirwA
c6wCc60Acq4Ac64Bc68Ac7ABcqwAc64Bc7IAdK8BcqwAcq4Ac6wchLmo0eX7/////v///v+93eoA
dK8Ac6wAcq4AdK/f7vX/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////+///+///+/v7//////v////0eg7cfhbYfhLgfhbaq0OP//f7////+//////3/////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////3////+/v78///+/v/7/P5usNMAc64AdK0Ac6wAc7IAdK0AdLEAc6wAcq4A
da8Ac6oCdLIBcbAAdKwAdLEBdK0Acq4Ac6xhp8v19vj//v+93eoAcq0Ac64AcrAAc7Df7vX/////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////+/vz//f7/
//3///////8Ac64Ac6wAc6wAc66ey+L//v/+///7//7///3//v//////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////3+////
//3//f/1+/tGmcMBcqwAdLEAcq4CcrEAcq4Dca4Ac7ADdbEdgrYjh7gQfrMBcq4Bcq4Ac6wAc6wA
c64Ac7AAdK8Ac64tjcDz+Pu/3OoBc68Acq4Acq4Acq7f7vX/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////3+/////v/+/////v////8Ac6wAcrAAdK8B
cq6dyuH//////v///v3//v//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////v9/f9OncYBc68BcbAAdKwB
cq4Ac6wFeK9lq8zA3Or3+v/////////+//3r9Pmr0uFIm8UBcqwBc7EAc6wAcq4Bcq6Fv9f+//+/
3OoAcq4BcbABdK0AdK3f7vX/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////3+/v7///38//////0Ac6wBcqwAcrABc7Gey+D///3////8//3///3+
/v7/////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////+///9/v96tdMBdbAAca8AdK4Bc68Bc7FIncbk7vf////+/v7/////
/fz//v///v/+///////+/v7M4vAwjL0Ac6wBc6+Gvdv//fz//v+/3OwAda8Acq4Ada0Acq7f7vX/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////+
///////+/////v8Ac64Bc68Ac6wAcq6dy+P////+///////+/v7//v//////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////v+
///G4ewDc7IAc6wAdK8Cc68Acq56ttL+/v///v/////+///////////+///+/////f/+//3+////
/vz5+v5xstKGvtn+/vz+//////+/3OoBcq4AdK0Aca8BdK3f7vX/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////3+/////v3///////8BcqwAc64B
c68Ac66gyuL///3//////v/+//3+/vz/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////v/+/v41kcAAc6wBcq4Ac7EAc6xu
sNL/////////////////////////////////////////////////////////////////////////
//+/3OoAcq4Acq4Ac64Acq7f7fb+/vz+//////3////+/v7t9fjg7fby9/v+/////////f7///3/
///////////+///+//////3////+/////v/9//7////////////+/vz////////////+//////3/
//////3//////v/9//z+//3//v/+///+//////3////////+//3+/v7///3+/////v/+//3/////
//3//v///////v////////v+//////3//v////////0Ac7AAda8Acq4Ac6yey+L///3////+//3/
/////v///////v///v/////+//////3///3////+//////////////3z+/vh8PXm7/b6+/3+////
/v////3///////3///3+/v7///3+//r////////9//7///3////8//3//v/+//////3+/v/////+
/////////v////////////////+y1uYAdKwAda0BcbAAdK03ksH+/P//////////////////////
//////////////////////////////////////////////////////+/3OoAcq4Acq4Ac64Acq7e
7fT////k7/WAudYvjcAHdq4Acq0AdK8AdK0Wf7hToMqs0eP8/Pz//v/+/////v3////+/vz/////
/f/////+/v7//////v/8/P652OyButhMm8YniLsVfLQPebMihrgykcFfqMmdzN7y9/v8/////f7/
/v////3///3////+/v+l0ONyr85wsNNusNKdyt/////+///+///+//3X5/SCuddHnMUihrcPfLU9
lMH+/v4sjr0NfLMOfK8Bc7EBdK0Ac6wAc64JeLAOe7MRerQPfLQOe7MQe7MNerMPfLSz1+X8////
/v/+//3+//////////293epkqM0ghbsAcq4Acq4Bc7EBdbIniLtvr9LM5ez//v/////9/v///v//
/f///v/////+/v/L4e5wr9JwsNRvsNB6tdX//////v/+//3////e6vaButdCmcQYgrYOe7MOe7P+
//9JnMQBcbAAcrEBc68BdKvU5vL///v/////////////////////////////////////////////
//////////////////////////////+/3OoAcq4Acq4Ac64Acq7Z6vJ8t9cFdrAAc6oAdLEAcq4A
da0AdK4Acq4AdK8Ac7AAcq4ni7zE3uv////7//7///3///3+/v7+///+/vz////Q5O9nrM0RfLQA
dK0Ada0Bc68Ac6wBdK0Bc68Ac6wAc6wAcK8Bc68LeLB7t9P3+/z+/v7////+/v7//////vxepswB
c7EAcq4Ac6xQnsX+//r+///R4/FFmcUAdK4AdK0AcasAcrEAc6wtjb3///8fg7cAcq4BdbABcqwA
cq4AdK8Bcq4AcrAAdLEBcq4Acq4AcrAAda8AdK0Ac66v0ub//v///vz///3//v/P5fA5kcEAdLEA
cqsBcq4AdK8Ac6wAc6wBc68Cc68Ac64AdK5SoMfi7/f+//////3+//3///////38//+gyuAAcq4A
dK8Ac6wNfLH//////f7h7/hWocgCda4Acq4Bcq4BcqwAcq4Bc6/q9PYCcrECdLIAc6wAcq5Tocf+
////////////////////////////////////////////////////////////////////////////
//////+/3OoAcq4Acq4Ac64Acq4ujL8Cc68Ac7AAcq4Ac6wAcrAEcq8Cc68Bc68Acq4Ac6wBdK0A
crAAd7Gly+D//////v/////+/////v36/v9CmcQCc68AcrABc68Ac6oAdK8Acq4AdK8Ac6sAc6wA
dLEAcq4Ac64BdK0Ac6wAc6wujL/k8ff///////3+/v7///9eqMsAda8BcqwAdK5Pnsn+/f+DvNkE
da8Ac6wBc68Bc7EBdKsAcq4BcbAtjrv///8eg7cBc7EAc7AEcrEAc6wAc6wBdK0BdK0Bcq4Acq4A
c64Bc68Ac6wAcq4BdK2v0uj////+//3+/v6Yxt0FdrIAc6wAcq4Acq4Bc68AcrABc68AcrAAc6wA
dK0AdK8Acq4EcrERf7LC3On//////v////////3///+fyeEAdLEBcqwAcq4Qe7P///+t0+YNe7AA
c7ABc68Bcq4Ac7AAcq4Bc68Acq6fzN8AdK4AcrAAdK8Bc6+52ej/////////////////////////
//////////////////////////////////////////////////////////+/3OoAcq4Acq4Ac64A
cq4Ac6wAcq4Bc7EAcrAAc64Ac64BcqoAc7EAc64Acq4Cc6sAc64Ac7ABc68Cc6252ej/////////
//////////1LncUAcq4Bc7EAc64Ada8Acq4BcbABc7EAcq4AdLEBcqwAcq4BcbAAc6wBc68AdK0A
c7Amhrjx+fz//v////3+//9gpcwAcq4Bc68AdK1QncllqtEAc64Ac6wBc68AcqsAcq4Ac7AAc64A
c6wtjb3///8chbQBcbABdK0Ac7ACc68Ac7AAc6wAdLEAc64Ac64AdbIAc6wAcq4AcrAAc66v1Of/
//3+/vyNvtwAc64Ac64Bcq4AcrAAc6wAc6wAda8AcqsBc68Ada8CcrEAc64AdK8Acq0CcrEKebDG
4u7+/v79//z///3///2gyuAAdK8Ac6wAdLEOe7SXx94BdK0Bc7EBc7EAc6wBc68AdK8BcbAAcq4B
c69mqs0Acq4AdLEAdK0NerL6+/3///////3/////////////////////////////////////////
//////////////////////////////////+/3OoAcq4Acq4Ac64Acq4Bc68Acq4Acq4YgrSGvNjM
4/Hs8/vq8/rH4e54tdQMe7MAc7AAc6wBc7EAc6obgLb0+fz///3+///+//3//f631uoBdK0Ac64A
dK8Acq4tjLxur82ey+Cy1ua83OuozuF7t9Eni70AdK8Cc68BcbAAcq4Bc69pq87+/v/+//////9f
qMsAc64Cc6sAc7AFdrAAc6wAcrEBcqwAca0Bc7EBc7Eeg7dJnMheqMt9uNb///1zstNdp8xepswA
da8Ac64Ac7AAcq48k8BfqMlhp8tgpcxgqNBep8pepsxfp83M4/H+//+01eYAc7AAc64BdK0Acq4A
c7AUgrWDvNfQ4/Hu9vnn8vi+2+trrdAFdq4BdK0Ac6wAda8Ac64Zgbbr9vr///3+/v///v+fzOMA
c64Ac6wAc6wDdK4BdbAAcq4Bcq4Ac6wCc60Ac6wQfrNFmcVcpMpfp806ksAAda0Ac64Acq5HmsL/
/v///vz//v//////////////////////////////////////////////////////////////////
//////////+/3OoAcq4Acq4Ac64Acq4Acq0Bc69cps35+P7+//v//////vz///3///////3i7/cr
irgCc60BcqwAc7ABc6+Lvtv//////f7////////9//4khbgKebBurtHZ6/X//////////fz////+
/vz//////v/+/v6ZyeAEdrIBcqoAcq4AdKwDdq3k7/X+/vz///9gpsoAdLEAc64Ac6wAc6wAdKoB
cq4AdK4DdK5kqszT5/L//v////3+/v///v///v/9//z///3//f8CcrEAc64Bc7EAcq6gyuL9/v//
//////3//v////v+/v7///3+///u9fsWgbUAcK8BdK0Ac6wAc6xWocjz9vv+//////3//f/+//3/
/v/+///Z6vEmh7wBcqwAcrEAc6wAdK9jqc3+/v7//v///v+ey+IAdK8Ac6wAdK8Ac64Bcq4Ac64C
da4Ac7BElsXB3ev8/f///v////////8WgrMAcq4Bcq4Cc69usNL////+//////3/////////////
//////////////////////////////////////////////////////////////+/3OoAcq4Acq4A
c64Acq4Bc69Wocj9//7+//////////////////////3//v/+///g7vcNerUAdK0Bcq4AdLEqirr+
/vz//v/+/v/+//3+///H3vDq9ff+//3//v/////9//z//////v///v/////+/////v///v+jzOAA
c64Bc7EAcq4AcrGHv9r////+//9eqM0Ac6wDca4Bc68Ac64Bc68Ac7AUf7XD3ez//v////3////+
//3////+//3+//3////////+//0Acq4Bc68Acq4BcqygyuL//////f/8//v////+///+/////v//
//94s9MAca0Ac64AdK8Ac65WpMr+/v///v/+/v/////+/////v/+//////v+///l8PYVgLYAc64B
cq4BcqwDdq/e7fT9//7///+ey+IAdK8Bc68Ac7ABcqwAc64Ac64DdauYxeL+///+//////3+////
//////8BdK0AdK8Acq4Ac6yLvt3///3+/v7/////////////////////////////////////////
//////////////////////////////////////+/3OoAcq4Acq4Ac64Acq4Qe7Hu9vn//////v/9
//z+/v7///////3////+//////3+//93tNMBcqoAcq4Ac7ABc6/k8ff+///////+//////////3/
///+/v7+//3+/v7///3////+//////3//v////////3///3//v8niLsAc6wAcrAAcqtIm8X//f7/
//1fqc4Ac64Cc68Ac64Ac7AAcrAJe6/S5vH+//3//f7+//////3////////////////////+////
//8Acq4Acq4Acq4Acq6ey+L////////////+//////////3////x+fwOfLEAc64Ac64Cc68egrb2
9/n9/v/////////////////////////////+//3///2lzuQAdK4Ac6wAc64Bcqx6t9b//v////uf
yeIAdK0Acq4Acq4Ac6wAcqsAdK+kzeP///3+/v7//////f/+//////////8BcqwAc7ABc68Acq6O
wtr9//7/////////////////////////////////////////////////////////////////////
//////////////+/3OoAcq4Acq4Ac64Acq5wstX+/////////v////3////+///////+//3////+
/vz////G4vAAdK8AdK8Bc68Acq641+n//////vz///////3+/v///v/////+///////////9//7/
//////39/v/+///+/////f7+//9ztNIBdK0Ac64Ac64ihLX+/////v9fp80Acq4Ac6wAdK0Ac6wB
c6+bytz////////////+///////////////////////////+//////8Acq4Acq4Acq4Acq6ey+L/
///////////+///////////+//+pzeMAdK8Acq4BdK0Ac7Cby+L9//7+//////////////3/////
//////////////39/v/9//4fhbYBc7EAc64AdK0qirz8///+//+gyuIAc6wBc68Ac6wAc64AdK9j
qc3////+///+/////f7//v////v///////8Acq4Ac64Bc68Bc6+Lwdv///3///3+////////////
//////////////////////////////////////////////////////////////////+/3OoAcq4A
cq4Ac64Acq672Oj///v+/////////////v/+//3//////////v////3////8/PwBc68AdK4Bc68A
c66fyt3//////v/+///+/v/+///+//r5+v611ul3tNNAl8IniboZfrYNerMSfbEhhbc5krxbpcyE
vdpkqs4AcrAAcq4Bcq4Qe7P///////9eqM8Bc68Acq4Ac6wBcqwvi7r9//7//f7//v//////////
//3////////////////////+//////8Acq4Acq4Acq4Acq6ey+L////////////+/////////v/+
//9jqM8AdK8BdK0Ac64JeLD2+vv////////////////////////////////+//////39/v////92
stQCc68Ac6wBc68Dcqrt9fj+//+gyuIAcrABc7IAcq4Acq4Gd6/p8Pb///3///3//////v/7//z/
/v////////8Me7MAdK0Aca8Acq51tNX9//7///3///3/////////////////////////////////
//////////////////////////////////////////+/3OoAcq4Acq4Ac64Acq7Y6fH/////////
/////////v////3+/v7////+/v7////+/////v0MebQAdK0Bc68Bc7GTw9r///////////////34
+f1/u9UQfrMAc64Cc60Bc68Ac7EAcrAAdLEAc64Bc7EAc64AcrABc68AcrAAcq4AdK4Acq4PfLX/
/vz///9eqM0Ac64Bc68AdK4AdLGTxd7+/v7+//////////3///////3////////////////////+
//////8Acq4Acq4Acq4Acq6ey+L////////////+///////+//////sxjLsAdK0AdK4Bcqwni72w
0+ew0+aw0+ev1Oev1Oeu0+au0+av1Oeu0+av0uau0+Ww0+av0+N0s9YAc6oAdLEAcq4Bc6/E3u3+
//+gyuAAc64Ac6wAc64Acq5Zo8r+///////////////////+///+/f////////8si7sAc64Bc68A
dK1LncX+/////v///v//////////////////////////////////////////////////////////
//////////////////+/3OoAcq4Acq4Ac64Acq7f7fb///////3///////3+/v//////////////
///////+///+//8Qe7MBc68Acq4Acq6Owdz///3///3+///W6fAmh7oBc7EBc68BdK0Ac64BdK0A
cqsAdK8Ac6wAdLEBcqwAdK8Bc68Ac6wAda8BcqwAc6wAcq4Oe7P///3///9hps0Acq4Bc68AdK4A
c67g7vf///////v+//////3////+//////3////////////////+//////8Acq4Acq4Acq4Acq6e
y+L////////////+/////////////vwUfrgAcK8AdK8Ac6wAc6wAcq4BdK0Ac6wAc6wAc64Ac64A
c64Ac64Ac6wAdK0Acq4Ac7ABc68Ac7EAdK0BcqwAc7ABc6+mz+X9//6gyuAAc6wBdK0Ac6wAc66l
zuD//v/+//////////v//f////3//v////////9SocgAdLEAcrAAcqsWgLL//f7+/v/+////////
//////////////////////////////////////////////////////////////////////+/3OoA
cq4Acq4Ac64Acq7e7fT////+//////////3////+/v7//v///////v////////3///0Oe7MAcbAB
dK0Cc62RwNr+/////f/e7PUVgLYCcrEAdK8Ac6wAdLEAdK8Ac7AAcrAAc6oBdK0Bcq4AdK8Ac6wA
c64Ac6wAc6wBcqwCc68Acq4Oe7P///3///9gpsoAc64Ac6wAc6wWfbX+/////v3///3+///+////
//3//v/+/v7////////////////+//////8Acq4Acq4Acq4Acq6ey+L////////////+///////+
///+//8AdK8Cc68AdLEAc64Acq4BcqoAcq4Acq4Acq4AcrABc7EBc7EAcq4Acq4AdK8Acq4Bc68A
c64Cc68Ac64Acq4Ac6wAc66ey+D///+dyeIAcq4AcrACc68AdLHc6/L///3///3//v/+/P3//v/+
//////3///////+IvtgAcq4AdLEAcq4Ac67H3u7////9//7/////////////////////////////
//////////////////////////////////////////////+/3OoAcq4Acq4Ac64Acq7f7vX///3+
///+/v7//////v///////v///////f7//////v////0PfLQAcrAAc6wAdK+Pwdr///v//v8+lcIA
dKwAcq4BdK0AdK8Bcq5Al8KLwdu62evO5O/P5fDK4uy51uiayN9ys9NAl8QUe7UAdK8Ac7AAcq4Q
e7P+/v7+//9fqMsAdK0Ac64Acq44kMD////////8///////+/////////v//////////////////
///+//////8Acq4Acq4Acq4Acq6ey+L////////////+/////////v////8Fdq4AdK8Aca0BdK0A
c7ABcq4Acq4Bc68Ac64Ac64Ac64Ac64Ac64AdK8Bcq4Ada8AcrABdK0BcbAAc6wAc6wAdK8AdK2g
y97///+dyuEBcqwAcq4Ac6wAcq74/P3+///7//7//v/////////+//3+///////////O5O8Bc68A
c6wAc7AAc65nqND+/////v//////////////////////////////////////////////////////
//////////////////////+/3OoAcq4Acq4Ac64Acq7f7fb//v///v////38/////v/+///+////
//////3//////v/+//8Qe7MAdK0AdLEBcqyNw9v+//+82+0BcqwAcq4AdLEAcq4ZgbbB3+r///3/
/v///v/8//////3+///////+///+//////2v0uYAc64BdK0Ac6wRfLT///3+//9gqM4BdK0Acq4A
dLFCl8D+/v7//////////v////3////+///////////////////////+//////8Acq4Acq4Acq4A
cq6ey+L////////////+//////////3///8WgbUAc64Cc60AcrAQe7EujL8ujb0vjr4ujb0ujb0u
jb0ujb0vjr4ujb0xjb4ujbsvjr4wjLsujbsvjcEvjcAwjLsujbu+2+v//f6ey+IAdLEBc68Ac64L
eLP///////3//v/+///+//3//v///////v///////////v8ihroAc64Ac6wAcq4Fd7Pg7/L///3/
//////3+/v7////+/////////////vz+///+/v7+/////v3//v/8//////v//////////v/+///A
3esBc68Acq4AcqsAdK/f7vX///////////////////////////////////////////////8Oe7MA
cq4Acq4Bc6+Pwdr///9ors8Acq4Bcq4Ac6wAdK/L4ez////////+///////////+/vz8/////f//
//////39//yv1OYBc68DcbAAc64Qe7P///////9fp80Acq4Bc68Acq5Pnsf/////////////////
//////////////////3//v/8//////3////+//8Ac64Acq4Ac6wBcq6gyuD+/v7///3+/v7///3+
///+//3+//0/k8EAcrAAcq0Ac64vjr7///////////////3//v/9/v/+/////v/+//3//v/8//3/
/v////3//////////v////////3+//3+//+ey+ABc68AdK8BcqwPfLX/////////////////////
///////////////////8//+IvtoCc68AcqsAc6wBcbBUocv+/v7////+//3///3+/v////38///9
//z//v///vz+//////////3+//////////////3+//3////+//+/2+kAcq4Acq4CdLAAcq7f7vX/
//////////////////////////////////////////////8Oe7MAcq4Acq4Acq6Nw93///88ksMA
c6wBcbAAcq44kL7////+//////39//z+//////3//fz////+//3//v/+/v///f+YxuAAc6wCc60A
c64Qe7P///////9fp80Acq4Bc68Acq5Pnsf////////////////////////////////+/////v/+
/v7//v///v///v8BdK0BcbACc68BdK2dyeL//v////3+/////v///v////////90s9QCc68BdK0A
cq0Ada3h7vb///3///////3+//////3//////v///////v/+/////v///////v/////+////////
/////v////2eyuMAcrAAc6wAd6wQe7P///////////////////////////////////////////3u
9fsRfLQAc7ABc68Bcq4Acq6Zx9///////v/////////////+//r//v/+/////v///v/9//7+////
/v///v/+//////////////3//vrA2+wBdbAAc6wBc68Acq7f7vX/////////////////////////
//////////////////////8Oe7MAcq4Acq4Ac6qPwdr//v8vjrwAca8Acq4Ada1VoMr+/v7////9
/v///v/+/////////v/+///8//v//f////3+//1ToskAc7AAcq4Acq4Qe7P///////9fp80Acq4B
c68Acq5Pnsf////////////////////////////////9//7//v////3//v/////9//4AdK0AcrEA
crAAc7CgyuD8/////v3////+/v/+//3+//3////B3uwAdK0EcrEAdK8Ecq9tr9L+/////v////3/
/v///f7//////////v///v////3///3////////v9/rj8Pb//////v/9/v////+fyeEAc6wAcrEA
c6wOfbX////////////////////////////////////////9//7///2OwNkBdK0AcrAAc6wAdK0C
da6t0uT////+/////v///v///v///f/////+//////////////////3+//2/2+lrrdD9+/7/////
//+/3OoBcbMAdLEBcq4Ac67f7vX///////////////////////////////////////////////8O
e7MAcq4Acq4Acq6Pwt3///86k70Bc68AdK4AdKwpir3//////////f/9/v////3///3//////v//
/f7//////v/L4e4DdKwBc68Bc7EAcrAQe7P///////9fp80Acq4Bc68Acq5Pnsf/////////////
//////////////////////3///3+/////f/+///8//8Fdq4Ac64AdK8Acqufyd/////+///+/v//
//////v//v/////+/vwlib0Acq4Ac64AcqkDdbHE3+r////+//////////////39//7///38////
//v////+//34+f1AlsUagrfS5u////3+///+/v6hy+MAcasAdK4Cc68OfLH/////////////////
//////////////////////////3////8/P43ksEAdK4BdK0Acq0Cc68AdK+FvNr8/f/+/v7+///8
/////v/////////+/v////////35/fyEvNcDdq8Bc69ZpMz8/f/9//6/3egAc6wBc68Ac6wAdK/f
7vX///////////////////////////////////////////////8Oe7MAcq4Acq4AcrCRw97+/v5n
rdEBcqoAda8Bcq4Bcqysz+P+//39//z+//////3+///+//3//f7////////Y6/EagrcAc6wBdK0A
dKwCc60Qe7P///////9fp80Acq4Bc68Acq5Pnsf/////////////////////////////////////
///+/////v////////0ZgbQCc60Ac6wAdK91sNL//v////v//////v////3+/////f////+cy98B
c68Ac6wBc7EAc7AWfrPQ5vH+/v///v/////+/v7////+/////v/+/f/////l8/Y3kr4Acq4AdK0P
ebO52Or+//////+cy90AdLEBc7EBc68Oe7T/////////////////////////////////////////
///+/f///v/g7/QWf7YAc6wCc68Bc7IAcq4Bcq4sjLyo0eX6/Pn///3+/////vz+//3///34+fui
zOIniboBc7EBcq4Ac7ABdKtapMv//P+93eoBdK0Cc60Ac7AAcrDf7vX/////////////////////
//////////////////////////8Oe7MAcq4Acq4BdK2Pwdr///2+2+0Bc68Acq0Cc68Acq4Fd7OX
xd39/v////3//v/+//////////309/yLwdkPerIAcrABc68Ac64AdLEAcrAQe7P///////9fp80A
cq4Bc68Acq5Pnsf////////////////////////////////+/////////v////3+/v7//f9FmsEA
dLEBcbAAdK4QerbV6fT+//3+///+/vz+///V5/Nprs3F4e3//f87k8EAcrEAcq4AdK0Ac64MdrKL
wdvy+vr///3///3///3///3////4/P2Xxd8SfLYAdK8Bcq4Acq4AdK0Ygbj1+P3//v+fyeEBc7EA
crECc60Qe7H///////////////////////////////////////////3+///+/vz+///S5vEPerIA
dLEAdaoAdK4BdK0Ac6wAcq4Re7VGm8RurtJvsNBgpc5BlcMJeLAAdK4Acq4AcrAAc6wAdK8AcrAt
jrvp8vm+3usAc64Acq4BcqwAdK/f7vX/////////////////////////////////////////////
//8Oe7MAcq4Acq4BdK2Mwtr+//////9ClcEBdK0AcrAAdLEAdK8Ac64cgbVnq86Mv9qTxd5+utZN
nMcOeLIAc64BdK0Bcq4AcrAAdK8Cc68Ac64Qe7P///////9fp80Acq4Bc68Acq5Pnsf/////////
//////////////////////////////////3+//3///3+/v+XxtoAcq4Ac6wAc64BdK0Fd61PnsVx
sNNlq80xjb4AdqsAcqvA3un////g7fMWf7gAc6wAcq4AcrAAc6wAdKwQerRYo8qGv9qVxN6FvNpZ
o8gNfLEBc68AcrEBdK0Acq4Acq4Me7LJ4O7//vz///+gyuAAdK4BdK0AdK0RerP/////////////
/////////////////////////////////v/+//////3////W5+8ghLYBc68Bcq4Ac6wBc68AcrEA
c6wBc68Ac64AcrABc68Ac64AdK8Bc68Acq4BdK0Ac6wAdLFIm8fx9/f///+83OkCc68Ac6wBc68A
cq7f7vX///////////////////////////////////////////////8Oe7MAcq4Acq4AcrCSwdv/
/f7+///l7/gagrcAdK0Bcq4Bcq4Bc7EAcrAAc64AdK0Acq4Bc7EAdasAcq4Ac6wAc64Ac7ACc68A
cq4Ac6wAc6wQe7P///////9fp80Acq4Bc68Acq5Pnsf/////////////////////////////////
//////////////////3////1+P0Zg7UBcq4Ac6wAc7ABcq4Bcq4Ac64BdKsBc68Acq4AdLG83On/
//////3Q5+8TfrYBc68AdK0Ac7ABc68Bc68Ac6wAcq4AcrAAc6wAc64BcqwAcq4Bc7EAc6wAdK8W
f7bL4+///////////v+dyuEBc68Ac6wAc7AOe7P/////////////////////////////////////
///9//7//v3+/////v3////////t9/lfqMsAcq4Ac6wAc64Ac64BdK0Bcq4Bc68Ac6wAc6wAcq4A
c6wAdbEBcqwAc64LeLCLwdv9//7///////3A3OoAdLEAc6wAdaoBcbDc7fT9/v///v39//7/////
///+///////+//////3+/v7+//3+//8Oe7QBdK0Acq4Ac6yNw93+/////v/////e7PcyjL4AdKoA
c64Bc68Acq4Bc68Ac6wAc6wAc64Bc68AdK0Ac6wBc68YgLVurtIBc7EAc64Ac6wQe7H//////v9e
p8oAc6wAc64AcrBNn8X+/v7////////////+/v7////////////////+/////v/////+/////fr+
///H3uwLeLAAc64Ac64Bcq4Acq4Ac6wAc6wAc7AAcq0Bc6+/2+n////////8//3e7fQ4kL4AdKwB
dK0Acq4Bcq4BdK0Ac64Cc68AdK0Ac64BcqwAdLIDcawAc7BEl8Pm8ff+//3//f78///+//+hyeIA
dK4Acq4AcasOe7P////////////////////////////////////////+/////vz////+////////
///+/////v/N4+5WocgFdrAAca0BdK0Ac7AAcq4Bc68Ac64Cc60BcbABcbASfbNys9Pm8ff//v/+
///+///////A2+wBcqwBc68Ac64AcrDf7PL///////3+///////////+///+/v7///3+/v7/////
/f////8Qe7EAc6wAc7ABcq6Mwtr///3+/v7///3///35/fyQwt0bg7gBcqwAc7AAc64Acq4AcrEA
crABcqwAcq4OeLRvr9Lr9viy0+YAc6wAc6wAdK8Qe7P9/v///v9fqc4Acq4Acq4Cc69Oncb/////
///////+/v7////////+/v7////+///+///////+/v78/////////f7+///Q5+9ClcEAc7ABdK0A
c64AdLIAcasAcq4Ac6wsi7nZ7vP+///////////////5/fyZxuMhhbYAc7IAc6wAda8Ac64BdK0A
cq4BcqwAcrAAc64xkL6r0OL///////3//v///v////3+//+gyuIBcqwAdLIAdLEQe7P/////////
/////////////////////////////////v/+//3+/vz//v///////vz///////3///////3s9fyo
zOJtr9FGmsYyjr8xjb46lcJWn8h8udi92+b5+vz+/v////3///////////3+/vzu+fu/3O7A3OjA
3OrB3en0/P7+/v7//////////v/+/v7+//////////////39//7////+///F3Oq93O7B2+i/3Ozi
8fj////+///////////8//////38/P682el5udVOncQ6ksA2kcBHmcFsrs6n0OTz+Pv+/v/+///r
9PvA2+zA3OrA2+zC3uz////+//3W6PLB3O3A3Oq+2+nV5/P////////////////////+/v7/////
///////////////////////+//////3//vv+///////N5e+Hvddmqs9Wochiq86HvNvK4O7///3/
/f7+/////////////fz8///+//3+/v/C3uyAuddTnsU7lMAzjr1EmMRgpc6Pwt/W6fD/////////
//3//v/+///8/////////vzo8/W93ezA3Oq/3ejD3+3/////////////////////////////////
/////////v/////+//3////+///8/////vz////+//////3+/v7+/////////f7///3///v///3/
///////////////+//3+//v///////3//////v/+///////+//v//v/+/v79//7/////////////
/v////3+/////v///v/////8///////+/v7///3+///+//r9//7///3//v///vr///////////3/
/f7//////v/+/v/////+/v7////+///8///////9//7//v////3///3////////////////9//z/
//3//v/+///+//3///3////////////////////////////////////+/v7//v/////+/v7//v/+
/v78///+/////////f7///3//////v///v///v////3//////f7//////v/+/////v/+///9//z+
//////3////9/v/+//////3//v/////+//////v///3//v/////+/////v///v/9//7//v///f7/
//////////3///3+/v///////////////////////////////////////////v////3+//////3/
/f7////+//3+//3////+/////////v/+///+//3+/vz+/f////////3+//3//v/+/v///////f/+
/////v/+///+//////3///////3////8//////3////+///+/v7//v/////+/v7///////v//v//
/v/+/v/+//3+/////v/+/////////////f7////+///////+///+//3+///+/vz////////+///+
//3///3//v////3//v///v/////////+//3///3////+/v7+/////v///v/+/vz+/////////v//
///////+/v7////////////////////+///+/v7////+//////3//////////////v/////////+
/v////3+///+//////3+/vz//v/+///+/vz8//3+/vz+//3//v///v/////////+/////////v//
/////v/////+/v////3+/v7//v/////+//////////3////8///8/////v/+/v////3+//3+/v7+
/v7////////////////////////////////9//7+///////////+//////3//v/+/f/+/v7//v3/
///+/////v///vz//////v/+/v7//v/////+//3////9/f3///3///3+//3//v/+/v7///3//v/+
///+/////f////3////////////////////////////9/v/////+//3///38//3////+///////9
/v/+///8//////3///3//f///v/+///+/////v///v/+/v7+/////v///f7////+//3///3////9
//78/////////f7///////v///////39//7//////f7///39/v//////////////////////////
//////////////////////////3///////////3+//3+/vz////+//////3//vz//////v////v+
/v////3//////////v/+/////v/9//z//v3////+/////v/////+//////3///////////3//P//
/v////3//v////39//z////////+/v7//v3//////v//////////////////////////////////
///////////+//3//v///////f7//v////////3///3///3////9//78//3///////////////3+
//3//////v/+///+//////3+///////////+///////+//3//f7+///+/v7///3/////////////
//3//////////////////////v/+/////////v///v///v///////////v///v/7//////3////+
//3///3////+///+/////////v///////////v/////+///+/v////v//f///v/8///////+/v//
/v/+/v7////////+///+/////v/////+/v7////+/v7//////////////////v//////////////
/vz////9//7+//v+/v/////+/v////////3//v///v/+//////////3///3////9//z+/v/////+
///+///////+/v7///3+/v7////+/v/////////////+/vz+//39//7+//////////3+////////
///+//3+/v/+/////v////3////////////+/v7//////////////////////////v/+/v7/////
//3+///x8vTExce2t7nDxMjv7/H//////////v/////+///v8fDDxMa2t7vGyMf19fX////////+
/v7//v/////c3N7Gx8n9//7//////v/Z29rJycv///////////////3u7/HBwcPy8vL////+//3v
6u7BwMX29/v///3+///9//77+/nBwcP3+fb////////V1dfh4eH////+//////3///3U1NTX2Nr+
///////09PbBwcP//v/+//////3+//38+v/BwsT39/f////+///+/v7+/v7////k5ee+vsC3t7nN
zc/5+fn////////////////////////V1dXMzM7///3////+//////////3f4OLAv8TBwcHCwMXA
wcXMzs3+/vz//////////v/U1tXf4OL+/v/////////////////29vbJycm3trvCwsTt7ev/////
//////3////////o6OrHx8n9/f/////+/v7Lyc7s7Oz//////v/////+///19ffExsW6ub7OztD5
+fn////////+/v7////////////////////////////+/v7////+/v7v7/GYmJqxsbPOzs6wsLKo
qKj////+/v7////////o6OqYmJq0tLbOztCtra+bm53w8PL////+/v7+/v7////BwcGSkpTR0dP/
///v7/GWlZqen6H+/v7////////////j5eSRkpSxsbP////9/f+oqKqSkpTx8fH////////////4
+PiRkpby8vT///////+0tLbIyMr////////////+/v60tLaTk5Xi4uT////r6+uSk5X////+/v7/
///////4+PiSkZbw8PD////////////////X19mVlZfAwMLKysyjo6XGxsj/////////////////
///6+vyZmZuTk5Xx8fP+/v7////////////g4ODBwcOtra+enqDBwcPNzc3///////////////+y
s7XJycv+/v7////+/v7////09PadnqCtra/OztC2triVlZfl5ef+/v7////////////V1dWSkpTC
wsT+/v7///+fn6Hc3t3+/v7///////////+qqqyys7XLy82np6nV1dX////////////////+/v7/
///////////////////////9/f3///+2triysrT////////////4+Pj///////////////+vr7G6
urz////////9/f+rq628vL7////////////////AwMKenaKYmJrx8fGurrChoKWen6P////+/v7/
///////i5OOUlZeampzY2NjNzc2enqCTk5Xx8fH////////////4+PiRkpbx8fP///////+zs7XI
yMr////+/v7///////+zs7WenaKbm53z8/Pq6uyRkpT////////////////4+PiSkZbx8fH////+
/v7////9/f2ampzQ0NL////////7+/38/P7////////////////////S0tSqqqy1tbfDw8X////+
/v7////////+/v7////Pz9GsrK7///////////////////////+0tbfIyMr///////////////+/
v8Gpqqz+/v////////++vsCqqqz////+/v7////////X19ebm52UlJbb29v+/v+fn6Hc3t3/////
//////////+YmJrMzc/+/v/+/v/////////////////+/v7/////////////////////////////
//////+hoaPR0dP////////////////+/v7+/v7///////+ZmZva2tz////+/v7////MzM6lpaf/
///////////////BwcO6ury5ubufn6GgoKLX19men6P////////////////j5eSXmJrZ2duampqX
l5fh4eORkZPx8fH////+/v7////4+PiRkpby8vT///////+zs7XIyMr+/v7///////////+0tLbH
x8m2trioqKjp6euRkpb////////////////4+PiSkZbx8fH////////////x8fGSkpTv7/H////+
/v7////////+/v7////////////+/v+jo6XY2Nrk5OaXl5n6+vz////////////////////Pz9Gu
rrD+/v7///////////////////+ztLbIyMr////////////+/v6qqqzHyMr+/v7////////d3d+T
k5X////////////////W1tamparX19mXl5ft7e+gn6Tb3N7////////////+/v7R0dOVlpibm528
vL7z8/P///////////////////////////////////////////////////+rq63CwsT/////////
///////////////+/v7///+ioqTKysz///////////+9vb+wsLL+/v7////////+/v7Cwca6urz3
9/ednZ/j4+Xd3d+dnqL////+/v7////////j5eSYmZv///+zs7PExMT4+PqTk5Xx8fH+/v7/////
///7+/uRkpbp6ev////+/v+wsLLJycv////+/v7///////+0tLbIyMr5+fujo6OsrK6Rkpb/////
///+/v7////4+PiSkZbx8fH////////////4+PiTk5Xi4uT////////+/v7////////+/v7/////
///g4OKRkZOxsbO0tLaTk5XPz9H////////////+/v7////Pz9Gtra3/////////////////////
//+ztLbJycv+/v7////////+/v60tLa4ubv////////////Q0NKgoKL////+/v7////////W1tam
pqj///+9vb2kpKaamZ7c3d/////////+/v7////////5+vzf3+GoqKqzs7P////////////////+
/v7////////////////////////////////Z2duVlZfX19nz8/PZ2dm6urr9/f3////////////Q
0NKXl5na2tzz8/PT09WVlZfe3uD///////////////3AwMK8vL7////z8/X////d3d2en6P/////
///////////j5eSXmJr////39/f8/Pz4+PqSkpTx8fH+/v7///////////+nqKyysrTu7u7c3N6V
lZfj4+X+/v7///////////+0tLbJycv////t7e2VlZeSk5f////////////////4+PiSkZbx8fH/
//////////////+6uryhoaPk5Obz8/XGxsjPz8/+/v7///////////+vr7G5ubvW1tjW1tjAwMKi
oqT+/v7+/v7////////////Pz9Gtra3////+/v7////////+/v7///+ztLbIyMr////+/v7/////
///h4eOSk5XQ0NLy8vLd3d+ZmZvNzc/////////////+/v7X19empqj////8/PyoqKqTkpfb3N7+
/v7////////4+Pi1tbXg4eP29vi+vsCtra3/////////////////////////////////////////
///////+/v7////S0tSdnZ+SkpKenqDY2Nj////////////+/v7////OztCdnZ+SkpShoaPZ2dv/
///+/v7///3////////Fxce/v8H////+/v7////f3+Gkpaf////+/v7////////k5uWen6H////+
/v7////5+fuZmZvy8vL////////////////r7PCqqqySkpKZmZvMzM7///////////////////+5
ubvLy83////////Z2duXmJz////+/v7////////6+vqXlpvz8/P+/v7////////////7+/2+vsCY
mJqSkpSsrK7q6ur////////+/v7w8PCampz09Pb////////6+vyenqDi4uL////+/v7////////R
0dOxsbP///////////////////////+4ubvMzM7+/v7////////+/v7////Z2tyhoaORkZOcnJ7N
zc////////////3////////Y2NisrK7+/v/////y8vSdnZ/e4N/////+/v7////+/v7Kysyen6GU
lJalpafq6ur////+/v7///////////////////////////8ADwEAAAMAAAABAJIAAAEBAAMAAAAB
AC4AAAECAAMAAAADAABPdgEDAAMAAAABAAEAAAEGAAMAAAABAAIAAAEKAAMAAAABAAEAAAERAAQA
AAABAAAACAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEWAAMAAAABAC4AAAEXAAQAAAABAABOtAEc
AAMAAAABAAEAAAEoAAMAAAABAAIAAAFTAAMAAAADAABPfIdzAAcAAAxIAABPggAAAAAACAAIAAgA
AQABAAEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMg
c1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAA
ABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAAC
VAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFz
AAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0
ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAA
AAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNR
AAEAAAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAA
AGKZAAC3hQAAGNpYWVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3
LmllYy5jaAAAAAAAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERl
ZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERl
ZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAA
AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA
AAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAA
AAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAA
AABDUlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkA
XgBjAGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDr
APAA9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEB
qQGxAbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKi
AqwCtgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD
7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3
BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08H
YQd0B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmP
CaQJugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIM
KgxDDFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8J
DyUPQQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUS
ZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYD
FiYWSRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQa
KhpRGncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6U
Hr4e6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2Yj
lCPCI/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijU
KQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIu
ty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTY
NRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7
qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1
QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdK
fUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8
UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVb
RVuVW+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RA
ZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbblu
Em5rbsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gR
eG54zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC
9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/
jmaOzo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ
/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYa
poum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKz
OLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBw
wOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbO
ts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q
3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vs
hu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH
/Jj9Kf26/kv+3P9t//8AAAAA

--_004_5152F9BB039C40C59BBB2DCACCB65575chartercom_--


From nobody Mon Nov 22 05:23:00 2021
Return-Path: <internet-drafts@ietf.org>
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 AC46D3A0975; Mon, 22 Nov 2021 05:22:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sidrops@ietf.org
Message-ID: <163758737463.29518.7867333115141485613@ietfa.amsl.com>
Date: Mon, 22 Nov 2021 05:22:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1yfoNOeM8kMx8pdK1a9pqqUFUJw>
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-09.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2021 13:22:55 -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           : The Use of maxLength in the RPKI
        Authors         : Yossi Gilad
                          Sharon Goldberg
                          Kotikalapudi Sriram
                          Job Snijders
                          Ben Maddison
	Filename        : draft-ietf-sidrops-rpkimaxlen-09.txt
	Pages           : 14
	Date            : 2021-11-22

Abstract:
   This document recommends ways to reduce forged-origin hijack attack
   surface by prudently limiting the set of IP prefixes that are
   included in a Route Origin Authorization (ROA).  One recommendation
   is to avoid using the maxLength attribute in ROAs except in some
   specific cases.  The recommendations complement and extend those in
   RFC 7115.  The document also discusses creation of ROAs for
   facilitating the use of Distributed Denial of Service (DDoS)
   mitigation services.  Considerations related to ROAs and origin
   validation in the context of destination-based Remote Triggered Black
   Hole (RTBH) filtering are also highlighted.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpkimaxlen-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



From nobody Mon Nov 22 05:37:31 2021
Return-Path: <benm@workonline.africa>
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 4D1513A0A0D for <sidrops@ietfa.amsl.com>; Mon, 22 Nov 2021 05:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=workonline.africa
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 hEFtsAwXjAxt for <sidrops@ietfa.amsl.com>; Mon, 22 Nov 2021 05:37:23 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 52B933A09F5 for <sidrops@ietf.org>; Mon, 22 Nov 2021 05:37:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eHpmaqcnyaXhcoH9fH9rzA8oSiI57px9I2tKChXB/M9dN7DA1u23XGRSWxu3l8x9h/eNQB1zLExtm4PkM+PnlFZOklPgmgZVGuENF8q3+KYR6u/0nfEQ1OmGZEuqy4IbtPHSgLZDTpBFxunt1T0e/y5h5iTnTglu5chHc7rK0OcbrIp0y72QZgG/iYY41mxbzP+LeOJra0W4JzwneVmE3WErO1YKCzkgmCdYiESDHzZnnw/5l7zb4CzOe8DLLeE9h1+dcLTKMOtA3uIT9VxQDPjr7TJUISaN0lwBwoXPHILNApXp2EQrBxRq469WK/w/KYNZ5B+aLcJOPfTrLOR85w==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0unKojUc1hRbjdLOKvWSUBqKm4mH2l2jBHchFfBFFUQ=; b=noq13QJ+cjUf/nKTTsCjKEa2nSYO3wn+Czz/fxPCPLdFM6V8Z260KAPEDwj3Mh+TTFRQPGMhvPEMn8/dPbkIynYiHWcdStJGFK2QnNOvkoPQfYQH5RgL1K6OX0wbGm5quTvBodquCbgXeQ8FfK65DsO527r0O48+EZcb31z0u2KcblX+HF64XaWPmxYO4CobuN2y1H06KJ3x8qTLmBSude6eDeydCtLrNePOy4YvjHr35S7Scq+G5LUPKTde6bM/kjqtCqpzCbNMC0h55qt73UbQ3zs5aEAy8SodYb8xndubRYFLiYEIUmf9vcyePYqcXBmfszdpz/XU2eJCgJkmKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0unKojUc1hRbjdLOKvWSUBqKm4mH2l2jBHchFfBFFUQ=; b=aO8YIYlRsg1uKWM98xFGmTdppclGX1f02413qcFJcSbMVwm0gNNj3PVobMB3CcTOPgqHqeFhC1eT6PT86tqjnEk4vUXRk4XuCE7VlWn+51PZ7I260CYTwRG0+31/0o5m1VOe7qUKFf+ZfiLZ3IFjuLtu1v0y03xEHfQxqfvKrrk=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa;
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1141.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2b6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Mon, 22 Nov 2021 13:37:19 +0000
Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%6]) with mapi id 15.20.4713.024; Mon, 22 Nov 2021 13:37:19 +0000
Date: Mon, 22 Nov 2021 15:37:12 +0200
From: Ben Maddison <benm@workonline.africa>
To: sidrops@ietf.org
Message-ID: <20211122133712.4zs5x62j3jjpi3r3@benm-laptop>
References: <163758737463.29518.7867333115141485613@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fevtyyavnwy5jghz"
Content-Disposition: inline
In-Reply-To: <163758737463.29518.7867333115141485613@ietfa.amsl.com>
X-ClientProxiedBy: CT2P275CA0029.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::17) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13)
MIME-Version: 1.0
Received: from localhost (105.233.97.54) by CT2P275CA0029.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19 via Frontend Transport; Mon, 22 Nov 2021 13:37:19 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ae74c1c8-a09c-4204-b195-08d9adbd34a7
X-MS-TrafficTypeDiagnostic: AS8P190MB1141:
X-Microsoft-Antispam-PRVS: <AS8P190MB114167C0DC003641D77EB808C09F9@AS8P190MB1141.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: rhzh2StCVqxH4zBiS1TC7xN6KMrqUgnEqBWRLOBr5qZ8/2ZdogzEP/SvNAVBZcS+iDYkjDoc4z9yfwob8fq5aTVeTF6G2WLxPSgMzKnJKhNDpQ/4BX/Dk9UGXTbgyutTUsqiJuE1LdYtTVuq4/Lc269Kzi8/+rDOYyQ4M7jebe88rjm9Kzj/6TzHlYQi8K7SEgcJI7Pabxa1mZ5h5cZqQ1q9NIMRplFl/HbNmWBmvlxKiHNQzxMxbQrtsM/6f2JjgwOguzP6IWTCV4AMnPvXbwzzgs3d/HS5KO3ZroaVox6pgj/eriz7EXJGTSwG1UvQ4Rv1Fbhx1az4f/09dhoEhrW2O5/LEJ1qt3NNU7Dqme/fQWGkRY8wasR3VSL3zeWI7md5yZJTUC1Vy5/nxjSgoNYEiYLBoIHAIVfGNU8l8hUXOu2wQFfXSSZWS+wTmBjEGrfDIiwBnwfBu6vXS1d2nHQf8PMAQd4lQJq0EBver6L6Xi9OZnOiLfHTXYrmPInvJB5ZaV/W1Z23PG6cJqTW8U/SC8dVMCvUjur38K4wpD2+m+EYXSu35Phs7CLhhNJYlr9VqfNy8mnOzp5V/BCZAT6VxYugW7WEnpUqNjm6Itwz7Gk4BW7vniZnhcB+NfYet2q9l/QPE/Y3MWnrkJadYi7y8XSaTo09TNM89XL+ibpFHoAdSci48jaZBakoziQ8JiWD3R5fzIZyGPCkamoKQwxpySTwWaHcmFSvDvq7RVZzaepK6uGoyq5RO3Q95RgxYJSp8iz7yd64CR8cagHPVQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AS8P190MB1078.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(7916004)(376002)(39840400004)(136003)(366004)(346002)(396003)(6916009)(2906002)(8676002)(6666004)(66946007)(21480400003)(1076003)(38350700002)(186003)(26005)(4001150100001)(38100700002)(9686003)(5660300002)(66556008)(508600001)(44144004)(6496006)(8936002)(6486002)(33716001)(316002)(86362001)(52116002)(66476007)(956004)(66574015)(46492014)(2700100001); DIR:OUT; SFP:1101; 
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?DjLaOAsr8+t7hTYKkckQeNxZ9z+Rqk+IXmxYno/UkuwDTTrCpy1reFPouJij?= =?us-ascii?Q?oEKoydLqx268TjCAWJFlw+4PaTjjhaCalZU4GHOafHQB0kQSDNNt5Fr28wGM?= =?us-ascii?Q?nOwgrJGeQm3byKvjoXdBBcx12gcvsp0+hBe3oOp7SrCIBfork3MWj8Z10Mq5?= =?us-ascii?Q?Q4BcDHn2gCL1L2DQ7tNDCyeO6NQF1pDJThYTBwVYdOQvB6YreixA2C1w6Iak?= =?us-ascii?Q?EDd2+MGUNBOaQxxX534dim3Za86+y0sCRHInRodXLIRaxrblVuctp2YpYOU3?= =?us-ascii?Q?v79AtbFO2zUBYJJybtimH9pt/wvDZ5DzdZrh4VzKQKXIR15Qidq1ay0uPTJ6?= =?us-ascii?Q?7f99pBpi2FN8uN8fdIfK+pOIBquD9TkKwI77yVYeLPqrV8Rd8hhp/Mv6MPXr?= =?us-ascii?Q?mRjXLNKlKxubahg1pKVZM/HHmkLRZDPG4vircE86UVJ+//G6YV4+Yu/nBDjW?= =?us-ascii?Q?2wd22CfEjysy4mLUXYw7o55VOvuohY2pLHs2zex9SfH//Ckn5Gf2sFTjX+8k?= =?us-ascii?Q?FkY6cJ+0wcGeodXURJoGVeLfPF5k0pt00vgj5KtT4Pxb9nI1y62k0YudGv+c?= =?us-ascii?Q?7cXDnyRNrYURzO04rPzgag5oKbTBL/ubHN8fK5D4xnKmJbXpo5EGE1D9p0rS?= =?us-ascii?Q?+pIAgs8VdtCdRPn0rsMI5g3RqIxgqmq6Eoo7OTIzqm72YV2ClGgpvjbqbJj+?= =?us-ascii?Q?0rf2CotJEXNj8LoDODG2HKOO0etz+WZklVKudZT8SuK7hWzsqzQPQ8UvMfxW?= =?us-ascii?Q?yMOP6BXYP0+3RKBMiRW/Vfr30Ar1Mv1TPwV3JPe9f8BzZiNFEv06IN7jTdqL?= =?us-ascii?Q?CdfYOaeBorlDSLXKY1UaRoCSmHp/mot2Ju9K8cm61Vrze/TxDNvJwp8klx3C?= =?us-ascii?Q?3L/VXnqxPmgJPUJ4lUYu+mymHixS5hgk8G3o5cw6OhAYCPConB2iGQuxp7he?= =?us-ascii?Q?m74EaEY4s87YbKqmHDf401ezbr+fqUInRxD2o/XWTkixeOCVriKFkAjehVzy?= =?us-ascii?Q?QUbnrqUxd0knmUjLLnxDJF8ECJtn64hhygYsvN7MeATJOvSw+o3GqRLZAQ8h?= =?us-ascii?Q?1BEL7nHD5KN7zvpL0CtevfOAqAbK+UmempF0tZtjfXc+SKXQsblG8HjF4Y+x?= =?us-ascii?Q?B8erHEQ57FxwmzF7WtbvF5Sb3VJFqApMZrFfs6fgtSBZrV/XV36kfTIEqExZ?= =?us-ascii?Q?foba0paz/sAqYnhr1kooJMLK8ahagVABoUGyrKIsDF8sESBSqykcDk3zpNG7?= =?us-ascii?Q?YXVY7eJiSkx52ZAdDzoJ78YIOof0p4lSvE/Frw514jNkGGqtHvb/r0zr4YLg?= =?us-ascii?Q?TW45/mGW+MTllWi2XcEKdZSa7VqEj+H6M1QvDNQScgq23MW/Dg6lm1NaIhT0?= =?us-ascii?Q?jL8vjjogwU3NNGBp6Mv+gq92J9PqRv/Ru4Z5roOaoihQw/PTlNeAyyYtgjql?= =?us-ascii?Q?A2UYwFgtQg53Vi1mpf8+E37sHe0VhonJOQpnawA5mep0EylYIKP9le/IgUVO?= =?us-ascii?Q?6Q+tE/HteTEGZ3qkY4dKwKxAWMmw76XGVK/j+WTRSU24vY7lgk+sB/5oe06e?= =?us-ascii?Q?P4PLstAQqr8oVdKaIVHI3iTTCYT5iyjZYpzvEcR3A00WIHOL7IW1ECz1n6by?= =?us-ascii?Q?qsIZPLS5ppBhkAy01P1TAS8=3D?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: ae74c1c8-a09c-4204-b195-08d9adbd34a7
X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2021 13:37:19.4311 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rt99c/90xL94N1zRjMf8SHEAbv5kPal+tTkL2JIPbHFAVyv6mlgivFKPpLbyIjJKhWJDhSQUAJJPOUcZ4G2/bA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1141
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RLSEHmB3DkSCtYPO2bF1wQ6uIws>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-09.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2021 13:37:29 -0000

--fevtyyavnwy5jghz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

On 11/22, internet-drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the SIDR Operations WG of the IETF.
>=20
>         Title           : The Use of maxLength in the RPKI
>         Authors         : Yossi Gilad
>                           Sharon Goldberg
>                           Kotikalapudi Sriram
>                           Job Snijders
>                           Ben Maddison
> 	Filename        : draft-ietf-sidrops-rpkimaxlen-09.txt
> 	Pages           : 14
> 	Date            : 2021-11-22
>=20

-09 has been posted to address the comments received during WGLC (thanks
in particular to Ties and Amreesh), along with a bit of editorial
housekeeping.

Hopefully this is now ready for publication.

Cheers,

Ben

--fevtyyavnwy5jghz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmGbnQgACgkQOkYk/rSL
aGDonQ/+N8e/18w+zL4cv1btXesAE3mB/3L8qbZ+Wezi/L/jz3VD0x+rByfbmswY
6zdGPSZ+gTew+4Uh04m1snJeHuI3bNqk3tAsQLTyRtfq8HakvWvuCQSCzXq2AZPR
/p7OMBUSo4H6NltyLJT3BMElEngACO2Nyj5CY08wh0oozZRVe4Zr2986WI4zglfs
yIAN/eOjRpshuzgMmgxjqnBRkAVBvrQnxyZYhRlSIr7CgSSwm6XPfz1DEdgjHXaQ
WIFeS71E0qI0hK5Xfzzkkt5iuIKBezPp2aNf411qcQH3b7YrVuRVEVOn0tAfp7JA
OBLE4YgxG0unAVX/CHq8B1JloegS1BtqxpQYVX3ofpOawK2kuLff+6b7z/h2WOhw
SnL7QEyh8UXLjgbuT6ALILjwx+0E9S6GunrjVYU6G+lZDYjneDOeVb6lkhEMaMnp
c3cN1vIrLSN3bQBuJjXAghWP3hvfQV7kBCMN82A4fgNe7yiJiCtpWGLnFU79UPjA
GG0R8GhnFt+CTVznnEAFQIwx8yMxW2T+VV1b3I4dvKDLrZToSnr+fCx8VJYAVH1p
u8TIPL/6XKqoCSrATKczMnv4/aO4hxeF7ZdjJyUWW7fK1NQsmNpNfaa0/32PbrHV
6qzbDurIUpBVaLd+vdGASHfiWve/b0UO3aMw3abor39oW9tP/ic=
=r3z6
-----END PGP SIGNATURE-----

--fevtyyavnwy5jghz--


From nobody Mon Nov 22 06:52:44 2021
Return-Path: <kotikalapudi.sriram@nist.gov>
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 C5A323A0BD1 for <sidrops@ietfa.amsl.com>; Mon, 22 Nov 2021 06:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 S3YR1Zkndzss for <sidrops@ietfa.amsl.com>; Mon, 22 Nov 2021 06:52:38 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2118.outbound.protection.outlook.com [40.107.89.118]) (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 D7EEE3A0BCE for <sidrops@ietf.org>; Mon, 22 Nov 2021 06:52:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zqb+QINN77flda1Z8/Us5rFCt+ynF7sqAnAquAgQRtY6gUe7RSDbz4HIEvkXz554MHy0afW/Xw9fbxc701PlCAt6VaQKGpd/KuPcZaTW51sAmsvSv7l6IqG0urIEsKB+n5AiJssnUY34pxsMPJpqwIlWuj/ZG9ONw+OfVUiYBbXsp/BfOVeDDN9tDTjWV7ts9SZHTLqBy1gSBNCEy8M02oalG92GVcp/W/HsOHRr1UFp6P/4GasU5IPoRdjpPKvOr0M8wJUvVNgPhs6nHAClQ/QnLsGTQQe4Z5aZKqflC4P1ukKtXzYx6whB29xJp5SjhhdRuKxLfc2GtJhIo1wogQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q6pFhWUOAzfOMligkimdkQsWX3t/8wCpqe24k4WJols=; b=LdHiE/I20r/SLSpm66uz2NGW1XVxWfEnyN+LOcAosiDDoMiCj6qigVBpNYU32eGWfVserRaHbxjcYDVooiu5B0ud0/AYf7uivRT+uGdzLUPYqu7DbskoUTCx/STnb/4Rc4EfwVZFXLvflxtLEz8aRjaLVZTTy2scwJneNx0+R2NDj+WtOi1Uoo792wEzBv7k/2Nlejzm4C9NLQ4YFmEaiq6dqcC1XnH+SMtNFVjonFMm/vwyx+exl56ZIBiFV+DnxlRninouakImbl25tGOM7h795gI6xpfo9FC7QDFwdtY8TeZdMu31w0gaTJtgaRGIz+5vqtPqCdkIXNlTJkxQfw==
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=Q6pFhWUOAzfOMligkimdkQsWX3t/8wCpqe24k4WJols=; b=s1EBpAbyhnlvNcA0v7rlMCgjGk3/O6xZdRk0pTGxXOKaWOgAr6t3+AkNnGtfh9rqPJdr2snWWcORTrEYPWSwQgFArpDBFvrJ6l4GJfTgkLIWX11gEsUXQP1C5oP2NhQSb0wXDN/6HBFv//r5y2m9leOgm9j4io3gZtayZ6YlREs=
Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB7630.namprd09.prod.outlook.com (2603:10b6:806:179::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Mon, 22 Nov 2021 14:52:32 +0000
Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::bd9a:9a9e:82de:1b3b]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::bd9a:9a9e:82de:1b3b%3]) with mapi id 15.20.4713.025; Mon, 22 Nov 2021 14:52:32 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: "Compton, Rich A" <Rich.Compton@charter.com>
CC: Alexander Azimov <a.e.azimov@gmail.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] Grammatical errors in ASPA doc
Thread-Index: AQHX37CTEIYuJfZO3UOwkmM6ZZ0y1Q==
Date: Mon, 22 Nov 2021 14:52:32 +0000
Message-ID: <SA1PR09MB8142DA185C9615411F721ABD849F9@SA1PR09MB8142.namprd09.prod.outlook.com>
References: <SA1PR09MB8142E683DCDF66810A17DD4E849E9@SA1PR09MB8142.namprd09.prod.outlook.com>
In-Reply-To: <SA1PR09MB8142E683DCDF66810A17DD4E849E9@SA1PR09MB8142.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6b439fd0-750a-48b3-9998-08d9adc7b687
x-ms-traffictypediagnostic: SA1PR09MB7630:
x-microsoft-antispam-prvs: <SA1PR09MB7630C09F477CD1E192078B3D849F9@SA1PR09MB7630.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SVRAzV3tWNl8hvaAaHICPqfWmJrFDzC3HfPQwHL3tpFnWNp2Yv5yCSLKVj7SsVMwrjZ1NbIB9tChNyhPWbiHB9siCISiLfzVaCGxIDm0xtWdYbBn+HtLhxl1+BNWF/Ed8/rk24ugzoAJ+EG6H6WwKVDd3n424BErAI/XhX7bGwi8wuZV3X8sU2cp9RDJMkE5QYD20Ste7F3exHEoxq/Hf6hfn5CRssfJAStmAKrXhvfpGdytfwblBMbEKkAFohH+mvHpntnCQwslzP57LnDJqBA9+Q4TYUjkOXSBMc/AsPLy/wQy1aH7W0O4xOEVAUXAwiHR9mSc5ucFPHgwDBrb/hU4CULi6bmCuyy1KCgiDFkCckT4+v+kM4TOUGUZDgLMrBzWVYMkueTCf26EvD2ebt+vhHLfWy4WDTt56TwGKD/sOKLHWg7wHahWBJskg/7mh8LmZYq8rRUyPQmnm+cYIxhcB2BA20G8g+28nuP3DEZK9DGRYyNKHbbKwtFh6AJT01+qsE79MNIhKcrUI00T7GSd+01KLZm/ikMdJSdf9K5VSCjUX/o65qSDKaqg7Lp2JRuDpIX7PyPjB5L9FonSjL1TOiRdbo5mc13LzeEH0djhNYWxAB6oz+0b2ME4ACLyU4RG8XlW839yMwQZU3JTgaEYy6VWY+gVcnyt5i2HdswUW74QbkXdtJrWM+s1JPVpLLi5cAewBHLwhItqwqt1HJWEQpkJn5rT3R6ksCFycoeJXqvJLKfk6GUt3VSR0+cFPvmTg1ALcr8ot2uOzVBBb+CaG6RAlzXGCuiT7k/CfjM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SA1PR09MB8142.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(52536014)(9686003)(55016002)(5660300002)(2906002)(6916009)(8936002)(9326002)(8676002)(7696005)(66476007)(64756008)(33656002)(966005)(166002)(66556008)(66446008)(76116006)(54906003)(86362001)(66946007)(82960400001)(6506007)(558084003)(122000001)(38100700002)(508600001)(316002)(38070700005)(186003)(71200400001)(26005)(4326008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?sm6GP5F2kBLLqY2pcQu5aNGbMTyeXxHgzyKSERGmDL+QVovdyPgDytn1GwJO?= =?us-ascii?Q?st5wiBWwBPg69laQE88t1rFuO/Uku05hFurTd5vV0qOTr6A00tqUequTv7Sb?= =?us-ascii?Q?yKdhhk10yJYCYzoj5qMK78JYrRefzSD19HnzAa01SILBXnQp7Eo7l/rS6PqJ?= =?us-ascii?Q?11WCtITV3e8S1IjOmg3W1D2sQcEcLrJ8NVbU0fnBOiLK3gdyVQGJ79EjHbIO?= =?us-ascii?Q?yXhTyJRyuP/0c30+ZyNAbkB9bvV8DaBq+UG+TwaZwLeKN5nUArPsrviF+kZ+?= =?us-ascii?Q?fXm3p6k0fG37plSi95q3lOsAPetpNro2YlwAop6Ne5pYton5cQwvOWbfbrZL?= =?us-ascii?Q?0qSbeb1H53qGfhrfJS8SkJhz/T8RAwmTu1dsHGI2scRTEpYgu+la9cnBmlU3?= =?us-ascii?Q?jL0K1rb+ezhk5jkmRVuP5HFM0ngfiQNnd+ToxrL/wlmwMfbxhkowYnNq3UEx?= =?us-ascii?Q?zd2l4m2e/0Yuk76ojHFCirjk2pZyPDsdu/Q+a4QyWO9ZWz0lpXcoj5pq5mZj?= =?us-ascii?Q?ZOmhFsURoqABhnEQGhbvn9Vy0FpaC9BgGla5HSz2chiE5lkQv0xyWWGQokjL?= =?us-ascii?Q?tlSMm3jnCF+aiU219lsWKf+jnth0xQWldVCr7i9lEXXz/6HzYO3jMDG9lHA8?= =?us-ascii?Q?M+Bt6oRIfd164pqi2/XIIbXWfGaKE7z+AAn12tyuaiXBSBG72q/lTPa+wtvt?= =?us-ascii?Q?Chze7RWFox8WA78jseXZ4mWTnra4ZcSf2FPwLiHYAtfmbcr8G13dGungylQH?= =?us-ascii?Q?gUrvvHXQ3TJBCoW3tmponGN5nkK03q4AFkevUYOsPtSjl0Qt97zqrzKvvSH4?= =?us-ascii?Q?LQJG4DLPxeT9gKwfiR1kT9vLfe95Dfs5YV25deemlOLO0TKi2cFbcDtAxXRL?= =?us-ascii?Q?Ptznruk5bVWNdp0+DbgrX26Dd337Aziwfo1RDwjbhHLBvRSElEn9QHmrES+1?= =?us-ascii?Q?vwc7yBEXqhIYaDqDfLV0bCHnAZYdUuapLMwnkwAv4Qg0LdbdtytTNWPSWLxe?= =?us-ascii?Q?UTn9HT86sQf1RAas1OPP96ba5MDbJBNZF8CZSeB8jev675YdMFXR5pRlu7po?= =?us-ascii?Q?dS5O4ochY4V4fSnPnbjI0t7F1NT7HAed01uMcxyMJDjqj6g7lM9861fM5wy1?= =?us-ascii?Q?4FPHT5vmQAT3rN4N8eALKzID3giErma7RWYA3TQd9+Ike4+YXyCH27ANLZQ+?= =?us-ascii?Q?65rK0gl4I91H5MsydvwwcQ+RBSrpS9CgtgkkjoG6Xb3RV+NI1qQaXdZuxPFx?= =?us-ascii?Q?5kb48ovjZZsk1NV2gZ5eDLGAcaMVwyoRpUBn0/tFIf6ZsQobPtiB7IdIiewA?= =?us-ascii?Q?vaE=3D?=
Content-Type: multipart/alternative; boundary="_000_SA1PR09MB8142DA185C9615411F721ABD849F9SA1PR09MB8142namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR09MB8142.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b439fd0-750a-48b3-9998-08d9adc7b687
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2021 14:52:32.0380 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB7630
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/kbP9Svq7ohHwLQQpUdOk-jntaR4>
Subject: Re: [Sidrops] Grammatical errors in ASPA doc
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2021 14:52:43 -0000

--_000_SA1PR09MB8142DA185C9615411F721ABD849F9SA1PR09MB8142namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rich,

We are awaiting the publication of version -09. Please see:
https://mailarchive.ietf.org/arch/msg/sidrops/spTmfVH-lIfGPnjFePOLcf8E6uk/

Alexander and I have been discussing -09 revisions for the algorithms. Your=
 suggestions for the grammatical corrections are timely.

Regards,
Sriram

--_000_SA1PR09MB8142DA185C9615411F721ABD849F9SA1PR09MB8142namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Hi Rich,<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">We are awaiting the=
 publication of version -09. Please see:
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><a href=3D"https://=
mailarchive.ietf.org/arch/msg/sidrops/spTmfVH-lIfGPnjFePOLcf8E6uk/">https:/=
/mailarchive.ietf.org/arch/msg/sidrops/spTmfVH-lIfGPnjFePOLcf8E6uk/</a><o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Alexander and I hav=
e been discussing -09 revisions for the algorithms. Your suggestions for th=
e grammatical corrections are timely.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt"><o:p>&nbsp;</o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Regards,<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:12.0pt">Sriram &nbsp;&nbsp;=
&nbsp;<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_SA1PR09MB8142DA185C9615411F721ABD849F9SA1PR09MB8142namp_--


From nobody Tue Nov 23 05:43:46 2021
Return-Path: <a.e.azimov@gmail.com>
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 81B003A080C for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 05:43:44 -0800 (PST)
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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 mC3z2BCK_Nn8 for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 05:43:40 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 4555E3A080B for <sidrops@ietf.org>; Tue, 23 Nov 2021 05:43:40 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id y7so17168820plp.0 for <sidrops@ietf.org>; Tue, 23 Nov 2021 05:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tcWnZHWolURxgPm54kMSeOBb/i/wiEMNIBqqej2+gCk=; b=Ya22KE1Ae0vcSd2uue0T2L6HkpfmGcMqQB1Gnc6K7koGY6iRtkVIJJ0jcTOB0ZoGL3 zyqN0vbLHr73dl45kf6MOzcxsc9103CjSdorRxX1x+Kv9PNten4zuo3tTBAjiQl0sJ53 aUujY9DbXHIgpopoj7QnFuE3D1riHJX1kUw8eN5TfGVmi3fXJt67fr1lGpPEtWpkCwpG r5sQYY3tWtRjYf2at4NCM12mmk2Vw9d2N3iAAprXwRlYi+ubMu5PtmtxveaWoqotkFuv k0at2i0tlD5Sz4gUYTppNBeF7IXvSfpaflaUU1Ddr/wbup4PAPyJeegDkIUi1gZ4QGEX sVaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tcWnZHWolURxgPm54kMSeOBb/i/wiEMNIBqqej2+gCk=; b=bL37R73YdI1yxDNjmuHXLVf1Vywl82y+mcnuMdrBG2I8YR6r/4J2VxATpbRqDsA3SC qNNxQOlby/ZYDobYJNtTKRgju1EeCxhA2BZes7h0Rip/Kxkt5Dm9EAmFHxjgewEYiWx1 iZD7JdabCmccIOulBucAgE/MzqYYb32QuTl6F3fEIuQ9T9Jj3he2Y4hginW2hzpmafsu UaEYUcgujoV3ZWyvxE1aAPtXxQDf+5ORT7XafXHKTr5o7jgaZXcmAPIbZAmzUJBibafy P3lWHYIFH2tlz1GGuEOP5A/GzpXyDnBf+D0lEaJWnhfuzDypwMT3U0/pmymwUztkFA6V C6Lg==
X-Gm-Message-State: AOAM533mtphZ+tAMG+2KmBcHz2uUUAnTnaD6nFTNb//UzO5jC68IbtWy S/AvjzLBZj2urxIGbnOBuy7pijcLXLV6qwdtYc0=
X-Google-Smtp-Source: ABdhPJxCnl7oe0J9zwIbF3A7+Kksou8KKMNo+skkU6VA5XUtR/oN0U4d1R1GfsA22ciqX2sBK1RvokA75rIXyL7lvfE=
X-Received: by 2002:a17:90a:e7ca:: with SMTP id kb10mr3097014pjb.8.1637675017574;  Tue, 23 Nov 2021 05:43:37 -0800 (PST)
MIME-Version: 1.0
References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> <a775bf84-29a3-45f1-08f5-a6728cf11bc3@foobar.org>
In-Reply-To: <a775bf84-29a3-45f1-08f5-a6728cf11bc3@foobar.org>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Tue, 23 Nov 2021 16:43:26 +0300
Message-ID: <CAEGSd=BvEhaZyqE01hCBYwafZH5Z1-6-0eYbRL-AD3sURe4STg@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Cc: Ties de Kock <tdekock@ripe.net>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae1f2f05d174ed8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/LeKKvQ4KOK36eB9KeaOY_Z02jFE>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2021 13:43:45 -0000

--000000000000ae1f2f05d174ed8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I've read the latest version of the document,  it now sites the
de-aggregation scenario in response to a hijack.
The draft says:

   Nevertheless, this document recommends that where possible, network
   operators publish minimal ROAs even in the face of this risk.  This
   is because:

   *  Minimal ROAs offer the best possible protection against the
      immediate impact of such an attack, rendering the need for such a
      response less likely;
   *  Increasing ROV adoption by network operators will, over time,
      decrease the size of the neighborhoods in which this risk exists;
      and

   *  Other methods for reducing the size of such neighborhoods are
      available to potential victims, such as establishing direct eBGP
      adjacencies with networks from whom the defensive routes would
      otherwise be hidden.


In the world with high adoption rate of ROV I would have definitely
supported this document for publication.
Unfortunately, according to latest research by Geoff Huston - we are
living in a very different world. We have steady progress in signing
ROAs but far less progress in adopting ROV.
And you can't easily distinguish is it safe enough to start using
maximal ROA length or not. For the network that I'm responsible at the
moment - it is not safe.

Another complication may happen when ROV is done at egress (rfc8893).
In case of fast de-aggreagation you may need to turn it off, though
such issue is much easier to resolve.
To sum it up: I still have a feeling that the document is ahead of its
time, and in the imperfect world may itroduce new gaps between
routing-security-in-theory and operations.


=D0=B2=D1=82, 26 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 12:43, Nick Hillia=
rd <nick@foobar.org>:

> Have read through thoroughly.  It looks fine and is definitely BCP
> material.  It could be improved by being slightly shorter, but this would
> require some refactoring.
>
> Nick
>
> Ties de Kock wrote on 26/10/2021 08:13:
>
> I agree! In my opinion it contains a well-motivated recommendation to
> reduce the
> risk of forged-orgin subprefix hijacks caused by loose ROAs, as well as a
> good
> suggestion that user interfaces should recommend this type of ROA.
>
> Kind regards,
> Ties
>
> On 25 Oct 2021, at 20:53, Borchert, Oliver (Fed) <
> oliver.borchert=3D40nist.gov@dmarc.ietf.org> wrote:
>
>
> I read through the draft and believe it is ready to move on to the next
> step,
>
> Oliver
>
> -----------------------------------------------
> Oliver Borchert, Computer Scientist
> National Institute of Standards and Technology
> (Office) +1.301.975.4856
> (GVoice) +1.240.668.4117
>
>
> *From: *Sidrops <sidrops-bounces@ietf.org> on behalf of Keyur Patel <
> keyur@arrcus.com>
> *Date: *Monday, October 11, 2021 at 7:20 PM
> *To: *"sidrops@ietf.org" <sidrops@ietf.org>
> *Subject: *[Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends
> 25/October/2021
>
> Hi Folks:
>
> A working group last call has been requested for
> draft-ietf-sidrops-rpkimaxlen-08, =E2=80=9CThe Use of Maxlength in the RP=
KI=E2=80=9D.
> Please reply to the list with your comments. The WGLC will end on October
> 25th, 2021.
>
> The draft can be found at:
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-08
> <https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdata=
tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-sidrops-rpkimaxlen-08&data=3D04%=
7C01%7Coliver.borchert%40nist.gov%7Cec8e8b19fd814e8e876f08d98d0da775%7C2ab5=
d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637695912071940980%7CUnknown%7CTWFpb=
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7=
C1000&sdata=3DsiwaghZqxNR5835kbYOBkcVElAbSmDyFyZC6wd2yvyE%3D&reserved=3D0>.
> Authors, please reply indicating whether you're aware of any relevant IPR
> that hasn't been disclosed.
>
> Regards,
> Nathalie, Chris & Keyur
>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>
>
>
>
> _______________________________________________
> Sidrops mailing listSidrops@ietf.orghttps://www.ietf.org/mailman/listinfo=
/sidrops
>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>


--=20
Best regards,
Alexander Azimov

--000000000000ae1f2f05d174ed8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve read the latest version of the document,=C2=A0 it=
 now sites the de-aggregation scenario in response to a hijack.<div>The dra=
ft says:<br></div><div><br></div><div><pre class=3D"gmail-newpage" style=3D=
"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;col=
or:rgb(0,0,0)">   Nevertheless, this document recommends that where possibl=
e, network
   operators publish minimal ROAs even in the face of this risk.  This
   is because:

   *  Minimal ROAs offer the best possible protection against the
      immediate impact of such an attack, rendering the need for such a
      response less likely;
   *  Increasing ROV adoption by network operators will, over time,
      decrease the size of the neighborhoods in which this risk exists;
      and</pre><pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;ma=
rgin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><pre cla=
ss=3D"gmail-newpage" style=3D"margin-top:0px;margin-bottom:0px;break-before=
:page">   *  Other methods for reducing the size of such neighborhoods are
      available to potential victims, such as establishing direct eBGP
      adjacencies with networks from whom the defensive routes would
      otherwise be hidden.</pre><pre class=3D"gmail-newpage" style=3D"font-=
size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb=
(0,0,0)"><br></pre><pre class=3D"gmail-newpage" style=3D"font-size:13.3333p=
x;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><pre=
 class=3D"gmail-newpage" style=3D"margin-top:0px;margin-bottom:0px;break-be=
fore:page"><div style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sa=
ns-serif;font-size:small;white-space:normal">In the world with high adoptio=
n rate of ROV I would have definitely supported this document for publicati=
on.<br>Unfortunately, according to latest research by Geoff Huston - we are=
 living in a very different world. We have steady progress in signing ROAs =
but far less progress in adopting ROV.<br>And you can&#39;t easily distingu=
ish is it safe enough to start using maximal ROA length or not. For the net=
work that I&#39;m responsible at the moment - it is not safe.<br><br>Anothe=
r complication may happen when ROV is done at egress (rfc8893). In case of =
fast de-aggreagation you may need to turn it off, though such issue is much=
 easier to resolve.<br>To sum it up: I still have a feeling that the docume=
nt is ahead of its time, and in the imperfect world may itroduce new gaps b=
etween routing-security-in-theory and operations.<br></div></pre>
</pre></pre></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">=D0=B2=D1=82, 26 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 =
12:43, Nick Hilliard &lt;<a href=3D"mailto:nick@foobar.org">nick@foobar.org=
</a>&gt;:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div>Have read through thoroughly.=C2=A0 It looks fine
 and is definitely BCP material.=C2=A0 It could be improved by being slight=
ly
 shorter, but this would require some refactoring.<br>
<br>
Nick<br>
<br>
<span>Ties de Kock wrote on 26/10/2021 08:13:</span><br>
<blockquote type=3D"cite" style=3D"overflow-wrap: break-word;">
 =20
  <div><div>I agree! In my opinion it contains a=20
well-motivated recommendation to reduce the</div><div>risk of=20
forged-orgin subprefix hijacks caused by loose ROAs, as well as a good</div=
><div>suggestion that user interfaces should recommend this type of=20
ROA.</div></div>
  <div><br></div>
  <div>Kind regards,</div>
  <div>Ties</div>
  <div><br><blockquote type=3D"cite"><div>On 25
 Oct 2021, at 20:53, Borchert, Oliver (Fed) &lt;<a href=3D"mailto:oliver.bo=
rchert=3D40nist.gov@dmarc.ietf.org" target=3D"_blank">oliver.borchert=3D40n=
ist.gov@dmarc.ietf.org</a>&gt;
 wrote:</div><br><div><div style=3D"font-family:Helvetica;font-size:12px;fo=
nt-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;text-decoration:none"><div style=3D"margin:0in;font-si=
ze:12pt;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt;font-=
family:Courier"><u></u>=C2=A0<u></u></span></div><div style=3D"margin:0in;f=
ont-size:12pt;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt=
;font-family:Courier">I read through=20
the draft and believe it is ready to move on to the next step,<u></u><u></u=
></span></div><div style=3D"margin:0in;font-size:12pt;font-family:Calibri,s=
ans-serif"><span style=3D"font-size:11pt;font-family:Courier"><u></u>=C2=A0=
<u></u></span></div><div style=3D"margin:0in;font-size:12pt;font-family:Cal=
ibri,sans-serif"><span style=3D"font-size:11pt;font-family:Courier">Oliver<=
u></u><u></u></span></div><div style=3D"margin:0in;font-size:12pt;font-fami=
ly:Calibri,sans-serif"><span style=3D"font-size:11pt;font-family:Courier"><=
u></u>=C2=A0<u></u></span></div><div><div><div style=3D"margin:0in;font-siz=
e:12pt;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt;font-f=
amily:Courier">-----------------------------------------------<u></u><u></u=
></span></div><div style=3D"margin:0in;font-size:12pt;font-family:Calibri,s=
ans-serif"><span style=3D"font-size:11pt;font-family:Courier">Oliver Borche=
rt, Computer=20
Scientist<u></u><u></u></span></div><div style=3D"margin:0in;font-size:12pt=
;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt;font-family:=
Courier">National=20
Institute of Standards and Technology<u></u><u></u></span></div><div style=
=3D"margin:0in;font-size:12pt;font-family:Calibri,sans-serif"><span style=
=3D"font-size:11pt;font-family:Courier">(Office)
 +1.301.975.4856<u></u><u></u></span></div><div style=3D"margin:0in;font-si=
ze:12pt;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt;font-=
family:Courier">(GVoice)=20
+1.240.668.4117<u></u><u></u></span></div></div></div><div style=3D"margin:=
0in;font-size:12pt;font-family:Calibri,sans-serif"><span style=3D"font-size=
:11pt;font-family:Courier"><u></u>=C2=A0<u></u></span></div><div style=3D"m=
argin:0in;font-size:12pt;font-family:Calibri,sans-serif"><span style=3D"fon=
t-size:11pt;font-family:Courier"><u></u>=C2=A0<u></u></span></div><div styl=
e=3D"border-style:solid none none;border-top-width:1pt;border-top-color:rgb=
(181,196,223);padding:3pt 0in 0in"><div style=3D"margin:0in 0in 0in 0.5in;f=
ont-size:12pt;font-family:Calibri,sans-serif"><b><span>From:<span>=C2=A0</s=
pan></span></b><span>Sidrops &lt;<a href=3D"mailto:sidrops-bounces@ietf.org=
" style=3D"color:rgb(5,99,193);text-decoration:underline" target=3D"_blank"=
>sidrops-bounces@ietf.org</a>&gt; on behalf of=20
Keyur Patel &lt;<a href=3D"mailto:keyur@arrcus.com" style=3D"color:rgb(5,99=
,193);text-decoration:underline" target=3D"_blank">keyur@arrcus.com</a>&gt;=
<br><b>Date:<span>=C2=A0</span></b>Monday,
 October 11, 2021 at 7:20 PM<br><b>To:<span>=C2=A0</span></b>&quot;<a href=
=3D"mailto:sidrops@ietf.org" style=3D"color:rgb(5,99,193);text-decoration:u=
nderline" target=3D"_blank">sidrops@ietf.org</a>&quot;
 &lt;<a href=3D"mailto:sidrops@ietf.org" style=3D"color:rgb(5,99,193);text-=
decoration:underline" target=3D"_blank">sidrops@ietf.org</a>&gt;<br><b>Subj=
ect:<span>=C2=A0</span></b>[Sidrops]
 [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021<u></u><u></=
u></span></div></div><div><div style=3D"margin:0in 0in 0in 0.5in;font-size:=
12pt;font-family:Calibri,sans-serif"><span style=3D"font-size:11pt"><u></u>=
=C2=A0<u></u></span></div></div><div style=3D"margin:0in 0in 0in 0.5in;font=
-size:12pt;font-family:Calibri,sans-serif"><span>Hi Folks:<u></u><u></u></s=
pan></div><div style=3D"margin:0in 0in 0in 0.5in;font-size:12pt;font-family=
:Calibri,sans-serif;font-variant-caps:normal;text-align:start;word-spacing:=
0px"><span>=C2=A0<u></u><u></u></span></div><div style=3D"margin:0in 0in 0i=
n 0.5in;font-size:12pt;font-family:Calibri,sans-serif;font-variant-caps:nor=
mal;text-align:start;word-spacing:0px"><span>A working group last call has =
been requested for=20
draft-ietf-sidrops-rpkimaxlen-08, =E2=80=9CThe Use of Maxlength in the RPKI=
=E2=80=9D.=20
Please reply to the list with your comments. The<span>=C2=A0</span>WGLC<spa=
n>=C2=A0</span>will end on October 25<sup>th</sup>, 2021.<u></u><u></u></sp=
an></div><div style=3D"margin:0in 0in 0in 0.5in;font-size:12pt;font-family:=
Calibri,sans-serif"><span>=C2=A0<u></u><u></u></span></div><div style=3D"ma=
rgin:0in 0in 0in 0.5in;font-size:12pt;font-family:Calibri,sans-serif;font-v=
ariant-caps:normal;text-align:start;word-spacing:0px"><span>The draft can b=
e found at:<span>=C2=A0<a href=3D"https://gcc02.safelinks.protection.outloo=
k.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-s=
idrops-rpkimaxlen-08&amp;data=3D04%7C01%7Coliver.borchert%40nist.gov%7Cec8e=
8b19fd814e8e876f08d98d0da775%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C6=
37695912071940980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM=
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3DsiwaghZqxNR5835kbYOBkc=
VElAbSmDyFyZC6wd2yvyE%3D&amp;reserved=3D0" style=3D"color:rgb(5,99,193);tex=
t-decoration:underline" target=3D"_blank">https://datatracker.ietf.org/doc/=
html/draft-ietf-sidrops-rpkimaxlen-08</a></span>.
 Authors, please reply indicating whether you&#39;re aware of any relevant=
=20
IPR that hasn&#39;t been disclosed.<u></u><u></u></span></div><div style=3D=
"margin:0in 0in 0in 0.5in;font-size:12pt;font-family:Calibri,sans-serif"><s=
pan>=C2=A0<u></u><u></u></span></div><div style=3D"margin:0in 0in 0in 0.5in=
;font-size:12pt;font-family:Calibri,sans-serif;font-variant-caps:normal;tex=
t-align:start;word-spacing:0px"><span>Regards,<u></u><u></u></span></div><d=
iv style=3D"margin:0in 0in 0in 0.5in;font-size:12pt;font-family:Calibri,san=
s-serif;font-variant-caps:normal;text-align:start;word-spacing:0px"><span>N=
athalie, Chris &amp; Keyur<u></u><u></u></span></div><div style=3D"margin:0=
in 0in 0in 0.5in;font-size:12pt;font-family:Calibri,sans-serif;font-variant=
-caps:normal;text-align:start;word-spacing:0px"><span>=C2=A0<u></u><u></u><=
/span></div><div style=3D"margin:0in 0in 0in 0.5in;font-size:12pt;font-fami=
ly:Calibri,sans-serif"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u><=
/span></div></div><span style=3D"font-family:Helvetica;font-size:12px;font-=
style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;text-decoration:none;float:none;display:inline">_________=
______________________________________</span><br style=3D"font-family:Helve=
tica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:=
normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;text-decoration:none"><span styl=
e=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant-ca=
ps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decor=
ation:none;float:none;display:inline">Sidrops mailing list</span><br style=
=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-variant-cap=
s:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-ind=
ent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decora=
tion:none"><a href=3D"mailto:Sidrops@ietf.org" style=3D"color:rgb(5,99,193)=
;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:=
normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px" target=3D"_blank">Sidrops@ietf.org</a><br style=3D"font-family=
:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-w=
eight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tr=
ansform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a h=
ref=3D"https://www.ietf.org/mailman/listinfo/sidrops" style=3D"color:rgb(5,=
99,193);text-decoration:underline;font-family:Helvetica;font-size:12px;font=
-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:no=
rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma=
l;word-spacing:0px" target=3D"_blank">https://www.ietf.org/mailman/listinfo=
/sidrops</a></div></blockquote></div>
  <br>

  <br>
  <fieldset></fieldset>
  <br>
  <pre>_______________________________________________
Sidrops mailing list
<a href=3D"mailto:Sidrops@ietf.org" target=3D"_blank">Sidrops@ietf.org</a>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidrops" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/sidrops</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Sidrops mailing list<br>
<a href=3D"mailto:Sidrops@ietf.org" target=3D"_blank">Sidrops@ietf.org</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidrops" rel=3D"noreferrer=
" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sidrops</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">Best regards,<div>Alexander Azi=
mov</div></div></div>

--000000000000ae1f2f05d174ed8e--


From nobody Tue Nov 23 10:51:23 2021
Return-Path: <keyur@arrcus.com>
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 37FF13A085F for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 10:51:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ny-5chICQmK for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 10:51:16 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2085.outbound.protection.outlook.com [40.107.244.85]) (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 2CCE53A085C for <sidrops@ietf.org>; Tue, 23 Nov 2021 10:51:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VJZMaOboBRUgYDjrzbfWHRWNuWfB2kWvw+uc+E0ZrA/1TTXYXuJZWTS6z9IkO9OeSzWheoqskrQe0gsmYB6Za/mI4Ljj7Ww3oG/vrToVTPUxu4DL2v22UZC7X8m3djOV1qxPGQT2P3a5gPmzAcbPte4DzvDt1xibtICt096c71tBw398m9ki0LCzRY8j91bGst2BFyN5l7yEe/1Xv/91eEhHuWqecUCWdxu2xuMoY0cowdDFmS8kXjHrpKxPaq2r2d5HjinesvJs2vCRi1G3jrV4zwNRJGrj38WPGIxDlI/YDclyHd5s8EqFoLxsIpyW9lljUvthGs3VSlGREqZKgw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jw8atrocoJkyv/sXO7kjyR+9PcieIi9UgFk7mPS9ffs=; b=h9t4JS+8aEwcT2lVCpK4hcBV6ORDBLD39WId2Seq34L4CiPb0qrG3YMEH/Xm3k2Uqa0Bz6FLLgckaGlTztglEuKAvkaILh2Qic7RpB/+44AHZ0lsrwxVOOAiGYl438MoUpwHNHMlG8lRuj99/9OAnIITFITlAMukl9jVBP5CN/FTUNjd52PkbmuYdDzDv8PRDZN8P76q70+uIjByGixkuiEiIg6yjD/4droDV1iAGra1cYwGx8jNf7YphJCJx4CCdkSTxydd3Pu383uTro4zGZh8+VCjEnvgcGUqsNEB37ofrMYS6YqZSIXfnJzuXx2vz3i1od2Glcp14xgURHDY0A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jw8atrocoJkyv/sXO7kjyR+9PcieIi9UgFk7mPS9ffs=; b=cpH71y9adSEhNVDs13g+KzcJ47AxhVwZmeQa5Wbwmn/vMcXLyZREWk3sy/OfuODmQagAeA1ZTnkNLj6ybWTpVxShtb8Zy6HIHxRzoZwN7QGelXUKKSwZ7LsBweDqJzVY/nvrFS5AY97yLC9SRTsGqqxC58M4xPE+5/pEIu0y80s=
Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB3048.namprd18.prod.outlook.com (2603:10b6:a03:102::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Tue, 23 Nov 2021 18:51:13 +0000
Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162%5]) with mapi id 15.20.4713.026; Tue, 23 Nov 2021 18:51:13 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] Extended - [WGLC] draft-ietf-sidrops-rpkimaxlen-09 - Ends 7/December/2021
Thread-Index: AQHX4JsWC+H7JQ5di0Sd0BHbLJj28Q==
Date: Tue, 23 Nov 2021 18:51:13 +0000
Message-ID: <B1F434C7-583D-4DB4-81A3-C6DDA9808C41@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3b821758-6e79-4b46-d9ec-08d9aeb238ee
x-ms-traffictypediagnostic: BYAPR18MB3048:
x-microsoft-antispam-prvs: <BYAPR18MB3048D2ABE46F1DDFACB7AA3AC1609@BYAPR18MB3048.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yMQdRlJ/f00tngk7WtzyEzm7wWNKDgl0W2FxfwT2fR8LQsBY3aJ2jLyNMbGlgvXslWFWLFzq3Y5A3Y7mEpxBRih5q12jt4ZnGLn3phujGhbJd+7D6LTySn73z6lnvOQDI00hswDkkLJHsG+hoB5TcQVt1u1pATu67RojouWH+4yf2OL6uVI8iZrJ39J7y0nmenfSiimHMELPzrrrFh99XOzAoGpYWuVmMudwUNMzhku622iOqH3UtMDylDiDUhx9t/j4oe+5P4WkiIcZJVubgQ2IKWers9KdQL2FVTXFNv4aPXGRRzJw1GFlpibzMguMksmA95Aw97FjUR5cHQuTnwt41ribsaLoZcqxZtcmPAG4P2EBFKSX/+e1lrhrMWawp08IAmw/G3fs6z/D9ZOs2nCPQxLLWWtWsfTLcTDiMdwkBIvPWYMPVh+8h/NiAyMkpPZH6/Q8W+zRqCQtzdWqdJT5M+muTffufADgylwe6nd72l22esafkNPDc5UrSjct22fXggtfwQHSr/6N8O6GGv/EP4eFWv7uY5WFNnWLc++ypa0PgwdUDAUTAKPyhW2KjDuD8maD1qM1Bv9/kDCPNLJ+HSsos5SOZTVYB2MxjQsQ50DBi7dHRBVRM6Qu0RJtLZ+oX+0WuE5BuVHOpvK/bu+CiUyA6HrXcoOLK7hP46xuBCwWLhtPBSavbQo2KZBK/EsnzUB/wffhLSLqyQt8NzGhXCSdeFXmxDP5R0A8cknMrG0igOj9cGP6T3x+RUnCoDW7Klcqbp9Dz/IVuKA5rkoSyRt5swAHqolpm/0Mv3fNoYoyx7jYnrLJp1tSWBWi
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFS:(396003)(346002)(376002)(366004)(136003)(39840400004)(53546011)(6506007)(2906002)(6916009)(86362001)(508600001)(71200400001)(2616005)(76116006)(26005)(966005)(66946007)(38100700002)(8676002)(83380400001)(33656002)(6486002)(5660300002)(36756003)(64756008)(66476007)(66556008)(66446008)(6512007)(316002)(122000001)(8936002)(166002)(186003)(38070700005)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bk9zak5NdjJDT0trVGgzZW1EUHduNTk2STUxU2RRTWNiMDlXQkt3cnNUVTdV?= =?utf-8?B?L2dFUDR1aWEwSVNPK1loZkxycFk2NndERnBSd1EvUzFmRWpMbmxMOWlIeGhB?= =?utf-8?B?R2ZSazV0OU1KanNabk8wSjBicGdsYkJYYWVWeE50MWlFdnVGaG5Bb21sd2Ux?= =?utf-8?B?aTNpbHlCR3BwdlNTUXl5cFk3cjBwd0Z3MEJwVWNwdGY0ajFXaVh1Y2wvdS9L?= =?utf-8?B?cWloZW9xTk9ydTIwc2ExMEZTOVZwYUJVUUpnSHRQVkZobGlYakJ1dlFERzYx?= =?utf-8?B?b0VCOHFwY0tldTAxNXZEU25XZXpJWVF5MjVHYzRXRHRkN2sxTTlVVDdncDEw?= =?utf-8?B?RkRGMitwUFRiL0hnNzlMRTJiMWc0bG1UUkRsT3NtY1ZqbWRoYjVnQ2ZyRFJr?= =?utf-8?B?WUsvR3FRT0pTVVRHOXVCNUFWMWtlSUp4VEpnNG9kUzBjYld6QjIzRnRxZWUz?= =?utf-8?B?U01BcHlGM2YwWFFmZDFrMlFBaFZ2Njc1N2Fub3MzZzhsQXMrNjR5TXlYY2pH?= =?utf-8?B?NTVQWVc2ZVNvK3FKU3RWcWl4K290Rk9ZMVpDRU8xTzJNOWpvMWFVd1VSS0k4?= =?utf-8?B?VVFlRE9Wb1JQS2xaU1NjNUQ3WC9SL2ovdmJKa282NkFJek95UnBleDBMOFhL?= =?utf-8?B?a2lXdFVhRDFSYnRvckJZOEZzMmdaNmc0b05HZmh2eElycFdvWS9VaXVTcmNS?= =?utf-8?B?NFhxd2Vmcm52UThTbUlKL3lRWHFZeGg2cm1jazlDR3ZZYVUzNUhza1o2RlpS?= =?utf-8?B?WDJQMTgvK0VWeTNZK2lsdUNMa0pCM3h0dFBqRUhKVWZXMVhPTGhHd2owWUNM?= =?utf-8?B?djF3bkxPY3RuZDhkbjM1bEQxTUJqVEhrUnI1U2RzM2VmL3VxVitLYktDRTRV?= =?utf-8?B?QWRhU0s5czFjSURMY2tlQzMrcVNpd2hvaTNQNEZhQlUwR3R0QkVOWmY4dFp6?= =?utf-8?B?b0xjb0RaTmxmRlE1QkxBQzJaMVcydVNWS2h5RE90eGVIYll4R0Z1cHdycGdG?= =?utf-8?B?akVWRjF6Qi9aMys2WlZxdUJMUWFhNXJuUG9QMmJZWERGUnVGM2d1TG5tN3N5?= =?utf-8?B?bHdpNTkva21nZ0pCNnYxMXk4dVkrMXA5TGNFQVJpMlNlYmdCbmN6SCtOS3BD?= =?utf-8?B?Y1lUVy9BRGxQYmxHa3RrM04rREQxclRrYXdTb1I3M202R2J5TDVuUExwY1ZG?= =?utf-8?B?MHE2bEtLWlNjWXNVQTNVcWU1MDJTTU04RnNqdHk4cTF4Nlp6aDFyaFFGREt4?= =?utf-8?B?b0MxOE9YN1RSTHRRRUQzUHdGRTVLbzRIL1BieSt6SkxGR0R2QmRMbDBQNXJs?= =?utf-8?B?L29CSzNYT1lNVUY3Zno0RE5BaHozZWR1cjdCbjNEbExYMitjdm81VmZOWXdk?= =?utf-8?B?VkJabWRZUi9SOExGSlViTnI4bTdHU0k3U1N0UENLMXZhQ1JoaUtta01Gd2RO?= =?utf-8?B?azhxamE0SlYyN0JRMmRwZS9OQmxoaVY3Q00xY3V3OFM4eHBFWGViQ2x0SktH?= =?utf-8?B?SFhCaGk3VDJUZCtTbE0xRUNia01NdmRrcEJnR3lkdnVFTnc0cER4Q2I5d0l5?= =?utf-8?B?Y3psVmJVczVuWEQ3VGZSM0Z1ZE9GNWhqKzlTakZIRVoyUFhvdE1DWnh3R0Fq?= =?utf-8?B?NWQwYWYxZDhPcnhldGxTaldvTzlOdmhmUlNkd0hVaDZ6NW5kL3BxY2hoakwy?= =?utf-8?B?YWQxOUQ2eVBOb0xUVExkMG9BdXkySFdkZHZZeTBCYkYrZm85MW4xd0g0d3k0?= =?utf-8?B?c0p5U1ZuWWV2OXAza2JWWUVXSk95WlhpUXI1STFjQ01lNzdNQUhINGJqU0Va?= =?utf-8?B?TmJYbmhONm40UC9YeXhaMUx4TStYUkp1MGFoajA0MzFaVnFBUFhCVVN3OWpQ?= =?utf-8?B?eE9wZUR3cHJwQ0tjK1dkK2xRUGt4UUhPMitQWlE5blhpMG4yZUJzZEEwOHR5?= =?utf-8?B?a1YxYnV0dTBCVFA0cTNONk45NzJMUGlOSUloVHZhQkVqcjdjVTJieGZzSHJL?= =?utf-8?B?eFJqaWhEK3lwcEZZVGk5THhiajFOTHpXckJOYTYzUlVwOTRrc0VCbEdtYS9Y?= =?utf-8?B?d0xvN2pENmpiK29rQlNQWjJQTmV1NTVDZ1F4L05kSHI1MThVdHNBaUczVUc1?= =?utf-8?B?V1BTVTZOK09nSlpVVjRsbm95SjNLZ2NjcUxjclQyclRnSWtMemQ5eXNvZmpz?= =?utf-8?Q?tLuD/orCF208zTuPI8FHuDgZF3Wku1aq0pAyWsXYDKGD?=
Content-Type: multipart/alternative; boundary="_000_B1F434C7583D4DB481A3C6DDA9808C41arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b821758-6e79-4b46-d9ec-08d9aeb238ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2021 18:51:13.0456 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9y7JvGN/pQZ3A5Ju5jB454je0xhmm1zApMK8LqwvQfzlznng69hVlcH12N1HGTiQDmEIPI9NEeKK2X3yATKjTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB3048
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QXruZde4UnunNgcCH8MLWHYFcqg>
Subject: Re: [Sidrops] Extended - [WGLC] draft-ietf-sidrops-rpkimaxlen-09 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2021 18:51:21 -0000

--_000_B1F434C7583D4DB481A3C6DDA9808C41arrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rm9sa3MsDQoNCldlIHJlY2VpdmVkIGNvbW1lbnRzIGZyb20gQWxleGFuZGVyIEF6aW1vdiBhbmQg
aXQgbWFrZXMgc2Vuc2UgdG8gZXh0ZW5kIHRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9y
IGFub3RoZXIgdHdvIHdlZWtzIHRvIERlY2VtYmVyIDcsIDIwMjEuIEl0IHdvdWxkIGJlIGdyZWF0
IGlmIHRoZSBkcmFmdCBhdXRob3JzIGNhbiBhZGRyZXNzIEFsZXhhbmRlcuKAmXMgY29tbWVudHMu
DQoNCkJlc3QgUmVnYXJkcywNCktleXVyDQoNCkZyb206IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNl
c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPg0K
RGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMiwgMjAyMSBhdCA4OjUwIEFNDQpUbzogInNpZHJvcHNA
aWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBFeHRl
bmRlZCAtIFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOCAtIEVuZHMgMjMv
Tm92ZW1iZXIvMjAyMQ0KDQoqKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoqKg0KSGkgRm9s
a3MsDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgZXh0ZW5kZWQgZm9yIGFub3Ro
ZXIgdGhyZWUgd2Vla3MgKGluY2x1ZGluZyB0aGUgaWV0ZiB3ZWVrKSB0byBOb3ZlbWJlciAyMywg
MjAyMS4gSXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGRyYWZ0IGF1dGhvcnMgY2FuIGFkZHJlc3Mg
YWxsIHRoZSBjb21tZW50cyBhbmQgcG9zdCB0aGUgdXBkYXRlZCB2ZXJzaW9uIGZvciB0aGUgcmV2
aWV3Lg0KDQpSZWdhcmRzLA0KTmF0aGFsaWUsIENocmlzICYgS2V5dXINCg0KRnJvbTogU2lkcm9w
cyA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2V5dXIgUGF0ZWwgPGtl
eXVyQGFycmN1cy5jb20+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMTEsIDIwMjEgYXQgNjoxOSBQ
TQ0KVG86ICJzaWRyb3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtT
aWRyb3BzXSBbV0dMQ10gZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDggLSBlbmRzIDI1
L09jdG9iZXIvMjAyMQ0KDQoqKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoqKg0KSGkgRm9s
a3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBk
cmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOCwg4oCcVGhlIFVzZSBvZiBNYXhsZW5ndGgg
aW4gdGhlIFJQS0nigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVu
dHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE9jdG9iZXIgMjV0aCwgMjAyMS4NCg0KVGhlIGRyYWZ0
IGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k
cmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOC4gQXV0aG9ycywgcGxlYXNlIHJlcGx5IGlu
ZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhh
c24ndCBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVy
DQoNCg0K

--_000_B1F434C7583D4DB481A3C6DDA9808C41arrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <A6BC886B68EE3A40A12E8EAD717C4B01@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND
MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw
YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls
U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg
dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Rm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij5XZSByZWNlaXZlZCBjb21tZW50cyBmcm9tIEFsZXhhbmRlciBBemltb3YgYW5kIGl0IG1h
a2VzIHNlbnNlIHRvIGV4dGVuZCB0aGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBhbm90
aGVyIHR3byB3ZWVrcyB0byBEZWNlbWJlciA3LCAyMDIxLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB0
aGUgZHJhZnQgYXV0aG9ycyBjYW4gYWRkcmVzcyBBbGV4YW5kZXLigJlzDQogY29tbWVudHMuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CZXN0IFJlZ2FyZHMsPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPktleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPlNpZHJvcHMgJmx0O3NpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyZn
dDsgb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4N
CjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBOb3ZlbWJlciAyLCAyMDIxIGF0IDg6NTAgQU08YnI+DQo8
Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5v
cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbU2lkcm9wc10gRXh0ZW5kZWQgLSBbV0dM
Q10gZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDggLSBFbmRzIDIzL05vdmVtYmVyLzIw
MjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+KioqKlNlbmRlciBpcyBub3QgZnJvbSBBcnJjdXMqKioNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+SGkgRm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5UaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIGV4dGVuZGVkIGZvciBh
bm90aGVyIHRocmVlIHdlZWtzIChpbmNsdWRpbmcgdGhlIGlldGYgd2VlaykgdG8gTm92ZW1iZXIg
MjMsPHN1cD4NCjwvc3VwPjIwMjEuIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSBkcmFmdCBhdXRo
b3JzIGNhbiBhZGRyZXNzIGFsbCB0aGUgY29tbWVudHMgYW5kIHBvc3QgdGhlIHVwZGF0ZWQgdmVy
c2lvbiBmb3IgdGhlIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaWRyb3BzICZsdDtzaWRyb3BzLWJv
dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJy
Y3VzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBPY3RvYmVyIDExLCAyMDIxIGF0
IDY6MTkgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0
O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltTaWRyb3BzXSBbV0dM
Q10gZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDggLSBlbmRzIDI1L09jdG9iZXIvMjAy
MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij4qKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoqKg0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0
LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xv
cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0
ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1
dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVu
IHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDgsIOKAnFRoZSBV
c2Ugb2YgTWF4bGVuZ3RoIGluIHRoZSBSUEtJ4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qg
d2l0aCB5b3VyIGNvbW1lbnRzLiBUaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj53aWxsDQogZW5kIG9uIE9jdG9iZXIgMjU8c3VwPnRoPC9zdXA+LCAyMDIxLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0
LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBkcmFmdCBj
YW4gYmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm
LXNpZHJvcHMtcnBraW1heGxlbi0wOCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
aHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wODwvYT48L3NwYW4+LiBBdXRob3Jz
LA0KIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSBy
ZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u
dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk
b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4
Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4
dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQt
Y29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+TmF0aGFsaWUsIENocmlzICZhbXA7IEtleXVyPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7
d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B1F434C7583D4DB481A3C6DDA9808C41arrcuscom_--


From nobody Tue Nov 23 11:00:39 2021
Return-Path: <keyur@arrcus.com>
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 BD2D13A0863 for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 11:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=netorgft1331857.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJYFbZd3sO6B for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 11:00:34 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2063.outbound.protection.outlook.com [40.107.244.63]) (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 5C2033A0864 for <sidrops@ietf.org>; Tue, 23 Nov 2021 11:00:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=liuroTmXX9OkluwwJLhlNNF0uuXPgFSfwc2wK2ebtJAJhhFwA8yi1QfyRtYA4W45+GkZqXbLRrJChG3xfxcLyDTJJJnZ/+3TLZeHCZ7iXcNcANjWfNDUiTh1pVLNzXF1GB4db0v4jFrCGUKyHgkbft6Bv/n6lbBzcnODzxhek0R1+ZVCbky5Hr8c7yYdO5HW6PQLo09OaUhlr/9UpionU10jpPDTg+ECxgG7+fZ5FL1cLhtWWPJ8/X7D/QpWOgEjj9dz03dC6TzS9iHa9VJD6FCXQ0b9Rzs1W8UhJ9hFiYDyl2c4mbXt3mrQ1skjBdXDzSCBe94Rbk/pMokFHm2/dA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lopts/9xSkRNFS7VhsS5oCcJty0ZLw2uM0hJtPRFX4I=; b=C/686qJlXk33GUSREKtb90rTzRX3MYsxFnPFRwmQIO8WwzyHKDpiUcQZwKEs8wVF+wSTXmGs8AAbace4BvPgyO5N1UhggQnvKwILQnC3kXTKYOaAPQjW96qegYPmLa/kl0PFbGnxpTGGo0LJI5NpBbTWq6Maywz2bn/wbojr9ACfHMmKBQtK45IYp0+IPuDmVSsVTEoSzjDr1JzUZj8f6k8YgWUa8k6Z81YqT06m3V+ZI12SPQyNGQDz1tr9NfIMUNXDxdN4+vl2YI281sMN1siHW7JogRSK9FGNR/6e50doca2CjaNpb4kxogw6k6bOw8Khn08KC62/ecinuhezHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lopts/9xSkRNFS7VhsS5oCcJty0ZLw2uM0hJtPRFX4I=; b=GZ4lsMFHbIWITuRa3/znsVYXkGyjmXyfegRtq+Ldt2oebRgqIpQQcUUgbpm4Rb62vpH4jAwwRnYvn5Y5TOuh7u0kLept2RClF+XTFlEW5Df2dqVpVSliTDR5rywMfK3G0vy2T26PHO846xbQTk/LHbYADVw0JlbjZdAPaDJ+49U=
Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3201.namprd18.prod.outlook.com (2603:10b6:a03:196::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Tue, 23 Nov 2021 19:00:31 +0000
Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162%5]) with mapi id 15.20.4713.026; Tue, 23 Nov 2021 19:00:31 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
Thread-Index: AQHX4JxjysDMm9aqUk+5kLJKlC2YPw==
Date: Tue, 23 Nov 2021 19:00:31 +0000
Message-ID: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8cf27cee-0230-4a92-7077-08d9aeb385eb
x-ms-traffictypediagnostic: BY5PR18MB3201:
x-microsoft-antispam-prvs: <BY5PR18MB3201A9ED9A46D094FF8951AFC1609@BY5PR18MB3201.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0WmuS/z9AVWTys48k6K/sebHM0Ozdk5TIJYxaLH7+2ngoliu19Kan0lJbOlSF0pJEdKGU0Y+poONLvjU0ZunoUNmLbDj3YZQcwCZMP9n7/+//+U6jetGfeJQT7ISEqknWuKBaE3oRmJArKR2+2yWpihVicpi+IjXEdiGEJWVw1BQoui++NyNgkBLKxtVE246Q91pjWmyo2N/dg+Bc5nd6XonAEpS8PJtoLaWVNaiRB3NAKzos1qzbko8m8aaHrY8VW4kwepwaw0DFImouPAszVo7mLkK7Ki9LwKG3uQ/DOZgP5VXHaTH1PmtgNNtJP58RYPkZZ/a0baxkKHkktcE0w7vuzNGOY1a/ZXq4YZYqSs/Fv+qUM0QBOtafugPYrQFBIaEnNxEMRIsFGb4Aqk1OldfU4t2KtYoJ1AneA21dZzTqvMhb46mWn+3OM79rww0FSUFz46TDPu48X+3FgMFw/4ahd00lYKX4rGHFDHMg/SuCZ14pGauHmav5QzgQaFi2m0MbxRYDKk1p16JGfGqxwXmP2BqbHp8YqwcpXC1NxsEwvGKYI67yeJojH15bteLPvlPYJENtA/gXnKRcfRkGZbzX2cnCXCRm+4/ZUaZnFgoU9c2ax+M5mp2Ui03ttIJfz7+M5HNIu9QxlfflbXi4NBY/yY4Cbv5dqrpCANb9kQWOQkjE/Zq7E+rMPF6olQ0CDN12tpJWTdOF/dGFHx0D5eXEM4ijmeFNiHIRkP5gq8sVt9Nu0i3s/1CdKsOqL0KKMg0njkAD4BP6hQrQdO/LGR2+23fuKV/RuemZZmbpum05Ge/2U3yyqCO21y5gUiE
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE;  SFS:(136003)(396003)(376002)(346002)(366004)(39840400004)(66574015)(166002)(66946007)(26005)(71200400001)(76116006)(66556008)(186003)(8676002)(2616005)(966005)(66446008)(66476007)(64756008)(6506007)(36756003)(508600001)(33656002)(5660300002)(6916009)(316002)(83380400001)(6512007)(4744005)(6486002)(38070700005)(8936002)(38100700002)(122000001)(86362001)(2906002)(45980500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TGt5UXNiMGpXNHE4dWJWeFNlOWI3dDByTnZDQndpV282dm8rVU1VclZ4c3NZ?= =?utf-8?B?ZFowek4yZzMxM1hhbkJXejJ1Ym9uSlRweUdlVUlWbDZVRnZaeGwrWkJveHRI?= =?utf-8?B?QzRUc2U3c1MrNlBLeUxNV29wZHU3WnhRMWZDbEI5YTI0Q3NNZkpKVExUQnVY?= =?utf-8?B?clZlZFFBNk5OTjVoaStWbE5sMmJFRVBoUVJnMDJMMVBvVWdKUTI2Nmo1TGdY?= =?utf-8?B?VGRsdzdSUjNROW1HZGZJTlNIRmM5S1FROGUvM29qZkw2b2E0NDR4RStkVmRR?= =?utf-8?B?QXJZVDlFelM4RUxBVTF6YnZ0V3kzN2pZVzZlTU1mNFZSbjkzNXhVR1R4M0Mw?= =?utf-8?B?czJWa0pwVFgxcnVBM3dNUFEyb0NTWTRDbkE3aGtnUDJ1cFFvWllqMFZhZDhk?= =?utf-8?B?eW5COERRV3BuaEJlZEFTMFd4dVlsQzJ3OGFtSndjZWVRcG1iRXJoSi9wY0h2?= =?utf-8?B?bGpROHprWnozZXVuT2pPTGVxRFQyank3UTlmRTZISDRmanp0V0ZGYWtadThF?= =?utf-8?B?VXdFeU45dFRjL1ExTUpjMWdPS01sSDJMaHFZSlIzVzlicmxkNWRYQkI2YlBj?= =?utf-8?B?RHFOT2F1aGNtWHdJUnVzVzhGdmVIKzZRRzhyNC83UnVmdEJXSVJzZk9DbDh0?= =?utf-8?B?c3pEVDZ3U0FCMFlGZHkva2pKcUUvLytXODVlUVdCK3pxRGc1WU1wbmpwQkpO?= =?utf-8?B?elNHNStmdDJFL25ZaGtRYm14VDh2dHp0c2FsVE9TeENLZVAxRWRldnlSUElj?= =?utf-8?B?OGYzUTcvc1krdk1QV2xvd3JzVFZEZU9maDcvZndZamdCOGs5eWN0bWlhZy9x?= =?utf-8?B?clMxWEcwZ3RnV2ZsN1NTTmhZclQvL3QyYlk0THNObnNTYmwwc2NPbTAyN3Zn?= =?utf-8?B?VE5ldjlscDVqdVhqVzBKak5WSU1JbVg3dlpqQlNIU0pDSDhweFdNTVYrV29t?= =?utf-8?B?WThMcHVDb296ejYzd3JhZUlQRDYxQ1VQNTdrUWEvbFU5bXZzOFFOR3VjUHNa?= =?utf-8?B?ekR4YmFMYXBOamkyV3ZMcytrOGozQ1JCL210dHlUOCs5blhjNkM3R1dFcWlP?= =?utf-8?B?a21Vb3V0aVZZMytmYlZBbll6WitSZU1tck5La2NLUzZ0aDlxREg3a2RhVGQx?= =?utf-8?B?NWQvRkZhV1hkMVRRUFpFYkY3Z1ZMZFRXa3ZSSGxBeFBacUppQWpHVzZZa1Mw?= =?utf-8?B?NlhLMmhOUnpELzZxdmozOTh6U3lPZHdBWk56Y3dsc1pFTFpFZXhEY1MzQkZ4?= =?utf-8?B?blVVZERYQlR6SjFFZjRDZ25rbjZuTTZyb0lkZjB6d2lzeUlFalBKZjRibDVD?= =?utf-8?B?VFFGbGNKVFYrdlI2ZU1RREhvWXR2NlBtbVRrK0dGNE1yS1YxRVBTMmhyelZG?= =?utf-8?B?bm9vRXg4QjA3WGh6eCszTmtRRnhTa0E5TnJaTGY5UmxWRUQvajBjeXdscExa?= =?utf-8?B?aklNeThIUG03eiswdjVuUHFjSmlzU0NJNUZpUUc3RlA1OUt2VUVFNUhMUGpv?= =?utf-8?B?UGlycDBTSFN2MHpYQ29mdlpuWUh1M3RZU2tkUDlPWHFMcEFrMXE2WkRHZGJn?= =?utf-8?B?TEszUkE4WmRrYTEvM0xmMnA5bk5RdjFHdi9ralNjNUVMMkFJUDF1cmRwZElk?= =?utf-8?B?YTZCdFVHaXRqakcvTEZUbm1ZRHFCRk5TUzYybGgvSzhVRDlTMzh5bnVLZ2l3?= =?utf-8?B?NHZVQlUvZkFrZ0N0OWF4WjBJZVVaRTBVQ01lMjJRS3Y1bjJ5OVFpekFFaW1C?= =?utf-8?B?ZmRKZEdFRVVnQzJEd0pIWllBRmVleEVoVm80VFBIVFdGNXY4ZlpnbURJSzNK?= =?utf-8?B?enFTOTgrZXI5ZjBDckRSZmduTktVYVVSZGU4eS9aRE1abzl5OGRhT1UvSDZP?= =?utf-8?B?OWZOOHZwNWNZRVhlY2hJejFUVFhraVVOZmFoN2x6Q2dzRzdsV3ZIYU1IaDlG?= =?utf-8?B?cGNBS2NnMVdvQXpmZzBoQVB1dGJDcnJaNTY1ZHFkeFdFWUhVTGpyWFVNWFZP?= =?utf-8?B?dU11b09YTG5OajdLU0VWcEhQTEM1QS9CVG05eE5KM0dzWGJ3U1hUUFk4Mjlx?= =?utf-8?B?V2VYUDgzNDlHUHpPMDBvRWdTNUk0MHpYNmlOWnpPdUI1cng5bEd2MmZaRFhm?= =?utf-8?B?RDBEd1RURWR3Y3R2cjFhd1ZRait5c1dLMGRBR1Vkejl5KzRHanVrWERsYXRw?= =?utf-8?Q?HXcJeIZzf1TaY2Iz4cJ1xMYpaTJUYbCeSPsqal2Vg8w6?=
Content-Type: multipart/alternative; boundary="_000_0B2DE27EB67F413B806B7131B90F3333arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8cf27cee-0230-4a92-7077-08d9aeb385eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2021 19:00:31.6905 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3Mf4WyE5CPX1MgBQ3pNMc6qdvnxIPp3N2eWqUz8/JM02P3/nDOdlyKJFg4yWcaSt3mnvj645jnuJu6ucrx/pQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3201
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YsGJNl_SiVXQ-9OpjX509Hr-8Tg>
Subject: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2021 19:00:38 -0000

--_000_0B2DE27EB67F413B806B7131B90F3333arrcuscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVk
IGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wMywg4oCcVGhlIFJlc291cmNlIFB1Ymxp
YyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFJQS0kpIHRvIFJvdXRlciBQcm90b2NvbCwgVmVyc2lvbiAy
4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dM
QyB3aWxsIGVuZCBvbiBEZWNlbWJlciA3dGgsIDIwMjEuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91
bmQgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNp
ZHJvcHMtODIxMGJpcy4gQXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhlciB5
b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3Nl
ZC4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg==

--_000_0B2DE27EB67F413B806B7131B90F3333arrcuscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <A42970000A142D41A56E9D7AD8A88933@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBwbGUt
Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTIuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi
IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv
cmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw
aGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6
ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9y
OiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz
dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3Bh
Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAgbGFz
dCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMt
MDMsIOKAnFRoZSBSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSB0byBS
b3V0ZXIgUHJvdG9jb2wsIFZlcnNpb24gMuKAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdp
dGggeW91ciBjb21tZW50cy4gVGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPldHTEM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+d2lsbA0KIGVuZCBvbiBEZWNlbWJlciA3PHN1cD50aDwvc3VwPiwgMjAyMS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h
bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dv
cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZHJhZnQgY2Fu
IGJlIGZvdW5kIGF0PC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPGEgaHJlZj0i
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMt
ODIxMGJpcyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm
LXNpZHJvcHMtODIxMGJpczwvYT4uIEF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdo
ZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBk
aXNjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z
OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFk
anVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJn
YigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh
cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNp
bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TmF0aGFsaWUsIENocmlzICZhbXA7
IEtleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_0B2DE27EB67F413B806B7131B90F3333arrcuscom_--


From nobody Tue Nov 23 11:12:25 2021
Return-Path: <randy@psg.com>
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 4B26D3A0878 for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 11:12:24 -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, 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 FTx4NQjW9rhI for <sidrops@ietfa.amsl.com>; Tue, 23 Nov 2021 11:12:22 -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 E47D13A0871 for <sidrops@ietf.org>; Tue, 23 Nov 2021 11:12:21 -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 <randy@psg.com>) id 1mpbDG-0000ys-H1; Tue, 23 Nov 2021 19:12:18 +0000
Date: Tue, 23 Nov 2021 11:12:17 -0800
Message-ID: <m2bl2asn3i.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Keyur Patel <keyur@arrcus.com>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
In-Reply-To: <B1F434C7-583D-4DB4-81A3-C6DDA9808C41@arrcus.com>
References: <B1F434C7-583D-4DB4-81A3-C6DDA9808C41@arrcus.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/JRJ-JzEv5GaO7xrVgltAMtSFW-Y>
Subject: Re: [Sidrops] Extended - [WGLC] draft-ietf-sidrops-rpkimaxlen-09 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2021 19:12:24 -0000

ok, i was gonna stay out of this but ...

maxlen is a macro.  think big, e.g. ipv6.

randy


From nobody Wed Nov 24 02:30:09 2021
Return-Path: <job@fastly.com>
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 494433A0D49 for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 02:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 cfCd-nhTmUiN for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 02:30:03 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 A96903A0D36 for <sidrops@ietf.org>; Wed, 24 Nov 2021 02:30:02 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id z5so8222952edd.3 for <sidrops@ietf.org>; Wed, 24 Nov 2021 02:30:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Oj1T3LKRjN+jIT91S+BhfVGqWHjczYjjTm43oE61G9c=; b=DG9Efqh58HVk5KF31OZ2N2IUsVwqsL2YQeHdKIKychga7kPfGujDam5AS5T5DGvVbQ qgc5ki+GK4+WZF5NjkNaMHslkO2SL76dxRJCvRqpOhw2JzNUt5z1WUF9iM6lVRMteE+1 F8ziB9f74PU8qfYPKnpeUwV2dS50PBbIcSdvY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Oj1T3LKRjN+jIT91S+BhfVGqWHjczYjjTm43oE61G9c=; b=6J9GryrIChk5fa2xIjLKAydUOJD9v8p/V803U/FZdBHn/YiTrFTFB8ecUGaTIQBGUv ooLDi27Sjgk7DHuIUABi874e2CR9irD1PJ+EWM7njL6qtV7GaDI83ckoAiBmr/hiztcU jgwE7/6UvUtScDSmIp2FNaQ9g8YxbG9nR6iBt6Dn5bKlXK9Lzegs+29FPFgTdZ3rrsmw F6Abkme0kDLGU8bRnHj2tkU6eZ70wC/02f9X+3YmQpNWcufafMo9PwwqNLAwhfyiWKoX BQErVyVzVcqT+hem9Wvqr8CFzgg/YK02SqrPhMlY/iZSXPbw4lrzfeZ2PX9P/4cLVacO TFGQ==
X-Gm-Message-State: AOAM533Tp+K1TbPgZtn3eI4qA4iYDU8ySc/mlUXUlDzia0g/JaXjhOoP LN5cz+ZC9JKr175cAiJraH3L8ZWmd8ajAg==
X-Google-Smtp-Source: ABdhPJwN0FShMGimk0Y5r4PhK/1w94MsJjpQisGkUsHH91f5+aKbplJLHNsc+i1SmiZju5kPG7Hpag==
X-Received: by 2002:a05:6402:11cb:: with SMTP id j11mr23825238edw.38.1637749798962;  Wed, 24 Nov 2021 02:29:58 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id r13sm7413267edo.71.2021.11.24.02.29.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:29:58 -0800 (PST)
Date: Wed, 24 Nov 2021 11:29:57 +0100
From: Job Snijders <job@fastly.com>
To: Keyur Patel <keyur@arrcus.com>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <YZ4UJYBx2ihZAWwG@snel>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/39d4vGrT10Sg0pU2gWptH9wvYRU>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2021 10:30:07 -0000

Hi all,

Is there at least two implementation reports I can review? If yes,
where?

Kind regards,

Job

On Tue, Nov 23, 2021 at 07:00:31PM +0000, Keyur Patel wrote:
> Hi Folks:
> 
> A working group last call has been requested for draft-ietf-sidrops-8210bis-03, “The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2”. Please reply to the list with your comments. The WGLC will end on December 7th, 2021.
> 
> The draft can be found at https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis. Authors, please reply indicating whether you're aware of any relevant IPR that hasn't been disclosed.
> 
> Regards,
> Nathalie, Chris & Keyur
> 

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


From nobody Wed Nov 24 02:43:08 2021
Return-Path: <job@fastly.com>
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 3BFAC3A0D50 for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 02:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=fastly.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 x3s6Wh4BjTda for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 02:43:03 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 D4E8D3A0C8C for <sidrops@ietf.org>; Wed, 24 Nov 2021 02:43:02 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id o20so8220582eds.10 for <sidrops@ietf.org>; Wed, 24 Nov 2021 02:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JDkEUJMvqKhjhH+daI4p+VsDPRdJPb9kcIt8BwUEDbQ=; b=cPoQkYeltxqFw6zY692CJ3yNIn8gB9wDDKzkBgaa1Exrr0pKGNKvMG6Okhsd6jF/Kk y7aS9Z6DpGgpTsyKoTQFjXrjO//jdDXMVF54RDIDnw6aUPb/gg3kPB+h9T/BLTxOh3BL FWZfw2I32GK/yYy4CWNzOIuZ+bgms52FrZ18Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JDkEUJMvqKhjhH+daI4p+VsDPRdJPb9kcIt8BwUEDbQ=; b=ep33DtgNFv6DoGsH6y7uqEzvJSCB0mRrc4e/Vg0oEOoCS1sYw/0uvrHcPuzP1KNNJw LPkETLD4oh77W2OK/2lql5UZblqNIAIJHvnAQCtf1jydDyBDOb4oRx8o4PydpNPIOXHZ mjHdW6bJ8AX8yqXspmsBAFY8ycXhwbzzviOERM5hyd6rgVWdo2LVFXG8dEyRcSSfjB0j bxIm61N8wMFJ9qCfLYP5onKqeXWoQtL0xM1DMPurn38EOyfo1WMPk5qS1+WwNPBVy1Yx ySMID55GxDVTnfBRFe5XGOpFsqAlt1h+ZDVdu1smXaxq/8CSLHisRQmuQHjAaicL5KXQ E1Lw==
X-Gm-Message-State: AOAM532Mzvp18K0kSxCod6cUWOqQGQXxhY6bA348+DgqPdaZ58Hnb+Lj KcLHeb0WxFLfOauYZJHiW5lh1Cewt+yuCw==
X-Google-Smtp-Source: ABdhPJwmjTZb+haO/Z0x8YSHp1vOvJ+J3gQ32Gh8IfCGAXybZPKQAwMz388mHcYa/m7ScCIGJhHY3w==
X-Received: by 2002:a17:907:3f83:: with SMTP id hr3mr18726441ejc.555.1637750579147;  Wed, 24 Nov 2021 02:42:59 -0800 (PST)
Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id hs20sm6837041ejc.26.2021.11.24.02.42.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 02:42:58 -0800 (PST)
Date: Wed, 24 Nov 2021 11:42:57 +0100
From: Job Snijders <job@fastly.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: Nick Hilliard <nick@foobar.org>, "sidrops@ietf.org" <sidrops@ietf.org>, Ties de Kock <tdekock@ripe.net>
Message-ID: <YZ4XMQKHI5ZlLAui@snel>
References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> <a775bf84-29a3-45f1-08f5-a6728cf11bc3@foobar.org> <CAEGSd=BvEhaZyqE01hCBYwafZH5Z1-6-0eYbRL-AD3sURe4STg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEGSd=BvEhaZyqE01hCBYwafZH5Z1-6-0eYbRL-AD3sURe4STg@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sHoqE7Czv3_-VwjPQYPfayUpF5Y>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2021 10:43:07 -0000

On Tue, Nov 23, 2021 at 04:43:26PM +0300, Alexander Azimov wrote:
> In the world with high adoption rate of ROV I would have definitely
> supported this document for publication.
> Unfortunately, according to latest research by Geoff Huston - we are
> living in a very different world.

Can you provide a reference for this 'latest research'?

> We have steady progress in signing ROAs but far less progress in
> adopting ROV.  And you can't easily distinguish is it safe enough to
> start using maximal ROA length or not. For the network that I'm
> responsible at the moment - it is not safe.

Can you elaborate? This seems a rather subjective statement. In any
regard, you are free to configure your own ROAs as you deem fit for
purpose. :-)

> Another complication may happen when ROV is done at egress (rfc8893).
> In case of fast de-aggreagation you may need to turn it off, though
> such issue is much easier to resolve.
> To sum it up: I still have a feeling that the document is ahead of its
> time, and in the imperfect world may itroduce new gaps between
> routing-security-in-theory and operations.

I fail to see how this document introduces new gaps. It merely warns
about the potential pitfalls of using the maxlen macro functionality.

Kind regards,

Job


From nobody Wed Nov 24 03:11:52 2021
Return-Path: <tim@nlnetlabs.nl>
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 2693A3A0D7C for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 03:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 N8IXYbbrWhAg for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 03:11:36 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 3FFD43A0D6E for <sidrops@ietf.org>; Wed, 24 Nov 2021 03:11:35 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 55C15A0 for <sidrops@ietf.org>; Wed, 24 Nov 2021 11:11:29 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1637752282; bh=nQMRinvLSrLEeOaAVq6mVJnA8Vz6d/qavQNHMsk+AWQ=; h=Subject:From:In-Reply-To:Date:References:To:From; b=qwi/Retr8+JqqOu1H69KrDjihoG1pxHSM8bNgpED1DimOjwg+S550ccvR/qUzX5ol I28bxj5VtZT21Ws+AlytR5GClWohbtuVG8+XxJGXqHXVlxSg8j0t90kRVYiTnoG72T VN5nIrc2AghXhlIf0oLOPuuaIGhIYmB/XWWyJT5MCmGOhgBJJoPr4TuT6b2PM385mh B0uFQoRfuq1EjSIV5WqE+QwXW/8ZHY6HzmvlAAdpBuEXnVPjyRiVgivyADfIHXTNAY yYFaMRBE5w5OPissYX10uWmhxd4S0CWJUFk4kzSj1JlhwgcvpUk3gHvCKw6IRUQQ0j E+ZomNiXtzPRg==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com>
Date: Wed, 24 Nov 2021 12:10:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/IPcwVUXFxoeNtPPfC9U3kNRMgqc>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2021 11:11:46 -0000

Hi all,

I still have some issues with the ASPA =10PDU as defined here.

I am not necessarily opposed, i.e. I am open to be convinced otherwise, =
but I do not see a very strong reason for having big, per AFI, PDUs =
which "MUST deliver entire data of an ASPA record in a single ASPA PDU".

I understand that there is an intent to avoid / minimise race =
conditions, but I am not fully convinced that this is the best way to =
achieve this.

I think that a model similar to multiple ROA objects and resulting VRP =
PDUs is preferred.=20

Even though we instruct CAs to use a single ASPA per customer AS, =
situations may arise where multiple valid ASPA objects exist - e.g. =
because of transfers, or because of SLURM (which I think should be =
extended for ASPA). It would be much more intuitive to me that RPs would =
therefore derive "Validated ASPA Payloads" (VAP) - essentially tuples =
of: (AFI, Customer AS, Provider AS). And that "announcement" and =
"withdrawal" of these individuals VAPs would be communicated as PDUs - =
similar to the IPv4 and IPv6 payloads.

I think it should be possible to avoid race conditions because a single =
update can contain multiple such PDUs. They could be sorted by customer =
AS to help routers further. I think we can expect then that a router =
applies all updates for customer AS - provider AS mappings in an atomic =
way. And if they can't then I do not see how they would do any better in =
case the PDU always has the full new list (per AFI). The same can be =
achieved locally by making a new copy of an existing provider list for a =
customer as, apply the delta, and then replace the original list with =
the copy.

So to me the advantage of having the smaller "VAP" =
announcement/withdrawal PDU would be that it:
- is similar to ROAs so more consistent and intuitive to implement,
- deals well with the possibility of multiple objects which cannot be =
prevented,
- reduces overhead in updates.

As I said, I have an opinion on this, but I am truly open to hear what =
others have to say - router implementers in particular - because of the =
possible race condition mentioned in case routers apply updates naively.

Tim


> On 23 Nov 2021, at 20:00, Keyur Patel <keyur@arrcus.com> wrote:
>=20
> Hi Folks:
>=20
> A working group last call has been requested for =
draft-ietf-sidrops-8210bis-03, =E2=80=9CThe Resource Public Key =
Infrastructure (RPKI) to Router Protocol, Version 2=E2=80=9D. Please =
reply to the list with your comments. The WGLC will end on December 7th, =
2021.
>=20
> The draft can be found at =
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis. =
Authors, please reply indicating whether you're aware of any relevant =
IPR that hasn't been disclosed.
>=20
> Regards,
> Nathalie, Chris & Keyur
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


From nobody Wed Nov 24 11:20:54 2021
Return-Path: <oliver.borchert@nist.gov>
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 1FE3F3A0B53 for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 11:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, 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 VExXKmb4jund for <sidrops@ietfa.amsl.com>; Wed, 24 Nov 2021 11:20:48 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20709.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::709]) (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 7B39B3A0B57 for <sidrops@ietf.org>; Wed, 24 Nov 2021 11:20:48 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kLxZb4Kj2+ZTkoQn1XnWS978X3CeszQaPj4zBBGyHDUVDzAn/fg3+hmaz8UCa6e5mx9MyjoGm7YQqrulgH3G7q/hYhMRllizhfzxRHUUleIESAa3DXudBGvnnZFXgkcz2T/gDEeXkBCIRAFz9V8kEe0AQ7d5vQhCVWBRuvaX61vG8AYjgi0J6YVI/S5UBkAycLMboX3dWyW0EoMlbK9B/CbMyNJ8d0pIVDlGLPwfWW3IX35EeIau6rClyvNGCBOJsBsp6byycQu6zteCyH8QebpOWJrLS7Fh4QRHUKSdqg5EfDiry51Kq6Gdz8dIyIx699k7ycIIIpwrItGE8M6EGA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9dlm+PnDHdOeLHiTj7lA86u+PABYmPJQ153JahDAFf4=; b=jiSrn8Mxb5Rify9zNiGEtZm7vMCtBGA5t6lVZQOiwFREt5y80HTs82nn+eTg8YRIstzKN9xVLrAEWPylQ/ioPeSnd2kqOTgSsJyZnGoeJrIutq+8KAddMVmYuS5ZhDFkVzkjQ6YctWz2iqK15mnFEIQ9K6gLqWx5beIxvETvatUKZrcnfi0/oU4sipBL3bOLnhIJv3vkTfTuCRaIHWUacb0bvWORwM/09Ub4VHFWcHi6+5zf/6hGp9ulWZtFxQKXonPypmqLFssbdnezIyw9tskbq9mu8Ok+7GIx/eeOwMivGo3CjwTI90GWwskGcWRbLnHWxX3IVwEKJou+QxwkSg==
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=9dlm+PnDHdOeLHiTj7lA86u+PABYmPJQ153JahDAFf4=; b=X87Y7CzEExMod2JNOOPEl75rYDdYemkjy3UycW1zXdSAX9iRRLjWqtvl8AGvk6X4Aq6jZ/6jfkFKTdCYR474KngZd1aNpIiOm5l+iAkUPCidBYgZycacKgtuj2NQK6SHP3zkTa0hU827n+S0wNr05fFf7pWirVubK9NcWwt35No=
Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6708.namprd09.prod.outlook.com (2603:10b6:208:2a7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20; Wed, 24 Nov 2021 19:20:39 +0000
Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4734.022; Wed, 24 Nov 2021 19:20:39 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: "sidrops@ietf.org" <sidrops@ietf.org>, Tim Bruijnzeels <tim@nlnetlabs.nl>
CC: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
Thread-Index: AQHX4JxjysDMm9aqUk+5kLJKlC2YP6wShquAgAA1BAA=
Date: Wed, 24 Nov 2021 19:20:39 +0000
Message-ID: <98F86C8F-9E56-4622-B854-83B8D8C77125@nist.gov>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl>
In-Reply-To: <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.55.21111400
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7cec8681-fb2f-4684-d54e-08d9af7f802a
x-ms-traffictypediagnostic: BLAPR09MB6708:
x-microsoft-antispam-prvs: <BLAPR09MB6708E130649F9EC78410102798619@BLAPR09MB6708.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: b2H0XwCucqGMhDDp9AHn2IJtVpHNvpPheeo3tZzaknv+zltBOcZs4PwByCZ2rPoVSoc6vew4B6XeFLyHPGCaBso9qc0kJM27vAT3YSGosUy8EpXflilTqEMC6iCYXW/ur0vQrWBUCBtAS/5t823CigOhH0yM0nMcJkGUrcqWjRqGOJh58zZtnicAiihZyeCRk0B4+U7pUYinVSemYilsU7WUMXwpRYBT9ZZXKpdsb2V6v2eIGPOYZDUZaLwCVcG1kUix0SQqPUd+GQTRzMLvLfaf+4RKKyK6TrfuHd/KvgfGKRY3wzmrQl/kmevQ15gmZu0P4G8bQTlW9CvhqTwcQiycbT0jZJmp8DdeIr1BAll9J7D3B4Zx6U0Aq1kToP4dnDsnb4/KI6VyBveWdEpGjuQcULU1XAzi3sPt66SvM+lptHqf/pnTmFxt3mVghD8OOJ3RihRlpI622ikhodG3N4u/XHLb2DRu4Zg6Ea5j2nbyLJRgaH4JlXpLltErrTnubQ8kzuwYBA3A3D8fClLRxyb/8vC7cD3dNj1lxMl8WQnBsE8ZscRaBUQgqw3wO59pPMVNOQXgiseoEf1EnFaUFSDtc7IBaW+RRuABY7dvjmzGyzE8drRF7K/xof5FKxI5VJWrhxDmUx3tdqyPObsc2uVTbXyzL3iYMtU+IpfKpzKV8eczcGk07ERmPB4z1+4kBU82NZDFpkkWOq2k2lxzG7l9LFbXrcYdjFs6M2kG/hP88Y5xq0b6xLeMe9gAjPZ+
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(36756003)(82960400001)(6512007)(33656002)(186003)(83380400001)(316002)(40140700001)(508600001)(71200400001)(5660300002)(38100700002)(76116006)(122000001)(107886003)(66446008)(4326008)(110136005)(8676002)(38070700005)(86362001)(6486002)(2906002)(64756008)(66476007)(8936002)(66574015)(6506007)(66946007)(2616005)(66556008)(45980500001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bVkwQ1NxTk1SaHVTeU5nV09hL3ZoWU1EWW5uYXkwVzBxaDgzMFlweGlmZW9U?= =?utf-8?B?WkVDOWdBUXJDN0JWTkFxWEZpcWFtcWdNakFhajUxNjkveFBSVnV6K0hEY2dN?= =?utf-8?B?Z1dmckk2anFaMDZzVkU3TGNQbThCd2tSRlZUdGZJVy9EZ2J0dkJ4YVQwbitR?= =?utf-8?B?OWNTcXUxUXo5OUx3Z3lhOHNuR042R2VNYnNES2dDRzNqb3QzNnVLWUpyMkQx?= =?utf-8?B?RUUzOS9QWGZLekNxTjhtVVY4SHl4amhDZHpDZnQyN0FmUGdRdHRGU1JTUzRH?= =?utf-8?B?ZTBDUXkybEtKUlVPYnl2aTR3L3FEbDVmRUozcG8xLzg1d2NFdUNDRzNzUHA4?= =?utf-8?B?dVVHc1czVGF0K2d5YjVnbWErNW1BK253d2Jpb3JSM1BPamp2YTNhVGZMS3ZS?= =?utf-8?B?K1RDQzFxNU43OXFzL2VORGNIeXV4UHVlaDVHT0hvTHlLWEFYM2toY0tvQ1ZY?= =?utf-8?B?R1B2WnBpdVRCbzUxcFg4NG5EaDFjNmpWZVowc3RKU1ZkbVVrQ0xJcmVqWU5z?= =?utf-8?B?cDJLSnVGckZzYlMzRHZydksxZTdSWTZTK2VseitLbVhYVEJSTm5HazFaT3dP?= =?utf-8?B?OG1NSW9kVCtBRitnZnpJOWZGOVJkQWpQajZmNzJ6RnlpVEdmU21LWDhjakNi?= =?utf-8?B?eXBnNS95SW0yTWNVM1h3b0kwTHVGQWNpTktBaEFoYWltTGFuQWM0WmI1YlpH?= =?utf-8?B?enhTKzNPWDlBbS9VK1FTVHk3MStDT2JTQVRlNG5HNUdtK25ISmF1TVhrdzIw?= =?utf-8?B?ZlNDL0NqckZhM0k1OENqWENlbWVEc25XMllyWXZJbDdGUHB3dGZ2T2dxSTJP?= =?utf-8?B?K0tYb0oxSXYxcDRnYnVxWUhQdXAzL1dTaDRpTS9mQWlLeTZTN2FnRHlqZ2Rr?= =?utf-8?B?L0hvQkswV0Mxei9wc1pqNkpTdU8yWXppWCtGc05rdE5PRzZmcW5LbHh2b0pD?= =?utf-8?B?R3FyV3JHY1ZuTUhWQ0xwWWQ4eGV2SXM1Zyt4Z3N1YlMvTXJpY1ZiT3lJblo2?= =?utf-8?B?ZmlOYXlXcTNycjFFNE5QZnJvdy9xVDJXcXFNdWF6clovY21vT1RabjVRYnJo?= =?utf-8?B?VjlNZURsV05OTTNMRkc1Z2ZBaFNkZ1RmMlh5ZDQ1cHdlbFNtZWt6cXlHclhM?= =?utf-8?B?NlllZEV5cEFYcjFhdWRLcXZUWmVRbTFSb0VsSVpLVGZEY014dzd1WHd4b1lM?= =?utf-8?B?TGsrTnBxOHJQbndaZzd2MHhtQ3ZkSnIreVZpVVpjZGhDbzVwNG80c2h5Y3c5?= =?utf-8?B?WVI1blhwNTdvdXY1Wm5lcWdwQWZWNmVCTzZxRHpTMUVrZlg5V0FFNWVvRGg3?= =?utf-8?B?MXQvYTBsbVVqeXIrajM3bk90R1NWSmlVQkhzckYya01RL3haRDlES1V1RHM1?= =?utf-8?B?MjNFQUpIZFZqTDd2bUlBdWN4elBac1l4K2UrRUl0eUJabE53NUZDZFNMUGRG?= =?utf-8?B?MVZOLzBCZStrbExEdEpNaSsycTR0NWp4T3Q1YjcrWTFERUZSdlBOQzUvaXoz?= =?utf-8?B?ZVVCUWVlNDJ3Rm9jcTBEcSs2UTFjcUVhN1JKekZ4WXpWNVlIMHVOdmlBYnNR?= =?utf-8?B?MW5XMDBmaDUrOGZXSDZGQithajRPT2FZOUs4cytnOG1tK1Z4TC96YUFPTXpO?= =?utf-8?B?VUt1UHYva1FEUG85WG9vOUp0dE1GRnpUYnRzaW1EWlJXdk1PWm4rQ05YY0My?= =?utf-8?B?a3dwdjg3NFJYbFZJd1hPanlUY3YwWnhGSVdjcFFPRVFKS0Y1Um9vVnlzSFlK?= =?utf-8?B?T1RqdjVKYmZ5b2poSElqdVhKeGVsZzd6TE5NWVRoMXhsL3lmT3dwQXMrRXlv?= =?utf-8?B?Q082Rms1YVpSMUJJdXdJZz09?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <55D97A40AA853245BB09006B539A10B6@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cec8681-fb2f-4684-d54e-08d9af7f802a
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2021 19:20:39.4289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6708
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/w2nhCRGhSdW4qmNtdLyzJQIiRYk>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2021 19:20:53 -0000

SGkgYWxsLA0KDQpJIHRvbyBoYXZlIHNvbWUgaXNzdWVzIHdpdGggdGhlIGN1cnJlbnQgdmVyc2lv
biBvZiB0aGUgZHJhZnQuIEZpcnN0IHRoZSBwcm9jZXNzaW5nIG9mIHRoZSBBU1BBIFBEVXsxMX0g
YnJlYWtzIHdpdGggdGhlIHByb2Nlc3NpbmcgZmxvdyBjb21wYXJlZCB0byBhbGwgb3RoZXIgZGF0
YSBQRFVzOiBQRFV7NH0sIFBEVXs1fSwgYW5kIFBEVXs5fS4gU2Vjb25kIHRoZSBGbGFncyBmaWVs
ZCBzcGVjaWZpY2F0aW9uIGlzIGFtYmlndW91cywgYW5kIHRoaXJkIHRoZSBlbmNvZGluZyBvZiB0
aGUgQUZJIGJpdCBjb25mbGljdHMgUkZDIDY0ODIuDQoNCg0KMS4pIEFTUEEgUERVIHByb2Nlc3Np
bmc6DQo9PT09PT09PT09PT09PT09PT09PT09PT0NClRvIHJlZnJlc2ggb3VyIG1lbW9yaWVzLCBQ
RFV7NH0gYW5kIFBEVXs1fSAoUk9BIGRhdGEpIGFzIHdlbGwgYXMgUERVezl9IChCR1BzZWMga2V5
IGRhdGEpIHdvcmsgaW4gYW4gKGFubm91bmNlIC8gd2l0aGRyYXcpIG1vZGUgY29udHJvbGxlZCB3
aXRoIHRoZSBGbGFncyBmaWVsZC4gRWFjaCBQRFUgaXMgY2FycnlpbmcgYSBzaW5nbGUgZGF0YSBw
b2ludC4gDQpGb3IgaW5zdGFuY2UsIGEgUk9BIHRoYXQgY29udGFpbnMgIm4iIHByZWZpeGVzIHJl
c3VsdHMgaW4gIm4iIGRhdGEgUERVcy4gVGhlIEZsYWdzIGZpZWxkIGlkZW50aWZpZXMgd2hhdCB0
byBkbyB3aXRoIHRoZSBkYXRhIHBvaW50LCBhZGQgaXQgb3IgcmVtb3ZlIGEgcHJldmlvdXMgcmVj
ZWl2ZWQgbWF0Y2hpbmcgb25lLiBBbHNvLCB0aGUgY2FjaGUgbXVzdCBub3Qgc2VuZCB0aGUgc2Ft
ZSBkYXRhIFBEVSB0d2ljZSBvciB0aGUgcm91dGVyIHJldHVybnMgYW4gZXJyb3IuDQoNClZlcnkg
c2ltcGxlIGZvciB0aGUgcm91dGVyIHRvIHByb2Nlc3MhIQ0KDQpOb3cgdGhlIEFTUEEgUERVezEx
fSBmdW5jdGlvbnMgc29tZXdoYXQgZGlmZmVyZW50IGFuZCBicmVha3Mgd2l0aCB0aGUgcHJvY2Vz
c2luZyBmbG93IHVzZWQgaW4gYWxsIHRoZSBvdGhlciBkYXRhIFBEVXMuDQogDQpGaXJzdCBpdCB1
c2VzIGEgc2luZ2xlIFBEVXsxMX0gZm9yIGFsbCBjdXN0b21lciBwcm92aWRlciByZWxhdGlvbnMg
b2YgdGhlIHNhbWUgQUZJLiBTZWNvbmQgaXQgaW50cm9kdWNlcyB0aGUgY29uY2VwdCBvZiDigJxp
bXBsaWNpdOKAnSB3aXRoZHJhd2FsIGluIGFkZGl0aW9uIHRvIHRoZSDigJxleHBsaWNpdOKAnSB3
aXRoZHJhd2FsIHdoaWNoIGlzIHNpZ25hbGVkIHVzaW5nIHRoZSBGbGFncyBmaWVsZOKAmXMg4oCc
d2l0aGRyYXdhbOKAnSBmbGFnLiANClJlZ2FyZGluZyB0aGUg4oCcaW1wbGljaXTigJ0gd2l0aGRy
YXdhbCwgdGhlIGRyYWZ0IHJlYWRzOg0KDQp8IFJlY2VpcHQgb2YgYW4gQVNQQSBQRFUgYW5ub3Vu
Y2VtZW50DQp8IHdoZW4gdGhlIHJvdXRlciBhbHJlYWR5IGhhcyBhbiBBU1BBIFBEVSB3aXRoIHRo
ZSBzYW1lIEN1c3RvbWVyDQp8IEF1dG9ub21vdXMgU3lzdGVtIE51bWJlciBhbmQgdGhlIHNhbWUg
QWRkcmVzcyBGYW1pbHkgKHNlZSBGbGFncw0KfCBmaWVsZCksIHJlcGxhY2VzIHRoZSBwcmV2aW91
cyBvbmUuICBUaGlzIGlzIHRvIGF2b2lkIGEgcmFjZSBjb25kaXRpb24NCnwgd2hlbiBhIEJHUCBh
bm5vdW5jZW1lbnQgaXMgcmVjZWl2ZWQgYmV0d2VlbiBhbiB3aXRoZHJhd24gUERVIGFuZCBhDQp8
IG5ldyBhbm5vdW5jZWQgUERVLg0KDQpOb3csIHRoZSBQRFUgImFubm91bmNlIiBwcm9jZXNzIGZv
ciBhIG5ldmVyLWJlZm9yZS1zZWVuIGN1c3RvbWVyIEFTIGlzIHRoZSBzYW1lIGFzIHdpdGggYWxs
IG90aGVyIGRhdGEgUERVcy4gTmV3IGRhdGEgaXMgcmVjZWl2ZWQgLSBhZGQgaXQg4oCTIGRvbmUs
IHZlcnkgc2ltcGxlISANCkl0IGJlY29tZXMgdHJpY2t5IHdoZW4gdGhpcyBkYXRhIGdldHMg4oCc
dXBkYXRlZOKAnS4gSGVyZSB0aGUgcm91dGVyIHJlY2VpdmVzIGEgUERVIHdpdGggdGhlIOKAnGFu
bm91bmNl4oCdIGZsYWcgc2V0IGFuZCBhIGRpZmZlcmVudCBsaXN0IG9mIHByb3ZpZGVyIEFTcyB3
aGljaCBsZWFkcyB0byBhbiDigJxpbXBsaWNpdOKAnSB3aXRoZHJhd2FsIG9mIHRoZSBtaXNzaW5n
IHByb3ZpZGVyIEFTcy4gDQoNCkZvciBpbnN0YW5jZTogKGN1c3RvbWVyLWFzKSAocHJvdmlkZXIt
YXMpIChwcm92aWRlci1hcykg4oCmDQoxc3QgUERVOiA2NTAwMCA2NTAwMSA2NTAwMiA2NTAwMw0K
Mm5kIFBEVTogNjUwMDAgNjUwMDEgNjUwMDMgNjUwMDQNCg0KVGhlIGlzc3VlIGhlcmUgaXMgdGhh
dCB0aGUgcm91dGVyIGlzIHRhc2tlZCB3aXRoIGlkZW50aWZ5aW5nIHRoZSBjdXN0b21lci1wcm92
aWRlciByZWxhdGlvbnMgdGhhdCBhcmUgbWlzc2luZyBmcm9tIHRoZSBuZXdseSBwcm92aWRlZCBs
aXN0IGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyBsaXN0LiAoaGVyZTogNjUwMDAtNjUwMDIgaXMg
aW1wbGljaXRseSB3aXRoZHJhd24gYW5kIDY1MDAwLTY1MDA0IGlzIGFubm91bmNlZCkuDQoNCldo
YXQgYWJvdXQgaWYgdGhlIGNhY2hlIHNlbmRzIHRoZSBzYW1lIFBEVSB0d2ljZT8gU2hvdWxkIHRo
ZSByb3V0ZXIgcmVzcG9uZCB3aXRoIGEgRHVwbGljYXRlIEFubm91bmNlbWVudCBSZWNlaXZlZCBF
cnJvcj8gTm8gbWVudGlvbiBhYm91dCB0aGF0LCBzbyBpdCB3b3VsZCBiZSBsZWdhbCBpbiB0aGlz
IGNhc2UuIEF0IGxlYXN0IEkgY2FuIGltYWdpbmUgc29tZSBkaWZmZXJlbnQgaW1wbGVtZW50YXRp
b25zIGluIHRoaXMgcmVnYXJkLg0KDQpUbyByZW1vdmUgYWxsIGN1c3RvbWVyLXByb3ZpZGVyIHJl
bGF0aW9ucyB0aGUgY2FjaGUgbmVlZHMgdG8gcmUtc2VuZCB0aGUgMm5kIFBEVSB3aXRoIHRoZSDi
gJxkZWxldGXigJ0gZmxhZyBzZXQgYmVjYXVzZSB0aGUgY2FjaGUgY2Fubm90IGp1c3Qgc2VuZCBh
IFBEVXsxMX0gd2l0aCBhbiBlbXB0eSBwcm92aWRlciBzZXQuIFRoZSBsZW5ndGggZmllbGQgbXVz
dCBub3QgYmUgMC4gDQoNClRvIGFsaWduIEFTUEEgd2l0aCBhbGwgb3RoZXIgUERVcyBhbmQgcmVt
b3ZlIGFueSB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5LCBhIG1vZGlmaWNhdGlvbiBvZiBQRFV7MTF9
IHRvIHRoZSBmb3JtYXQgc2hvd24gYmVsb3cgaXMgaW4gbXkgbWluZCB0aGUgbW9zdCBmZWFzaWJs
ZSBzb2x1dGlvbjoNCg0KICAgMCAgICAgICAgICA4ICAgICAgICAgIDE2ICAgICAgICAgMjQgICAg
ICAgIDMxDQogICAuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS4N
CiAgIHwgUHJvdG9jb2wgfCAgIFBEVSAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KICAgfCBW
ZXJzaW9uICB8ICAgVHlwZSAgIHwgICBGbGFncyAgfCAgIHplcm8gICB8DQogICB8ICAgIDIgICAg
IHwgICAgMTEgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgIEN1c3RvbWVyIEF1dG9ub21vdXMgU3lzdGVt
IE51bWJlciAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwg
ICAgUHJvdmlkZXIgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyICAgICAgfA0KICAgfCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KVXNpbmcgdGhpcyBhbGxvd3Mgc2ltcGxl
IGRlbHRhIHVwZGF0ZXMgYnkgYWRkaW5nIGFuZCByZW1vdmluZyBhIHNpbmdsZSBjdXN0b21lci1w
cm92aWRlciByZWxhdGlvbnNoaXAgYXMgZG9uZSBmb3IgUk9BIGFuZCBCR1BzZWMgS2V5IGluZm9y
bWF0aW9uLiBBbHNvLCBpdCByZW1vdmVzIHRoZSBpbXBsaWNpdCB3aXRoZHJhd2FsLiBUaGUgcm91
dGVyIHByb2Nlc3MgZmxvdyBmb3IgdGhpcyBQRFUgbWF0Y2hlcyB0aGUgcHJvY2VzcyBmbG93IGZv
ciBhbnkgb2YgdGhlIG90aGVyIGRhdGEgUERVcy4NCg0KRnVydGhlcm1vcmUsIGl0IHNvbHZlcyBh
bGwgaXNzdWVzIG1lbnRpb25lZCBpbiBhbiBlYXJsaWVyIHRocmVhZCB3aXRoIHRoZSBjdXJyZW50
IGxlbmd0aCBmaWVsZC4NCg0KUmVnYXJkaW5nIHRoZSBzdGF0ZW1lbnQgb2YgcmFjaW5nIGNvbmRp
dGlvbnMsIHRoZSByb3V0ZXIgc2hvdWxkIG5ldmVyIGFjdCB1cG9uIHBhcnRpYWwgcmVjZWl2ZWQg
ZGF0YSBmcm9tIHRoZSBjYWNoZSBhbnlob3cg4oCTIHRoYXQgd2FzIGFscmVhZHkgaWRlbnRpZmll
ZCBtYW55IHllYXJzIGFnbyBmb3IgUk9Bcy4gSSBiZWxpZXZlIFJ1ZWRpZ2VyIHNwb2tlIHRvIHRo
YXQgb24gdGhlIG1pYyBkdXJpbmcgSUVURiB3ZWVrIHNvbWUgdGltZSBhZ28uIFBlcmZvcm1pbmcg
cm91dGUgb3JpZ2luIHZhbGlkYXRpb24gaW4gdGhlIG1pZGRsZSBvZiByZWNlaXZpbmcgUk9BIHVw
ZGF0ZXMgbGVhZHMgdG8gYWxsIGtpbmQgb2YgaXNzdWVzLiBUaGUgcHJvdG9jb2wgaGFzIGFuIOKA
nEVuZCBvZiBEYXRh4oCdIFBEVXs3fSB3aGljaCBzaWduYWxzIHRoYXQgYWxsIGRhdGEgaXMgc2Vu
ZC9yZWNlaXZlZCBhbmQgaXQgaXMgc2FmZSB0byBzdGFydC9yZXN1bWUgcHJvY2Vzc2luZyBvZiBh
bnkgdmFsaWRhdGlvbiBvbiB0aGUgcm91dGVycyBzaWRlLiBBbnkgcmFjaW5nIGNvbmRpdGlvbiBy
ZWxhdGVkIHRvIHRoaXMgcHJvdG9jb2wgYXJlIGVsaW1pbmF0ZWQgaWYgdGhlIHJvdXRlciBmb2xs
b3dzIHRoZSBzaW1wbGUgcnVsZSBvZiDigJxzdXNwZW5kIGFsbCB2YWxpZGF0aW9uIGR1cmluZyBh
IGNhY2hlIHVwZGF0ZeKAnS4gT3IgdXNlIHRoZSBvbGQgaW5mb3JtYXRpb24gdW50aWwgdGhlIGRh
dGEgaXMgdXBkYXRlZCBhbmQgdGhlbiBzd2l0Y2ggb3ZlciB0byB0aGUgbmV3IGRhdGEgc2V0LiBC
dXQgYWxsIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBkb25lIGFscmVhZHkgZm9yIHJvdXRlIG9yaWdp
biB2YWxpZGF0aW9uLiBJIGRvIG5vdCBzZWUgdGhlIG5lZWQgZm9yIHNwZWNpYWwgdHJlYXRtZW50
IG9mIEFTUEEgZGF0YSBoZXJlLCBBU1BBIGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHByb2Js
ZW0gc3BhY2UgaW4gdGhpcyByZWdhcmQhDQoNCkkgcmVhZCBzY2FubmVkIHRocm91Z2ggdGhlIGRv
Y3VtZW50IGFuZCBjb3VsZCBub3QgZmluZCBhbnl0aGluZyBpbiB0aGlzIHJlZ2FyZHMsIG1heWJl
IHRoYXQgaXMgYSBnb29kIHBvaW50IHRvIGFkZCB3b3JkaW5nLg0KDQoNCjIuKSBGbGFncyBmaWVs
ZDoNCj09PT09PT09PT09PT09PT0NClRoZSBzZWNvbmQgbWFqb3IgaXNzdWUgSSBoYXZlIGlzIHJl
bGF0ZWQgdG8gdGhlIEZsYWdzIGZpZWxkIGFuZCBBRkkuIEN1cnJlbnRseSB0aGUgZHJhZnQgaGFz
IHR3byBhbWJpZ3VvdXMgc3BlY2lmaWNhdGlvbnMgb2YgdGhlIEZsYWdzIGZpZWxkLiBUaGUgZmly
c3QgZGVmaW5pdGlvbiBpcyBpbiBzZWN0aW9uIDUuMSBGaWVsZHMgb2YgUERVLiANCg0KVGhpcyBz
ZWN0aW9uIGN1cnJlbnRseSByZWFkczoNCg0KfCBGbGFnczogIFRoZSBsb3dlc3Qtb3JkZXIgYml0
IG9mIHRoZSBGbGFncyBmaWVsZCBpcyAxIGZvciBhbg0KfCAgICAgIGFubm91bmNlbWVudCBhbmQg
MCBmb3IgYSB3aXRoZHJhd2FsLiAgRm9yIGEgUHJlZml4IFBEVSAoSVB2NCBvcg0KfCAgICAgIElQ
djYpLCB0aGUgZmxhZyBpbmRpY2F0ZXMgd2hldGhlciB0aGlzIFBEVSBhbm5vdW5jZXMgYSBuZXcg
cmlnaHQNCnwgICAgICB0byBhbm5vdW5jZSB0aGUgcHJlZml4IG9yIHdpdGhkcmF3cyBhIHByZXZp
b3VzbHkgYW5ub3VuY2VkIHJpZ2h0Ow0KfCAgICAgIGEgd2l0aGRyYXcgZWZmZWN0aXZlbHkgZGVs
ZXRlcyBvbmUgcHJldmlvdXNseSBhbm5vdW5jZWQgUHJlZml4IFBEVQ0KfCAgICAgIHdpdGggdGhl
IGV4YWN0IHNhbWUgUHJlZml4LCBMZW5ndGgsIE1heC1MZW4sIGFuZCBBdXRvbm9tb3VzIFN5c3Rl
bQ0KfCAgICAgIE51bWJlciAoQVNOKS4gIFNpbWlsYXJseSwgZm9yIGEgUm91dGVyIEtleSBQRFUs
IHRoZSBmbGFnIGluZGljYXRlcw0KfCAgICAgIHdoZXRoZXIgdGhpcyBQRFUgYW5ub3VuY2VzIGEg
bmV3IFJvdXRlciBLZXkgb3IgZGVsZXRlcyBvbmUNCnwgICAgICBwcmV2aW91c2x5IGFubm91bmNl
ZCBSb3V0ZXIgS2V5IFBEVSB3aXRoIHRoZSBleGFjdCBzYW1lIEFTIE51bWJlciwNCnwgICAgICBz
dWJqZWN0S2V5SWRlbnRpZmllciwgYW5kIHN1YmplY3RQdWJsaWNLZXlJbmZvLg0KfA0KfCAgICAg
IFRoZSByZW1haW5pbmcgYml0cyBpbiB0aGUgRmxhZ3MgZmllbGQgYXJlIHJlc2VydmVkIGZvciBm
dXR1cmUgdXNlLg0KfCAgICAgIEluIHByb3RvY29sIHZlcnNpb24gMSwgdGhleSBNVVNUIGJlIHpl
cm8gb24gdHJhbnNtaXNzaW9uIGFuZCBNVVNUDQp8ICAgICAgYmUgaWdub3JlZCBvbiByZWNlaXB0
Lg0KDQpUaGVyZSBpcyBubyBtZW50aW9uaW5nIG9mIHRoZSBBU1BBIFBEVSgxMSkgdGhvdWdoIHRo
aXMgUERVIHRvbyBkb2VzIGhhdmUgYSDigJxGbGFnc+KAnSBmaWVsZCBhcyB3ZWxsLiBUaGlzIG1p
Z2h0IGJlIGJlY2F1c2Ug4oCcU2VjdGlvbiA1LjEyIEFTUEEgUERV4oCdIGNvbnRhaW5zIGl0cyBv
d24gZGVmaW5pdGlvbiBmb3IgdGhlIEZsYWdzIGZpZWxkIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9t
IHRoZSBnbG9iYWwgZGVmaW5pdGlvbiBsaXN0ZWQgYWJvdmU6DQoNClRoZSBGbGFncyBmaWVsZCBp
cyBkZWZpbmVkIGFzIGZvbGxvd3M6DQoNCnwgICAgICAgQml0ICAgICBCaXQgTmFtZQ0KfCAgICAg
ICAtLS0tICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgICAgICAgIDAgICAgICBBbm5vdW5jZS9X
aXRoZHJhdyAoYW5uID09IDEsIHdpdGggPT0gMCkNCnwgICAgICAgIDEgICAgICBBRkkgKElQdjQg
PT0gMCwgSVB2NiA9PSAxKQ0KfCAgICAgICAgMi03ICAgIFJlc2VydmVkLCBtdXN0IGJlIHplcm8N
Cg0KSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBhIHNsaWdodGx5
IGRpZmZlcmVudCBkZWZpbml0aW9uIG9mIHRoZSBvdGhlcndpc2UgZ2xvYmFsbHkgZGVmaW5lZCBm
aWVsZC4gRWl0aGVyLCBoYXZlIGVhY2ggUERVIHNwZWNpZnkgaXRzIG93biBGbGFncyBmaWVsZCBv
ciB1c2Ugb25lIHNpbmdsZSBnbG9iYWwgc3BlY2lmaWNhdGlvbiBhcyBkb25lIHNvIGZhci4gDQoN
Ck5vdyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGJvdGggc3BlY2lmaWNhdGlvbnMgaXMgaW4gdGhl
IEFGSSBmaWVsZCwgd2hpY2ggZG9lcyBub3QgZXhpc3QgeWV0IGluIHRoZSBnbG9iYWwgRmxhZ3Mg
ZGVmaW5pdGlvbi4gQWRkaW5nIEFGSSB0byB0aGUgZ2xvYmFsIGRlZmluaXRpb24gdGhvdWdoIHdp
bGwgaW50cm9kdWNlIGNvbmZsaWN0cyB3aXRoIFBEVXs0fSBhbmQgUERVezV9IGFuZCBub25zZW5z
ZSBmb3IgUERVezl9LiBQRFV7OX0gaXMgYSBrZXkgYW5kIHRoZXJlZm9yZSBzaG91bGQgbm90IGhh
dmUgYW55IEFGSSBzcGVjaWZpZWQgYXQgYWxsLiBQRFV7NH0gZm9yIElQdjQgUk9BIGRhdGEgbm93
IGNvdWxkIGhhdmUgYW4gaW5jb3JyZWN0IGVuY29kaW5nIG9mIElQdjYgQUZJLiBTaW1pbGFybHkg
UERVezV9IGZvciBJUHY2IFJPQSBkYXRhIGNvdWxkIGNhcnJ5IGFuIElQdjQgQUZJIGVuY29kaW5n
LiBUaGlzIGp1c3QgYWRkcyB1bm5lY2Vzc2FyeSByZXF1aXJlZCBzYW5pdHkgY2hlY2tzIHRvIHRo
ZSByb3V0ZXIuIFBvc3NpYmx5IGV2ZW4gYSBuZXcgRXJyb3IuIFRoZXJlZm9yZSwgSSBwcm9wb3Nl
IHRvIHVzZSB0aGUg4oCcemVyb+KAnSBmaWVsZCBvZiBQRFV7MTF9IGZvciBBRkkgaW5mb3JtYXRp
b24gYW5kIGxlYXZlIHRoZSBGbGFncyBmaWVsZCBhbG9uZS4gV2l0aCB0aGlzLCBub25lIG9mIHRo
ZSBvdGhlciBQRFXigJlzIGFyZSBhZmZlY3RlZC4NCg0KV2l0aCB0aGlzIEkgcHJvcG9zZSB0aGUg
ZmluYWwgUERVIGNoYW5nZToNCg0KICAgMCAgICAgICAgICA4ICAgICAgICAgIDE2ICAgICAgICAg
MjQgICAgICAgIDMxDQogICAuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS4NCiAgIHwgUHJvdG9jb2wgfCAgIFBEVSAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0K
ICAgfCBWZXJzaW9uICB8ICAgVHlwZSAgIHwgICBGbGFncyAgfCAgIEFGSSAgICB8DQogICB8ICAg
IDIgICAgIHwgICAgMTEgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgIEN1c3RvbWVyIEF1dG9ub21vdXMg
U3lzdGVtIE51bWJlciAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgIHwgICAgUHJvdmlkZXIgQXV0b25vbW91cyBTeXN0ZW0gTnVtYmVyICAgICAgfA0KICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQozLikgQUZJIGVuY29kaW5n
Og0KPT09PT09PT09PT09PT09PQ0KVGhpcyBicmluZ3MgbWUgdG8gdGhlIGxhc3QgaXNzdWUgSSBo
YXZlOiBUaGUgQUZJIGVuY29kaW5nIGluIFBEVXsxMX0uIA0KQ3VycmVudGx5IFBEVXsxMX0gZGVm
aW5lcyBhbiBBRkkgZm9yIElQdjQ9MCBhbmQgZm9yIElQdjY9MS4gSSBkbyB1bmRlcnN0YW5kLCB0
aGlzIGlzIGRvbmUgdG8gb25seSB1c2UgYSBzaW5nbGUgYml0LiBSRkMgNjQ4MiB0aG91Z2ggc3Bl
Y2lmaWVzIHRoZSBBRkkgdmFsdWUgZm9yIElQdjQ9MSBhbmQgSVB2Nj0yIHdoaWNoIG9mIGNvdXJz
ZSB1c2VzIDIgYml0cy4gVGhpcyBpcyBhIGJ1ZyBmZWFzdCBpbiB0aGUgd2FpdGluZy4gSGVyZSB1
c2luZyB0aGUgZW5jb2Rpbmcgb2YgUkZDIDY0ODIgcmVkdWNlcyB0aGUgZGFuZ2VyIG9mIGludHJv
ZHVjaW5nIEFGSSByZWxhdGVkIGJ1Z3MgaW4gdGhlIGNvZGUgYW5kIGEgcmVxdWlyZW1lbnQgb2Yg
ZW5jb2RpbmcgdGhlIEFGSSB2YWx1ZSBhY2NvcmRpbmcgdG8gUkZDIDY0ODIgaXMgaGlnaGx5IHJl
Y29tbWVuZGVkLCByZWdhcmRsZXNzIG9mIGVuY29kaW5nIGl0IHVzaW5nIDIgYml0cyBvZiB0aGUg
RmxhZ3MgZmllbGQgb3IgaW4gaXRzIG93biBwcmVmZXJyZWQgQUZJIGZpZWxkIGFzIHByb3Bvc2Vk
IGFib3ZlLg0KDQoNClRoYW5rcywNCk9saXZlcg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVu
dGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0KKE9m
ZmljZSkgKzEuMzAxLjk3NS40ODU2DQoNCg==


From nobody Fri Nov 26 00:57:29 2021
Return-Path: <tim@nlnetlabs.nl>
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 CDD783A0C36 for <sidrops@ietfa.amsl.com>; Fri, 26 Nov 2021 00:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 kF2K9Fqwe1GU for <sidrops@ietfa.amsl.com>; Fri, 26 Nov 2021 00:57:23 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9394C3A0801 for <sidrops@ietf.org>; Fri, 26 Nov 2021 00:57:23 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id A3B9E2A0; Fri, 26 Nov 2021 08:57:19 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1637917038; bh=bUz3AMovDAkwnJRQnDKmg7LANYKFtIZp3CJgh9IiSNw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=YuPnL0uT75KNBgl3ZPv7cLxeDBWanoLN2fKZLcWNlDipq/y0tOQLkR8u22KBEYl2O 1PEJXjEWBIN6zaVUPD3VRfoBf7IE5tOpQFRL8AzNJ1n9wEq50D8fVNB+zZB6nbDy5v K77Nymv4oW97YkBtFm3ayZf1WTQBZjnXSQxGufqj+RVHM3NMOzR+IXgobIvzns1FJ+ 6FULraMnZBMMKMFC2ltK3Te7IE32DWtHSsH+sKg5p8xCNqlWtPCCy4f6bz7zLTEyvB PnEZW2SRa4O5efggoqzqq1Uc5OWDUBi5Vk+SozYMNe5EpBB+Y5/dkshL+K+9RFO7Ro PBcU1ew4TuSYQ==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <B0D86237-3F8E-4118-85E4-E669DEB07B2D@nlnetlabs.nl>
Date: Fri, 26 Nov 2021 09:57:16 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <18750FB7-CE8F-4320-830D-F54879FD1BCF@nlnetlabs.nl>
References: <4427CFCB-D170-4B25-A5C3-E5614F04BACD@nlnetlabs.nl> <20211111174823.lpt5t4yctroxtb4c@benm-laptop> <B0D86237-3F8E-4118-85E4-E669DEB07B2D@nlnetlabs.nl>
To: Ben Maddison <benm@workonline.africa>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/92YE9QXtKMF5vsyOnAAkAZIoP0o>
Subject: Re: [Sidrops] Experimental ASPA object published in testbed
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Nov 2021 08:57:28 -0000

Hi,

> On 18 Nov 2021, at 17:01, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>=20
>> 2.  Should we keep the "AS0" method of asserting transit-free-ness, =
or
>>   use an empty SEQUENCE OF?
>>   Again, my preference is the latter.
>=20
> I have a slight preference for the latter, because I like explicit. =
But,
> in the end what is important is that it's well understood.
>=20
> If the empty list is used, then it may be needed to cover this case =
more
> explicitly in validation. =10As in: an explicit empty list would be =
different
> from no ASPA exists for the customer AS. This may also impact =
8210-bis.
>=20
> In that sense AS0 as the only provider, where AS0 cannot naturally =
occur
> in the wild as a real AS, may allow for an easier validation algorithm =
- similar
> to how things are done with ROAs and AS0 as the only ROA for a given =
prefix.
>=20
> I realise this seemingly contradicts what I said about preferring =
explicit,
> but what I am trying to say is.. given the impact on other documents I =
can
> live with either.
>=20

Ok, so after re-reading and commenting on the 8210-bis LC..

I am starting to think that it would be best if we stick to a SEQUENCE =
OF 1..MAX
and use AS0.

I really don't like overloading and implicit stuff, but...

  ASPA for customer AS with no providers !=3D no ASPA for customer AS

The first would lead to 'invalids' by design, while the second should =
result
in 'not found'. In order to communicate the difference to routers we =
would
need to add specific PDU handling in 8210 for the no providers case vs =
no ASPA,
and we would need to revise the wording in the validation algorithm.

I am not convinced that this is worth it. If we would go down the empty =
sequence
path then we need to explore the impact in terms of changes to the =
validation doc,
and 8210-bis - for which we would need to reconsider LC then as well.

Let me end by repeating what I said earlier:

> It would be good to hear what others think.



=10Tim=


From nobody Sat Nov 27 18:35:41 2021
Return-Path: <randy@psg.com>
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 004A23A0A21 for <sidrops@ietfa.amsl.com>; Sat, 27 Nov 2021 18:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 VA18ip7RoRl5 for <sidrops@ietfa.amsl.com>; Sat, 27 Nov 2021 18:35:34 -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 010243A0A1F for <sidrops@ietf.org>; Sat, 27 Nov 2021 18:35:33 -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 <randy@psg.com>) id 1mrA2L-0006Fg-I6; Sun, 28 Nov 2021 02:35:29 +0000
Date: Sat, 27 Nov 2021 18:35:28 -0800
Message-ID: <m2ilwdovm7.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
In-Reply-To: <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.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: <https://mailarchive.ietf.org/arch/msg/sidrops/crI8xORTi6kgoZwO4xaRdlQuBog>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Nov 2021 02:35:39 -0000

> I think that a model similar to multiple ROA objects and resulting VRP
> PDUs is preferred.

From: Randy Bush <randy@psg.com>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: SIDR Operations WG <sidrops@ietf.org>, Tim Bruijnzeels <tim@nlnetlabs.nl>
Date: Sun, 06 Oct 2019 17:07:36 -0700

i have not thought deeply abut this.  but it seems to me that, as in
ROAs, one enters into and leaves relationship with a provider.  whacking
a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
example, what if there is a delay between delete and recreate?

keep things simple, please.

randy


From: Randy Bush <randy@psg.com>
Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
To: Alexander Azimov <a.e.azimov@gmail.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Date: Tue, 24 Mar 2020 12:02:10 -0700

> The current proposal addresses this issue for ASPA and ROAs in a different
> way:
> 
>    - For ASPA a single PDU per customer AS is neveling the issue;
>    - For ROAs the draft introduces ordering of the updates + suggests
>    sending updates with the same prefix back to back.
> 
> The way ROAs will be processed decreases the chances that valid prefixes
> will be marked as invalid, but they are not zero. My thinking is, that
> since RTR protocol is negotiating its version at the start of the session
> there is no need to keep full backward compatibility with the way ROAs were
> processed previously. Instead, we can change ROA RTR PDUs is the same
> fashion as it is introduced for ASPA: a single PDU for a selected prefix
> that replaces previous records.

two dimensions of why not

  o the ASPA is a single atomic assertion signed by the only party who
    has the authority.  it's pretty simple.

  o ROAs for a range are not atomic and may be asserted by many parties.
    e.g. a /15 with two delegated /16s, each with delegated /whatevers.
    if a /29 down the subnet-chain changes, you have to re-do the whole
    shebang.

    a number of these are likely to be via CA delegation; more and more
    as alex's marketing engine revs up.  so they will arrive at a cache
    skewed in time.

    think what this does to the load on the router; and remember that
    one major goal here is to minimize router load so current hardwhere
    running on 6502s with 640k can route origin validate.

and ask folk such as mark how rov deployment is going on some of the
more common platforms.

randy


From nobody Mon Nov 29 03:17:35 2021
Return-Path: <tim@nlnetlabs.nl>
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 62EC03A0408 for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 03:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 ThUvQDDJGCef for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 03:17:26 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:65::8:228]) (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 569E23A0597 for <sidrops@ietf.org>; Mon, 29 Nov 2021 03:17:25 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id D12DB850; Mon, 29 Nov 2021 11:17:17 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1638184634; bh=w5otKNjBmwUljjlw8gHX8UVxCK3C5ZRayTR2YySaUes=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FwaJdlbNQeoJq0Et/439KOp2iAemuIboTrr+xc1rXN6jx3rFLJDU+YuIHBch+85tA v2Yu9gIfG5DVyuTLRqL2yb+HeoHQ9SQTfi9m3ve4tNm/UblBXv0aVHXDOtE2OudcRY 9qrxLzhb1RieOTtOgIsLFZd0wvxbHeyUb7u0DoiGyqAwzE/exy9AsC+3/V1WmCtbeA PUTw+yc/7h7SD5wJCE+GjJhLMvf9qZF4JtHzOHck2NK94suPP3rcvbuOUeUm2T0gn9 45Is4wh+QDfmU1rIAmgsDKNthyx7l0j2Au0FBWRYLOoG6WVKDU60MX+feFjBsppHpD WcRpgD5ShF1pQ==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m2ilwdovm7.wl-randy@psg.com>
Date: Mon, 29 Nov 2021 12:17:06 +0100
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0520521A-DF0E-4209-8FF2-745094D742C8@nlnetlabs.nl>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <m2ilwdovm7.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/0aoKXhv0jVuwpQU6TCa-ul60iks>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 11:17:33 -0000

> On 28 Nov 2021, at 03:35, Randy Bush <randy@psg.com> wrote:
>=20
>> I think that a model similar to multiple ROA objects and resulting =
VRP
>> PDUs is preferred.
>=20
> From: Randy Bush <randy@psg.com>
> Subject: Re: [Sidrops] Minor comments on =
draft-ietf-sidrops-aspa-profile-00
> To: Alexander Azimov <a.e.azimov@gmail.com>
> Cc: SIDR Operations WG <sidrops@ietf.org>, Tim Bruijnzeels =
<tim@nlnetlabs.nl>
> Date: Sun, 06 Oct 2019 17:07:36 -0700
>=20
> i have not thought deeply abut this.  but it seems to me that, as in
> ROAs, one enters into and leaves relationship with a provider.  =
whacking
> a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
> example, what if there is a delay between delete and recreate?
>=20
> keep things simple, please.
>=20

I am all for simple, but you cannot assume there will only ever be one
valid ASPA object for a customer AS.

I know the profile text says the a CA MUST make a single ASPA for a =
customer,
and I agree. But there are a number of reasons why RPs need to be =
prepared to
see multiple valid ASPA objects in the RPKI:

1 CA migration make before break

Suppose that I want to change from one CA implementation to another, =
then
I want to ask my parent to authorise my new CA and set up everything, =
ROAs,
ASPAs etc before removing and breaking my old CA.

2 Parent publishing ASPA

A parent can publish an ASPA for my customer ASN, delegate the ASN to =
me,
and then I can publish a second ASP=10A. Ill advised indeed, but we =
cannot
assume it won't happen.

3 Multi TA

ASPA objects for the same customer ASN can appear in different trees, at
least in theory.

4 (future) Local exceptions (SLURM)

While this would not be an object as such, we can (and should) extend
SLURM to allow for local ASPA filters / additions. This could also cause
overlaps with actual objects.

5 Algorithm Roll?

I need to re-read this in detail (RFC 6916) but I think there may be
duplicate objects in there as well, though I am not sure whether RPs
are required to validate both for the same CA. But, there may be =
something
here too.


In short I think RPs should process all *valid* ASPA objects and then
derive the *union* of all providers for a given customer ASN and AFI.

Note that this is orthogonal to the question of whether that union =
should
be presented to routers as a single PDU, or that single provider =
announcement/
withdrawal PDUs could be used.


> randy
>=20
>=20
> From: Randy Bush <randy@psg.com>
> Subject: Re: [Sidrops] New Version Notification for =
draft-ymbk-8210bis-00.txt
> To: Alexander Azimov <a.e.azimov@gmail.com>
> Cc: SIDR Operations WG <sidrops@ietf.org>
> Date: Tue, 24 Mar 2020 12:02:10 -0700
>=20
>> The current proposal addresses this issue for ASPA and ROAs in a =
different
>> way:
>>=20
>>   - For ASPA a single PDU per customer AS is neveling the issue;
>>   - For ROAs the draft introduces ordering of the updates + suggests
>>   sending updates with the same prefix back to back.
>>=20
>> The way ROAs will be processed decreases the chances that valid =
prefixes
>> will be marked as invalid, but they are not zero. My thinking is, =
that
>> since RTR protocol is negotiating its version at the start of the =
session
>> there is no need to keep full backward compatibility with the way =
ROAs were
>> processed previously. Instead, we can change ROA RTR PDUs is the same
>> fashion as it is introduced for ASPA: a single PDU for a selected =
prefix
>> that replaces previous records.
>=20
> two dimensions of why not
>=20
>  o the ASPA is a single atomic assertion signed by the only party who
>    has the authority.  it's pretty simple.

See above, there can be, and therefore RPs must assume there will be, =
more
than one object.

>=20
>  o ROAs for a range are not atomic and may be asserted by many =
parties.
>    e.g. a /15 with two delegated /16s, each with delegated /whatevers.
>    if a /29 down the subnet-chain changes, you have to re-do the whole
>    shebang.
>=20
>    a number of these are likely to be via CA delegation; more and more
>    as alex's marketing engine revs up.  so they will arrive at a cache
>    skewed in time.
>=20
>    think what this does to the load on the router; and remember that
>    one major goal here is to minimize router load so current hardwhere
>    running on 6502s with 640k can route origin validate.

I am all for reducing the load on routers.

How is presenting a single PDU with a provider list that is supposed to
replace the previous list better on routers than having multiple PDUs
in a single update - i.e. before the end of data as Oliver mentioned?

In the first case there is possible overhead in case lists get long,
the second puts some burden on the router to build up its own new =
version
of a list before replacing the one it had. I expect that burden to be
low, but if router implementers can attest that it isn't then I would
love to hear it.

As I said, multi ASPA objects is orthogonal. If we MUST have a single
PDU then the cache can send the union of providers in ASPA objects as
a single PDU.

> and ask folk such as mark how rov deployment is going on some of the
> more common platforms.

I don't know who you mean by mark and what you mean by this. If there
are lessons to be shared, then please share specifics.

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


From nobody Mon Nov 29 06:12:02 2021
Return-Path: <oliver.borchert@nist.gov>
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 9F4EA3A09EE for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 06:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, 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 CAmR2ytLAa5u for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 06:11:55 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20703.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::703]) (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 4245C3A0842 for <sidrops@ietf.org>; Mon, 29 Nov 2021 06:11:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VGOBU20LXoN2biMSiylI5cFecHtOnIsxRzQNdETKJ6+3gi2KOUIZQxDiqKg+9IdbzUEcRjDjFzAilpgZOeBajNgghCmYauUo5lVhmS1U/J9XDLrxTA/65SX604JIagH+syiDFNVRyH7bDKd+oB61EGBgOvKQHIbR8JO+9pPh15b/IzJ5/cFK7VJin3xNJ9nNn9ZTVZw8dxiJI67dBVMtVHYVmWAE7PXsf9P0OmKr7L/UDaGvcDuRidoC0RF8Ph8zq6Oq1xg0pkOiS2++nmUdJE5yZAxijSxu1mcWPSKoyBT7wm0/E2+6LvtrMTiIS4c9Lu9cnfJ1iycw15UtGCbbGw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=voIyl1r2ZO+3/X5E0C42RWobGfMcKIGLvxEKjCXi1pU=; b=Njsltc13bt3GYttyh0nb9iI9UyR8KNZ2MblAbapTK59/8g/IluM42C48k0V3Gm3PJxrGOXbflAUnYvAM27+x//sMLgieA0L6uTD8F42ihY5Ck5aX+voPLpQa6j1W4/xlhDUp92rAw17UQgi5GgjJvKPVrKLmjBQD8wM6eYDfDSIEA7XjBsl0TtycJI0OC/15+VnyVFfKBvY24lJKL0CU/7qn/b9MD9TrEz9KHfDg7O6lsRyPholTZ9zivjB5x9+yJxi6beU7izHojUrHx+7kuQT9zoU/brUKDl7pXZNrSvM6wVNlmLfDJzbLOWyJ6tLxvkgOoOUs0LjuGefUD+6v0A==
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=voIyl1r2ZO+3/X5E0C42RWobGfMcKIGLvxEKjCXi1pU=; b=jhhq9fgHWiGkRu9NHp6MJFln2YkkatP8pizwuxMs1Wt3vAqDxZFvKSU72hTL4JVEuVY0EvfqG0PKqajaVGBZw4FAtlWUzB7AJF/qA5c7uprV8JakzrTSz5yAM0ztJATDD5OOesZajRiK0XUloPFos3a87r6BnFdnM2s8Vn+X310=
Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB7300.namprd09.prod.outlook.com (2603:10b6:208:288::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20; Mon, 29 Nov 2021 14:11:49 +0000
Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::c161:f060:c5ad:9b59%6]) with mapi id 15.20.4734.024; Mon, 29 Nov 2021 14:11:48 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>, Randy Bush <randy@psg.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
Thread-Index: AQHX4JxjysDMm9aqUk+5kLJKlC2YP6wShquAgAW5UQCAAiQTAP//3P4A
Date: Mon, 29 Nov 2021 14:11:48 +0000
Message-ID: <4ECF3177-C682-480F-81EF-9155498F081F@nist.gov>
References: <0B2DE27E-B67F-413B-806B-7131B90F3333@arrcus.com> <14BFC0A3-0352-47C7-86CF-23223F0E660E@nlnetlabs.nl> <m2ilwdovm7.wl-randy@psg.com> <0520521A-DF0E-4209-8FF2-745094D742C8@nlnetlabs.nl>
In-Reply-To: <0520521A-DF0E-4209-8FF2-745094D742C8@nlnetlabs.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.55.21111400
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 301d8bee-e7fa-4943-48e6-08d9b3422f0d
x-ms-traffictypediagnostic: BLAPR09MB7300:
x-microsoft-antispam-prvs: <BLAPR09MB730029013C685BBEB92782B098669@BLAPR09MB7300.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rJ5tCuKFkgieDZ2v0GU22jSrjQJdmCgRDLHSyLxqpmzKzv9HO9HByVANOXeqdtBsIztfBiaNjk4RRXlnwh/xRHREZg2ZxAwNnlgP83NHCQ2aujl5hE8keptK/CLXMQm7xPmhqRFokUB4FAp7yKVCmIQzXMSEyGG83wycE6NBf51jJGsZK5hndXG2ejvWs8AsUsp9bBogBkOKm0LFM6Cv1CUzysvjDpXhFVZuIJj55DSPHh6N4ItJMouyVczsbSmG3GOK09j7Q3SDopzKlbWDnawg8R3e3wmZm9uNdu2f2E75OXtk1O5tsuPxhe4vQ83wwbU4XSBxmqwbGcv+vFZ1w3YVher9vhRRtCC0hjQ2NX2/O9+/2gSdvzrBKagaxf+cN3n7e00Yv223LTSqXuq6aLYgjqrmPcAt9KG49ikUf3EixPC3V50kree3jC6S2KU0NJzz/U7bdiWRWarmOziZV2cuVMHxtCPCj2fCgaS1gn7g1FH7cs19rarwfO+t//bUTIj04pu5g+WY4NDFqS89nQ5qJAAZCr0jB8BvqsTxfa9Vs06XHn71VTopQ4SgpOTEuLAv3Q1dDHfsfH9158uUCgIE2HyJ9NztUl67GLoFH2HQtscvKwHbP8mfXOt8HfpK+N7O4aDXlIRS8kYVz6yuZQ03HgPjt9b/TJm4MqGA9fK/0C6CV4HHYzU5TFM/XbRlkozGmDZ7Hs+G0KHUHuMwsAFA4D01+hVtWRSxQbneYpyYwXMKF1iYt4M2KIOovnzkRpY/qzhAQjDG9kbwaVAP2iEeq7zlJZC31eHV1og7u3VXQR+1ue51unrfovh1AWVM
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(38100700002)(122000001)(40140700001)(66446008)(71200400001)(36756003)(38070700005)(53546011)(316002)(5660300002)(66556008)(66476007)(6506007)(64756008)(66946007)(6486002)(6512007)(82960400001)(54906003)(8676002)(45080400002)(83380400001)(110136005)(508600001)(33656002)(107886003)(2906002)(966005)(4326008)(86362001)(2616005)(66574015)(186003)(8936002)(76116006)(45980500001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MnlJQS9tVnQ2N05KVFVPMFVyREdBYTRoY1RxeUNrR3M1akRIVVFTMXJUL0pZ?= =?utf-8?B?amZkUGI4SThaRHRDc0twZDAwSmtXOHNKeVdYNzdldUNReWRNMVZNdTE0WnBi?= =?utf-8?B?M21CaFBCUFplSFd5eStsVXhHMGt2aUl4MjlZN2l6RjUrajc3cG00cThuWU9H?= =?utf-8?B?amhjUzcvdE5mVGk5UTd6eHdxS05ja3gxTXdXZkdONkxDUVM0VGZpSVlkZE42?= =?utf-8?B?TFJhNkRacGROUlVMelFSTmpLbGFkRXZBdm05eVFod1B3MGpmZk1vZGQ4ZUd3?= =?utf-8?B?dmJUdlFnRWUrcDdNQlVlVkFBNEdlemhQTmdwdWFEbnYzd0l2VVZkRndzdEF1?= =?utf-8?B?UkMzdGJZaVBjYzAyM0tJOHk1WnFuQ1lFMXBwUnEzYVRYUFQzclEvRVpLZ0Ro?= =?utf-8?B?cFlSczIxNGVYK0VhamdRUEpySHBmcUxFYTg0RVRzYW5vbDJhVis2bnZxMkZW?= =?utf-8?B?ek10Tmd1Y2c0cVMrZHRWenY3WUh0ZkZBNUhVT04xK284VWZEdDZPWkR1Nytz?= =?utf-8?B?U1EvL3RhRDBVQTZuclY4WHd1UUZNMWp0OUVCTWl2S25LZDFHMVRjOTI5VnJ0?= =?utf-8?B?Y0pTTlZGRUExV0xaUklTTkRGMXZRWUNPdlZwM0VPRG1pY1Z3RnRRNjJoR2lj?= =?utf-8?B?WGZuWVNPOEYxcnI0djhlbkRWcWRqL21Zb0k4SHBpN3NOMTZNZnl2ZzlwRk12?= =?utf-8?B?YmNHSEplU0JDTXcvcjFvU0xRWis3RTZYT2pkSWdtN0JaaFF4Q0luaDBTVTJX?= =?utf-8?B?RTRRUHFiNXF2UjNNaGsxeTJpdTFyL3JPd2JlOHRwK1dmRXRtUEM3aHg2OENJ?= =?utf-8?B?ODBSUCsrUXk2bmlQaCswa2RjaTVicG5xSXIxUnVUbDcrVFZEM2NVMjl1MndM?= =?utf-8?B?VTdvL09BTXlEQ25OcHdSK3puZVRZMVUvU0lUR2gzc1VuaGFzMnVzSlFlY1E2?= =?utf-8?B?aHNlZFNrQ3hUWnh0RFFLWlVxbjVpamRra09CWTYrZHhtTWFpS3hZejZpczNK?= =?utf-8?B?cUdzcG5pWjF4WlhHMVhMWTB6YXNtWlRtWEZLdG9mUnlhSWZycFU1TVhIWWdk?= =?utf-8?B?WmFJcS9KTEMzMW82eTg3Y3FENExpaVQvMVdWYTNjKzhKWlpBNFQwb3pFbmRC?= =?utf-8?B?eGNiVkVzWVhWOUU2K1BuUU16WnpWa0hDbTZCeVNUdWtwSUQ2QUZQSlBWTFcv?= =?utf-8?B?bTZVUE1pZjR4T3FXTzUwZXhlUzlTdjJjRkJKcGNIVFU2eE0xNUxMYnR3R3pq?= =?utf-8?B?VFF2eU9uYWNwWThPbXRyU1B4OHdUd2lzMkhpYXR5eW1NV3Z3OEdocW91TW40?= =?utf-8?B?Lzk4RGE4WkhLeG9tNDZlRVYxaitraTMxSlhNalhTKzc3Q29aYVBxRnFBbFgr?= =?utf-8?B?UUNvVDFqQlNDT01yeEd4YzBXVHNZeE9kVDRFNDAreTluU0plNkRVRkhpVk5X?= =?utf-8?B?dkNSaHIvV2FueGxiNCs2ZERPL1B6Q1I3SnFpK2tYWU01NSsrblJhNld4UTVW?= =?utf-8?B?MHNGQ0pxZFpqbnpjcTlmTGpsdStkWGdaRUpFV21SVWtMQlNlOXlhajZFUnVU?= =?utf-8?B?VUUwaTQzNlNLVWZVVWxwaCtoYlpxTUIyQXZpM1ZQRTRrVTgzYkpRMlA5UEw0?= =?utf-8?B?TFo2Y1NwZkhzclUvZ3ZadGJqYTQxTDZ1Z0Zoc0JXM3RieVFsQVFJTExuVnJF?= =?utf-8?B?ZGgzSWZVeExGQ2t2YXlIcElFSWpzMkZockovRWxmeFZNYnlQeTRpTUg1UzVY?= =?utf-8?B?YVpVd3ZiVE1vS21Idy9LR1NNaVVrVDVLdUNSTEJNdHJPUCtmQk5selJGRnA5?= =?utf-8?B?QXVoZ2d5Y01GeisrdFlldz09?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <A542569F1A5D5142AFE42BB4828DA32E@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 301d8bee-e7fa-4943-48e6-08d9b3422f0d
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2021 14:11:48.6636 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7300
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Y-Gktj3IRdyvwgPyB1Z3CVXU8Y0>
Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 14:12:01 -0000

VGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgbWVudGlvbnMgYSByb3V0ZXIgb25seSBj
b250YWlucyBvbmUgc2luZ2xlIEFQU0Egb2JqZWN0IHBlciBjdXN0b21lci4gVGhpcyBhc3N1bWVz
IGEgc3BlY2lmaWMgZm9ybSBvZiBpbXBsZW1lbnRhdGlvbi4gSSBkb24ndCBiZWxpZXZlIGEgcHJv
dG9jb2wgc3BlY2lmaWNhdGlvbiBzaG91bGQgZG8gdGhhdC4gT25lIGNhbiBpbWFnaW5lIGFuIGlt
cGxlbWVudGF0aW9uIHRoYXQgc3RvcmVzIHRoZSBkYXRhIGFzIGxpbmsgcmVsYXRpb25zIGhlbmNl
IG11bHRpcGxlIGludGVybmFsIG9iamVjdHMgcGVyIGN1c3RvbWVyLiBUYWtlIDEwIGltcGxlbWVu
dGVycyBhbmQgeW91IG1pZ2h0IGVuZCB1cCB3aXRoIDEwIHNvbHV0aW9ucy4NCg0KSSBhbHdheXMg
cmVhZCB0byBrZWVwIHRoaW5ncyBzaW1wbGUgLSBHcmVhdCBJIGxpa2Ugc2ltcGxlLiBUaG91Z2gs
IGFzIEkgb3V0bGluZWQgaW4gbXkgZW1haWwgZnJvbSBsYXN0IHdlZWssIHRoZSBjdXJyZW50IHNw
ZWNpZmljYXRpb24gaW50cm9kdWNlcyBpbXBsaWNpdCB3aXRoZHJhd2FscyB3aGlsZSBhbm5vdW5j
aW5nIGFuIEFTUEEgb2JqZWN0LiBUaGF0IGNvbnRyYWRpY3RzIHNpbXBsaWNpdHkgLSBpdCBhZGRz
IGFkZGl0aW9uYWwgY29tcGxleGl0eSB0byB0aGUgcm91dGVyLg0KDQpBcyBJIG1lbnRpb25lZCBp
biBteSBlbWFpbCBhcyB3ZWxsIGFzIHdhcyBtZW50aW9uZWQgaW4gcHJpb3IgSUVURidzIGEgcm91
dGVyIHNob3VsZCBuZXZlciBwZXJmb3JtIGFueSB2YWxpZGF0aW9uIG9uIGluY29tcGxldGUgZGF0
YS4gVGhlIG1vbWVudCB0aGUgcm91dGVyIHN0YXJ0cyB1cGRhdGluZyB0aGUgZGF0YSwgaXQgbW9z
dCBsaWtlbHkgd2lsbCBlbmNvdW50ZXIgYSBicmVhayBiZWZvcmUgbWFrZSBzaXR1YXRpb24gLSBh
dCBsZWFzdCB3aGVuIGl0IGNvbWVzIHRvIFJPQSdzLiBUaGVyZWZvcmUgdGhlIHJvdXRlciBzaG91
bGQgYWx3YXlzIHdhaXQgdW50aWwgYSBjb21wbGV0ZSB1cGRhdGUgaXMgcHJvY2Vzc2VkIHByaW9y
IGFjdGluZyB1cG9uIGl0Lg0KDQpUaGVyZWZvcmUsICJLZWVwIGl0IHNpbXBsZSIgc2hvdWxkIHJl
c3VsdCBpbiBhIFBEVSBhcyBJIHByb3Bvc2VkIHdpdGggb25seSBhIHNpbmdsZSBDdXN0b21lciBQ
cm92aWRlci4gQW4gQVNQQSBvYmplY3QgdGhhdCBjb250YWlucyAxMCBwcm92aWRlcnMgc2hvdWxk
IHJlc3VsdCBpbiAxMCBQRFUncyBlYWNoIHdpdGggdGhlIGN1c3RvbWVyIGFuZCBhIHNpbmdsZSBw
cm92aWRlci4gRHVwbGljYXRlcyBhcmUgdHJlYXRlZCBhcyBlc3RhYmxpc2hlZCwgd2l0aGRyYXdh
bHMgYXJlIHRyZWF0ZWQgYXMgZXN0YWJsaXNoZWQuIE5vIHNwZWNpYWwgaGFuZGxpbmcgcmVxdWly
ZWQgb24gdGhlIHJvdXRlcidzIHNpZGUuDQoNCi0tPiBTaW1wbGUhDQoNCg0KT2xpdmVyDQoNCg0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBC
b3JjaGVydCwgQ29tcHV0ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRh
cmRzIGFuZCBUZWNobm9sb2d5DQooT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCihHVm9pY2UpICsx
LjI0MC42NjguNDExNw0KIA0KDQrvu79PbiAxMS8yOS8yMSwgNjoxOCBBTSwgIlNpZHJvcHMgb24g
YmVoYWxmIG9mIFRpbSBCcnVpam56ZWVscyIgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBi
ZWhhbGYgb2YgdGltQG5sbmV0bGFicy5ubD4gd3JvdGU6DQoNCg0KDQogICAgPiBPbiAyOCBOb3Yg
MjAyMSwgYXQgMDM6MzUsIFJhbmR5IEJ1c2ggPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KICAgID4g
DQogICAgPj4gSSB0aGluayB0aGF0IGEgbW9kZWwgc2ltaWxhciB0byBtdWx0aXBsZSBST0Egb2Jq
ZWN0cyBhbmQgcmVzdWx0aW5nIFZSUA0KICAgID4+IFBEVXMgaXMgcHJlZmVycmVkLg0KICAgID4g
DQogICAgPiBGcm9tOiBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPg0KICAgID4gU3ViamVjdDog
UmU6IFtTaWRyb3BzXSBNaW5vciBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpZHJvcHMtYXNwYS1w
cm9maWxlLTAwDQogICAgPiBUbzogQWxleGFuZGVyIEF6aW1vdiA8YS5lLmF6aW1vdkBnbWFpbC5j
b20+DQogICAgPiBDYzogU0lEUiBPcGVyYXRpb25zIFdHIDxzaWRyb3BzQGlldGYub3JnPiwgVGlt
IEJydWlqbnplZWxzIDx0aW1AbmxuZXRsYWJzLm5sPg0KICAgID4gRGF0ZTogU3VuLCAwNiBPY3Qg
MjAxOSAxNzowNzozNiAtMDcwMA0KICAgID4gDQogICAgPiBpIGhhdmUgbm90IHRob3VnaHQgZGVl
cGx5IGFidXQgdGhpcy4gIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0LCBhcyBpbg0KICAgID4gUk9B
cywgb25lIGVudGVycyBpbnRvIGFuZCBsZWF2ZXMgcmVsYXRpb25zaGlwIHdpdGggYSBwcm92aWRl
ci4gIHdoYWNraW5nDQogICAgPiBhIG11bHRpLUFTIFJPQSBvciBhIG11bHRpLXByb3ZpZGVyIEFT
UEEgcmVjb3JkIHNlZW1zIGlsbCBhZHZpc2VkLiAgZm9yDQogICAgPiBleGFtcGxlLCB3aGF0IGlm
IHRoZXJlIGlzIGEgZGVsYXkgYmV0d2VlbiBkZWxldGUgYW5kIHJlY3JlYXRlPw0KICAgID4gDQog
ICAgPiBrZWVwIHRoaW5ncyBzaW1wbGUsIHBsZWFzZS4NCiAgICA+IA0KDQogICAgSSBhbSBhbGwg
Zm9yIHNpbXBsZSwgYnV0IHlvdSBjYW5ub3QgYXNzdW1lIHRoZXJlIHdpbGwgb25seSBldmVyIGJl
IG9uZQ0KICAgIHZhbGlkIEFTUEEgb2JqZWN0IGZvciBhIGN1c3RvbWVyIEFTLg0KDQogICAgSSBr
bm93IHRoZSBwcm9maWxlIHRleHQgc2F5cyB0aGUgYSBDQSBNVVNUIG1ha2UgYSBzaW5nbGUgQVNQ
QSBmb3IgYSBjdXN0b21lciwNCiAgICBhbmQgSSBhZ3JlZS4gQnV0IHRoZXJlIGFyZSBhIG51bWJl
ciBvZiByZWFzb25zIHdoeSBSUHMgbmVlZCB0byBiZSBwcmVwYXJlZCB0bw0KICAgIHNlZSBtdWx0
aXBsZSB2YWxpZCBBU1BBIG9iamVjdHMgaW4gdGhlIFJQS0k6DQoNCiAgICAxIENBIG1pZ3JhdGlv
biBtYWtlIGJlZm9yZSBicmVhaw0KDQogICAgU3VwcG9zZSB0aGF0IEkgd2FudCB0byBjaGFuZ2Ug
ZnJvbSBvbmUgQ0EgaW1wbGVtZW50YXRpb24gdG8gYW5vdGhlciwgdGhlbg0KICAgIEkgd2FudCB0
byBhc2sgbXkgcGFyZW50IHRvIGF1dGhvcmlzZSBteSBuZXcgQ0EgYW5kIHNldCB1cCBldmVyeXRo
aW5nLCBST0FzLA0KICAgIEFTUEFzIGV0YyBiZWZvcmUgcmVtb3ZpbmcgYW5kIGJyZWFraW5nIG15
IG9sZCBDQS4NCg0KICAgIDIgUGFyZW50IHB1Ymxpc2hpbmcgQVNQQQ0KDQogICAgQSBwYXJlbnQg
Y2FuIHB1Ymxpc2ggYW4gQVNQQSBmb3IgbXkgY3VzdG9tZXIgQVNOLCBkZWxlZ2F0ZSB0aGUgQVNO
IHRvIG1lLA0KICAgIGFuZCB0aGVuIEkgY2FuIHB1Ymxpc2ggYSBzZWNvbmQgQVNQP0EuIElsbCBh
ZHZpc2VkIGluZGVlZCwgYnV0IHdlIGNhbm5vdA0KICAgIGFzc3VtZSBpdCB3b24ndCBoYXBwZW4u
DQoNCiAgICAzIE11bHRpIFRBDQoNCiAgICBBU1BBIG9iamVjdHMgZm9yIHRoZSBzYW1lIGN1c3Rv
bWVyIEFTTiBjYW4gYXBwZWFyIGluIGRpZmZlcmVudCB0cmVlcywgYXQNCiAgICBsZWFzdCBpbiB0
aGVvcnkuDQoNCiAgICA0IChmdXR1cmUpIExvY2FsIGV4Y2VwdGlvbnMgKFNMVVJNKQ0KDQogICAg
V2hpbGUgdGhpcyB3b3VsZCBub3QgYmUgYW4gb2JqZWN0IGFzIHN1Y2gsIHdlIGNhbiAoYW5kIHNo
b3VsZCkgZXh0ZW5kDQogICAgU0xVUk0gdG8gYWxsb3cgZm9yIGxvY2FsIEFTUEEgZmlsdGVycyAv
IGFkZGl0aW9ucy4gVGhpcyBjb3VsZCBhbHNvIGNhdXNlDQogICAgb3ZlcmxhcHMgd2l0aCBhY3R1
YWwgb2JqZWN0cy4NCg0KICAgIDUgQWxnb3JpdGhtIFJvbGw/DQoNCiAgICBJIG5lZWQgdG8gcmUt
cmVhZCB0aGlzIGluIGRldGFpbCAoUkZDIDY5MTYpIGJ1dCBJIHRoaW5rIHRoZXJlIG1heSBiZQ0K
ICAgIGR1cGxpY2F0ZSBvYmplY3RzIGluIHRoZXJlIGFzIHdlbGwsIHRob3VnaCBJIGFtIG5vdCBz
dXJlIHdoZXRoZXIgUlBzDQogICAgYXJlIHJlcXVpcmVkIHRvIHZhbGlkYXRlIGJvdGggZm9yIHRo
ZSBzYW1lIENBLiBCdXQsIHRoZXJlIG1heSBiZSBzb21ldGhpbmcNCiAgICBoZXJlIHRvby4NCg0K
DQogICAgSW4gc2hvcnQgSSB0aGluayBSUHMgc2hvdWxkIHByb2Nlc3MgYWxsICp2YWxpZCogQVNQ
QSBvYmplY3RzIGFuZCB0aGVuDQogICAgZGVyaXZlIHRoZSAqdW5pb24qIG9mIGFsbCBwcm92aWRl
cnMgZm9yIGEgZ2l2ZW4gY3VzdG9tZXIgQVNOIGFuZCBBRkkuDQoNCiAgICBOb3RlIHRoYXQgdGhp
cyBpcyBvcnRob2dvbmFsIHRvIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoYXQgdW5pb24gc2hv
dWxkDQogICAgYmUgcHJlc2VudGVkIHRvIHJvdXRlcnMgYXMgYSBzaW5nbGUgUERVLCBvciB0aGF0
IHNpbmdsZSBwcm92aWRlciBhbm5vdW5jZW1lbnQvDQogICAgd2l0aGRyYXdhbCBQRFVzIGNvdWxk
IGJlIHVzZWQuDQoNCg0KICAgID4gcmFuZHkNCiAgICA+IA0KICAgID4gDQogICAgPiBGcm9tOiBS
YW5keSBCdXNoIDxyYW5keUBwc2cuY29tPg0KICAgID4gU3ViamVjdDogUmU6IFtTaWRyb3BzXSBO
ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXltYmstODIxMGJpcy0wMC50eHQNCiAg
ICA+IFRvOiBBbGV4YW5kZXIgQXppbW92IDxhLmUuYXppbW92QGdtYWlsLmNvbT4NCiAgICA+IENj
OiBTSURSIE9wZXJhdGlvbnMgV0cgPHNpZHJvcHNAaWV0Zi5vcmc+DQogICAgPiBEYXRlOiBUdWUs
IDI0IE1hciAyMDIwIDEyOjAyOjEwIC0wNzAwDQogICAgPiANCiAgICA+PiBUaGUgY3VycmVudCBw
cm9wb3NhbCBhZGRyZXNzZXMgdGhpcyBpc3N1ZSBmb3IgQVNQQSBhbmQgUk9BcyBpbiBhIGRpZmZl
cmVudA0KICAgID4+IHdheToNCiAgICA+PiANCiAgICA+PiAgIC0gRm9yIEFTUEEgYSBzaW5nbGUg
UERVIHBlciBjdXN0b21lciBBUyBpcyBuZXZlbGluZyB0aGUgaXNzdWU7DQogICAgPj4gICAtIEZv
ciBST0FzIHRoZSBkcmFmdCBpbnRyb2R1Y2VzIG9yZGVyaW5nIG9mIHRoZSB1cGRhdGVzICsgc3Vn
Z2VzdHMNCiAgICA+PiAgIHNlbmRpbmcgdXBkYXRlcyB3aXRoIHRoZSBzYW1lIHByZWZpeCBiYWNr
IHRvIGJhY2suDQogICAgPj4gDQogICAgPj4gVGhlIHdheSBST0FzIHdpbGwgYmUgcHJvY2Vzc2Vk
IGRlY3JlYXNlcyB0aGUgY2hhbmNlcyB0aGF0IHZhbGlkIHByZWZpeGVzDQogICAgPj4gd2lsbCBi
ZSBtYXJrZWQgYXMgaW52YWxpZCwgYnV0IHRoZXkgYXJlIG5vdCB6ZXJvLiBNeSB0aGlua2luZyBp
cywgdGhhdA0KICAgID4+IHNpbmNlIFJUUiBwcm90b2NvbCBpcyBuZWdvdGlhdGluZyBpdHMgdmVy
c2lvbiBhdCB0aGUgc3RhcnQgb2YgdGhlIHNlc3Npb24NCiAgICA+PiB0aGVyZSBpcyBubyBuZWVk
IHRvIGtlZXAgZnVsbCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIHdheSBST0FzIHdl
cmUNCiAgICA+PiBwcm9jZXNzZWQgcHJldmlvdXNseS4gSW5zdGVhZCwgd2UgY2FuIGNoYW5nZSBS
T0EgUlRSIFBEVXMgaXMgdGhlIHNhbWUNCiAgICA+PiBmYXNoaW9uIGFzIGl0IGlzIGludHJvZHVj
ZWQgZm9yIEFTUEE6IGEgc2luZ2xlIFBEVSBmb3IgYSBzZWxlY3RlZCBwcmVmaXgNCiAgICA+PiB0
aGF0IHJlcGxhY2VzIHByZXZpb3VzIHJlY29yZHMuDQogICAgPiANCiAgICA+IHR3byBkaW1lbnNp
b25zIG9mIHdoeSBub3QNCiAgICA+IA0KICAgID4gIG8gdGhlIEFTUEEgaXMgYSBzaW5nbGUgYXRv
bWljIGFzc2VydGlvbiBzaWduZWQgYnkgdGhlIG9ubHkgcGFydHkgd2hvDQogICAgPiAgICBoYXMg
dGhlIGF1dGhvcml0eS4gIGl0J3MgcHJldHR5IHNpbXBsZS4NCg0KICAgIFNlZSBhYm92ZSwgdGhl
cmUgY2FuIGJlLCBhbmQgdGhlcmVmb3JlIFJQcyBtdXN0IGFzc3VtZSB0aGVyZSB3aWxsIGJlLCBt
b3JlDQogICAgdGhhbiBvbmUgb2JqZWN0Lg0KDQogICAgPiANCiAgICA+ICBvIFJPQXMgZm9yIGEg
cmFuZ2UgYXJlIG5vdCBhdG9taWMgYW5kIG1heSBiZSBhc3NlcnRlZCBieSBtYW55IHBhcnRpZXMu
DQogICAgPiAgICBlLmcuIGEgLzE1IHdpdGggdHdvIGRlbGVnYXRlZCAvMTZzLCBlYWNoIHdpdGgg
ZGVsZWdhdGVkIC93aGF0ZXZlcnMuDQogICAgPiAgICBpZiBhIC8yOSBkb3duIHRoZSBzdWJuZXQt
Y2hhaW4gY2hhbmdlcywgeW91IGhhdmUgdG8gcmUtZG8gdGhlIHdob2xlDQogICAgPiAgICBzaGVi
YW5nLg0KICAgID4gDQogICAgPiAgICBhIG51bWJlciBvZiB0aGVzZSBhcmUgbGlrZWx5IHRvIGJl
IHZpYSBDQSBkZWxlZ2F0aW9uOyBtb3JlIGFuZCBtb3JlDQogICAgPiAgICBhcyBhbGV4J3MgbWFy
a2V0aW5nIGVuZ2luZSByZXZzIHVwLiAgc28gdGhleSB3aWxsIGFycml2ZSBhdCBhIGNhY2hlDQog
ICAgPiAgICBza2V3ZWQgaW4gdGltZS4NCiAgICA+IA0KICAgID4gICAgdGhpbmsgd2hhdCB0aGlz
IGRvZXMgdG8gdGhlIGxvYWQgb24gdGhlIHJvdXRlcjsgYW5kIHJlbWVtYmVyIHRoYXQNCiAgICA+
ICAgIG9uZSBtYWpvciBnb2FsIGhlcmUgaXMgdG8gbWluaW1pemUgcm91dGVyIGxvYWQgc28gY3Vy
cmVudCBoYXJkd2hlcmUNCiAgICA+ICAgIHJ1bm5pbmcgb24gNjUwMnMgd2l0aCA2NDBrIGNhbiBy
b3V0ZSBvcmlnaW4gdmFsaWRhdGUuDQoNCiAgICBJIGFtIGFsbCBmb3IgcmVkdWNpbmcgdGhlIGxv
YWQgb24gcm91dGVycy4NCg0KICAgIEhvdyBpcyBwcmVzZW50aW5nIGEgc2luZ2xlIFBEVSB3aXRo
IGEgcHJvdmlkZXIgbGlzdCB0aGF0IGlzIHN1cHBvc2VkIHRvDQogICAgcmVwbGFjZSB0aGUgcHJl
dmlvdXMgbGlzdCBiZXR0ZXIgb24gcm91dGVycyB0aGFuIGhhdmluZyBtdWx0aXBsZSBQRFVzDQog
ICAgaW4gYSBzaW5nbGUgdXBkYXRlIC0gaS5lLiBiZWZvcmUgdGhlIGVuZCBvZiBkYXRhIGFzIE9s
aXZlciBtZW50aW9uZWQ/DQoNCiAgICBJbiB0aGUgZmlyc3QgY2FzZSB0aGVyZSBpcyBwb3NzaWJs
ZSBvdmVyaGVhZCBpbiBjYXNlIGxpc3RzIGdldCBsb25nLA0KICAgIHRoZSBzZWNvbmQgcHV0cyBz
b21lIGJ1cmRlbiBvbiB0aGUgcm91dGVyIHRvIGJ1aWxkIHVwIGl0cyBvd24gbmV3IHZlcnNpb24N
CiAgICBvZiBhIGxpc3QgYmVmb3JlIHJlcGxhY2luZyB0aGUgb25lIGl0IGhhZC4gSSBleHBlY3Qg
dGhhdCBidXJkZW4gdG8gYmUNCiAgICBsb3csIGJ1dCBpZiByb3V0ZXIgaW1wbGVtZW50ZXJzIGNh
biBhdHRlc3QgdGhhdCBpdCBpc24ndCB0aGVuIEkgd291bGQNCiAgICBsb3ZlIHRvIGhlYXIgaXQu
DQoNCiAgICBBcyBJIHNhaWQsIG11bHRpIEFTUEEgb2JqZWN0cyBpcyBvcnRob2dvbmFsLiBJZiB3
ZSBNVVNUIGhhdmUgYSBzaW5nbGUNCiAgICBQRFUgdGhlbiB0aGUgY2FjaGUgY2FuIHNlbmQgdGhl
IHVuaW9uIG9mIHByb3ZpZGVycyBpbiBBU1BBIG9iamVjdHMgYXMNCiAgICBhIHNpbmdsZSBQRFUu
DQoNCiAgICA+IGFuZCBhc2sgZm9sayBzdWNoIGFzIG1hcmsgaG93IHJvdiBkZXBsb3ltZW50IGlz
IGdvaW5nIG9uIHNvbWUgb2YgdGhlDQogICAgPiBtb3JlIGNvbW1vbiBwbGF0Zm9ybXMuDQoNCiAg
ICBJIGRvbid0IGtub3cgd2hvIHlvdSBtZWFuIGJ5IG1hcmsgYW5kIHdoYXQgeW91IG1lYW4gYnkg
dGhpcy4gSWYgdGhlcmUNCiAgICBhcmUgbGVzc29ucyB0byBiZSBzaGFyZWQsIHRoZW4gcGxlYXNl
IHNoYXJlIHNwZWNpZmljcy4NCg0KICAgID4gDQogICAgPiByYW5keQ0KICAgID4gDQogICAgPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gU2lk
cm9wcyBtYWlsaW5nIGxpc3QNCiAgICA+IFNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v
Z2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy
Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmYW1wO2RhdGE9MDQl
N0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDNzBkMDQ4YmYzZTViNDllZjc5YzAw
OGQ5YjMyOWYzZDglN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdD
NjM3NzM3ODE1MDMzMjE5NjUwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq
QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMw
MDAmYW1wO3NkYXRhPWJid055WWlvN01ZOUhjUzZ5NWMlMkZjJTJGM2JlNnRoRFdheWZ3UXU3N1Zo
N0RjJTNEJmFtcDtyZXNlcnZlZD0wDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgU2lkcm9w
c0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m
byUyRnNpZHJvcHMmYW1wO2RhdGE9MDQlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292
JTdDNzBkMDQ4YmYzZTViNDllZjc5YzAwOGQ5YjMyOWYzZDglN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkz
ZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3NzM3ODE1MDMzMjI5NjA1JTdDVW5rbm93biU3Q1RX
RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx
aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPVlVT2VYJTJCRkJQY0JkY0tFYjV4
R0JTRnU2a08wY0J1MWQ3M2JpeE9OcTBmZyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQo=


From nobody Mon Nov 29 09:10:32 2021
Return-Path: <warren@kumari.net>
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 60BF03A0775 for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 09:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.723
X-Spam-Level: 
X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 xyJUI2IasoMV for <sidrops@ietfa.amsl.com>; Mon, 29 Nov 2021 09:10:25 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 C85453A0688 for <sidrops@ietf.org>; Mon, 29 Nov 2021 09:10:25 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id z18so22467921iof.5 for <sidrops@ietf.org>; Mon, 29 Nov 2021 09:10:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google;  h=mime-version:from:date:message-id:subject:to; bh=lT8od992UNarS3aI8+d+4OP1U14O1BShyojenkhJqqo=; b=ByjGslx9ipUVFh9A5ZCrEmUwGxTyxpJUmcunicHKXmGkyIw+ba3RnQAEl7mIS9ialq N/wpKaAoTJMLmIzXOJEet6JNGUsrXFHcr9rkqHLZpiDVGs9sy6D08pAlBeQ9QzhB5zlQ rM0PER3zc2T+6gWoKM0WD4FApDDwmefTCtDiVirE2ZqMISVi5yTJY9uZSNAbCYNpr6fJ unYax41Jr1j0VM7YqJD1crexgL7NKONjGAzWJbZpxXjXOmjVRSqcgauDxm0Xr9sYd+nG 5L7h7xSchJwWHKrW6tNLc1zzke+3Nu706kkkXeUAbeWpt4YD8dFa82gEzntu45XaAaXG SPyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lT8od992UNarS3aI8+d+4OP1U14O1BShyojenkhJqqo=; b=wKAZedl+loHfgzq9x4uki6neURV3hCu74n4eTD6mrFpysrCP218s5VhWr/dRjeQdRk RrFRAAncskW5oXZobS67Oj+mcUE5PwuKIWcCjzEt8HyhGx5DoQKk6rV98238LCt6qw9p BdYjEsRVdn+g+1pgP5lE4RkKLcNjH7B9xfLuYsW+m2OsRIfGIxnxZL3D2a9INrRq5Yko bdex+J0hIsJiypGpw/DQk1c3Ku2EtXGPzaCdrW1pW9xqVJuOHWakevRSgQl6FAbdRyx6 O9Fu6+/uMn9COnArmMCERd03hO/gNfkEQs3ZmJyR6NqwcsVuciwLPKtaBKfMCpLxkCFf nhFQ==
X-Gm-Message-State: AOAM531PvGhPDZAXS1Sh4LDHd+FfODqPfYZsXmGHf9pQUu1irOo7UvDf 0CBZARgYXfNDBnnTnUcZ94tJLIu0MLd0koQ/UewAKDiz6AEMOw==
X-Google-Smtp-Source: ABdhPJzsHB/Vx+G8JZdcIkBV/ggdTu6CtrdmW36yF7mrPllvx5IMolVyADigKg4IivoSMsM7jZ+72Uqmctj2E+Uaoyc=
X-Received: by 2002:a6b:2cc1:: with SMTP id s184mr56816572ios.63.1638205823148;  Mon, 29 Nov 2021 09:10:23 -0800 (PST)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Mon, 29 Nov 2021 12:09:47 -0500
Message-ID: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com>
To: SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-6486bis@ietf.org
Content-Type: multipart/alternative; boundary="000000000000287d8d05d1f084db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YDaoZwYrsg1bQN03g5OgrR30wQ4>
Subject: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2021 17:10:30 -0000

--000000000000287d8d05d1f084db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi there,

Apologies for how long it has taken me to do this review...

In general I think the document is really good, and understandable, but I
did have a few questions and comments. I suspect that some of these can be
answered with: "This is already a well known practice in the CA/PKI world,
we don't want to relitigate it..."

I also have a number of comments that are purely nits, but if you are
opening the editor anyway, please address them as - it's more polite than
expecting the RFC Ed to deal with them (and it will calm down my OCD :-))

1: S 3. Manifest Signing
O: termed a "one-time-use" EE certificate.[RFC6487]
P:  termed a "one-time-use" EE certificate [RFC6487].
C: Reference before the period (consistency nit)

2: S 4.2.2. Names in FileAndHash objects
"As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a valid filen=
ame."
I'm not sure where to make this comment (here or in the validation
section), but I'm *assuming* that the case is "important" -- vixxBTS.cer !=
=3D
VIXXBTS.CER? There are some operating systems which are case insensitive
for filenames (e.g: Mac OS can format a device as "Mac OS Extended
(Journaled)" or "Mac OS Extended (Case-sensitive, Journaled)". I'm
suspecting that this might be a corner case, and / or not really an issue
for this document, but it seems like it may be worth having a reminder /
note.

3: S 5.1. Manifest Generation Procedure.
"2. Issue an EE certificate for this key pair. The CA MUST revoke
 the EE certificate used for the manifest being replaced.
 This EE certificate MUST have an SIA extension access description
 field with an accessMethod OID value of id-ad-signedobject, where
 the associated accessLocation references the publication point of
 the manifest as an object URL.(RPs are required to verify this.)"

It is somewhat unclear to me what exactly the RP is required to verify here=
:
A: that the EE cert has an SIA extension with accessMethod of
id-ad-signedobject
B: that the associated accessLocation references the publication point of
the manifest
C: Both?
If B or C how does it do this? (I'm assuming it doesn't have to fetch the
manifest to make sure :-)). I did check in Sec 6 to see if this was
answered (S 6.2 / S 7 were close). I suspect that this is obvious, but it
seems like a few more words would help.

4: S 5.1:
"3. The EE certificate MUST NOT be published in the authority=E2=80=99s rep=
ository
publication point."

Why is this a MUST NOT?
S2 says: "Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used to
verify it [RFC6488]. Thus, there is no requirement to separately publish
that EE certificate at the CA=E2=80=99s repository publication point."
"no need" is different to "MUST NOT" - what is the harm if the EE were to
be published? If it is not referenced, does it matter?

5: S 6.2. Acquiring a Manifest for a CA
Nit: "an RP MUST treat this as a failed fetch and, proceed to Section 6.6"
Superfluous comma

6: S 6.3. Detecting Stale and or Prematurely-issued Manifests
"If the current time is earlier than thisUpdate, the CA has made an error;
..."
There was some discussion on this during the WGLC, but I don't think that I
actually saw a resolution. Let's say that the thisUpdate is  "Nov 18
12:37:56 2021 GMT", but when the RP fetches it, it's clock is "Nov 18
12:37:55 2021 GMT" (one second slow) -- it seems silly for this to be a
fetch failure
I *think* that it is general practice for certs to have the "Not Before" be
backdated by some amount of time (e.g LE does 1h), and Windows at least
backdates CRLs by ClockSkewMinutes (10 minutes by default) -
https://social.technet.microsoft.com/wiki/contents/articles/20652.how-thisu=
pdate-nextupdate-and-nextcrlpublish-are-calculated.aspx

I'm fine with the answer being "Yeah, no IETF document says that, and we
don't want to open that can of worms", but I do want to make sure that it
has been considered and discussed.

Again, thank you very much for writing this, and addressing the nits /
educating me.
W



--=20
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

--000000000000287d8d05d1f084db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi there,<div><br></div><div>Apologies for how long it has=
 taken me to do this review...</div><div><br></div><div>In general I think =
the document=C2=A0is really good, and understandable, but I did have a few =
questions and comments. I suspect that some of these can be answered with: =
&quot;This is already a well known practice in the CA/PKI world, we don&#39=
;t want to relitigate it...&quot;</div><div><br></div><div>I also have a nu=
mber of comments that are purely nits, but if you are opening the editor an=
yway, please address them as - it&#39;s more polite than expecting the RFC =
Ed to deal with them (and it will calm down my OCD :-))</div><div><br></div=
><div>1: S=C2=A03. Manifest Signing</div><div>O: termed a &quot;one-time-us=
e&quot; EE certificate.[RFC6487]</div><div>P:=C2=A0=C2=A0termed a &quot;one=
-time-use&quot; EE certificate [RFC6487].</div><div>C: Reference before the=
 period (consistency nit)</div><div><br></div><div>2: S 4.2.2. Names in Fil=
eAndHash objects</div><div>&quot;As an example, =E2=80=99vixxBTS_TVXQ-2pmGO=
T7.cer=E2=80=99 is a valid filename.&quot;</div><div>I&#39;m not sure where=
 to make this comment (here or in the validation section), but I&#39;m *ass=
uming* that the case is &quot;important&quot; -- vixxBTS.cer !=3D VIXXBTS.C=
ER? There are some operating systems which are case insensitive for filenam=
es (e.g: Mac OS can format a device as &quot;Mac OS Extended (Journaled)&qu=
ot; or &quot;Mac OS Extended (Case-sensitive, Journaled)&quot;. I&#39;m sus=
pecting that this might be a corner case, and / or not really an issue for =
this document, but it seems like it may be worth having a reminder / note.=
=C2=A0</div><div><br></div><div>3: S=C2=A05.1. Manifest Generation Procedur=
e.</div><div>&quot;2. Issue an EE certificate for this key pair. The CA MUS=
T revoke</div>=C2=A0the EE certificate used for the manifest being replaced=
.<br>=C2=A0This EE certificate MUST have an SIA extension access descriptio=
n<br>=C2=A0field with an accessMethod OID value of id-ad-signedobject, wher=
e<br>=C2=A0the associated accessLocation references the publication point o=
f<br>=C2=A0the manifest as an object URL.(RPs are required to verify this.)=
&quot;<div><br></div><div>It is somewhat unclear to me what exactly the RP =
is required to verify here:</div><div>A: that the EE cert has an SIA extens=
ion with accessMethod of id-ad-signedobject</div><div>B: that the associate=
d accessLocation references the publication point of the manifest</div><div=
>C: Both?=C2=A0</div><div>If B or C how does it do this? (I&#39;m assuming =
it doesn&#39;t have to fetch the manifest to make sure :-)). I did check in=
 Sec 6 to see if this was answered (S 6.2 / S 7 were close). I suspect that=
 this is obvious, but it seems like a few more words would help.</div><div>=
<br></div><div>4: S 5.1:</div><div>&quot;3. The EE certificate MUST NOT be =
published in the authority=E2=80=99s repository publication point.&quot;</d=
iv><div><br></div><div>Why is this a MUST NOT?=C2=A0</div><div>S2 says: &qu=
ot;Every RPKI signed object includes, in the Cryptographic Message Syntax (=
CMS) [RFC3370] wrapper of the object, the EE certificate used to verify it =
[RFC6488]. Thus, there is no requirement to separately=C2=A0publish that EE=
 certificate at the CA=E2=80=99s repository publication point.&quot;<br></d=
iv><div>&quot;no need&quot; is different to &quot;MUST NOT&quot; - what is =
the harm if the EE were to be published? If it is not referenced, does it m=
atter?=C2=A0</div><div><br></div><div>5: S=C2=A06.2. Acquiring a Manifest f=
or a CA</div><div>Nit: &quot;an RP MUST treat this as a failed fetch and, p=
roceed=C2=A0to Section 6.6&quot;</div><div>Superfluous comma=C2=A0<br><div>=
<br><div>6: S=C2=A06.3. Detecting Stale and or Prematurely-issued Manifests=
</div><div>&quot;If the current time is earlier than thisUpdate, the CA has=
 made an error; ...&quot;</div><div>There was some discussion on this durin=
g the WGLC, but I don&#39;t think that I actually saw a resolution. Let&#39=
;s say that the thisUpdate is=C2=A0 &quot;Nov 18 12:37:56 2021 GMT&quot;, b=
ut when the RP fetches it, it&#39;s clock is=C2=A0&quot;Nov 18 12:37:55 202=
1 GMT&quot; (one second slow) -- it seems silly for this to be a fetch fail=
ure</div><div>I *think* that it is general practice for certs to have the &=
quot;Not Before&quot; be backdated by some amount of time (e.g LE does 1h),=
 and Windows at least backdates CRLs by=C2=A0ClockSkewMinutes (10 minutes b=
y default) - <a href=3D"https://social.technet.microsoft.com/wiki/contents/=
articles/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.=
aspx">https://social.technet.microsoft.com/wiki/contents/articles/20652.how=
-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx</a></div><div=
><br></div><div>I&#39;m fine with the answer being &quot;Yeah, no IETF docu=
ment says that, and we don&#39;t want to open that can of worms&quot;, but =
I do want to make sure that it has been considered and discussed.</div><div=
><br></div><div>Again, thank you very much for writing this, and addressing=
 the nits / educating me.</div><div>W</div><div><br></div><div><br></div><d=
iv><br></div><div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr">Perhaps they really do strive =
for incomprehensibility in their specs.<br>After all, when the liturgy was =
in Latin, the laity knew their place.<br>-- Michael Padlipsky<br></div></di=
v></div></div></div></div>

--000000000000287d8d05d1f084db--


From nobody Tue Nov 30 10:44:48 2021
Return-Path: <stkent@verizon.net>
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 9B1393A14A2 for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 10:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.953
X-Spam-Level: 
X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 T232V5lEk8mS for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 10:44:45 -0800 (PST)
Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (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 0885F3A149D for <sidrops@ietf.org>; Tue, 30 Nov 2021 10:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1638297884; bh=zd6RO4N0P9vFQiYn6/qpRkEwvIGlUs4vClSn983IdDY=;  h=Date:From:Subject:To:References:In-Reply-To:From:Subject:Reply-To;  b=nnn4Nu8mMgPXPliU2FgzXn+TZ6iCBahudQJr5QI97iiggyDwaNxTP1AlZNKn2BAcc71Ur9RSQLUUmFvCLaexFO/+EL5HhUDO9rrmBcBx+5i0q5dDtqz+/aHB65W23IHdFfCanKs/EFHCfJH/wp6/um8ofp7W9Ekv+XH8fAwnuux3UUBnRvchGMNUWnrzIDQe5xQPOWq/FNprojI+NnhkB+geBDkBLGs9bIA6MRGXEXI8FSj5/jew6+9Ev/ot3Qez6i2H+MFhEnln5ygw8zUzRN/gptmyFy9xKOTBsgTzIevVt1jTcKnU/GJYTxCB3JwNz0NT7EVTy+xGPgeLnI1l5Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1638297884; bh=oHqn8sLPfg1Pk0ihbBImPHw9kT+aNs0ivQ1KQiVHn8a=;  h=X-Sonic-MF:Date:From:Subject:To:From:Subject; b=hPmNbC6/Ia+6BJUuUS428/b30Phj33OGbjXElmJzA4mJYmT2B3j/DgNL/ioRvdhX9cjWVL0UlTZS780tZRLdm7KQGAQm9nzMTi+9CxXQUaZtGY2MyrU9cz2kePjOUn8WZWQhDnoCZ42EfQZBSoSC3hEPviviFHsncdqLbxAPBxzHkZxVkN1exK4Zt4e6Qtvwe5U9cyjDRSMDW4hZl8RqCfJU+PmHwmK5JE38CwzLHhN6EZT5luEMMu+O3YPG0PNTQXQTNpOIPQrsnm/TLq+R9N0z2uHyHKhBmBKdPOFD5iZT+7BdgBNkS71Oan7sgw5R56W9djoYuOhOCrvDqy6XiQ==
X-YMail-OSG: IyCW_s4VM1mbLfpqL_fRB3Xui4YtZ4kcDSCrdWacj6NKhNx9oRLxuhtTFrXyaWU dS3qMDixT95xPFSJFqnfIiUgWEoyOGuHDJirFtijen57V8ayo01UeYj5RS6Dsf9vYNNbRIci8KWv fAIkMAQHCnmoP.59xdg9KtsjoVbHMCun8KwFc0ahfMVNSQ8bxRSHKEpUXjehUGHipBckOq7UmkZ2 ma7Xmi6oGi1qnaOpDC8SPS_D9hwmsWCks91dZH7xoYkcKDBoOPTziDn9C2cCaS2d40BFlKqGBmK_ 5uf29FJqsOA2BGlC99ZuVftKhIIeyZjZUOHSFrkH2j8O1kxaeyIk1e7JUkZOf.g8gd062aNTODCJ eheoMyl6wIEFpPLgtFwfMJhrjfW7KaNTBwhMHLbHcxztNlxlKG4dhCTHUuSWMeJY.kzQtkHVqJ.i Ib3tgjAGM1KYOWBlv_VMj8BM0ZUJa.iiOls4fmoemP8wZwksgYTmz_qzGZdozd_9u1dZfBM_GfO8 yZA24v26Qln1bKmge.5Ian7uLVRe.om4CeRf.DWc2gLDM8sPIPbu4s0k0GQ5GW7Uku2DjgMrWzYR Z5t2seBnbGSSnjsJQ4.hsaoLKO2YThPKy.uuRruxjC4IiY03m5h5sx43zWOmtmHW1C66z5hIAAHC 9JMUszuDSFpNx6fRq3V98hozGSjCSW0TT5k6vmcPN8iZ7rGioZVbP2P2J6Iz2_eUVEF1mNRs7bqX vmriud7GoIM8MSkLkwSfssKFXminQtD__ia9DDI.UggMPaahk7trnuHg2uaM7ybUUOnRDSI_u5zG 91e178XSCFYbeGmD4KQNH7r1C_I2EzBl5Gfjw3rVPpEKtIlpk.YnKpmLQ5j5TLhAjhnX88z7CJin AmHMteYtbg1cn3E7nXfvflDn2uuPaKr82wrSnHzqpPl.CMJJUnpLb3iactfAIBUr8mya9cViWBYi 70PnU9aUvUO8XAOV0LfGgutQRHQcQpWD4Wphrgs91m6W70KFC5MBJLRgO0sNtwE5Q1XmjeB0Vdr7 52CqhzB6dlw0c6ySBjEJRiwtEWLI9Ai52z6wXxa24jRPyiBI4YoX6YaAjsaaVQHsch4e0WXJCC0b .6JOpg3.getbMoUEyOlP5vCOrfuw6Q921nVVMUlCW7mjrGRmw5BOmKKGNpraPVSwLLJgLaOdeRMZ OiyTIGqEN5.1v3Y.MZiQdyvODIS5TNotbENvz.0O7GtWx9yq_v353WioIlKmYPYVRkvgW1eFw9UX JA2bm5BIJOnEJRP37Y2a0vzbJe7frcwyXvTIFn5dEIRn06YbLERNCt4E3i.G7SwXKH.S4yNq3znA KOro_W.nnd1wmkyuhhatUOAyRKLumKy6FZX4hy3CuWnNiFYDEbfhFSUmYv5_NB9vsof2etP3Hz2l cKNkcYqPyug7Oklnr5WAEXlWOgsjXTVyKw4CLEWIW2P.5zQkRj3NtY0JvT5YoTPeH5vEwb4Ohjnb I7egM31Y0IlDzWyj8RRCySdCZrvnSs0yNawPbaFUGibzVqShji4jD_sc6KWnhb9XDK6HnIa_V9Iz bvwXAce3XBpFtGWVS2xrhRGUqBF2V3Nt3EPV7Ohr_LoPkD.S6TwQiozRY09CeGGx6PFKNXRCyXVQ 3FBnS76SU.D6wYQdhl0MDj4ohaFy3vhJyOMgCbmQLTjj0lY0jeEUXY0vG9aU5rotmwVl3uAMNtM8 VZ_POJkxIh8X7wa1yBGl7N8oeKNlirXTVPUcLxFcIjO_qu6N.9Rcb3AZbQNxQLHxuT36kB6.9zTb guuHqErL5qjdplVgtz7yByKcRuVO7HNEX4EgPtQAsbFvy5kuntSwoSU.j_YYwNGByhH1NR8ZxnaH QgdNHfugtxmapqULv1ML9dHZV2dtf5naLceK0.k9R.LiQnZ_sIfNltXjZaSFbUVrKzX_q2t0qCm0 JkhJDB0ADcMYvhuABJd9qgFZ00ghjvsojCucK3zZO31.q4hmPvtaMuRsYjwKkyVPeAWab4V6K3oI KapnfXj2Yt.fWci1ojF1OCxLkundJr.mh39OGcIk6pj.7sREr_uk.xdf9J0XQMW6Ya23sR.b4tK9 K4PM4jCpJmJlcoTMZhNkLrV8RDq2HCcOMhm3UNvH8euIERLnJuFm45mnCWlAuncUJLN4PfWTGhvT lpd9jYnw9rYrX.xFfsv1XEhP9R_Sw3L_bc46HjvgntgR_qMgoteXFDZFGuJW0ZGc9pJMu2Rgvssq W
X-Sonic-MF: <stkent@verizon.net>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Tue, 30 Nov 2021 18:44:44 +0000
Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2b6e3482e99434847ea1c58c453e1e0f;  Tue, 30 Nov 2021 18:44:40 +0000 (UTC)
Message-ID: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
Date: Tue, 30 Nov 2021 13:44:38 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
From: Stephen Kent <stephen.kent@verizon.net>
To: Warren Kumari <warren@kumari.net>, SIDR Operations WG <sidrops@ietf.org>,  draft-ietf-sidrops-6486bis@ietf.org
References: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/NblmcUPQZGjvi5WSrBBQ5s3KZtM>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 18:44:47 -0000

Warren,

Thanks for the detailed review. Responses inline.
> ...
>
> 1: S 3. Manifest Signing
> O: termed a "one-time-use" EE certificate.[RFC6487]
> P:  termed a "one-time-use" EE certificate [RFC6487].
> C: Reference before the period (consistency nit)
fixed.
>
> 2: S 4.2.2. Names in FileAndHash objects
> "As an example, ’vixxBTS_TVXQ-2pmGOT7.cer’ is a valid filename."
> I'm not sure where to make this comment (here or in the validation 
> section), but I'm *assuming* that the case is "important" -- 
> vixxBTS.cer != VIXXBTS.CER? There are some operating systems which are 
> case insensitive for filenames (e.g: Mac OS can format a device as 
> "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive, 
> Journaled)". I'm suspecting that this might be a corner case, and / or 
> not really an issue for this document, but it seems like it may be 
> worth having a reminder / note.

This text first appeared in version 3 of 6496bis, published in November 
2020, over a year ago. The text was proposed by Job Snijders. The topic 
of case sensitivity, as well as some other aspects of the proposed text, 
were discussed on the list from 11/19-11/24/20, by several WG 
participants. I'm happy to add further clarification re case 
sensitivity, if the WG agrees on what that clarification should be.

>
> 3: S 5.1. Manifest Generation Procedure.
> "2. Issue an EE certificate for this key pair. The CA MUST revoke
>  the EE certificate used for the manifest being replaced.
>  This EE certificate MUST have an SIA extension access description
>  field with an accessMethod OID value of id-ad-signedobject, where
>  the associated accessLocation references the publication point of
>  the manifest as an object URL.(RPs are required to verify this.)"
>
> It is somewhat unclear to me what exactly the RP is required to verify 
> here:
> A: that the EE cert has an SIA extension with accessMethod of 
> id-ad-signedobject
> B: that the associated accessLocation references the publication point 
> of the manifest
> C: Both?
> If B or C how does it do this? (I'm assuming it doesn't have to fetch 
> the manifest to make sure :-)). I did check in Sec 6 to see if this 
> was answered (S 6.2 / S 7 were close). I suspect that this is obvious, 
> but it seems like a few more words would help.

C- both, and I have modified the text to make this clear.


>
> 4: S 5.1:
> "3. The EE certificate MUST NOT be published in the authority’s 
> repository publication point."
>
> Why is this a MUST NOT?
> S2 says: "Every RPKI signed object includes, in the Cryptographic 
> Message Syntax (CMS) [RFC3370] wrapper of the object, the EE 
> certificate used to verify it [RFC6488]. Thus, there is no requirement 
> to separately publish that EE certificate at the CA’s repository 
> publication point."
> "no need" is different to "MUST NOT" - what is the harm if the EE were 
> to be published? If it is not referenced, does it matter?

If the EE cert for the manifest were published at the PP covered by the 
manifest, an RP implementation might perceive a circular dependency and 
act in an indeterminate fashion. The MUST NOT is designed to prevent 
such a situation.

>
> 5: S 6.2. Acquiring a Manifest for a CA
> Nit: "an RP MUST treat this as a failed fetch and, proceed to Section 6.6"
> Superfluous comma

fixed.

>
> 6: S 6.3. Detecting Stale and or Prematurely-issued Manifests
> "If the current time is earlier than thisUpdate, the CA has made an 
> error; ..."
> There was some discussion on this during the WGLC, but I don't think 
> that I actually saw a resolution. Let's say that the thisUpdate is  
> "Nov 18 12:37:56 2021 GMT", but when the RP fetches it, it's clock 
> is "Nov 18 12:37:55 2021 GMT" (one second slow) -- it seems silly for 
> this to be a fetch failure
> I *think* that it is general practice for certs to have the "Not 
> Before" be backdated by some amount of time (e.g LE does 1h), and 
> Windows at least backdates CRLs by ClockSkewMinutes (10 minutes by 
> default) - 
> https://social.technet.microsoft.com/wiki/contents/articles/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx
>
> I'm fine with the answer being "Yeah, no IETF document says that, and 
> we don't want to open that can of worms", but I do want to make sure 
> that it has been considered and discussed.

IMHO, if a CA issues and publishes a Manifest in which the thisUpdate 
value is earlier than the actual time, it's an indication of sloppy 
procedure, not a good sign:-)

I am unmoved by hacks that MS may have chosen to employ in issuing CRLs; 
they have a habit of not following PKIX standards when some engineer 
thinks he/she knows better.

Steve


From nobody Tue Nov 30 11:30:40 2021
Return-Path: <sra@hactrn.net>
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 374CA3A14F3; Tue, 30 Nov 2021 11:30:39 -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, 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 VktXQQA9hdOQ; Tue, 30 Nov 2021 11:30:38 -0800 (PST)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DE73A14F2; Tue, 30 Nov 2021 11:30:37 -0800 (PST)
Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 0B30513992; Tue, 30 Nov 2021 19:30:35 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 344F62EA0102; Tue, 30 Nov 2021 14:30:34 -0500 (EST)
Date: Tue, 30 Nov 2021 14:30:34 -0500
From: Rob Austein <sra@hactrn.net>
To: Warren Kumari <warren@kumari.net>
Cc: Stephen Kent <stephen.kent@verizon.net>, SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-6486bis@ietf.org
In-Reply-To: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
References: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com> <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20211130193034.344F62EA0102@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3F2jVIDlypQ_AocRvLd6iItxNmM>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 19:30:40 -0000

One thing that may not be immediately obvious to Warren: there's a big
difference between NotBefore in certificates and ThisUpdate in CRLs
and manifests.  Backdating NotBefore by some small amount makes sense
given the possibility that clock skew might cause a certificate to be
interpreted as invalid at the time it's issued, which could be bad.
ThisUpdate is more of a tick mark recording the passage of time in the
evolving history of a manifest or CRL: nothing terrible should happen
in the case of clock skew, so as Steve suggests it's probably best to
tell the truth about the time of publication.

Manifests have this extra twist in that the manifest CMS contains an
embedded EE certificate which has a NotBefore, so one gets to invoke
both of these rules at once while generating the same object, yay.


From nobody Tue Nov 30 12:21:36 2021
Return-Path: <stkent@verizon.net>
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 025593A153D for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 12:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.953
X-Spam-Level: 
X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 NT9FlkzNW59W for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 12:21:32 -0800 (PST)
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (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 40D413A1538 for <sidrops@ietf.org>; Tue, 30 Nov 2021 12:21:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048;  t=1638303691; bh=++6+MKBLNktEsgpGJ2ks6Sbh9xYN2CMxWuKyUTVQ+oQ=;  h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To;  b=TAJ6AlnFJpYpU2GQPzKqtRjlB4XejNto4NlkskDoM5c3rAvz3imZCPf199Q4oCmIRepW7RDfM55jszE1QteVwZLkbE2wFZn5a4TlpTJw9BaLgTDO9LDU4PavEhLFejHAW+T+Fkniumwzqa4aRJujkg0RSYJaL48a2kX1WXmJx5KOLlRGs8t5H/9vPkotIV25qRGt2GjBvOIbt5EboCIvFtdqSlgv2ASEoEu8zRyapT3q897flYIXlkQq3BbOIokATLTPz9VC6NN9qvq6XEK3KBlNj4uvJ0FEOpI48VFzDGgEZLvR64BDzL94pg+rjHsNyoAGHVpFWUBGFW64f+Q6iQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;  t=1638303691; bh=ateR48P+9r2q/rT4KvPaIS5SkTVuhZ0J1PNThw2Prif=;  h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=AaU4rDhYBbNoyALMnJp/XXoFMzwt2E14Ix6jJzsUMCwubMcoykAU8QZgrLAO4z7nuc9bgle9IguVi4fTyiCtZLFRuQYI4uqxs94yPQQSqHv+w1qJxRThvKz9+3fz4IbqEEuXP2W1dLzQurbM9OEO7nNvpz0IHyp2klnZGWnO5aam6kBjQfX9rNZcM2vDnN00CrTC2IwVQIgLSGWMSt1gdsGAt03BBP0TDwSpb+tzNHHz88rkFErPq/zBnoAV2M8FoRj16vDPvpDqHrepEIigyNUOytJLowpXkGotmvaaKqnWiJfyy5M1r1vaTQw6O9sCMpQwWlaczWRshGzM1rOqBQ==
X-YMail-OSG: B6qaqd4VM1m.YQElBtCtJlBo4dgWVHkCdrZy7631h_n6EJINhVaOUr92FulzUAR P6mgfey889tRgkYHbzdDb8oNwlLLzbL0NLg7OGXsxxh4TgEGHY1f1i0AityfrMjdB2huL0.KEO8q .zHdp2OTfGDT8HFo0nHV.xd7hRjDOdINYB2AQDO_kU_.p1Bsmy0kcz4BjRKoRpPNwObOj8Rtb5LZ MaO1.OkL_dmeWVLWSBNW8gEp.wK7P3opZjqd_60E98D50TShB8tmT8p1wLocduEG5XfGNsTVg1aY 1q8RxH.OC2Y9v.0RBZkZpQHKtcuAk.NllRTng03VJyBtU4xyQDL1el3QfT6JOMah4IHZZDG3WTEj oXYOblZyGmxd0zFxBkBOwX1pnVJWEuSCbOq2wAyfd43jFRLWPzQbs_EHXfyDtCq0A3hoZ_5J0KMw AbnKhrJ_I3vmz_CVrYKiNbcczVoN9hkHNrLwZaowbeDLXq0VHu1XatwiMkTblmQQBuN39mTR_H0m b4KM4Fyn5V6kmpNlCmQR.x6NMO9QWFgGyzDrZUKskqfxd3R3eZtZrl7V.gYY1Hs_4P6WEVyzjXD1 LKk2xQo8XNin2EoGug7KOrqWjRiBS0Rq83TghcrGWguHVmJOXoAoBQgHvbffHI97mFBhMUFCAM5S eBz36rDn69f9L6rBGRD1eRphcgHx7jHd7LAMaWsCG0Cao4nfotTYwKL8ONJb.hsWQqIm0fLrEIzz YWxApxWnSODtkNV98PiefBsQpYMEcXnjJv1zvT1H4xn9Cw_ew4tFUACJZone2FE54kOP5sIb7hlF JLZ2wwMZ47ZSHJMa25T2tGcjMtKH7o9B1U907cbp.WzX0JBm2r.cN8aayMX9ls3wS9nPr.tWOgyL fODA3j71r0B96zG0YH2uKdW9SMh0Cg_HsLg69FrEyzSpZgm5.jHGf2NwIcAnXbJGjSKywc53nqQM rCyi7uTR7Wp0ZpHzMliZfNL9NjR4ByNixK1cO71UrCIEDzuyhcqFUM_3qMWE1VqMkrUV0dpS.cqw sBQOJsheUJKVYBk2mVzMSQacXiTTGbqM4fO3MUW69EiJCKkyhxc0EsMTCPBaRPMw7j8_sUlXYkwC bSpvmSEGQWqVGMrz2zbWpW8Pf6ftc8Mm0q8L2IH1ZrOS1hlGJ7lDt_6Va_S5CHi_gK4EIRm6MGqI oE7eX6hMR9u_oygYHpNBmSH5X5rT8bkflqmm_ca8yBedoJpCZaG1rcEUa7oAn5iq5ajDxNz29i0E x5ddslmzbqAALgslzz.WcRrizYCpjTR3tyz5kGvtqkOp2VuAuGAoViGA8d3IoiwvgP9FxOPzmuHQ qM.Qk_YWm_ycjK0undhNC5.ncwxBWG8zx7Z9i2vW9RceH.4X8lVPR5mrhqom4k8yO0ziFX7XATmY T7YJJXSWtIbKPFr5KOFfYnMf3yKxnlswJBvFK5OvOuuRipviOGFGwEjeG7LqZqcVMZjGrUirDcGM 1MpPOkXuIkab5CeHxwmyWv5TotIEjGD7qcWAq0IlrdbJEhSXAcSrnq2lb40jhaocO0WYol0RnAOd RFjWu23U3mtSVqv_EsAkDFoNoPtwFtEVrz3eHo7sXxCsSZFWL_48YLS8KCSG3D33YbOegWCi7aZy hGyeo7MBlGmg8txtKfbo2Wi2mBBPAp.IvRTtFcHmybiM4nycAYcphwzVr.fIvoH8Cr0ZTHBLeJsh 1dTiNDB_lz3E4DMoBH_lzv56Z6B3oEQOQxdq2hAP3nBxwS72ghVOaVJqac5QoWmeor7LQrDXmg7Q 0YXGXyBAwbLbb_e2FKBenPM7jAEfPGHHlcHgu1UBFm9zY_49jIWjDxM8kgLF2TRibXW3WB2h1Vb. 8faH7rJu4Baw6yBNYoq3QFk_6T9zo46xuxIY22stKJBv69GzAl0kIB02R7r2JPFyb0GSsrVwWsDx iV7cl21sK7qDUIpuAYKUbXEcZtA3.PA0c8bbxqKzQ7Wh.mTD7pZs.NkW2jm.OnUmZ_WxTjdDUQL0 A4lGF33BrtYbtZeRDBRDzJW0EwvhL2gW6b7wbV927RpRuxRNR8p5gjkhvY9vi2vEAs60Z0ymofuh WJMOBN3v.KeiloIhhPWPxE8yi9vQU1vnw0PU9HH4OCWC9OzBvDShpYGzYPIqKWwDtMYdmA9ULyEg YOQxfUKmPrPrN1X1MDjIqUqDv_4qijX1Wn6Wk9Zo-
X-Sonic-MF: <stkent@verizon.net>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 30 Nov 2021 20:21:31 +0000
Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID aceb0fa74651ca2964eb868f937a360a;  Tue, 30 Nov 2021 20:21:29 +0000 (UTC)
Message-ID: <f09cbae8-f541-0e18-89d9-7830ceccca63@verizon.net>
Date: Tue, 30 Nov 2021 15:21:28 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: Rob Austein <sra@hactrn.net>, Warren Kumari <warren@kumari.net>
Cc: SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-6486bis@ietf.org
References: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com> <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net> <20211130193034.344F62EA0102@minas-ithil.hactrn.net>
From: Stephen Kent <stephen.kent@verizon.net>
In-Reply-To: <20211130193034.344F62EA0102@minas-ithil.hactrn.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5YiX3TKomjZlDpKIB_Vx-SHWZ5E>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 20:21:34 -0000

Rob,

Thanks for adding these insights.

Steve
> One thing that may not be immediately obvious to Warren: there's a big
> difference between NotBefore in certificates and ThisUpdate in CRLs
> and manifests.  Backdating NotBefore by some small amount makes sense
> given the possibility that clock skew might cause a certificate to be
> interpreted as invalid at the time it's issued, which could be bad.
> ThisUpdate is more of a tick mark recording the passage of time in the
> evolving history of a manifest or CRL: nothing terrible should happen
> in the case of clock skew, so as Steve suggests it's probably best to
> tell the truth about the time of publication.
>
> Manifests have this extra twist in that the manifest CMS contains an
> embedded EE certificate which has a NotBefore, so one gets to invoke
> both of these rules at once while generating the same object, yay.



From nobody Tue Nov 30 14:17:01 2021
Return-Path: <jsnijders@fastly.com>
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 152F93A15F5 for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 14:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=fastly.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 Suqz1R0mU7UP for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 14:16:54 -0800 (PST)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 217233A15EF for <sidrops@ietf.org>; Tue, 30 Nov 2021 14:16:54 -0800 (PST)
Received: by mail-il1-x130.google.com with SMTP id j21so23008104ila.5 for <sidrops@ietf.org>; Tue, 30 Nov 2021 14:16:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G6Z6kI+WVZSz0/9CT2cc32WEMHlX6iHfluPyGd2sCuk=; b=KielwUufbVcu46TbcYC4GNQDGhxNB+MBv8V/S1HdJ6AGNVBG27oHKdrx2qWOAzj0Fv KQFmlTaDGS5PL4kd1UZ+Mjt7v7D9W12mbgAX5UDzZ5kjKPKRe81xiSM9R5Yz22SWBrRQ OalF146UklR1oROYZfVCz9kGOc08HjZTPL5as=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G6Z6kI+WVZSz0/9CT2cc32WEMHlX6iHfluPyGd2sCuk=; b=akIX56AHQfY2bM0MFI80DyeXRzeA+6kPebgk1QcqP4kAgXlTsLISpPO8kUqMyxwyRj DMfNi9vh9aA+eBk4TwbZeHc1A9wSB2YXYBo0stK8uZGpn1w0IWzgl+Z4hqDYd9T0KnAX vegykrG/Y014ihF9qGVDW8wzEp5SV++bkIcFo5troJvrqxO0YaLkG1EjskOn8CyMGlXI dRLrtoDzvP3ml391xLY5nRy5OkH5BYMd61NIVwxsWloroA6Ub5tUxypYIDhIPe/dPt67 1hwdMQVnDEwfXAyNLyL1wyC7wCnGMc629QQtHH6++31cMjYtaQOYj8Wo8yGJaqmZstVQ 6y/A==
X-Gm-Message-State: AOAM5334ZYlXnp9pT2hVkhcie4oTyP5of7t2rGypxE82F8n5MWhI/SOQ BSih/1maUIGU5Wb7P4xHH7DQqU4fSfqUbPn3P+l35A==
X-Google-Smtp-Source: ABdhPJxzsbF1J+KLXHgbZg9jnju/Baj46QzHuz+lT1GIPq3/UyGw0kJEbd0QkG3vR6CfqAUT6QFDmTxip/u2EthiHLw=
X-Received: by 2002:a05:6e02:1aaf:: with SMTP id l15mr2745382ilv.187.1638310612230;  Tue, 30 Nov 2021 14:16:52 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com> <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
In-Reply-To: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
From: Job Snijders <job@fastly.com>
Date: Tue, 30 Nov 2021 23:16:41 +0100
Message-ID: <CAMFGGcCKWOvv2q-CLJBuV1OkmA9WFBcHPFjQ1A2fqt2QF1wvFg@mail.gmail.com>
To: stephen.kent=40verizon.net@dmarc.ietf.org
Cc: SIDR Operations WG <sidrops@ietf.org>, Warren Kumari <warren@kumari.net>,  draft-ietf-sidrops-6486bis@ietf.org
Content-Type: multipart/alternative; boundary="00000000000012fa8305d208ea59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sN9PcWbY7X10gKqCH_MLOjJt1GY>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 22:17:00 -0000

--00000000000012fa8305d208ea59
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all.

Thank you Warren for your review, thanks Stephen Kent for responding.

On Tue, 30 Nov 2021 at 19:44, Stephen Kent <stephen.kent=3D
40verizon.net@dmarc.ietf.org> wrote:

>
> > 2: S 4.2.2. Names in FileAndHash objects
> > "As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a valid f=
ilename."
> > I'm not sure where to make this comment (here or in the validation
> > section), but I'm *assuming* that the case is "important" --
> > vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems which ar=
e
> > case insensitive for filenames (e.g: Mac OS can format a device as
> > "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive,
> > Journaled)". I'm suspecting that this might be a corner case, and / or
> > not really an issue for this document, but it seems like it may be
> > worth having a reminder / note.
>
> This text first appeared in version 3 of 6496bis, published in November
> 2020, over a year ago. The text was proposed by Job Snijders. The topic
> of case sensitivity, as well as some other aspects of the proposed text,
> were discussed on the list from 11/19-11/24/20, by several WG
> participants. I'm happy to add further clarification re case
> sensitivity, if the WG agrees on what that clarification should be.



I would like to suggest to leave this part of the document as-is.

I don=E2=80=99t recall there ever having been any ambiguity in the minds of=
 either
RP developers, or CA operators, on the topic of case sensitivity.

A contextual aspect is that each file (listed by name), also is addressable
by its SHA256 hash, also listed on the manifest.

Kind regards,

Job

>

--00000000000012fa8305d208ea59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Hi all.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Thank you Warren for your review, thanks Stephen Kent for responding=
.</div><div><br><div class=3D"gmail_quote"></div></div></div><div><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, 30 Nov 2021 at 19:44, Stephen Kent &l=
t;stephen.kent=3D<a href=3D"mailto:40verizon.net@dmarc.ietf.org" target=3D"=
_blank">40verizon.net@dmarc.ietf.org</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204=
)"><br>
&gt; 2: S 4.2.2. Names in FileAndHash objects<br>
&gt; &quot;As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a v=
alid filename.&quot;<br>
&gt; I&#39;m not sure where to make this comment (here or in the validation=
 <br>
&gt; section), but I&#39;m *assuming* that the case is &quot;important&quot=
; -- <br>
&gt; vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems which a=
re <br>
&gt; case insensitive for filenames (e.g: Mac OS can format a device as <br=
>
&gt; &quot;Mac OS Extended (Journaled)&quot; or &quot;Mac OS Extended (Case=
-sensitive, <br>
&gt; Journaled)&quot;. I&#39;m suspecting that this might be a corner case,=
 and / or <br>
&gt; not really an issue for this document, but it seems like it may be <br=
>
&gt; worth having a reminder / note.<br>
<br>
This text first appeared in version 3 of 6496bis, published in November <br=
>
2020, over a year ago. The text was proposed by Job Snijders. The topic <br=
>
of case sensitivity, as well as some other aspects of the proposed text, <b=
r>
were discussed on the list from 11/19-11/24/20, by several WG <br>
participants. I&#39;m happy to add further clarification re case <br>
sensitivity, if the WG agrees on what that clarification should be.</blockq=
uote><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div><div><di=
v dir=3D"auto">I would like to suggest to leave this part of the document a=
s-is.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I don=E2=80=99t re=
call there ever having been any ambiguity in the minds of either RP develop=
ers, or CA operators, on the topic of case sensitivity.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">A contextual aspect is that each file (list=
ed by name), also is addressable by its SHA256 hash, also listed on the man=
ifest.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Kind regards,</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Job</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" =
dir=3D"auto"></blockquote>
</div>

--00000000000012fa8305d208ea59--


From nobody Tue Nov 30 14:17:39 2021
Return-Path: <k.w.vanhove@student.utwente.nl>
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 743863A15F5 for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 14:17:37 -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, 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=student.utwente.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 6Vtwsf8jy1fu for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 14:17:32 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 242243A15EF for <sidrops@ietf.org>; Tue, 30 Nov 2021 14:17:31 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id x6so92643641edr.5 for <sidrops@ietf.org>; Tue, 30 Nov 2021 14:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=student.utwente.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=8uYPtHxinqxZoOgX44ETRutA7pZJQ2mCGtL/nk53cAI=; b=uS4A3VAjf3xYNJXoZqJp/fQRvehSShZ+v/pHVaAjA9teqU/kAFJYkgLyagbkn6MoGQ P/umejgyhEqOVyputUu+b1XZse75mS5imu6IMWze17ZhYA4713QWgNb/QGuBHxIySWmj 35QvZnX6MP+l8iDjDBnD/xejaiL08OqbPN5p1Pr+QJ8sNZv7Lb4kSRXjHWf//wc00bj5 lb4ifsAbSCrzqMGDIm9W+xlShQ15m2WFeOihrzDWjw9/Jp5ErTH36M2ZlBqFYAbLPxUF APUgzqbskcnVZ1UMxwBccm9wWnG7T2uKDUxZvqs8dqRLHRztaq1GzEOmbxzKvgbXT1C5 b9oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=8uYPtHxinqxZoOgX44ETRutA7pZJQ2mCGtL/nk53cAI=; b=ceQVyyU2tZlZy3OwwvhbLAzfBTUbe2XOtzssZ1PvAj/tp11hwEBCvHEOs6/bkcIAkd yH9RHxBAPkpAnfhyxqRsTbyWkxWgXFODWnSU03FpseCGsp9zS5apKNHrPN0B4NXsHy0w GjsUkz+7qh9Q0cTv6LOuKRPbfp6g5xxn5aS73xOOEasJECrQI5Kwgl3jh0BF93BQKbWv AKbqEHjIXmYWVdyU4M+AjbcOSWJSoaCFm5hI3yMdQ8Le2M5hNglUa8SMypW+4gxi7c6A o1pZJyzyxIo4gxoIfOlzj0a3lwxmG9jD7u+8GSjBXFUAwzrb2kZ2VAXHUMnjXXzQBYoR hZlg==
X-Gm-Message-State: AOAM532wdL/Q+xFh83zO8A04N4k6vlwyGnI2WUuIKQ666j0vPnkOUnRE 1hLvCLUbqLEjIungyUqfDOVwT4N9Bxd+B/QVbLIUPr9YIesPzb4uOjo9lNh/WrmwiTIPCX38xMh 2Cv9LveBRAhbaq/YKmVdQfevyKrhhoC6hB91oqCqJgAbAr4E64ZWfjt0jTC+mabnpG4HEnqR9Pn zo
X-Google-Smtp-Source: ABdhPJy01+HSNUV5HApyzXe7cKObiiUdcDe4OwyVc/N+NaxiCcjDeSGQxVU6N2PPM1tp1wGN85ldjw==
X-Received: by 2002:a50:d741:: with SMTP id i1mr2620405edj.37.1638310648858; Tue, 30 Nov 2021 14:17:28 -0800 (PST)
Received: from DELTA (219-190-177-143.ftth.glasoperator.nl. [143.177.190.219]) by smtp.gmail.com with ESMTPSA id de37sm9531995ejc.60.2021.11.30.14.17.28 for <sidrops@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Nov 2021 14:17:28 -0800 (PST)
From: "Koen van Hove" <k.w.vanhove@student.utwente.nl>
To: "'SIDR Operations WG'" <sidrops@ietf.org>
References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <C80AF40F-7F86-4156-8915-5694D745AD31@nlnetlabs.nl>
In-Reply-To: <C80AF40F-7F86-4156-8915-5694D745AD31@nlnetlabs.nl>
Date: Tue, 30 Nov 2021 23:17:27 +0100
Message-ID: <001b01d7e638$0f34baf0$2d9e30d0$@student.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQG5KyS5O66QVqbINo4wVlHfa5ecZwF0ktdArE5gq7A=
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qv016OrLCOlEe8uezw7MIBOwpKw>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 22:17:38 -0000

Dear Tim, all,

I have looked at your motivation, particularly:
>    *  rsync is CPU and memory heavy on the server side, and easy to DoS

I decided to test your hypothesis, as RFC 6480 says otherwise, and created a
small program that aims to DoS an rsync daemon using many simultaneous
connections from different IP addresses (but the same machine). My
conclusion is the same as yours - with the old computer (4 cores, 16 GB of
RAM, home fiber connection) underneath my desk I can currently take down my
own test rsync server (8 cores, 16 GB RAM, 1 Gbps connection, different
network). Discussions with operators from RIRs seem to show that this would
also work for their rsync servers.  I believe this would even allow one to
take down all rsync servers currently running in the RPKI with a handful of
computers, but I have not tested that as I do not want to disrupt actual
operations. For this reason, running only rsync strikes me as problematic,
especially if one wishes to adhere to "The publication repository SHOULD be
hosted on a highly available service and high-capacity publication
platform." from RFC 6481, and thus believe that making RRDP a MUST is a good
idea. Of course, one can block the IP addresses used for the DoS attack, but
that turns into a cat and mouse game, where the rsync server operator has a
serious disadvantage (especially compared to RRDP).

What I further want to draw the attention to, and I did not see mentioned in
the draft, is that apart from rsync being an extra protocol that can be used
to receive data (which is useful if RRDP fails), it is also an additional
attack vector. I am thus opposed to the addition of: 
>    Relying Parties MUST attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod element
value(s) specified in the SIA of the associated certificate (see Section
4.8.8 of [RFC6487]).

Rsync was not created to be used with a possibly malicious server.
Therefore, there are currently simple things everyone could do that would
disrupt a relying party over rsync, which are difficult to solve:
1. One can set a motd file that is several gigabytes in size. Rsync will
wait until this is received (the --no-motd switch only hides it on the
client) and the timeout set in rsync does not affect the maximum time this
may take.
2. One can create an rsync repository with many folders (I tested it with 27
million folders). This fills up the maximum amount of inodes on most Linux
and *BSD filesystems within minutes whilst bypassing any size limits or
--includes and --excludes, as a folder has a size of 0, and folders are used
in non-malicious repositories. 
Both can be done when one is part of an RPKI tree, or using MITM, or a DNS
hijack - serving the actual files as well is not a problem, and you do not
need to sign anything new. Solving the first one can probably be easily done
by setting a timeout outside the rsync program, but the second one seems
more difficult to solve. I believe the impact could be quite substantial.
There is probably more an attacker can do - I did not look extensively into
it.

As both the server and the client can easily be attacked, I believe that in
this case "less is more", and to re-evaluate whether rsync support is an
asset or a burden. I believe availability of the RPKI ecosystem can be
better guaranteed without rsync, and believe a post-rsync section is
justified.

Koen van Hove

-----Oorspronkelijk bericht-----
Van: Tim Bruijnzeels <tim@nlnetlabs.nl> 
Verzonden: vrijdag 22 oktober 2021 11:03
Aan: SIDR Operations WG <sidrops@ietf.org>
Onderwerp: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt

Dear working group,

We just uploaded a new version of the prefer-rrdp draft.

The document has had some updates based on working group member comments and
discussion between the co-authors. The uploaded version still lacks final
review by my co-authors, but.. after discussing we decided that it would be
good to replace the now expired -00 with this. This also makes it easier for
WG members to comment.

This version is not intended to be final. It's intended to support further
discussion. So feel free!

Important changes compared to -00:
- We no longer talk about post-rsync in this document
   (this can be done as a later and separate exercise)
- We included some more text on rsync fallback

I would like to ask you all to give it a read provide feedback.

Kind regards
Tim




> On 22 Oct 2021, at 10:53, internet-drafts@ietf.org wrote:
> 
> 
> 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           : Resource Public Key Infrastructure (RPKI)
Repository Requirements
>        Authors         : Tim Bruijnzeels
>                          Randy Bush
>                          George Michaelson
> 	Filename        : draft-ietf-sidrops-prefer-rrdp-01.txt
> 	Pages           : 10
> 	Date            : 2021-10-22
> 
> Abstract:
>   This document formulates a plan of a phased transition to a state
>   where RPKI repositories and Relying Party software performing RPKI
>   Validation will use the RPKI Repository Delta Protocol (RRDP)
>   [RFC8182] as the preferred access protocol, and require rsync as a
>   fallback option only.
> 
>   In phase 0, today's deployment, RRDP is supported by most, but not
>   all Repositories, and most but not all RP software.
> 
>   In the proposed phase 1 RRDP will become mandatory to implement for
>   Repositories, in addition to rsync.  This phase can start as soon as
>   this document is published.
> 
>   Phase 2 will start once the proposed updates are implemented by all
>   compliant Repositories.  In this phase RRDP will become mandatory to
>   implement for all compliant RP software, and rsync will be required
>   as a fallback option only.
> 
>   It should be noted that although this document currently includes
>   descriptions and updates to RFCs for each of these phases, we may
>   find that it will be beneficial to have one or more separate
>   documents for these phases, so that it might be more clear to all
>   when the updates to RFCs take effect.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-prefer-rrdp/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-0
> 1
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-prefer-rrdp-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops




From nobody Tue Nov 30 15:14:34 2021
Return-Path: <warren@kumari.net>
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 40A203A044A for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 15:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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
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 Q7w0Ln2J0qF4 for <sidrops@ietfa.amsl.com>; Tue, 30 Nov 2021 15:14:26 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 56CA23A044F for <sidrops@ietf.org>; Tue, 30 Nov 2021 15:14:26 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id w22so28421943ioa.1 for <sidrops@ietf.org>; Tue, 30 Nov 2021 15:14:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e/DKjYuptXFhtwgvEvUofIVf1dcdO4ZxL+GV0yTkzUE=; b=Zm02eL7zOntnQ8lbvIBx/k91UHlh97o9ctoU8B4xcEGsLu71o+/cKr5BLjoGbxV5xx Kn3RDCimtC3Y2ASr1aXrJyJERJ/jSFSb/+nPqvApNFTVjEIuQGdWH+WpdrmCgNH1/0BR 3liHO9lUL4gqN7jybM6NLc4CsEnU2K2AxeJ6/Jyo9OcxWzaNfaZayEa1jU6c+SEnFXNk xmJ76lNsfEi7CWGidGqThyc4gOUtGJZSjga3x9UZxROwFheXuxmDC1TwjmCMB9+BwLch CZwkFiWXBIP70AuMhI99dBY5xTc0AJOzNKF+iKMcQchYCNEOlemyVI3VuNNuaJywzzBt osJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e/DKjYuptXFhtwgvEvUofIVf1dcdO4ZxL+GV0yTkzUE=; b=zJf9WXG7GH9yBL5QgZmiZoOnC+UL0MSungz/HOtwwjN8DzHDXU7YgYMr5G31zhsf+m ErxxASy+wZvx/0fY2dyZcSn0HWTXRHTI8W0r5qTEQlTUwabeAIq444NbUDZF/TneIRm9 5c4K0MVNjP+SHXJle3Tb9LY/6yed92PD/si0AfMtBFJWOW0lwmfx4G8EqxHRG7NyonJT UdAuamAD5zeSHv99kOpHosMl1rJ4HP3SuD/qvmgZ0wLOsrIvoO0IIaEqWtDJxxfzCjcH RMpLftdaK06SbsXluRWZXuuYB6/XUiQs5eQQtmCUq3kfavyx5nWPi7Ox33FSTLv6HLsx /giw==
X-Gm-Message-State: AOAM5331umfrgCo5/jcqnEImXw/dOAqEnT8XpkiZg8EpFkswUrBPsws4 xqzhUICRDEspZ8Ae2Hmwb5CcCSxweCQR776wt8vnww==
X-Google-Smtp-Source: ABdhPJwOw9yB7CwWSpvuCceyuSX5N8Oco5yIUtgKjnU31vcm1qZziqXpNtOwHxV/JwXdAjQdMf4Gup+pjM0iZJRJz+k=
X-Received: by 2002:a5d:9496:: with SMTP id v22mr3227712ioj.36.1638314064240;  Tue, 30 Nov 2021 15:14:24 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iKjjo_q=yP7_WAr2OagW5fhhC+ze=0dTDu6jhMyd6KjnA@mail.gmail.com> <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
In-Reply-To: <813d1599-fc9d-18b6-a76c-b550855b1186@verizon.net>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 30 Nov 2021 18:13:48 -0500
Message-ID: <CAHw9_iJ1_tCKaj8xeh1k0mQ_by+JjRZe3a8K455+wJ7VAJ54UQ@mail.gmail.com>
To: Stephen Kent <stephen.kent@verizon.net>
Cc: SIDR Operations WG <sidrops@ietf.org>, draft-ietf-sidrops-6486bis@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d47bcc05d209b7a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/KOVDyXNYcCtSiEb33-ybOA-uPeU>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-6486bis
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 23:14:32 -0000

--000000000000d47bcc05d209b7a3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[ Responding here so I can respond inline - thanks to Job and Rob for
additional clue ]

On Tue, Nov 30, 2021 at 1:44 PM Stephen Kent <stephen.kent@verizon.net>
wrote:

> Warren,
>
> Thanks for the detailed review. Responses inline.
> > ...
> >
> > 1: S 3. Manifest Signing
> > O: termed a "one-time-use" EE certificate.[RFC6487]
> > P:  termed a "one-time-use" EE certificate [RFC6487].
> > C: Reference before the period (consistency nit)
> fixed.
>

Thanks.


> >
> > 2: S 4.2.2. Names in FileAndHash objects
> > "As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a valid f=
ilename."
> > I'm not sure where to make this comment (here or in the validation
> > section), but I'm *assuming* that the case is "important" --
> > vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems which ar=
e
> > case insensitive for filenames (e.g: Mac OS can format a device as
> > "Mac OS Extended (Journaled)" or "Mac OS Extended (Case-sensitive,
> > Journaled)". I'm suspecting that this might be a corner case, and / or
> > not really an issue for this document, but it seems like it may be
> > worth having a reminder / note.
>
> This text first appeared in version 3 of 6496bis, published in November
> 2020, over a year ago. The text was proposed by Job Snijders. The topic
> of case sensitivity, as well as some other aspects of the proposed text,
> were discussed on the list from 11/19-11/24/20, by several WG
> participants. I'm happy to add further clarification re case
> sensitivity, if the WG agrees on what that clarification should be.
>
>
If it's already been discussed and everyone is happy, so am I (also thanks
to Job for noting that no-one has freaked out :-))


> >
> > 3: S 5.1. Manifest Generation Procedure.
> > "2. Issue an EE certificate for this key pair. The CA MUST revoke
> >  the EE certificate used for the manifest being replaced.
> >  This EE certificate MUST have an SIA extension access description
> >  field with an accessMethod OID value of id-ad-signedobject, where
> >  the associated accessLocation references the publication point of
> >  the manifest as an object URL.(RPs are required to verify this.)"
> >
> > It is somewhat unclear to me what exactly the RP is required to verify
> > here:
> > A: that the EE cert has an SIA extension with accessMethod of
> > id-ad-signedobject
> > B: that the associated accessLocation references the publication point
> > of the manifest
> > C: Both?
> > If B or C how does it do this? (I'm assuming it doesn't have to fetch
> > the manifest to make sure :-)). I did check in Sec 6 to see if this
> > was answered (S 6.2 / S 7 were close). I suspect that this is obvious,
> > but it seems like a few more words would help.
>
> C- both, and I have modified the text to make this clear.
>
>
Thanks!


>
> >
> > 4: S 5.1:
> > "3. The EE certificate MUST NOT be published in the authority=E2=80=99s
> > repository publication point."
> >
> > Why is this a MUST NOT?
> > S2 says: "Every RPKI signed object includes, in the Cryptographic
> > Message Syntax (CMS) [RFC3370] wrapper of the object, the EE
> > certificate used to verify it [RFC6488]. Thus, there is no requirement
> > to separately publish that EE certificate at the CA=E2=80=99s repositor=
y
> > publication point."
> > "no need" is different to "MUST NOT" - what is the harm if the EE were
> > to be published? If it is not referenced, does it matter?
>
> If the EE cert for the manifest were published at the PP covered by the
> manifest, an RP implementation might perceive a circular dependency and
> act in an indeterminate fashion. The MUST NOT is designed to prevent
> such a situation.
>

If easy, a sentence / parenthetical mentioning that in the doc would be
helpful (otherwise someone will likely ask it during LC / IESG eval)


>
> >
> > 5: S 6.2. Acquiring a Manifest for a CA
> > Nit: "an RP MUST treat this as a failed fetch and, proceed to Section
> 6.6"
> > Superfluous comma
>
> fixed.
>

Thanks!


>
> >
> > 6: S 6.3. Detecting Stale and or Prematurely-issued Manifests
> > "If the current time is earlier than thisUpdate, the CA has made an
> > error; ..."
> > There was some discussion on this during the WGLC, but I don't think
> > that I actually saw a resolution. Let's say that the thisUpdate is
> > "Nov 18 12:37:56 2021 GMT", but when the RP fetches it, it's clock
> > is "Nov 18 12:37:55 2021 GMT" (one second slow) -- it seems silly for
> > this to be a fetch failure
> > I *think* that it is general practice for certs to have the "Not
> > Before" be backdated by some amount of time (e.g LE does 1h), and
> > Windows at least backdates CRLs by ClockSkewMinutes (10 minutes by
> > default) -
> >
> https://social.technet.microsoft.com/wiki/contents/articles/20652.how-thi=
supdate-nextupdate-and-nextcrlpublish-are-calculated.aspx
> >
> > I'm fine with the answer being "Yeah, no IETF document says that, and
> > we don't want to open that can of worms", but I do want to make sure
> > that it has been considered and discussed.
>
> IMHO, if a CA issues and publishes a Manifest in which the thisUpdate
> value is earlier than the actual time, it's an indication of sloppy
> procedure, not a good sign:-)
>
> I am unmoved by hacks that MS may have chosen to employ in issuing CRLs;
> they have a habit of not following PKIX standards when some engineer
> thinks he/she knows better.
>


Ok, WFM!

It sounds like you've fixed the nits and comments in an editor version. If
easy, please add a bit explaining the MUST NOT ( I think that your "If the
EE cert for the manifest were published at the PP covered by the
manifest, an RP implementation might perceive a circular dependency and act
in an indeterminate fashion." works well), publish it, SHOUT LOUDLY so I
don't miss it, and I'll start IETF LC.

Thanks for addressing the nits and the gentle use of the clue-bat,
W


>
> Steve
>
>

--=20
The computing scientist=E2=80=99s main challenge is not to get confused by =
the
complexities of his own making.
  -- E. W. Dijkstra

--000000000000d47bcc05d209b7a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>[ Responding here so I can respond inline - thanks to=
 Job and Rob for additional=C2=A0clue ]=C2=A0</div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 30, 2021 at 1:44 P=
M Stephen Kent &lt;<a href=3D"mailto:stephen.kent@verizon.net">stephen.kent=
@verizon.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Warren,<br>
<br>
Thanks for the detailed review. Responses inline.<br>
&gt; ...<br>
&gt;<br>
&gt; 1: S=C2=A03. Manifest Signing<br>
&gt; O: termed a &quot;one-time-use&quot; EE certificate.[RFC6487]<br>
&gt; P:=C2=A0=C2=A0termed a &quot;one-time-use&quot; EE certificate [RFC648=
7].<br>
&gt; C: Reference before the period (consistency nit)<br>
fixed.<br></blockquote><div><br></div><div>Thanks.=C2=A0</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;<br>
&gt; 2: S 4.2.2. Names in FileAndHash objects<br>
&gt; &quot;As an example, =E2=80=99vixxBTS_TVXQ-2pmGOT7.cer=E2=80=99 is a v=
alid filename.&quot;<br>
&gt; I&#39;m not sure where to make this comment (here or in the validation=
 <br>
&gt; section), but I&#39;m *assuming* that the case is &quot;important&quot=
; -- <br>
&gt; vixxBTS.cer !=3D VIXXBTS.CER? There are some operating systems which a=
re <br>
&gt; case insensitive for filenames (e.g: Mac OS can format a device as <br=
>
&gt; &quot;Mac OS Extended (Journaled)&quot; or &quot;Mac OS Extended (Case=
-sensitive, <br>
&gt; Journaled)&quot;. I&#39;m suspecting that this might be a corner case,=
 and / or <br>
&gt; not really an issue for this document, but it seems like it may be <br=
>
&gt; worth having a reminder / note.<br>
<br>
This text first appeared in version 3 of 6496bis, published in November <br=
>
2020, over a year ago. The text was proposed by Job Snijders. The topic <br=
>
of case sensitivity, as well as some other aspects of the proposed text, <b=
r>
were discussed on the list from 11/19-11/24/20, by several WG <br>
participants. I&#39;m happy to add further clarification re case <br>
sensitivity, if the WG agrees on what that clarification should be.<br>
<br></blockquote><div><br></div><div>If it&#39;s already been discussed and=
 everyone is happy, so am I (also thanks to Job for noting that no-one has =
freaked out :-))</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
&gt;<br>
&gt; 3: S=C2=A05.1. Manifest Generation Procedure.<br>
&gt; &quot;2. Issue an EE certificate for this key pair. The CA MUST revoke=
<br>
&gt; =C2=A0the EE certificate used for the manifest being replaced.<br>
&gt; =C2=A0This EE certificate MUST have an SIA extension access descriptio=
n<br>
&gt; =C2=A0field with an accessMethod OID value of id-ad-signedobject, wher=
e<br>
&gt; =C2=A0the associated accessLocation references the publication point o=
f<br>
&gt; =C2=A0the manifest as an object URL.(RPs are required to verify this.)=
&quot;<br>
&gt;<br>
&gt; It is somewhat unclear to me what exactly the RP is required to verify=
 <br>
&gt; here:<br>
&gt; A: that the EE cert has an SIA extension with accessMethod of <br>
&gt; id-ad-signedobject<br>
&gt; B: that the associated accessLocation references the publication point=
 <br>
&gt; of the manifest<br>
&gt; C: Both?<br>
&gt; If B or C how does it do this? (I&#39;m assuming it doesn&#39;t have t=
o fetch <br>
&gt; the manifest to make sure :-)). I did check in Sec 6 to see if this <b=
r>
&gt; was answered (S 6.2 / S 7 were close). I suspect that this is obvious,=
 <br>
&gt; but it seems like a few more words would help.<br>
<br>
C- both, and I have modified the text to make this clear.<br>
<br></blockquote><div><br></div><div>Thanks!</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;<br>
&gt; 4: S 5.1:<br>
&gt; &quot;3. The EE certificate MUST NOT be published in the authority=E2=
=80=99s <br>
&gt; repository publication point.&quot;<br>
&gt;<br>
&gt; Why is this a MUST NOT?<br>
&gt; S2 says: &quot;Every RPKI signed object includes, in the Cryptographic=
 <br>
&gt; Message Syntax (CMS) [RFC3370] wrapper of the object, the EE <br>
&gt; certificate used to verify it [RFC6488]. Thus, there is no requirement=
 <br>
&gt; to separately=C2=A0publish that EE certificate at the CA=E2=80=99s rep=
ository <br>
&gt; publication point.&quot;<br>
&gt; &quot;no need&quot; is different to &quot;MUST NOT&quot; - what is the=
 harm if the EE were <br>
&gt; to be published? If it is not referenced, does it matter?<br>
<br>
If the EE cert for the manifest were published at the PP covered by the <br=
>
manifest, an RP implementation might perceive a circular dependency and <br=
>
act in an indeterminate fashion. The MUST NOT is designed to prevent <br>
such a situation.<br></blockquote><div><br></div><div>If easy, a sentence /=
 parenthetical mentioning that in the doc would be helpful (otherwise someo=
ne will likely ask it during LC / IESG eval)=C2=A0</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;<br>
&gt; 5: S=C2=A06.2. Acquiring a Manifest for a CA<br>
&gt; Nit: &quot;an RP MUST treat this as a failed fetch and, proceed=C2=A0t=
o Section 6.6&quot;<br>
&gt; Superfluous comma<br>
<br>
fixed.<br></blockquote><div><br></div><div>Thanks!=C2=A0</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;<br>
&gt; 6: S=C2=A06.3. Detecting Stale and or Prematurely-issued Manifests<br>
&gt; &quot;If the current time is earlier than thisUpdate, the CA has made =
an <br>
&gt; error; ...&quot;<br>
&gt; There was some discussion on this during the WGLC, but I don&#39;t thi=
nk <br>
&gt; that I actually saw a resolution. Let&#39;s say that the thisUpdate is=
=C2=A0 <br>
&gt; &quot;Nov 18 12:37:56 2021 GMT&quot;, but when the RP fetches it, it&#=
39;s clock <br>
&gt; is=C2=A0&quot;Nov 18 12:37:55 2021 GMT&quot; (one second slow) -- it s=
eems silly for <br>
&gt; this to be a fetch failure<br>
&gt; I *think* that it is general practice for certs to have the &quot;Not =
<br>
&gt; Before&quot; be backdated by some amount of time (e.g LE does 1h), and=
 <br>
&gt; Windows at least backdates CRLs by=C2=A0ClockSkewMinutes (10 minutes b=
y <br>
&gt; default) - <br>
&gt; <a href=3D"https://social.technet.microsoft.com/wiki/contents/articles=
/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx" re=
l=3D"noreferrer" target=3D"_blank">https://social.technet.microsoft.com/wik=
i/contents/articles/20652.how-thisupdate-nextupdate-and-nextcrlpublish-are-=
calculated.aspx</a><br>
&gt;<br>
&gt; I&#39;m fine with the answer being &quot;Yeah, no IETF document says t=
hat, and <br>
&gt; we don&#39;t want to open that can of worms&quot;, but I do want to ma=
ke sure <br>
&gt; that it has been considered and discussed.<br>
<br>
IMHO, if a CA issues and publishes a Manifest in which the thisUpdate <br>
value is earlier than the actual time, it&#39;s an indication of sloppy <br=
>
procedure, not a good sign:-)<br>
<br>
I am unmoved by hacks that MS may have chosen to employ in issuing CRLs; <b=
r>
they have a habit of not following PKIX standards when some engineer <br>
thinks he/she knows better.<br></blockquote><div><br></div><div><br></div><=
div>Ok, WFM!</div><div><br></div><div>It sounds like you&#39;ve fixed the n=
its and comments in an editor version. If easy, please add a bit explaining=
 the MUST NOT ( I think that your &quot;If the EE cert for the manifest wer=
e published at the PP covered by the</div>manifest, an RP implementation mi=
ght perceive a circular dependency and act in an indeterminate fashion.&quo=
t; works well), publish it, SHOUT LOUDLY so I don&#39;t miss it, and I&#39;=
ll start IETF LC.</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">Thanks for addressing the nits and the gentle use of the clue-b=
at,</div><div class=3D"gmail_quote">W<br><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
Steve<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">The computing scientist=E2=80=
=99s main challenge is not to get confused by the<br>complexities of his ow=
n making. <br>=C2=A0 -- E. W. Dijkstra</div></div></div>

--000000000000d47bcc05d209b7a3--

