From nobody Fri Oct 1 12:30:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74F13A0772 for ; Fri, 1 Oct 2021 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PnOTeOhoKIt8 for ; Fri, 1 Oct 2021 12:30:15 -0700 (PDT) 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 3C1DA3A0654 for ; Fri, 1 Oct 2021 12:30:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6F832300C17 for ; Fri, 1 Oct 2021 15:30:15 -0400 (EDT) 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 R1Ly4tC32NIG for ; Fri, 1 Oct 2021 15:30:13 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EC183300233; Fri, 1 Oct 2021 15:30:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Fri, 1 Oct 2021 15:30:09 -0400 Cc: Ben Maddison , SIDR Operations WG , Steve Kent Content-Transfer-Encoding: quoted-printable Message-Id: References: <162730591845.29690.12178353991713962835@ietfa.amsl.com> <2457bdd2-de07-241f-b8e4-87206dabcf16@verizon.net> <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 19:30:21 -0000 > On Oct 1, 2021, at 2:47 AM, Tim Bruijnzeels wrote: >=20 > Hi, >=20 > I saw this: >=20 >> On 30 Sep 2021, at 23:11, Russ Housley wrote: >>=20 >> version [0] INTEGER DEFAULT 0, >=20 > This is how it was done, and also what the e.g. the ROA profile uses. >=20 > However, reading the ASPA profile I came across another way, like: >=20 > version [0] VERSION DEFAULT v0, >=20 > VERSION ::=3D INTEGER { v0(0) } >=20 >=20 > This does not change the profile really afaik, but I believe this > explicitly limits the available options of 'version' to just 'v0', > i.e. an INTEGER with value 0. So, this may be a bit better in that > regard. Tim: These produce the same bits on the wire. The difference is that the = various versions have names ifor each of the integer version values. In = that case, the name is "v0". When v1 gets defined, the definition needs to be expanded to: VERSION ::=3D INTEGER { v0(0), v1(1) } For example, RFC 5652 has: CMSVersion ::=3D INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } Russ= From nobody Fri Oct 1 12:36:03 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A710A3A07A1 for ; Fri, 1 Oct 2021 12:35:59 -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, 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 xP5cdrDqx2Q0 for ; Fri, 1 Oct 2021 12:35:53 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40076.outbound.protection.outlook.com [40.107.4.76]) (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 022DA3A0788 for ; Fri, 1 Oct 2021 12:35:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hl+8qX12yTTq0KoTZcT2wI5V6l/9Blx8kAqIS9q5GQFgvcFFi4A53RuUEYaN2iO/jXYAFGNsyiN69lqpggacWbG9CtjoRLncF1ayXfzwDF320zSn2DwgwiQDj06ngimZmHHuAqpFaRzdHT2ZiiGsoS5ThSrAe1s4AEtuQOMgEoFYNY8dx5ClW0qbtRAX63vEXXyN8PSN1qeS0JYqnqVPWfw+9H9cMZl4XWS95SGs8YbfSlbDdW1oxPHitggIQ6qVJASaTr2iO+SNaecSTdzKiDAbxa+MnDbGSUtcSumfTLXceK+n+WNWilg7BwcYmfzoQ+bysDFOmGAiFV2C4ovjfw== 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=ELmPHClZ2ACQdrLqGzTjEv3ijalQ/z4yqqSb4EhZwn0=; b=koiRo7mlv8gvDvX9mrbHJypOnbJs663MosCiZRjUZR0EJelxTBVKdfWk7tn6otoaUikYdBzsFdChC2ZmYypYorCN7wTmlluyeiPVIT9zLjTs0+YOQHrJHPpoqzTKFGyS4otEdYrYIFnvpKpq4gQ2x3Jhh3ZGS7zegmwSJiV37loc/EM41xxe3vvLQ8/ttM9AxZpajXegvgQHuKmYT5fIWBv1545TZEwIPI1TVP5wwJBSoLRYI5iP9tq75fIIlk3NPEjQUpaWQ/Zm1ZaGjr98pAofcq53VO0c/hqC0x0wBCfNOpH2TOcci15YRY59NEE4Kqga3slFu1ZRlLFvALeWfg== 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=ELmPHClZ2ACQdrLqGzTjEv3ijalQ/z4yqqSb4EhZwn0=; b=sL3fmYldHZQ5WcPNjudLWMHut4vkZ6s0JDlyUpY3baHgE/O/ETcaTrnxgwM/rkgn0XhVOeNX2q3Yngb+mFm00MVeu7oSv02DWRUHRoqMrO+aDQFBaVK2WFM9BZjqd0G1YgB+AJtRbTSezZcqpEbmp0tstzZSFrUkl/fbR4Qutl0= Authentication-Results: nlnetlabs.nl; dkim=none (message not signed) header.d=none;nlnetlabs.nl; dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1685.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3fe::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15; Fri, 1 Oct 2021 19:35:33 +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.4566.019; Fri, 1 Oct 2021 19:35:33 +0000 Date: Fri, 1 Oct 2021 21:35:27 +0200 From: Ben Maddison To: Tim Bruijnzeels Cc: Russ Housley , SIDR Operations WG , Steve Kent Message-ID: <20211001193527.iqzj46waeozbh2po@benm-laptop> References: <162730591845.29690.12178353991713962835@ietfa.amsl.com> <2457bdd2-de07-241f-b8e4-87206dabcf16@verizon.net> <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gewml7ehbrs2d5ev" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CTXP275CA0042.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::30) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (160.119.236.41) by CTXP275CA0042.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Fri, 1 Oct 2021 19:35:32 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e096ce1c-ce78-4e1b-c0ea-08d98512a26b X-MS-TrafficTypeDiagnostic: AS8P190MB1685: X-Microsoft-Antispam-PRVS: 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: FctLdU2a7s5PWYkZ8hy/D96NugpJZy5zKzxji4tu9vW6YZRT4SOHhMJeTLOu9E1hPWNWXke2LWMk37IoT9lG4lC9xOiJyiYmDdj54x724g/53aVbRU3LZKYpjjIdQjCggA9CVznJ2v6IaqeyC3pyDjhI+8H6frbipfmV0Kn3o+XYyjgaTfgIUdEALaSo7MA7t7omzZp1tbw6EjbCSPfsn2WchDWjVaNnKO4AjloP1g+2uYAxV6Boq8XfyFTnos0xo9a/St/cYa/PbdEocSR68ol11iCX/Cxy/FLArTUvTzyhP8W9Z7+2unLGuVUz2sxrVbxv/8cwDkoKpo+dyBvZtsEbW+d2wF4kCrYX9iLSm+jFnf5p0C3wBWkfkkOnJ8rBbeRvTfjv9fD9QGxesODBpibmsaV4owYbWxClUvsJzqWzWo0Nc6WMlYlTJcWQsQ/zYIe2JP5Y9tVWB27DmUmeh3ajKcrpkgrEbntF2ybTlsCJI532Q3ycYa53hGdqpb2Do8fXGSYZVRBAvcOUyces7pe9EgQG4z6ftstO9wqe8diyLtCPrTPRg2sth9l2z+9ReEe6+quCQ3fRtFaCTZathJt7Kng+C33FEb9TnyL5vNfACZ7MVkfIoeOD3Q2dceNQmBatq3c1jY4Q7mrb4hp+HsUzFA3tuczIEjyA7R7c+WYIwHfq7ShQZ2XztSiO8ytQaWCHDiSfaxnzl+hNsTED9rL3N0X6bSYEwgYtW5I3bda/zWc9LQEFLH9lSoXab6SvcRgC5csyw9XrG6k3CjTQgg== 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)(396003)(136003)(366004)(346002)(39840400004)(376002)(6916009)(4326008)(53546011)(66946007)(66556008)(6486002)(44144004)(52116002)(8936002)(38100700002)(38350700002)(54906003)(66476007)(956004)(316002)(9686003)(508600001)(6666004)(2906002)(33716001)(8676002)(21480400003)(83380400001)(6496006)(5660300002)(26005)(1076003)(86362001)(186003)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B4hiEeRCPTrswDTBSmuKtT5tX/F0uLwFeQSmKZ1xZrowH37gEcZFVtRP2AHq?= =?us-ascii?Q?9/JihHF8ZsPLRoqpLMfOxAcG/UMtc3hOK7NvzfwYo8l0rU7VQ46koMJXZzIV?= =?us-ascii?Q?Qq6aUbGgfFe0i57nGfECvjfM3FLC7vGVe83z/94dh1acF/qKbI/rSHRAN3Kz?= =?us-ascii?Q?IcTqe8S3TuqNEd0vzU+cRfDEj4H1ja3dzf3e4ElIZyvorQ/a1ld+eCBkAz/x?= =?us-ascii?Q?9PyYUw1tga/RoVaFqRfG7oH9g2ktaGDwbtF8GJxmkjlHJbKADGgZ36pEdAiw?= =?us-ascii?Q?H5XRmMhjRLoW9IyTHAXg1m9d4naBu+BiTictB4r7Rv7jiev1rtpxwxKdZf57?= =?us-ascii?Q?2Q+AESrr48S5UHeGaqjDM58gb93vOT4Cs5wnxJRjzyiQezGmNcFerhB0E6s4?= =?us-ascii?Q?k82+wsED5KfpvAeyJxJL8Vfyf2ZzCNMIOddRyJjSd58uXIWCOQXzOdlYRSfe?= =?us-ascii?Q?L8+ulZlLujLHNW3WkgpwuLfBcLgNXzQwB9XnJUBwAog1ftw/DQk0KPFPnxLD?= =?us-ascii?Q?n3+Jy9gTFFetMI5tJ9QGwjIzM3qEeIofQJZwbXM6AYYRL1QYVv/BUVMDX6Ik?= =?us-ascii?Q?sqBym6Qy0rmc8rQetu2VvX7zmm28ycI4og6YG2wEmefjuEa3UHwXgFotoYj4?= =?us-ascii?Q?y/jq9S+5++JNvxWyEbRZSk51ce7v5nPzk86wS+V+y5BcpCW1QeD1hnCPfTA5?= =?us-ascii?Q?2jU6WBAt1U8aV39m9CNT/wlooLLpRYWy3rfEY6M7LZL1SjQRk6JubrHLR8y3?= =?us-ascii?Q?e8dEttPOK+u6tDBksQyMjG1lh/z3ZIozjqcwSfymFhW0fc9uvutMekwjpFzb?= =?us-ascii?Q?bXKh4ja1sUF4s2PJx4cmb1zb1iA9EJlX95qNmQ8yHQ52MxZGq3BOf0IaUird?= =?us-ascii?Q?ActrIZ7fY/NorJQqQxKTMXHw0vYJKqCdQ9LwLTUuTX3dgymcikYyMovKftrQ?= =?us-ascii?Q?5dRybZNbXQBbLPq77ks7XevpYRqiRAKHtGx8fm/9sta/UtWml5xqbnj8cTs7?= =?us-ascii?Q?l0om7F2q6Al59uf1exbnDEBjfyjm0HajQ8i2fooSNuFw2jjdunqYpCgWH1XY?= =?us-ascii?Q?shihd/EaKQyF0xQNkqTl2f7F4jCZYu/gzqf7DSZkfQoZz6UwLjIlag2lHUNq?= =?us-ascii?Q?nhTVfdISBbMISY/RaCxeRt3kOltTEAiWRnc1BVHGoNInZMLncwvSE8aAobis?= =?us-ascii?Q?Iw3Fyx+PRfIuRMgvjHORmq7AueYBjyspMQpJQ0NfbTus09Bh5r6zqda7Pb5d?= =?us-ascii?Q?F4GZHvHbGHvMoVf/1I7f9G1oJMJd4Jqihy5riaKNZk5pmFJaQyVdCYqHshGo?= =?us-ascii?Q?HhTG2qJiGV3mxOnWotPPZqFm?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: e096ce1c-ce78-4e1b-c0ea-08d98512a26b X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2021 19:35:33.2991 (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: 6kf6vo5k8zwhcMDuUMVHvcOPyKCnZTlr2wKZ85iwX4ZPAjg+3ipVp4UCuA+HWck6BM8b3kDrfNT8BHHGUbcbkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1685 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 19:36:00 -0000 --gewml7ehbrs2d5ev Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tim, On 10/01, Tim Bruijnzeels wrote: > Hi, >=20 > I saw this: >=20 > > On 30 Sep 2021, at 23:11, Russ Housley wrote: > >=20 > > version [0] INTEGER DEFAULT 0, >=20 > This is how it was done, and also what the e.g. the ROA profile uses. >=20 > However, reading the ASPA profile I came across another way, like: >=20 > version [0] VERSION DEFAULT v0, >=20 > VERSION ::=3D INTEGER { v0(0) } >=20 >=20 > This does not change the profile really afaik, but I believe this > explicitly limits the available options of 'version' to just 'v0', > i.e. an INTEGER with value 0. So, this may be a bit better in that > regard. >=20 The DER encoding would be unchanged using either definition. The primary difference is that any future change that required a version bump, but otherwise left the object structure unchanged, would have to publish an updated module. Similarly, an implementation strictly adhering to your version would be unable to process an object with a updated version number. It's hard to think of a change to the manifest spec that wouldn't end up touching the ASN.1 definition somehow, so in this context the above is probably moot. Cheers, Ben --gewml7ehbrs2d5ev Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmFXYv4ACgkQOkYk/rSL aGBegA/+O+JWza/2MZithGZSERcOC1aMZdfOKHJBuLFN5DtrMqjqLu02bOaurNyx 6mWYQEgO+2A0lOSvl51P8g/PS9Tg2rOrdYWxktjMAWEs6eomJ80m5Lx/9xChQk9l QRd+eYvUg4M32otJKtREm4XsHirRt0rMTWkXAP3bsVnDg/+iUoamsHrsy7ffLoUw g9rlUfJUetWVlF2hifkntdnpiLQxiKcP4tYFE6eYVOXi5pGLTFOiAZUucGwpQR5k a6DhwbrXxopYAhNDDwH/hyki1xPEFUhKwS8Mc3c4yKKbyvNXs0cvWh8za/dkwpQO Kn+XbfBkRjAYGYTadqUeMZOqXzECpruPAiTBs5GNqEbdeubA99M+ucQd4zn+ZpZ4 lA0/uEZUcelxYUI85xlhsV+9CnU38hQO5TarnwbEtTlnomWKEybrb/AOBO9VZK6c 0B60Ib9SiRCaOKWaqmeLaoaajM0DYh14K+72l+ZAAssJBN1EtEoRngLKX+WW3Xs0 VtAG9iKEjO7kqwwcv+eYD8J+DYMbLssKuSLmVukxkxSGyuTkci8OiBrmSzijggZG QOa9OPzCy0kkxKwc6v+9PyzTLzuDxQcP+98TSP1wnxzdSW2M3Kl6BqnjgR6eJDqz C6s6DMcLGezIayeth+foEoux3NGaFt91fuEGE7Bh7JOlY8h2kPg= =1/4E -----END PGP SIGNATURE----- --gewml7ehbrs2d5ev-- From nobody Tue Oct 5 09:35:47 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E91AE3A0922; Tue, 5 Oct 2021 09:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163345164383.29745.16829346804069846582@ietfa.amsl.com> Date: Tue, 05 Oct 2021 09:34:03 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 16:34:04 -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-08.txt Pages : 14 Date : 2021-10-05 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpkimaxlen-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 5 09:50:36 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88A53A0D5A for ; Tue, 5 Oct 2021 09:50:34 -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, 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 TEUrZH8YNhTQ for ; Tue, 5 Oct 2021 09:50:29 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2085.outbound.protection.outlook.com [40.107.22.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 5AD693A0D52 for ; Tue, 5 Oct 2021 09:50:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kUVTmQHz7cyoarCogSoKNcPYozATj3y8PDxGiTLFskzIEJgEsAb33hOvv2Xv6nzzP5W+t4PktwMZS9DICDZ6H5pPu2nHaSeG6CXf/iRtxdBwlkgcmYHC5Uwbjv1xokcct95C7IQ1cez0xgW2AsAPO5FXlN/AvRPAjcvF+8pT2hemh78rTc2y2VrxTS3BSpLL0knteIhCW1+pkALYgLc7+hGqHnQD1Kc3rQCDvPEUvoEjnBe/uj+Vn4GNdCzw02I3y8f7qz/T11F6xzLc/Q4KE8gxi6FMQzgKS8SEAE7ntvGcEJKD/I5fm2TfTxmeWTBwhbIAzVi+tS8BAsqlLkYKxg== 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=gj5xHFxj5zGyfnpjWf0cOf8D6/X4eLgZ3slxU7vA7xA=; b=GIugjGcg+vRqK5lvgNCyRyxAlpKVS1XHUQ+KUb7D6UHDIAG3z+IA10QXQvcK39aB83Qsayb1plCJR6SaO9S5syt+XDQLpsiBsy8345ZUrrj9LrXWLeyqkazuiPmXpvSgoAVwzBmp7nQsflQj1TH6ecJb85izHIpOLJ/Qw41GIf7GeBM9OKIOAPmM2CsyGo7Wd2dQ42r6LrpUbh2j+9finr6OVCjDQjc3tG8xrYPbCc0ODTuCP60f2ZPre5rweNqvxo6juBWLa5yZVapfRsVGbbHO+cOsNAkouHZYvKjvQME3xEmCvPDvB35D7kpq1t9eBhbhAF7nLywJ+LKbbVrKig== 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=gj5xHFxj5zGyfnpjWf0cOf8D6/X4eLgZ3slxU7vA7xA=; b=cY6NRBq89UEMB+wCHxlYf7eUQqKhNBig38O8TqEqQQPvtKbSqzUcYrWRTl6OWDXUiJRD+wskoQfrism4m0DiKKPGfeGk/Fv01zCRb6J1nWsit9aGJr0ELTJjAjll+4n//25Nx3sAuPQYJy+H3Cwb0AODGhoBadcy23gTchNMI+s= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AM5P190MB0513.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.19; Tue, 5 Oct 2021 16:50:23 +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.4566.022; Tue, 5 Oct 2021 16:50:23 +0000 Date: Tue, 5 Oct 2021 18:50:17 +0200 From: Ben Maddison To: sidrops@ietf.org Message-ID: <20211005165017.rnlnro6wupxfewmd@benm-laptop> References: <163345164383.29745.16829346804069846582@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f466ooo4ae3pwczv" Content-Disposition: inline In-Reply-To: <163345164383.29745.16829346804069846582@ietfa.amsl.com> X-ClientProxiedBy: CT2P275CA0016.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::28) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CT2P275CA0016.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15 via Frontend Transport; Tue, 5 Oct 2021 16:50:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a41ce76b-6cdc-427b-7e14-08d98820391f X-MS-TrafficTypeDiagnostic: AM5P190MB0513: X-Microsoft-Antispam-PRVS: 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: APchTjzgvEywi+hzjc58rxtXC5YvYo0alzBcit9nvGNDv+CFoJmCuXdpajhRnZUY/0Qg7XsxUj27JoEQ1m1OtpXCqxYLQyA/n4Z7BpvKV3IkQSOGq0KYbs+q7f9vNVa3ch9BsHk+p25hHdoub4+VoZxe6MRRrawInwp+bK+DzPz3GKXqtVGF7fai5vzMWTGQd1KnBw90ILZarDbhVjSZxdGhW1ZHGVaacXskc9RL7qyHKaAT6RFttMBdrtmWOWIuN0wrUWGa9ilC8O8QtAf+Y1e/dj97BfDfhyc5kUMcRMbe0ja2LbCEKa+9RHPVPSVcmc8Ixv6ATqvlp8kK7QogIrjovtAuhiLeH2wnhZUCJYZVu5dfyIVQ8VpJ8Vjt0LpgM/fXSzFjRf1nc1nJubHA+vK3Rx+NYUeMfn8q8YrnOKigrRRVtGHWDOEsdDw5h9epRGk1K/P/gJCL87f6F6+5vdwSIxmy/xKmGE8WOpYvWprF/lH2w3jBeoXtt8DJmMbKp9pf1l302uKRew5NysbiPZVvJX/rhE00mh2DCXkkiaH17as45amkBBrF29U4KcRZ9CnMlVw4L2/LshcRw9O/XXd7ddI2X5yCa59azbK3xr6zteXUSGHo22cw7g+FKMLnf+pultAh+A6ubnqJf5YfvkX7KpnG8bxr4O7vRRVzXS2dHJi8U41STeNLBRI2l69ApGNMA9k0bstmdJPArRoq3hMGX1FdzUvfPVXhZwbi2QzsW0cVEMVXAc0SbWDGh2kpgXBQl00wiHBL3Kdx01AgOg== 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)(346002)(396003)(136003)(366004)(39840400004)(6496006)(52116002)(6916009)(26005)(9686003)(2906002)(6666004)(21480400003)(44144004)(186003)(6486002)(66946007)(38350700002)(956004)(1076003)(508600001)(66556008)(33716001)(8676002)(66476007)(38100700002)(5660300002)(8936002)(316002)(86362001)(66574015)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?aQGxTqDanXujY2mxBsf/8qKP23y2SEbBgrMXScJ3G8JfLBeNtJ6nBouczlj1?= =?us-ascii?Q?LkHH4ZjK4X+UgEr5DCOCaxEODVXidcFSYcegoulguKz6Pv69ygw1kBP8MtjH?= =?us-ascii?Q?mTC46KG9hz4ts+7qTEYkZtdlhW7N7CRUtKxkkAmSB/8uEPUimQsmEXQXXIRM?= =?us-ascii?Q?GJxnFYKW43MBTcVaf4rnfb31cQ6gLp10e8rekqs0GwERTF3cSpz6f3sO8f5d?= =?us-ascii?Q?JdNm6SSlT+RegmEQGPvT5rUd4wN34/6VokLrUebBsQ+llK8608IkeXBwKLuA?= =?us-ascii?Q?s83uCDpc6ChKUMktIkNByrELA4JGMwZI2cb/BCd6p1KB/g+9JRjiTxeDVREN?= =?us-ascii?Q?3iHlCR5pqNXMTzHaHAKJi9WqYlyeRkcdcsMpBzFgOuAdMf6b5SI14fq7dR0A?= =?us-ascii?Q?1p8EXctYHikpZKpMpGS5Kbd8q+RCi1pX8WLCNmQ6aMdCBZykqFDp6R0EmgLq?= =?us-ascii?Q?9Z2QveKmQe3Eg2q/3Rx/0q32b+pwMdizawqxUBbtJozigZuwF61JRcD75jDy?= =?us-ascii?Q?i/cnyT1zXqANqG72zduxO+KeDr/3z3VqtoNBnFO6cGZzZP7UrHFh0GMSlh2V?= =?us-ascii?Q?2lxuSiCoj+XKlxG4q2pwEEX28TGZe1FMZC9GAaubV1JWzSHlU6EXQi5bCP4J?= =?us-ascii?Q?Co5uSiOjmgmGfZcjbidR0YyYWEqNNjUmFcgZN/8vEbQ7xjTqNOZaLRahOS0i?= =?us-ascii?Q?96OHlrkgmERf4LtsjjVzshlDEfDJtbSJWUyIL5OvxfriUO+WG1jBzK4hx4eR?= =?us-ascii?Q?vTKOpSn1+oKFhtVrIdo+DYQ7jF4dRT8AmXJopUUgVV3DrRHwNM1Cu0dCwiVd?= =?us-ascii?Q?rb6ap9uD+L3lzINoBQeJn9UPpxCp/IXBhi6hOrZ4ZqYFTBZ019xAJHU6w6NA?= =?us-ascii?Q?udATD60gsagBGe54PHSXCVul8wLQq6rtWR4xezr+i17LLaM2kvzkIVUGcS1Q?= =?us-ascii?Q?pWnA7ChZuFWPuMBtsnoeJHzYf9N9pY9W7nEuBsfkQhhhA9F7ns4rvKXHVeJ/?= =?us-ascii?Q?PZvA+peF/rmd0/JT/8T0kxGCuK2qd0mlNvuEp6yYEvLqW4EmkHmmgLCl2iR6?= =?us-ascii?Q?PiIvkIx/lxLNTK7m5Rb0Tq0pq0sKuCIMgta+bqz6I4851FpvFQ4098HDzMgs?= =?us-ascii?Q?z7eTtAAwlMuOBz8KeF2lt5za3uC2DA4YRFxhiUv5JV3W8Gtttp+kZhpA3Vkh?= =?us-ascii?Q?x/AMV9P1+2wvYdOLgzPz7B7VsOL9aPY04roH44LleO2l0hSdnaqhsO6Te0z3?= =?us-ascii?Q?FAOhko0YP8IGraZhZe7MrK475DD8akYRzgnAPAq7kxypei408C7ymCDU6NbY?= =?us-ascii?Q?SzubkguMVQbrzktQww6h+WVj?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: a41ce76b-6cdc-427b-7e14-08d98820391f X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2021 16:50:22.9257 (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: 0sI2Ygrj/8Rk4sqiPQUdeseiqBMJnTHAVdyOZuM4ek4Jt13l5iMSE74k1vmnn/UjkY4drn+5ROUyhKJABO6+Zg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0513 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 16:50:35 -0000 --f466ooo4ae3pwczv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, On 10/05, 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 As promised last week, this version adds a section (5.2) discussing the complications that may arise when an operator attempts to de-aggregate defensively in the face of an attack. Thanks again to Alexander for pointing out the issue. We believe that this is now ready for publication, and would like to ask for WGLC. Cheers, Ben --f466ooo4ae3pwczv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmFcgkgACgkQOkYk/rSL aGCYoxAAlK5sZK8QvP5eC6C1ShrcwKKTLr3Z9iXxt8tuKdOcgbQLc6muqQZRsyEx HAQfK2St/h8CA1E8WAOpL/+mysEqYgY4pDwq68b7tgLzgUXf2rAfU6kky3RD9QPI hb24WBkwk0/I1N1MTDBhD0f/9gbQ5iQugT1pqqxjGg/SVrcK8Lt8NughmQneApER BlsJsSo797hta4nMiP225Dwwv6vYTvGQvJPulnD4oPAxhw8XTGa1KeXL/BwCI/au SIxyvKR0fll+FqgymtnS2Re87RY2IZMmcIluTtstjQUa/6ypsJlKZaQUAZFSrsBs +TbjZs5qbxYsRnDjPwqoq6BwfAxuF6fokxpkxKbTQh91X3wJCCFVsiLTHUze7TWy pDWHyUtMF9m8VWRBjX93el4tif7A5XSVo37A0+8vszh+CycwdRRNcthE+QG0HDMk 73artGxejR31dfR62x9zENwR7tsApuTWkANvkSpkYcr86gXxLzCkN+TFS2QmWTVB aewCYYrKnRER8CjdyPOPRQul6Ncl2z0x1oWRIArUVVGmqSiIMVNYwWVKQNrB5r/7 WafCokFjMTJoqEpnvSR5CEbnNRknz6+15UKF1mAGpIragrij/YjYBa1WQblWFE5M IAoe12pSviB9MPymYZMDjV5ckx/xYwrh0Uy0iD9/TtNMBNco3vY= =KyLw -----END PGP SIGNATURE----- --f466ooo4ae3pwczv-- From nobody Tue Oct 5 23:52:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2A3A150D for ; Tue, 5 Oct 2021 23:52:45 -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 HQHRf6SNxg4t for ; Tue, 5 Oct 2021 23:52:39 -0700 (PDT) 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 612C93A0FD7 for ; Tue, 5 Oct 2021 23:52:38 -0700 (PDT) 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 0E82124C; Wed, 6 Oct 2021 06:52:33 +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=1633503151; bh=QeBNNO+0r+dc3w6Hzzp2xbaq82v5cgeCFq1djorvQvw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Iv6SlXvxECgVq3dVlZGjC+21bDW3euD89KU+TDnW0DcMU+W+DGP1HJZqV7GJHXDBV QA/6808mcrQ/skw+OHqWWORehI5AgFrdCJcuctCrIQa89l0hBIoJtGVN0L8t3Mpm7S UTGqkgbXMQ0Em6bRD8fDPKpXdGG9Hw5zIo2OuU9924JOTarAYEF/4dAGraEVUKdV1z zRo6mt7CsuTj63IiVEvYtvgEQxNlxePfa8NMeE7X1lFpfIhfyyoJyG6wdtaYaoyCNk UH9JJQrmYy8gVU/4VYN8vsYY1Wkpe+DbpN+pt8NpUKSNxcSPmBA8kryqSz0yOgzUoW gF1wMSxIgQ1kw== 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 In-Reply-To: Date: Wed, 6 Oct 2021 08:52:28 +0200 Cc: Ben Maddison , SIDR Operations WG , Steve Kent Content-Transfer-Encoding: quoted-printable Message-Id: <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> References: <162730591845.29690.12178353991713962835@ietfa.amsl.com> <2457bdd2-de07-241f-b8e4-87206dabcf16@verizon.net> <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> To: Russ Housley Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 06:52:46 -0000 Russ (and Ben): > On 1 Oct 2021, at 21:30, Russ Housley wrote: >=20 >=20 >=20 >> On Oct 1, 2021, at 2:47 AM, Tim Bruijnzeels wrote: >>=20 >> Hi, >>=20 >> I saw this: >>=20 >>> On 30 Sep 2021, at 23:11, Russ Housley wrote: >>>=20 >>> version [0] INTEGER DEFAULT 0, >>=20 >> This is how it was done, and also what the e.g. the ROA profile uses. >>=20 >> However, reading the ASPA profile I came across another way, like: >>=20 >> version [0] VERSION DEFAULT v0, >>=20 >> VERSION ::=3D INTEGER { v0(0) } >>=20 >>=20 >> This does not change the profile really afaik, but I believe this >> explicitly limits the available options of 'version' to just 'v0', >> i.e. an INTEGER with value 0. So, this may be a bit better in that >> regard. >=20 >=20 > Tim: >=20 > These produce the same bits on the wire. The difference is that the = various versions have names ifor each of the integer version values. In = that case, the name is "v0". >=20 > When v1 gets defined, the definition needs to be expanded to: >=20 > VERSION ::=3D INTEGER { v0(0), v1(1) } >=20 > For example, RFC 5652 has: >=20 > CMSVersion ::=3D INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) = } Indeed, I did not mean to suggest that the encoding would be different, = just that the set is limited. So, if there is a version change it would have to be expanded, but = presumably other properties would change as well - e.g. we would no = longer insist on the value being 0 in validation. So I am not sure that = this is an issue. In any case, I do not have any preference for one or the other but I = noticed that it's different between manifests and the proposed ASPA = profile. Plain 'INTEGER' is perfectly fine by me as well, but that does = make me wonder whether the ASPA profile should just use that as well. Tim >=20 >=20 > Russ From nobody Wed Oct 6 08:00:49 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F122C3A1D52 for ; Wed, 6 Oct 2021 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NHlyfoh1XLun for ; Wed, 6 Oct 2021 08:00:42 -0700 (PDT) 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 1498C3A1D42 for ; Wed, 6 Oct 2021 08:00:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C109D300C24 for ; Wed, 6 Oct 2021 11:00:42 -0400 (EDT) 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 S5_rXvrAa0rZ for ; Wed, 6 Oct 2021 11:00:40 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 15EFA3005D8; Wed, 6 Oct 2021 11:00:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> Date: Wed, 6 Oct 2021 11:00:37 -0400 Cc: Ben Maddison , SIDR Operations WG , Steve Kent Content-Transfer-Encoding: quoted-printable Message-Id: <90554F86-FA27-4364-B13D-BBE7CA4885B1@vigilsec.com> References: <162730591845.29690.12178353991713962835@ietfa.amsl.com> <2457bdd2-de07-241f-b8e4-87206dabcf16@verizon.net> <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:00:48 -0000 > On Oct 6, 2021, at 2:52 AM, Tim Bruijnzeels wrote: >=20 > Russ (and Ben): >=20 >> On 1 Oct 2021, at 21:30, Russ Housley wrote: >>=20 >>=20 >>=20 >>> On Oct 1, 2021, at 2:47 AM, Tim Bruijnzeels = wrote: >>>=20 >>> Hi, >>>=20 >>> I saw this: >>>=20 >>>> On 30 Sep 2021, at 23:11, Russ Housley = wrote: >>>>=20 >>>> version [0] INTEGER DEFAULT 0, >>>=20 >>> This is how it was done, and also what the e.g. the ROA profile = uses. >>>=20 >>> However, reading the ASPA profile I came across another way, like: >>>=20 >>> version [0] VERSION DEFAULT v0, >>>=20 >>> VERSION ::=3D INTEGER { v0(0) } >>>=20 >>>=20 >>> This does not change the profile really afaik, but I believe this >>> explicitly limits the available options of 'version' to just 'v0', >>> i.e. an INTEGER with value 0. So, this may be a bit better in that >>> regard. >>=20 >>=20 >> Tim: >>=20 >> These produce the same bits on the wire. The difference is that the = various versions have names ifor each of the integer version values. In = that case, the name is "v0". >>=20 >> When v1 gets defined, the definition needs to be expanded to: >>=20 >> VERSION ::=3D INTEGER { v0(0), v1(1) } >>=20 >> For example, RFC 5652 has: >>=20 >> CMSVersion ::=3D INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) = } >=20 > Indeed, I did not mean to suggest that the encoding would be = different, just that the set is limited. >=20 > So, if there is a version change it would have to be expanded, but = presumably other properties would change as well - e.g. we would no = longer insist on the value being 0 in validation. So I am not sure that = this is an issue. >=20 > In any case, I do not have any preference for one or the other but I = noticed that it's different between manifests and the proposed ASPA = profile. Plain 'INTEGER' is perfectly fine by me as well, but that does = make me wonder whether the ASPA profile should just use that as well. >=20 > Tim This is just a matter of style I think. Russ= From nobody Wed Oct 6 08:53:16 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613DC3A1E59 for ; Wed, 6 Oct 2021 08:53:14 -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 (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 GrvQhKCHsUT9 for ; Wed, 6 Oct 2021 08:53:10 -0700 (PDT) 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 0E8AF3A1E57 for ; Wed, 6 Oct 2021 08:53:09 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id d8so11596673edx.9 for ; Wed, 06 Oct 2021 08:53:09 -0700 (PDT) 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=ixSLPoqGA+TvQVDySL+jXS0AWb2YqPWx3Zk+HanebIU=; b=NZkucXlG2/GZCIU2KMLmwHT2d0+UW1WkPndub9/K11QHBax9oBPDfvUeGj6ViZH55C x9qqtGdncHkA4znGwBtxGSKsSxQstxpUHj37Ykvec1PR2OQMHF0jslyCy3jmoQdvAcB9 Uw2vYeVV/fDzwaO1T8oJQUxvcmiCuJlWlQq6o= 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=ixSLPoqGA+TvQVDySL+jXS0AWb2YqPWx3Zk+HanebIU=; b=EAMRKuTJD1mQBxK3rwLC3iOO+6xxMrmw6oNxQSGUkQb6mLPRTPFwhJUjkMWxsg+KP3 KjLNsy1fq82QS1HHVIgQjzRuUt5J/q4IHcP9mKrjkK8T4wMSrqAmMCWfaz6ELYwWkjT0 sovQcQQFI0FkL1bg5FIY8Gv/9Hzhq1nigTYHISDU1x85CHqnLHpNmacpMSR3p1E4kg/y WWlBMEosL8T78S7W0wWvv1g3MZ9Sx/Gpbd5K9dTCYpWr4WMYNBV0WdV/ZQ5FOPmDwhlW r1g5hLj3cVIN45CswidICbJjHlRemnrfm6YUanD59Afb/zB7IC32T+RQB4eFf3FtM2AM PJyA== X-Gm-Message-State: AOAM533nyxynX1ZaW05q+XVsUFlWchQcK0576yFkrwZNY9OsSIPu3BRa 88U5P/MNNqQ1sFKpaoGcqYS3rEdWaEKzrUkQ X-Google-Smtp-Source: ABdhPJwG6EPNw3Hh4p4PjI0UWcTLZ1Ch1k8232hvBNVcjqTQcsE479qyRmk3ZvM3PgIQV9DrJW6wyw== X-Received: by 2002:a17:906:7217:: with SMTP id m23mr32475931ejk.466.1633535587650; Wed, 06 Oct 2021 08:53:07 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id v13sm3258163ede.79.2021.10.06.08.53.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Oct 2021 08:53:07 -0700 (PDT) Date: Wed, 6 Oct 2021 17:53:05 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: Russ Housley , Ben Maddison , SIDR Operations WG , Steve Kent Message-ID: References: <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:53:15 -0000 On Wed, Oct 06, 2021 at 08:52:28AM +0200, Tim Bruijnzeels wrote: > So, if there is a version change it would have to be expanded, but > presumably other properties would change as well - e.g. we would no > longer insist on the value being 0 in validation. So I am not sure > that this is an issue. In case you are not aware, from X.690, section 11.5: "The encoding of a set value or a sequence value shall not include an encoding for any component value which is equal to its default value." In order words: when validating, you have to check that the 0 value is NOT present (if one is validating an object according to the version 0 profile). Kind regards, Job From nobody Thu Oct 7 10:26:24 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A302F3A0C99; Thu, 7 Oct 2021 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 2rE8XUOPMq48; Thu, 7 Oct 2021 10:26:18 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 E5D913A0C98; Thu, 7 Oct 2021 10:26:17 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id z24so2175313qtv.9; Thu, 07 Oct 2021 10:26:17 -0700 (PDT) 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; bh=6mV9xYfkSAYLQA94jEr/kqMS2m9wwC85d6JvTYIGMT8=; b=X7rPT6uc3ZxJ3iBT1Za8anrB64ZiHrEfOCp5Eddu+UPaMAefqU6lyCp8mb5hGhv2mI 0GZZn7L/hJa+PChe9t87EGzb0wTWoJBgr8IFMU6RvVDpZaczDEjECmCKR9TVAKUULHCU j0tp0ya1Ftuz4usIeHEXWBqY1XTYjYkE/5oQIfYJRH90TDVEnAn5qg1lTzbMkduPW8mb rtX/WTGQB2Az/IGb+Jp4XU0CFqMmyY6jGynXd1rjMDEwhHJuRgInQCT2XfDJoFbxq7nk 2QIRdoe+8Y/9D9lNwYzyTm5yJh/OEpkCWV6cMIsiRT9kxeMO2VAZglfeEcSuKFrar+bv h/rg== 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; bh=6mV9xYfkSAYLQA94jEr/kqMS2m9wwC85d6JvTYIGMT8=; b=Ga4ZSeoOaaJhemKdwmVIe6Bi1Wv9473chwACgUFegBWW54ddmAKzj24Tp7uzx/sO6G GLztmUIjgdBjk0Gp/WdbCaTh04+usbnQZfprtdW4t3Dv1b+UPHSw9CxOty1T3/6jBQJZ nB5TtrnK4tOGM+bLNt3sDlKWxg2ytos/HjG/e6RqOpjVCY91hSErfixIPHQbii3t5wMn 1lvvNZfT8PBvpkEtynWmAo6bOlkH5XZ3Y6GiuTOzOciEXyQGH/iu0xyKK0TOKcUxmu6F 1nSxCLgshjbYeBTgah/6b83c6yw7NDz2QW64+p6WI1Em9tONo/R1iXUVYEXDSwLqb2C6 nJZA== X-Gm-Message-State: AOAM532BMyaZIkZ6czOS2bWaBLKOkdnNkyCsP5cfj0U2ibtQiBmvdZlT +BJk/t0MACB71+n2HvB/6+lE5kiS3MzZgYrG/IStjY7ZpxM= X-Google-Smtp-Source: ABdhPJwyatI/hIpbp6x70t1CU5gn23QDlTxfXKH7IDuNsxHT9BkqWEuslAK9v2Nf8UMfzo0S9skOL35FF9OGGeTO8Ig= X-Received: by 2002:ac8:4314:: with SMTP id z20mr4129649qtm.317.1633627575054; Thu, 07 Oct 2021 10:26:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Thu, 7 Oct 2021 13:26:04 -0400 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="0000000000004e8a1005cdc68f00" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 17:26:23 -0000 --0000000000004e8a1005cdc68f00 Content-Type: text/plain; charset="UTF-8" howdy folks! This got some discussion before this WGLC message ,but none here... So.. all good? stop? start? restart? dance around a tree? comments on direction for this WGLC would be .. good :) -chris On Fri, Sep 24, 2021 at 1:58 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > WG Folks: > Please take this as a WGLC start for: > draft-ietf-sidrops-6486bis > > The abstract of such is: > "This document defines a "manifest" for use in the Resource Public Key > Infrastructure (RPKI). A manifest is a signed object (file) that > contains a listing of all the signed objects (files) in the > repository publication point (directory) associated with an authority > responsible for publishing in the repository. For each certificate, > Certificate Revocation List (CRL), or other type of signed objects > issued by the authority that are published at this repository > publication point, the manifest contains both the name of the file > containing the object and a hash of the file content. Manifests are > intended to enable a relying party (RP) to detect certain forms of > attacks against a repository. Specifically, if an RP checks a > manifest's contents against the signed objects retrieved from a > repository publication point, then the RP can detect "stale" (valid) > data and deletion of signed objects." > > The WGLC should finish on/about 10/11/2021 - Oct 11, 2021... There's > already one question/comment on-list for this WGLC a pointer to which is: > > https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc > > Please give the -06 version of the document a read/comment and if you have > opinions(about this document!) please express them on-list before Oct 11, > 2021 (10/11/2021) > > -chris > co-chair-persona > --0000000000004e8a1005cdc68f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
howdy folks!
This got some discussion before=C2=A0this = WGLC message ,but none here...

So.. all good? stop? start? restart?=
dance around a tree? comments on direction for this WGLC would b= e .. good :)

-chris

On Fri, Sep 24, 2021 at 1= :58 PM Christopher Morrow <christopher.morrow@gmail.com> wrote:
WG Folks:
Please take= this as a WGLC start for:
=C2=A0=C2=A0draft-ietf-sidrops-6486bis
<= div>
The abstract of such is:
=C2=A0 "This document d= efines a "manifest" for use in the Resource Public Key
=C2= =A0 =C2=A0Infrastructure (RPKI).=C2=A0 A manifest is a signed object (file)= that
=C2=A0 =C2=A0contains a listing of all the signed objects (files) = in the
=C2=A0 =C2=A0repository publication point (directory) associated = with an authority
=C2=A0 =C2=A0responsible for publishing in the reposit= ory.=C2=A0 For each certificate,
=C2=A0 =C2=A0Certificate Revocation Lis= t (CRL), or other type of signed objects
=C2=A0 =C2=A0issued by the auth= ority that are published at this repository
=C2=A0 =C2=A0publication poi= nt, the manifest contains both the name of the file
=C2=A0 =C2=A0contain= ing the object and a hash of the file content.=C2=A0 Manifests are
=C2= =A0 =C2=A0intended to enable a relying party (RP) to detect certain forms o= f
=C2=A0 =C2=A0attacks against a repository.=C2=A0 Specifically, if an R= P checks a
=C2=A0 =C2=A0manifest's contents against the signed objec= ts retrieved from a
=C2=A0 =C2=A0repository publication point, then the = RP can detect "stale" (valid)
=C2=A0 =C2=A0data and deletion o= f signed objects."

The WGLC should finish on/about = 10/11/2021 - Oct 11, 2021... There's already one question/comment on-li= st for this WGLC a pointer to which is:
=C2=A0=C2=A0https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516K= dg35Amc

Please give the -06 version of the doc= ument a read/comment and if you have opinions(about this document!) please = express them on-list before Oct 11, 2021 (10/11/2021)

<= div>-chris
co-chair-persona
--0000000000004e8a1005cdc68f00-- From nobody Thu Oct 7 10:38:28 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91A43A0F35 for ; Thu, 7 Oct 2021 10:38:19 -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 (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 iKve4Oe9ynMj for ; Thu, 7 Oct 2021 10:38:11 -0700 (PDT) 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 678803A0D5F for ; Thu, 7 Oct 2021 10:38:00 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id v18so26291509edc.11 for ; Thu, 07 Oct 2021 10:38:00 -0700 (PDT) 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=f13SNNVxWHHcFC5HPt3QYOoMG7lfPZdWfwSyA6RwsLw=; b=SdWWzE3wrBAJ/b6nKw0+zN1PKRvL7DbR6mp8FT2rE2mys8uwyEc2E8O8gRjBgxdaho 5wPJU40LJWGjHg7ojKtraAYACZj0CQQzJqTQUrx2gJYA8X/7DFoMcU/UqMg4yCuQlEaR 52rnKeBut7xN+2wOAgPP2IuGeGvi+BSmUGSnI= 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=f13SNNVxWHHcFC5HPt3QYOoMG7lfPZdWfwSyA6RwsLw=; b=8EVpbUgbCCGKg45Q7z6TxgQNURIQh5+ufBng6LyBSW6E1jbx45Clz40qK3fnSL394h ESjoZD79qXfftHt+YVV7EdBqO1bk4jVw5juyXC4m4TYEZwuHM4NyS+obeyxCBObFDl/o V2d6ZS6HY6tUk4TZfpr/AuIbJhSl+40MXsP8M+jIvoHJjo6Ifu8mydN7DT7iaRznjjMO VrKGmug7Sn5DEEF+zvv4pm4Hje4pGT3M7l1hfvuRrcNrkkQNK7EK3N5U/faGKw7eucJX /ZQgkeey7KIFPxeJEHT1hO0PG/FvYLLmuj43kPgxkBwZ9VbVDF7x0A0bqeFLrXBHSTfF wrdg== X-Gm-Message-State: AOAM532o/u1OKe5Cz//i/Pk2gJc5cJDA5lxtl301rI5DXe0zsrYKlMV2 fI4St8SrJnDoD2FlC800nF8o7w== X-Google-Smtp-Source: ABdhPJz5Zq7RwbX+IUOUv1CRGcx34PAoOGxQ76eMF/XnkW+Ys8gY51FkDFHhbSCH8iCu85ZWvSb4iw== X-Received: by 2002:a50:8405:: with SMTP id 5mr7798978edp.111.1633628277226; Thu, 07 Oct 2021 10:37:57 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id e7sm49305edk.3.2021.10.07.10.37.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 10:37:56 -0700 (PDT) Date: Thu, 7 Oct 2021 19:37:55 +0200 From: Job Snijders To: Christopher Morrow Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 17:38:25 -0000 Hi, On Thu, Oct 07, 2021 at 01:26:04PM -0400, Christopher Morrow wrote: > This got some discussion before this WGLC message ,but none here... > > So.. all good? stop? start? restart? All good. I'd like for the document to progress to the next stage. Might also be a good time for people to double check their implementation's behaviour in context of each uppercase normative term. https://trac.ietf.org/trac/sidrops/wiki/ManifestBisImplementations Kind regards, Job From nobody Thu Oct 7 12:23:45 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D57E3A0D1C; Thu, 7 Oct 2021 12:23:37 -0700 (PDT) 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 BrCBFLlKjQCf; Thu, 7 Oct 2021 12:23:36 -0700 (PDT) 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 109833A0DD5; Thu, 7 Oct 2021 12:23:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mYYzN-0001BP-Bm; Thu, 07 Oct 2021 19:23:33 +0000 Date: Thu, 07 Oct 2021 12:23:32 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org In-Reply-To: References: 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: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 19:23:38 -0000 > So.. all good? stop? start? restart? > dance around a tree? comments on direction for this WGLC would be > .. good :) there has been wiggling and back and forth. i would ask steve and russ if they feel change was significant enough to rewind. randy From nobody Thu Oct 7 12:44:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043C33A0E24 for ; Thu, 7 Oct 2021 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 TmX9jMTMSCrX for ; Thu, 7 Oct 2021 12:44:19 -0700 (PDT) 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 9CC3E3A0E00 for ; Thu, 7 Oct 2021 12:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 62A4B300C5D for ; Thu, 7 Oct 2021 15:44:20 -0400 (EDT) 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 Wx594FqT3a7f for ; Thu, 7 Oct 2021 15:44:17 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6FF77300BE1; Thu, 7 Oct 2021 15:44:17 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_472FF407-E4FE-4A18-B84E-16B19DBC055C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Thu, 7 Oct 2021 15:44:14 -0400 In-Reply-To: Cc: Christopher Morrow , SIDROps Chairs , SIDR Operations WG , sidrops-ads@ietf.org To: Randy Bush References: X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 19:44:35 -0000 --Apple-Mail=_472FF407-E4FE-4A18-B84E-16B19DBC055C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 7, 2021, at 3:23 PM, Randy Bush wrote: >=20 >> So.. all good? stop? start? restart? >> dance around a tree? comments on direction for this WGLC would be >> .. good :) >=20 > there has been wiggling and back and forth. i would ask steve and = russ > if they feel change was significant enough to rewind. Please excuse th e use of non-ASCII below, but it seems the easiest way = to convey the point... To me, the changes to these three paragraphs justify moving forward with = this document. The CA MAY choose to MUST sign only one manifest with each generated = private key, and MUST generate a new key pair for each new version of the manifest. This form of use of the associated EE certificate is termed a "one-time-use" EE certificate.certificate.[RFC6487] 2. Issue an EE certificate for this key pair. The CA MUST revoke the EE certificate used for the manifest being replaced. An authority MUST issue a new manifest in conjunction with the finalization of changes made to objects in the publication point. An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD MUST implement some form of repository update procedure that mitigates, to the extent possible, the risk that RPs that are performing retrieval operations on the repository are exposed to inconsistent, transient, intermediate states during updates to the repository publication point (directory) and the associated manifest. --Apple-Mail=_472FF407-E4FE-4A18-B84E-16B19DBC055C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 7, 2021, at 3:23 PM, Randy Bush <randy@psg.com> = wrote:

So.. all good? stop? = start? restart?
dance around a tree? comments on direction = for this WGLC would be
.. good :)

there has been wiggling and back = and forth.  i would ask steve and russ
if they feel = change was significant enough to rewind.


Please excuse th e = use of non-ASCII below, but it seems the easiest way to convey the = point...

To me, the = changes to these three paragraphs justify moving forward with this = document.
   The CA MAY choose to =
MUST =
sign only one manifest with each generated private key,
   and MUST generate a new key pair for each new =
version of the
   manifest.  This form of use of the associated EE certificate is
   termed a "one-time-use" EE certificate.certificate.[RFC6487]

   2.  Issue =
an EE certificate for this key pair.  The CA MUST revoke
       the EE certificate used for the manifest being =
replaced.

   An authority =
MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.  An
   authority MAY perform a number of object operations on a publication
   repository within the scope of a repository change before issuing a
   single manifest that covers all the operations within the scope of
   this change.  Repository operators SHOULD MUST implement some form of
   repository update procedure that mitigates, to the extent possible,
   the risk that RPs that are performing retrieval operations on the
   repository are exposed to inconsistent, transient, intermediate
   states during updates to the repository publication point (directory)
   and the associated manifest.


= --Apple-Mail=_472FF407-E4FE-4A18-B84E-16B19DBC055C-- From nobody Fri Oct 8 00:53:57 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ECF3A1429 for ; Fri, 8 Oct 2021 00:53:54 -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, 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 i_PMqGeGkT-r for ; Fri, 8 Oct 2021 00:53:48 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (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 B30043A142B for ; Fri, 8 Oct 2021 00:53:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jnRVVWYnetRs2uOA7UDb4Ilt3Sch4R381EfUeWW8OtaXa6n5eDCHYLEeId3CWtScEm/doI33gNUf4/iALoXECO8jmRAmzEdmRJXwT3rl4+69XUszaVEmzzpbPNKAcPuS9nyjj/XayLXBkkafQRuk63gYf/GK2eBJkMeZZhTCXXzaueKeLdGgaxbmp5whRgsgU3VyvUeJQ8VxTjRuEy4Rk63J1E2jMII0NdnGYjxz3ump80HHOMeD09pItnXPhsv2a3awj+iqsJfnxNs9DuAKwks11FRd9C/qzUVqTwjXVKiuNOeSQtJ9KNvP9rJ5gz0wgrlqN4Sy/z82lC9j19tuZw== 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=9kIUfbErM6wLpCtQXACzz5bwBGSfD1B5Awn14uu9kEQ=; b=AKSEu+lj8ceoeDRp/WlTuNOQUheBtueEjG/evdFzACAKzV7eF9TkyLSWsC5+yPx+IlJHFJ4j/g4pylFrvLo124JYvfWPhVE6rW/7Q+JyjuZY0Pf4TPYbMYqnEZZS/i8OlkDJ3yU5Ah/29BY/0V3elgaVpLHfTgAMPuZQGwfxgPnZOE5UTSJ3gsmWfh11qkItlg3kD7SoxyC1DnLDrZUZIIyKQDYJLhoCaQ6p6kPIysUxYORprjTC7HgkStv2GJN1Qj1UP2hg+14D/H9cIe5eJX+XNUNxpEACegYfJ7HxONwj+UP5lfRhxlL8M/wIyP7hfcotqazyzRrydN2ZaZy49w== 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=9kIUfbErM6wLpCtQXACzz5bwBGSfD1B5Awn14uu9kEQ=; b=T1ra+YRqlw5cttjEIXkCCwIPsPVq0nIHYnCMVx+JmQGz41g0sQajyFoZ2giNudlRzlEOUvW+/noW3jir8G75q3i8n8UV+zDncY9H2kUklKOAGcXcKaJs9U1kZWAsXVuWqN6wIZ5pWv5/OZO7CTIdSVNNiDRcTCP1omn8nrY/m7s= Authentication-Results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1526.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3fb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Fri, 8 Oct 2021 07:53:39 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%7]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 07:53:39 +0000 Date: Fri, 8 Oct 2021 09:53:33 +0200 From: Ben Maddison To: Russ Housley Cc: Tim Bruijnzeels , SIDR Operations WG , Steve Kent Message-ID: <20211008075333.muhym3dbscuqmafu@benm-laptop> References: <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> <90554F86-FA27-4364-B13D-BBE7CA4885B1@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3xuwbugqwyjgcliq" Content-Disposition: inline In-Reply-To: <90554F86-FA27-4364-B13D-BBE7CA4885B1@vigilsec.com> X-ClientProxiedBy: CTXP275CA0019.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::31) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (160.119.236.41) by CTXP275CA0019.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Fri, 8 Oct 2021 07:53:38 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3a38cf97-3f97-4463-8b87-08d98a30bd38 X-MS-TrafficTypeDiagnostic: AS8P190MB1526: X-Microsoft-Antispam-PRVS: 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: AKUnh/W1wdnDpnvAP16urAnRxr6KiMsCnHeX4MsiorgmMiAI135G/AtXnSLaJv7Xt6Qxt/HfRbGvM9Gm080y+6spIaJO08qD5IL9dTJ27enEGxL03jRv8L4Su02hltDEz/3JNAdFR4c6t/GINl4wg5+SGIRQ2+Pk0M+pqyvgW3Q8FcS5F1Ggp2XkhpZG035ukk+jvrQ+L5QBdyBlhwWtX0AHWl9WhuFVLfEL4Fk62imEUxL1n9L2GHRCiFfVxL64x/t4peU0WQFx/nr7fVehDz3/KQWNgu9iMxJHCaCk6+7WBKMvGRYF9jkjXLcOiiHlQ4x7ATfRW03wQKlcPvMUEyv48bWcfV/orkUmEeOKUqaxqFszVVvG+CTeLHuY0b0o4Ii5CITZdqSvrrIRSPhIY20Pw7eXNEChRNdoSKj/TDOProwNwQT4DbXqMbvFHIN888LB0TbyUTTz/6kUsuJfQRGDibW8x9FWcwJ7bhb7CSPBnj871N7ayPpCG2cVFrtmIDtWQm5f21zuWPQnHoy0Mf9lWWROWgEsQuAq5IqEKj7541wXVkq2jbcbH4qS5JdX3H9w61AMu/pGNUohpXv/hVtT3BxBByECRxB6w9wbG4SB9zXN4zQCMvgfE+6juLm0tpdtpcclgGQ7arfv6muhgb3xv9lp3JeNs9eoO1R55c2mJJqJsMGvBmPFnTyVDazRblu9cWCNO1VvBrnCN5DAvJlySl5ZLqkzz7YMBC+7r3SKDq/qtCCgkolU8pyPlcDhVF+NW9BzIYM4NrUBsj9dRg== 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)(39830400003)(136003)(366004)(396003)(346002)(6496006)(9686003)(66556008)(186003)(66946007)(66476007)(33716001)(5660300002)(956004)(508600001)(316002)(54906003)(1076003)(44144004)(21480400003)(6916009)(52116002)(6666004)(2906002)(38100700002)(38350700002)(6486002)(86362001)(4326008)(26005)(83380400001)(8676002)(8936002)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xMmRISarrrx+kisQ76RpctNn+r2rWewvPO+DAWSgtiarJtpB6DgmqUDynQGE?= =?us-ascii?Q?5RjP61GXUHRGEw+RDQIv9AVkFe2hPEZBhxOQ6uBZxk18COgL9WNl79m9oVgD?= =?us-ascii?Q?C1EOrxIifvxDwtyiwMllxM/kp6ruGkaPZShvQXSKj2b8V0e/defj1lehhKjg?= =?us-ascii?Q?SPsd/suPl6B3YRe28Ewl0nIL97xZZlWpsiK7KpHJBywYEVZ+TrRUFYMJgpbE?= =?us-ascii?Q?IWSqU1x757UQ3Blvx1eMHXLFK+DvdDKkyYXPbFVnh6q771rh5CNBE604/MH6?= =?us-ascii?Q?KXO7dq1k0ntJ38FJM7rSZMVOn/p9SOtwstrUf+zjX8M+ZhCskExFCZLUbRV1?= =?us-ascii?Q?MZR9fpqZebcYGhTOrysijsxmwBaVreofYAQ2nf0H1QuQ/EqwZijGQs/aHpgd?= =?us-ascii?Q?tKHPoQJLT7ez/mYrT9WbU2Zbi4KOs8xiysOONrB8FZPF0H1pHxeMI7HDUc7A?= =?us-ascii?Q?AshXxfW+jBxC4SbDraDo75/gM6LwsURV1bxm15NIUW7UBjBQuLKOOi2nlX0/?= =?us-ascii?Q?XNec5YkVzYQ5Mjp94jdLCjdZo7ZSC4njzeKYphPvn7HLyDfglSO4HcTTw/9b?= =?us-ascii?Q?CN268Nb6QRlqtLNh8EIHULYd2XiNwi12lB7d7opSXmlMEQjgFVL0hNgnTHd5?= =?us-ascii?Q?08ZzF/5waSe72BsDREgIgZlrf3cyaoZ40sK+S0V2ojawJ2D/CdCzknJAE2eN?= =?us-ascii?Q?VHDGOdKGwthcx45INrMtiS7oDavBTUkC28Sy4uhGPv0T2BF5nRF/409i4XVJ?= =?us-ascii?Q?gH8TIWvxNUrr8NnMbAkvvyDtnr5sz6YwRqNZmywstxmdRYUg8z5LyVrLmmMw?= =?us-ascii?Q?LUq8XDhd1QLzt6oUKQszHLFe/zcNdQ4CY2fg7/fDhnLC2O7+RQg2EaMZT9HO?= =?us-ascii?Q?pij1ntIyT+ZHeLOcY6KdxuDdz/IoD0s1IIOhRU9892C2WK4SA4Zr/PSqfPmm?= =?us-ascii?Q?cCw/qDGQAhzBWjwxaa+UguR7JAl3RMLnjleBXhbN4mmW/4AiOOkbh0z1bQ4K?= =?us-ascii?Q?fYD4m11q3aDTEtgK0dp7K/gxG9XPjFYKEP3A1tTBzw4MqsK8k2nUJtvRyezA?= =?us-ascii?Q?qc4OQXRXV6EjnuhjN9iN7txhJgpXPvLtTK4q07PH5hwOKZSbzBLcSGXecTnB?= =?us-ascii?Q?4JP6YmgyFRZshPGKHmIPzfUgroA01N6AA6w9l7OY3fGZqsVqcRQNi7grD2jv?= =?us-ascii?Q?8JNjTrAmjP78f+UFs8IPLw9X5MJz/10OrVSLtBnAV+soEz0zAWfSM0oQftob?= =?us-ascii?Q?Ax1QkOF3xHKltX4p0mA7R2OCoe4KY1jE7NaP5L5+aAasGvwOgCo+29Qsy293?= =?us-ascii?Q?rx+ReA/ZTROY8mnawumETrMM?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 3a38cf97-3f97-4463-8b87-08d98a30bd38 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2021 07:53:39.0325 (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: +wzYp1TGvHJ8z+QmMtKvliOe2o3wKbfQVBayYqFuQmlh6tNYBjuoyuU147oOYuRDMxDxs43dIxfCJWKnD2IXAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1526 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 07:53:55 -0000 --3xuwbugqwyjgcliq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Russ, Tim, On 10/06, Russ Housley wrote: >=20 > >=20 > This is just a matter of style I think. >=20 I've been thinking about this some more, and actually I think that this choice *is* important when considering asn1 -> code compiler friendliness. Consider: Foo ::=3D SEQUENCE { bar Bar, baz Baz, qux INTEGER } Bar ::=3D INTEGER Baz ::=3D INTEGER { a(0), b(1), c(2) } Compiling this to (for the sake of example) rust would be expected to produce something like: struct Foo { bar: Bar, baz: Baz, qux: usize, } struct Bar(usize); enum Baz { a =3D 0, b, c, } Of course other language type systems have more-or-less direct parallels. Each has advantages and disadvantages: - the "qux" style can be used directly as an integer with no additional work, but you get no safeguards from the type system to prevent using a bare integer where you expected a "qux" value; - the "baz" style gives the type system the ability to distinguish Baz integers from other integers, at the expense of some extra work to define the operations on Baz types that are permitted; and - the "bar" style is not usable as an integer at all (at least not conveniently). The integer value is just there to distinguish the variants in memory. I think this leads to the following general guidance: 1. Use a bare INTEGER ("qux"-style) for unit-less, context-less integer values, that can be sensibly combined in an operation with any other integer value. This seems to be rare in practise to me, so should probably be limited to situations where simplicity is more important than correctness. 2. Use a named type of type INTEGER ("bar"-style) for numbers that can be combined or compared with other numbers of a particular type. For example: bob.age !=3D sue.age # makes sense bob.height + sue.shoe_size # probably a bug! 3. Use enumerations ("baz"-style) when the *only* sensible operation that exists on the underlying numbers is equality comparison. In the present case, I would suggest that the 'version' field falls under category #2, since `foo.version < bar.version` could make sense in some situations. So, I would suggest: Manifest ::=3D SEQUENCE { version [0] Version DEFAULT 0, ... } Version ::=3D INTEGER Note that this is orthogonal to whether we explicitly limit the permitted value to 0, which can be done in any of the three schemes. I have no particular view on whether that is a good idea or not. Cheers, Ben --3xuwbugqwyjgcliq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmFf+P0ACgkQOkYk/rSL aGD2lA//Swi8xmYOp36CUIMY96q/h+qpt97yev7xrP6JX+P/hpKC+unX96XpbHPX cQN+n5GjpFpuZ8Io732Fr4K6RQCtKN0/avt9LDxulljjCremMTPTSVh2aGjHHNG9 eoZqq5yKw/xSrJCkLFOJhnt5Vm5MgGdey03EH24UB4ifa2Dq1V6MdYru+XaRbSnX gGLaU1o/f0qZN3m8kgG7itj9Xbf2iwX+LVysrhlRziQVuxKJGos85EoEllz4hhHW bZyAdxV5gJA6xPCwLgZY+NdrRb09zsScHtj6tPWU9pqaYDFe2DDF6plzAqSx2OLL b79/DosZWMtGs8V9we/22kvbnOh+6Zy6plRn718O4UNWNoKd2PkvNSG6KopWbW6r oGMBTvlXtw8mpRfi9txFkPU8mLpLpt656h9DUv+BnwSCXOQPp7AHauQ8XlmT6ufF fJNzlKmrlgSu8rBASWBct1Z38TPtNRA2tZ/XWdRuwUTplfIevuhib+H6UQCnFdN5 H/hoNHGc1pzUde/JUd+sUS08Ti5x8uRqQZFL946rgTEFMAAYSSV9SZxg1Hrf6aq3 clHo3x1nv7UvKjxn4Lt9/BzODrQLTkr5RmY7DQxDufXhZmXoESz7eOyApkgmrzZ/ tUWeSgP29WWvgNxqihxK5LOrX35tNU8Aon049azoel6siQVe7sA= =p3jB -----END PGP SIGNATURE----- --3xuwbugqwyjgcliq-- From nobody Fri Oct 8 00:59:57 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438443A1468; Fri, 8 Oct 2021 00:59:54 -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 Tpxo7REJtULQ; Fri, 8 Oct 2021 00:59:49 -0700 (PDT) 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 467013A1465; Fri, 8 Oct 2021 00:59:45 -0700 (PDT) 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 940E9187; Fri, 8 Oct 2021 07:59:33 +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=1633679971; bh=vXsWxYQtaRh+WezmJrf2sXo2ts33gy7EmgrKZt9c2mo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=E4r5/c+7U4WjCHC7avIoiUcbrlqOKplblwqsc7jF1ox6XcWT9PaPMsPLhwgKR2jP2 J9YlQG8wlAWjy0QsV1FTupizcM/sn+VDJ9uC9UH7l6FrhI0gdYJ+cTRe3fkxA0hyeY +hJZGKT0C/iGP5UH5TxDi+TO0BSfZ+DEklwOC7qohYwKs7CrzngNObDaGgRM+HI2qz kMtuwPOSQHMlceyC70DLjvVjGL47f8S6A0qROvgGEzOsq7Rn2UMPFdkqk6ktm/v7is HIWDTxeZAZ31aqUezoRlKx4F5YlcpFPKoqQpJc4SUJ+vpXD+FoI6dFBO2yfz7sLHJ6 QPrc5xiWCxV9g== 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 In-Reply-To: Date: Fri, 8 Oct 2021 09:59:26 +0200 Cc: Randy Bush , SIDROps Chairs , Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Russ Housley Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 07:59:54 -0000 =10Hi Russ, all, =46rom my perspective there is no need to rewind. I am fine with the = changes suggested by Russ. There is one other thing though. I suggested that we consider including = text that says that all removed, or replaced objects are revoked (if they are = of a kind that can be revoked, i.e. not CRLs): = https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc/= My feeling from responses was that people are fine with it - and that it = is inline with the requirement to revoke replaced manifests, but this is = not my call to make.=20 Tim > On 7 Oct 2021, at 21:44, Russ Housley wrote: >=20 >=20 >=20 >> On Oct 7, 2021, at 3:23 PM, Randy Bush wrote: >>=20 >>> So.. all good? stop? start? restart? >>> dance around a tree? comments on direction for this WGLC would be >>> .. good :) >>=20 >> there has been wiggling and back and forth. i would ask steve and = russ >> if they feel change was significant enough to rewind. >=20 >=20 > Please excuse th e use of non-ASCII below, but it seems the easiest = way to convey the point... >=20 > To me, the changes to these three paragraphs justify moving forward = with this document. > The CA MAY choose to MUST > sign only one manifest with each generated private key, > and=20 > MUST > generate a new key pair for each new version of the > manifest. This form of use of the associated EE certificate is > termed a "one-time-use" EE=20 > certificate.certificate.[RFC6487] >=20 > 2. Issue an EE certificate for this key pair. =20 > The CA MUST revoke > the EE certificate used for the manifest being replaced. >=20 >=20 > An authority MUST issue a new manifest in conjunction with the > finalization of changes made to objects in the publication point. = An > authority MAY perform a number of object operations on a = publication > repository within the scope of a repository change before issuing a > single manifest that covers all the operations within the scope of > this change. Repository operators=20 > SHOULD MUST > implement some form of > repository update procedure that mitigates, to the extent possible, > the risk that RPs that are performing retrieval operations on the > repository are exposed to inconsistent, transient, intermediate > states during updates to the repository publication point = (directory) > and the associated manifest. >=20 >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 8 05:47:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6313A16FE for ; Fri, 8 Oct 2021 05:47:44 -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 (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 dZfNgC4XuN6r for ; Fri, 8 Oct 2021 05:47:40 -0700 (PDT) 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 4852A3A16FC for ; Fri, 8 Oct 2021 05:47:40 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id t16so14124414eds.9 for ; Fri, 08 Oct 2021 05:47:40 -0700 (PDT) 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=m66pZ6BuvZIui7UbA8sKjh09cGYz+mo+baSYHsqMq8Q=; b=l4sdZRNjuq8ozcjDkzZd23TVb6b06G2NIEiOZr6TC5y+Lr2DD0rjRI9Z/JUcYltSq9 2gcZUHBiBZxwhplZWG7wzlwLpTmL8drDH/BzqaE9db5hMj4EwbRYaie651lE0S6OxZJW a5DA3iGLZF2n/gWgxZ34UDDsYBO5XeDesvlK8= 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=m66pZ6BuvZIui7UbA8sKjh09cGYz+mo+baSYHsqMq8Q=; b=KB6AuJFFs0d7KmnSsufEmWrnd0tjSbY4qzN246qoTevOufxO/42JS8WUwRhr3IOno+ ZcZ73c61SLe41sHfp467A2qiDUe6xiNkDcisinhc0HYC35bPW4Y7KMLf6FuVjwY1YS7g qEOQFCmp9O382VQNcEal7F0U+e0J8hkOmsuFIVVcYaUhatfmZHh2cXKKSWOuqVV/IzNP Seki7PCdOf7c9D6XswyLdvlXVqZwy3oLGqUPlbM1TGaFilCiX4hb+nwMWIvi/vINQXgi kQaW0c5BO7ZCRgQlOUet3rO7G2wdlHm8fGRHcYWRC9m/+S1AS5SimSbre9Frg2Ng/CGq Z+3g== X-Gm-Message-State: AOAM530TDjxVaV2GG0eC6obPCQF/b+swyV+YHxV09wYbf3wU6oCBVY3L EcYZA9aqJnPlvaVYy0ArzenkdD/EBOy+JZGvyvn3hPc8UqUXaYMUu14FwZ/zMxPE8WO8QXQU4Pw Go8LFkGmxkN19lKSnmNjsujC48ShEENvvw8+khvgCXpLJ6Bg2UPJbxgm50Q== X-Google-Smtp-Source: ABdhPJzSDlJ4YfGZsrWisAM7FeWcopEQO2tCnQihSgLydEExKq31kzpAmqFrVNb7wXl0eldBrGsTlQ== X-Received: by 2002:a50:d88a:: with SMTP id p10mr14579651edj.274.1633697256121; Fri, 08 Oct 2021 05:47:36 -0700 (PDT) Received: from vurt.sobornost.net ([2a10:3781:276:1:fa59:71ff:fe9d:67dc]) by smtp.gmail.com with ESMTPSA id q17sm985584edd.57.2021.10.08.05.47.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 05:47:35 -0700 (PDT) Date: Fri, 8 Oct 2021 14:47:33 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 12:47:45 -0000 Hi all, Similar to how in RPKI Manifests there is a BigNum embedded in the eContent to help figure out which object is the 'most current', there may be benefits to adding such a number to ASPA objects too. Doing so would change the ASN.1 to the below: ct-ASPA CONTENT-TYPE ::= { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } ASProviderAttestation ::= SEQUENCE { version [0] ASPAVersion DEFAULT v0, AspaNumber INTEGER (0..MAX), -- NEW ELEMENT aFI AddressFamilyIdentifier, customerASID ASID, providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } ASPAVersion ::= INTEGER { v0(0) } AddressFamilyIdentifier ::= OCTET STRING (SIZE (2)) ASID ::= INTEGER Some suggested natural language text: """ Aspa numbers can be expected to contain long integers. ASPA verifiers MUST be able to handle number values up to 20 octets. Conforming ASPA issuers MUST NOT use number values longer than 20 octets. Select the CA's current ASPA (the "current" ASPA is the ASPA issued by this CA having the highest AspaNumber among all valid ASPAs, and where ASPA validity is defined in Section 4). """ Note: The above doesn't fully resolve all possible duplication scenarios, for example if two CAs are entitled to issue statements for a given ASID, which of the two to pick? Thoughts? Kind regards, Job From nobody Fri Oct 8 06:28:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8C3A0115 for ; Fri, 8 Oct 2021 06:28:57 -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=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 LLJqN2qKg_qT for ; Fri, 8 Oct 2021 06:28:52 -0700 (PDT) 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 7D8A33A03F7 for ; Fri, 8 Oct 2021 06:28:51 -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 2FD5152; Fri, 8 Oct 2021 13:28:43 +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=1633699722; bh=q9ry4BxAc99qkj3AJhyspH9pvg9CvYNcnacI+5dtFc0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=UUWy1wuClOnf+f/hV+GZwG+33iMhuxWjaPzWcVyCFrjd49BYY3qtSZEfSkaJt+Cvj 2v4N5mU7rukISnqw36zeYesG4Cw5OsjSSZ1RwtgyE3eQQwXp+3SaMtCy4hUUn72dpA yGRQjLvQ3hMGw18ogHdhS19ez+h6gg+04BECJVjdXQSlEHhm152+A7QUjyGxVy8fgY BUuaRmyqloCEk7EPaolJNYrq+R4YMRo3s3jwHcvd0qvt0GnRoHQj85PrGlR4Cv7HPC zMZcuSn+QinUVtvr4Shmq4ICdeQA834WP2TGDtGNSMklNhgxEz4pzPGAjEkONUQMsE IyOvZDPh8XkGw== 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 In-Reply-To: Date: Fri, 8 Oct 2021 15:28:40 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F83BA6F-A9BB-4811-9777-B70216E9456E@nlnetlabs.nl> References: To: Job Snijders Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 13:28:58 -0000 Hi Job, all, > On 8 Oct 2021, at 14:47, Job Snijders = wrote: >=20 > Hi all, >=20 > Similar to how in RPKI Manifests there is a BigNum embedded in the > eContent to help figure out which object is the 'most current', there > may be benefits to adding such a number to ASPA objects too. >=20 > Doing so would change the ASN.1 to the below: >=20 > ct-ASPA CONTENT-TYPE ::=3D > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } > ASProviderAttestation ::=3D SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > AspaNumber INTEGER (0..MAX), -- NEW ELEMENT > aFI AddressFamilyIdentifier, > customerASID ASID, > providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } > ASPAVersion ::=3D INTEGER { v0(0) } > AddressFamilyIdentifier ::=3D OCTET STRING (SIZE (2)) > ASID ::=3D INTEGER >=20 > Some suggested natural language text: >=20 > """ > Aspa numbers can be expected to contain long integers. ASPA = verifiers > MUST be able to handle number values up to 20 octets. Conforming > ASPA issuers MUST NOT use number values longer than 20 octets. >=20 > Select the CA's current ASPA (the "current" ASPA is the ASPA issued > by this CA having the highest AspaNumber among all valid ASPAs, and > where ASPA validity is defined in Section 4). > """ >=20 > Note: The above doesn't fully resolve all possible duplication > scenarios, for example if two CAs are entitled to issue statements for = a > given ASID, which of the two to pick? >=20 > Thoughts? My take on this: don't. No, I am not trying to be negative :) TL;DR: I think this is covered because the manifest has a number and it refers to ASPA objects by name and hash. The extended version: I would expect multiple ASPA objects under a single CA. As written it would have to be one per "customerASID" and "aFI=10". So, if = "AspaNumber" is to be used then I would expect it to be tied to these values at = least. Keeping track of this adds a fair amount of state tracking. What if an ASPA is added for a "customerASID" and "aFI", then removed completely, and later a new ASPA is added for the same "customerASID" and "aFI". Should we keep history, and then continue counting? Why would this = matter when validating? Would RPs keep track of numbers of previously removed ASPA objects? Even if CAs MUST (as section 3 says) issue a single ASPA per = "customerASID", multiple CAs publishing ASPAs for the same customer AS can be a feature of either resource transfers, or organisations moving from one CA implementation to another. There is also nothing stopping operators from delegating the CA to multiple child CAs who all issue ASPAs for it. No, this is probably not the best idea, but it's possible. I realise we still need to do work on RTR for ASPA, but I imagined it would work in a similar way to ROAs, i.e. in the end routers should get something like "Verified ASPA Payloads" -- VAPs :), a list of = tuples: (customer as, provider as, afi) If multiple valid ASPAs are published for the same customer ASN, then = get the union of all VAPs, excluding duplicates. Just like we do with ROAs and VRPs. Tim >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 8 06:49:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526DB3A0522 for ; Fri, 8 Oct 2021 06:49:24 -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 (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 SWgLrWk-AGFW for ; Fri, 8 Oct 2021 06:49:19 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 C6E253A0484 for ; Fri, 8 Oct 2021 06:49:18 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id r18so36775526edv.12 for ; Fri, 08 Oct 2021 06:49:18 -0700 (PDT) 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=JeBa0eCB7j5faYrmqS1S0BpAYblDqxr7lnvL1aEt+7s=; b=KvIsBQxeY8hTzFwKkKbzDXz/520GDMs3fPoxteY/fnvfBuTqWDBoM2Rc7DC9+JS8yS n5WjI+OLt5ff/L6c9XBx1x4a834If4Vg2IrnP5ve9OsAOR9SC62ZUHJCbrfvYdgwvhpC wInSFAT4Gzphj2lIHsHbUxbdNfRjlWuV9uE3E= 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=JeBa0eCB7j5faYrmqS1S0BpAYblDqxr7lnvL1aEt+7s=; b=FHS0UPFTPiY4COUz5+mnoe5ShvMZt8oN8E5/DbDT3J7OqN89O9sneIy42NLJmcGJhp OwwI0EqmpCvQRg9rJKObJ7G/VA9Lg+zNImG4RtScPUZsPe4Cn0z1vA6KVx4sRYHStr+L YMPpP8EZnYg+ovx0sJjf+P+c/boOnQF+zkElJSQQG8MWvGOBhHzgc+Eh4FA/WWhu6QQ5 mFm8l4jLH6PSUxoBxqDIQmgpAUDcSamocObfuNmvTsjmjLbXSTuKJOebcLoLlwY60uz7 HaJKLcHcNu1wJ7/ZN30YyIME+dmmNq6QE5ONUJYjG1KvejipLLajx8UrfO4q7UQ/aoC8 l/IQ== X-Gm-Message-State: AOAM532uV4/pt4yHmEwDa6fQwv9f6BOkTRvCxxRTADZM8i343XbKkgPQ KVgzjxPZ8DgjCRe7lwBHtOZL/g== X-Google-Smtp-Source: ABdhPJwCrIjJakDYL2kqqY9ju0C40mX0yDy5W1aeSSZSXP3P+Lef4NcBgDHUv/X+civzVsoMgC54PA== X-Received: by 2002:a17:906:4f19:: with SMTP id t25mr4517417eju.176.1633700953846; Fri, 08 Oct 2021 06:49:13 -0700 (PDT) Received: from bench.sobornost.net (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id e7sm1095137edz.95.2021.10.08.06.49.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 06:49:13 -0700 (PDT) Date: Fri, 8 Oct 2021 13:49:11 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: sidrops@ietf.org Message-ID: References: <1F83BA6F-A9BB-4811-9777-B70216E9456E@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F83BA6F-A9BB-4811-9777-B70216E9456E@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 13:49:25 -0000 On Fri, Oct 08, 2021 at 03:28:40PM +0200, Tim Bruijnzeels wrote: > > Thoughts? > > I think this is covered because the manifest has a number and it refers > to ASPA objects by name and hash. Ah, good point. Thanks, Tim. Kind regards, Job From nobody Fri Oct 8 08:29:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC953A05AA for ; Fri, 8 Oct 2021 08:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X3UXy40rphrc for ; Fri, 8 Oct 2021 08:29:26 -0700 (PDT) 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 60C143A0744 for ; Fri, 8 Oct 2021 08:29:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 57294300C57 for ; Fri, 8 Oct 2021 11:29:26 -0400 (EDT) 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 TVHPPPvQaVRe for ; Fri, 8 Oct 2021 11:29:23 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 24F6030026C; Fri, 8 Oct 2021 11:29:23 -0400 (EDT) From: Russ Housley Message-Id: <26BD1B09-9EC6-44F9-B6F9-E4E8EEA1C640@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A22A4BDF-9ED4-4AC9-966B-488721A1A429"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 8 Oct 2021 11:29:19 -0400 In-Reply-To: <20211008075333.muhym3dbscuqmafu@benm-laptop> Cc: SIDR Operations WG , Steve Kent , Tim Bruijnzeels To: Ben Maddison References: <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> <90554F86-FA27-4364-B13D-BBE7CA4885B1@vigilsec.com> <20211008075333.muhym3dbscuqmafu@benm-laptop> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 15:29:37 -0000 --Apple-Mail=_A22A4BDF-9ED4-4AC9-966B-488721A1A429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ben: Different ASN.1 libraries are better at checking various constraints. For example, in pyasn1, these two are equivalent: ver =3D rfc5280.Version(2) ver =3D rfc5280.Version('v3') However, it does not complain if a value that does not have a name is = encoded. That is, it just uses the named values as a more readable way = to set specific INTEGER values. RFC 5280 uses: TBSCertificate ::=3D SEQUENCE { version [0] Version DEFAULT v1, ... Version ::=3D INTEGER { v1(0), v2(1), v3(2) } RFC 5652 uses: SignedData ::=3D SEQUENCE { version CMSVersion, ... CMSVersion ::=3D INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), = v5(5) } RFC 6486: Manifest ::=3D SEQUENCE { version [0] INTEGER DEFAULT 0, ... I think all of them are roughly the same to implement, but I tend to = like the ability to talk about values like "v2" in the text. Russ > On Oct 8, 2021, at 3:53 AM, Ben Maddison = wrote: >=20 > Signed PGP part > Hi Russ, Tim, >=20 > On 10/06, Russ Housley wrote: >>=20 >> >>=20 >> This is just a matter of style I think. >>=20 > I've been thinking about this some more, and actually I think that = this > choice *is* important when considering asn1 -> code compiler = friendliness. >=20 > Consider: > Foo ::=3D SEQUENCE { > bar Bar, > baz Baz, > qux INTEGER > } >=20 > Bar ::=3D INTEGER >=20 > Baz ::=3D INTEGER { > a(0), b(1), c(2) > } >=20 > Compiling this to (for the sake of example) rust would be expected to > produce something like: > struct Foo { > bar: Bar, > baz: Baz, > qux: usize, > } >=20 > struct Bar(usize); >=20 > enum Baz { > a =3D 0, > b, > c, > } >=20 > Of course other language type systems have more-or-less direct > parallels. >=20 > Each has advantages and disadvantages: >=20 > - the "qux" style can be used directly as an integer with no > additional work, but you get no safeguards from the type system to > prevent using a bare integer where you expected a "qux" value; >=20 > - the "baz" style gives the type system the ability to distinguish = Baz > integers from other integers, at the expense of some extra work to > define the operations on Baz types that are permitted; and >=20 > - the "bar" style is not usable as an integer at all (at least not > conveniently). The integer value is just there to distinguish the > variants in memory. >=20 > I think this leads to the following general guidance: >=20 > 1. Use a bare INTEGER ("qux"-style) for unit-less, context-less = integer > values, that can be sensibly combined in an operation with any = other > integer value. > This seems to be rare in practise to me, so should probably be > limited to situations where simplicity is more important than > correctness. >=20 > 2. Use a named type of type INTEGER ("bar"-style) for numbers that > can be combined or compared with other numbers of a particular = type. >=20 > For example: > bob.age !=3D sue.age # makes sense > bob.height + sue.shoe_size # probably a bug! >=20 > 3. Use enumerations ("baz"-style) when the *only* sensible operation > that exists on the underlying numbers is equality comparison. >=20 > In the present case, I would suggest that the 'version' field falls > under category #2, since `foo.version < bar.version` could make sense = in > some situations. >=20 > So, I would suggest: >=20 > Manifest ::=3D SEQUENCE { > version [0] Version DEFAULT 0, > ... > } > Version ::=3D INTEGER >=20 > Note that this is orthogonal to whether we explicitly limit the > permitted value to 0, which can be done in any of the three schemes. > I have no particular view on whether that is a good idea or not. >=20 > Cheers, >=20 > Ben >=20 >=20 --Apple-Mail=_A22A4BDF-9ED4-4AC9-966B-488721A1A429 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE3ZgmxD9TboJgMKMUcGKjIhkfjnwFAmFgY88ACgkQcGKjIhkf jnx69RAAlyXmucYBvASibSsQNscDpSWDs5uIJ5bPRzG9W7YTsArD7nj5+pEfNJJE SMlzo63OTdnQoPdusRB5MM8OOMbT/Z8m0K3+bg2EDshv29sYP+t2KphilJ4PELUO XNz9EeEhlcjiyyadhD0A/WSidnZ9xl4bnP9Bp51bOC0CrB4YLtJFonsq4dcqexz/ v3uS1RI2XXmVTL1fS17yzv0e+fc2HgXyLZkiedljyV15Lvb6Jv2RIEEDaA2Ap5G3 D5Pp0qGQsH/XLPlPUbLOINIqHUlaAhUUnlA2ANq1+chjpoIs30TmP9CkKjmHwPLk YY+GUyV+TmKvANKayfGG1AjO7jFh1aGXjkiSvfTj+zcmFh7zEfXi236GByK4CKRc QFx9J/ZL3FHbhVtJ27pQp1os+WX24nlzhJ3Q9/k7kg141FaIyCkbeALaLxyknz+6 sr+dvIoAvw4sWbaBP0IeLXptA4CLaJjDhFolpJeHFJCI7cHSkZ0JcFVDUTNXyFLA zjEHucwjoBt6RgxxbXqhhiic20TEfbyB6gb6lLIRgNXCjL002yIY/P/bLQydRX1/ PrkdVq+tooOJIiSY55/yPk423rEkFCZLunc1/Ylc5DUl87ZuaTRtFF7r9nqq+ENN 4LZDI1G5LSrqjSGEPK4fxZqldLgOhhXb4t3rwuVS6eHKLFHMRXA= =9gmC -----END PGP SIGNATURE----- --Apple-Mail=_A22A4BDF-9ED4-4AC9-966B-488721A1A429-- From nobody Fri Oct 8 09:20:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3133A05DE for ; Fri, 8 Oct 2021 09:20:50 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 WfZGol_knKqW for ; Fri, 8 Oct 2021 09:20:47 -0700 (PDT) Received: from sonic315-47.consmr.mail.ne1.yahoo.com (sonic315-47.consmr.mail.ne1.yahoo.com [66.163.190.173]) (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 CCF753A05A7 for ; Fri, 8 Oct 2021 09:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1633710046; bh=U62hZGkiVHJwXyJpcO5xseVJo5f5v4XSkJK0T5Pycwk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=egl4hOypjLBzhKaq7Qy34911OsLp7purIaeoffDKlJy2rHZx3r2R1hzqBgRh645rcYSXXGkki3X164Er8Y9HX+3PcVnf7fTTb85dZq/d0x9uNnkY0gm6oUINUYeMhSGK5F2qRIOt4k7JinDkvDLJTcbuHi05GmSUmP8oOBahSezs6E4DsGZ4b1v8YKqalEeQOD0Mf6J7/9tqnz6RjyyIRr02J2TA38k8jtI5uL9yU4tIjcpmZd7k5RuZwryRrmwQCVaCzLYRkLl09Dr0XdGQIDoyKpuvamcrZ9cQWKm+fBvy5PYK5ud04dvmvEysv/rYfCECPEIKLjisY77XJ/0BFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1633710046; bh=NFu4ZemMKJhS6QQIr4wLJ/zyMLNGQhGVnfGtxp/h8LI=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=WGkvns3qDn3BrKQb8fEzWS2vTmvZf9sv1j8uJ40J7X6OXwG7Ax41orFVnAoW9yissDr16DNMmbBa1Efqnp8GGmB3M+hKo/CofIJP4L1Jpd+HxKDdUyxv61hJ24sbIyilP1HGM6sY9iOhwMZJExXUKmBE54vbluSMgPrhcfVJRzarji93UcAQZGMWp70g0gdcMsbWrEOjb9AhM3UR/3MCbru6Dqjrc8UIvuG0qQszSWdCrEuGvvl+QGs+GN4A/evHqckZOePPYd3z0SFlV5yQSVyTis8+xtUqvQU56jGd4NxTMcrbQ1oB5dR1cSUEtgrIQf5bICV8UDRMPSi6U+pbpQ== X-YMail-OSG: 7CwtcgQVM1nOcuiuBYSrmEEYGW80qd.aDfdaW8F4QyA92Wp8cp1omJGF5OwPEXd bzyYvglXUmIjO9dCNSdJKli6_VGCJnb7APU4jj7v8QTbItHTtoUBoiwBdf9e.2YlmXN9hEO7c1R0 PSw0G.aZHwxjOd3SvcgUxxampIyhvN1p.pWgSPYA_W_cq4n4Aw.z2DxZyUk2ogADwzZbr6.4VCFI gFUCN2FIfRsQ4sJY6JYX2GQGneZY0ugnfSdGS9aCtyGdek2iQYEoDycnqh5qDu.BQLiRx9DEKsTz fR5.1jV.PHi5CN2h7Z3x1wzcXOxcBg9fvIrY3MNI.L.adm0WvbXSuR79Xp.1BG6TWRZO4EmNrNv1 DR0xVU3Y_3HH1Ex6LbaxEh0Uu9eukcm7v7ZKMpCSl8TfLjq2kC0CNPT6Zd8oa8_v12ctOE6a8orS 2JIJhyotIWCUNPE2h3N_62SL3NaxXJHZobwYF0tiM5rkt_XEwgYXISd4X.EeXxNFUN0lEDI93070 ve6jAzDKWeHsNFaVrFyF9kkGpPNnvJJEFwgaPGa7K2F4NRStKEGCjUig2FdqneApba_jYlwbevE4 1HcGJSrAoDluaS6vX3UoY8OU5WFXGDQWaetlMaCQ4eqedCMMqQnwD3HRIbE_BnGl4nUTAth6fzeM siLCW2K_EXrJ_r2Pr42PLvWedJwmRdUUybWq8N_TU9m.b8JBJM6ZsfYXjakyfLJfE9LeqnxaOQDz XEhQZBvkMw_I7r4EN.36aQ4a1u6cmWoGzC_CceZMDzwDix4GHSI_G481a8eVaviA64qUJ4GYCY4c GmgT7JcEWOYe6YhQHUXecnNI1R.mRhN9ieV.L3UWYgU6Zwd3NRd6BzVclGOp4H4qLXgqM0Uwok_R w6aNpD4l_QEMblLb7Uuq4m3zNRQ3Z.KbKNlOK1cc0Ydpc1yYFUq39oLyUh.ArxyM4r_lc8im5ITK sv.xG84j41MG01Q1u1RMg4Qx98RC3RRh_SDFofHZKBNrDlIVlgKIQUKQHMwBw4qTyQaKZQsJbPgT Z42KLIIgKiOuA4flqEUjqnQLwYRsOl17RnpYGzf2vj37GngR2QZlMFBgl22VjdeevkwLf1icUtQS WzIEm0MAREx3_QMde6Zs7FFyry8_WaBYebG2niBBalAvUO.iqvaOUaB_d0ijY0UJulpIfWxHp3x3 yXjfpHxEp9812y5RoMRHOL1G3YYd8eGtxcASkpzofL1squFnD6S8AxPAGEuCnpBpZULFXkPr25b. d0N5TQK7WIvZeXa3WSkhWkvNpeU5Va.WkfA1AP9mk.0TzDT6oU9FL8w1qjNS035Hkf5hkc2gV3xO SfOwZmY_OS3dCCkfiMK8iu5KkaY37E.V9e1lzDeWBLo97HXrdNOaRqmtLRQkVOLQRk0GPOivEeQi nQB2aiB3guDfqxovyNiYpXc0VlMuCgRcakYRC_VPE1vTrs_xjPaqK2uFoW3M7PdEYmSaMVjQ9qfE _HgAUUtPDlNjWWe8ft0Iq_Xo1tKGKKOwun0vLrjVzw9.9lOcL25iiPZaUqE0zTpMu3WvqHusB5O6 VPi0gOW8edNgJUh6dZT9_96mCUJj.84swDn.0u_WsjHQkWMVEx6QLM_sZB.3rqy_0RkTcL1ABFpm 7HHBXk6MrItsOGa7jLdtmoOQ8lldJixa9.WNqCibaTA.ByEtNp5qsvayCi7Rh8Hc96.CtR.K.wvf SzTcWDPsE740CDlfrdthxgqjQ.FanVnKxdacBSbRQv3hCOsn9iSAnjXg84f2_d6_v1eG8t_.wCu6 9S3yIS_tfh.SM8c4tUrhiGrvFgIjFjqWs9.W5dkMkBSuGBfTT4rbv8wY2fzgOdrU.NuJOIZV36PR 6YFfTIOWp5Y4YdheFlIZphpSuec9FKhSc2DkogxPopd8CGb9YoJM5mOxI9YL30_Og_vws_ZDPgej eERouYMVTfwyUE7j1.Y0LNgtobSTSscYULzwwFgZWkEqCGblNgCTRB_EGUpo9H8_RPUarNw2Bd4p qtziiH8hrbpexp4eD56Q7ldLxKw1hXvkUHMwYxUOr87kOiJO7bf5dOTnw5C5gckaW0ejAgOB4iWC m7L_16cZIU.bVHH.PN5u.lo9yrKwQZxmy4VGPaZwsJ011aaU5RlqBoYgWrywWpcYN.rVQsp8AK1O kY7wdsYDwcN6yxKHkrn7IUfmVyAKtpCLmQcJhMyxEDBR.tfam0IEG9.DqqBFbPNcbEI4BYWpxepF 06zb_V5A04qvrXwZTL8zBgH6noHL94o9IVaFQqjakEq.4U3mzL_CfOiMiYqcO8kFumjVg5xskxHc kfjqtBx97KvCJv9oTIA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Oct 2021 16:20:46 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 522ce493bb23f50fad9d9cca580711b8; Fri, 08 Oct 2021 16:18:44 +0000 (UTC) To: Tim Bruijnzeels , Russ Housley Cc: Randy Bush , SIDROps Chairs , Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org References: From: Stephen Kent Message-ID: <5058d0ba-6869-001c-fafc-4fc563411c99@verizon.net> Date: Fri, 8 Oct 2021 11:18:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E5009616C4C00EAB1D81F820" Content-Language: en-US X-Mailer: WebService/1.1.19116 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 16:20:50 -0000 This is a multi-part message in MIME format. --------------E5009616C4C00EAB1D81F820 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tim, > There is one other thing though. I suggested that we consider including text > that says that all removed, or replaced objects are revoked (if they are of > a kind that can be revoked, i.e. not CRLs): I think the  text below, which is in the new rev of the document, addresses your request: If any named objects in the publication point are replaced, the authority MUST ensure that the file hash for each replaced objectis updated accordingly in the new manifest. Additionally, the authority MUST revoke the certificate associated with each replaced object (other than a CRL), if it is not expired. Steve --------------E5009616C4C00EAB1D81F820 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Tim,

There is one other thing though. I suggested that we consider including text
that says that all removed, or replaced objects are revoked (if they are of
a kind that can be revoked, i.e. not CRLs):

I think the  text below, which is in the new rev of the document, addresses your request:

If any named objects in the publication point are replaced, the
authority MUST ensure that the file hash for each replaced object
is updated accordingly in the new manifest. Additionally, the 
authority MUST revoke the certificate associated with each 
replaced object (other than a CRL), if it is not expired. 

Steve

--------------E5009616C4C00EAB1D81F820-- From nobody Fri Oct 8 09:28:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B153A060D for ; Fri, 8 Oct 2021 09:28:40 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=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 fDX5P71uGtPV for ; Fri, 8 Oct 2021 09:28:36 -0700 (PDT) Received: from sonic315-47.consmr.mail.ne1.yahoo.com (sonic315-47.consmr.mail.ne1.yahoo.com [66.163.190.173]) (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 472B63A05E2 for ; Fri, 8 Oct 2021 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1633710510; bh=O28lCgBc/DkhOXFQH+is838Y5VdOmPp5cHYJSssjDDI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=hotmiUFWMThhhh5L+GbTK7pwDo9UjQKvWI8lTznaMfjJJny+sOS3JgLabLnItHCOmfclxYRY0VQfehPYQjuzXAfndPfTX1gvR36enkhGA1pBsX5+eDYRB5iy0AS4fyIYOpnQr5IvbhbJju7iHHWkpBJn/Jo+WkWWmT+klatBGlS0oCQonmyHupvN6/Z4/L93sATw9P6Z5Df8a1XHMRWVu5GMTowtg0FWvoUyCX5CqoZ/q4KHwetG/TVJtdeHnv0pgNQJ7X7jY7huID2Qo15ER9K6AGHOkkZAATp5bVuzkyaRBjIg8ECaywDYoAZkVwXeOef0blalZBFKoa/8oDLQEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1633710510; bh=O+lhHBcKA4Q/8YZse4B9eZeUaYyjJHHbI2m6ouYnSoh=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=G/vtq38TA1znj14WeSxbCWR8fDgwRsatNVMElV2WYQ8T6vA3BkePFZrWFV9pSaObvyoC/0zB41NlkDfciEO50ZQUBEN5aPvjo3iWWuvvwwOccZE81C/KMc3OQOsbY1fzXEjYxmgcOxzdcxnv08VYnghBQRhfsRiP77f/jQwuPwXt4Bg4eXMCj7hTEfbuCNRaowyq4T5rBj4keXaCjALlQs6wyIX8W5yZdKXitOJ4Sg1ZuBxFSt/fYF69dxyl8Ztn5sWy0RjxxwNEmsFTAl1Qkk5F/j0qGtLmt3yy/+enI525Er3jeaPkUJardJ+Ujdc+79Q4rqYC4SQKF3nddI0aqg== X-YMail-OSG: F6rTOm8VM1k_CMsHeyoaCFE59VxesI6ocZHXgbZXNEg_v75IXll3PhJoWSm0WSp b3pHfEnZTlizVu_5pFlssAYnWQxKPQYY6pcqn3elFK.ipcX9fxvwuv831AEdFPbYtru2RaM_PvD3 AdE552hghyWd21T.4GgwPwAGC_g0RpdDqjM5jjeDK75K7WeSnZ73MqyFHJyG1B7eNP1gWDFUxScJ GLaN_CsW1_febkBqksmum5BuxG17lznrNd92CsSDwbddKss1JemgU8dBekpoC7lD1ViTy_FqM_3g nr8O5WXea2gSfTY5__96enmsmRgjisJDSKCYkIzK8DSjLdxTyrSi_KIYLF96bj01KbTYy7GZyge8 T8FBDipQlsHMxjhASMw7lS2hPnx3LumqFDWZPF0IExmbo7TD0.82Ellv7R2f3S42y9h8DaCoU4w7 Ce2YEpV9xOy3jjrVBGfy2Ila3vvz2QNxNv9LnFc7SXQ.HvTbSlXZWAXOgt6R7FX._BuEPnAoaRIN jyo9oGTpDpsZmeVkBaFCWjSfLZ062QucL524K28aGzqbN.iRfVWLoVgUShl84bGIP5CKrF2f25A9 kZ8Z59FfXlIk7HMPKhkVe6gJmzCichWJ5g7MLcNOlXZ4x91.uBO4NTHjA2dvTM7A6yJ9vuOKfbWJ aBsOLJncxH7HjqBHHL4mL9zQvfn7bjpn5ifjsFh.5JgBj.PTqQ2Lwm15KOr6zooPZf.1V8gCv0Aj g9m_easfbPyesUwtWWVoJ4uWn9ax66d.pi0wp6ZbJyYzE3FWbimKvns7sEvFPLhnJmrxBdm0nRJi Q7NEj.XznpqFiDFQ_pcTdIk5Y6l03_Ip.SDCLx.Z7GjFC05V_IX9Ge6ty3SRWiJpm8mXuC8PBwlu HPuH2hvH6kl0CIkZ5KNiktrAjm2a26Rr61WoaHU8Pp04UDQPBhXYe.wsNSChmVjH3YvAYzb2SZ2O ns9bj2fqzGWFRNcERU_f_V4giY5vngU5BFiDW1LPjlxHGafmrvs2Bd7LwAa1_ERRabNNM5gfGGjR cfogKcYaHoNjh9.D9ifWwdgVlNJNpBwYfEpGqLhw.PxAw6VQRW0T9GCXxwJn3Du_fx_VafwrxZoH 4vQ3kEurXDLRqh..SgUNKEUgbc3PunpabC6NJRQFf8Lg7_CqbJUnI_uFe1MFla6A39rQHLGYSjuE ZerK6c87RVx_XCVnTseQBQiPcc55OjvK96ltB.pNE8xqkApxdlInIGjHHk0e2He7eUUKOYRACwgv tuj8Gd0..x_exuvVcVU56RgUxM_WvyZRIJwzKze_pPKaC9Tt32kYdlSnGHKIl0kqjeVWEPRPO.un 1p.cfHQ3ROLbwWaeH7ACWlC3Gytiyo8a669HWJwZxz7ObeVsy13QCP0Sdj7fZEmkJ7vvxxeOprwg RfMRe.VepucQHSV4AovGh3ZULVi0fCwCOV6cuA5D6WnZLJPwEIyGfXK4oE.28LwTChOxvtjwHVRW Rdg5u99OPzORmSv6okjYaNwbwicqTdLthigE1UfsJYW5H3fKqzlfEBirYSXZeqsnidUbq61Ie5qL VUVD8XJRu0h6VtyTDqk4ZwxeBLvBSpx9COEp97Uoynv.812I7TDAo0AIZfmY4nE_sjbwFm.fmk0b j0nSPv.SzkSZDMMmNidkAht_DNQo9kAO4ke7afKTBoJ9xyfhAnV0u7JcYgB4i4UdUcm259zlT8NK 1XwsB20OkDvDv8y4hYnREOrs44mI1iT2APfHc4gE9A40Lu6yZQFXMyhwjpKuv8aHuSt_xFRT_.LP mUg0OQuVF.tpxcRaH6zjCdiB6WRZ0plqG9gm8UJbglRztkgznq6IbgtuKzwUUxqY81xd9WQGGGsk YA1sPhchkbJjIVfMda0B.W2sANZGmSsEDRSNJKJwhuutnsBng0vigxnvcoPuJ956HJ__b5JOBqym tRMTSQrWdMZ_T1jn57EoZbkS1.i7Ifw2cgbLW3jpfgJipwb7HY5EW.VLphEStZjIApCHHGr5G34B nnDJVvHSqPfYHl_JjRWuVUhNWw4m40Y8OxSe8DZC0vc6YOUZTJBFNgpiBRjNI7Q5_vEgT.CmJK0Y rUIzSh7fultF46jrsVtXzS6HyKRxxg7oxHCSMkiqGdn8pkhiI5QOv6quskndq9X5xcCwIX5.hcz2 _DfLfMXHyQXbfaYrXdwPOfxoREv7gVKiJIWcaLEcXsCtTSbYELz2juYEpaUUCQGiURjmxNaKLKcB WFkCjKQIQ96VQVMldv7f5z5EvBA8E__HeBB9xt.JwAI4KglKaLRRdHtCtpd712P47ld11uFLHpx0 JEJeN.01jbsphNNU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Fri, 8 Oct 2021 16:28:30 +0000 Received: by kubenode510.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 116144037451159d48a93b6427a9e5d0; Fri, 08 Oct 2021 16:16:27 +0000 (UTC) To: Russ Housley , Randy Bush Cc: SIDROps Chairs , Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org References: From: Stephen Kent Message-ID: <496be631-b9b3-0df4-0eb1-a7f71a00a57a@verizon.net> Date: Fri, 8 Oct 2021 11:16:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E51101B7D5F5B3B16207759" Content-Language: en-US X-Mailer: WebService/1.1.19116 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 16:28:41 -0000 This is a multi-part message in MIME format. --------------5E51101B7D5F5B3B16207759 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Russ, All of the highlighted changes you cited have been made in the next rev of the document. > Please excuse th e use of non-ASCII below, but it seems the easiest > way to convey the point... > > To me, the changes to these three paragraphs justify moving forward > with this document. > The CAMAY choose to *MUST* sign only one manifest with each generated private key, > and*MUST* generate a new key pair for each new version of the > manifest. This form of use of the associated EE certificate is > termed a "one-time-use" EEcertificate.*certificate.[RFC6487]* > > *2. Issue* an EE certificate for this key pair.*The CA MUST revoke the EE certificate used for the manifest being > replaced.* > > An authority MUST issue a new manifest in conjunction with the > finalization of changes made to objects in the publication point. An > authority MAY perform a number of object operations on a publication > repository within the scope of a repository change before issuing a > single manifest that covers all the operations within the scope of > this change. Repository operatorsSHOULD *MUST* implement some form of > repository update procedure that mitigates, to the extent possible, > the risk that RPs that are performing retrieval operations on the > repository are exposed to inconsistent, transient, intermediate > states during updates to the repository publication point (directory) > and the associated manifest. > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --------------5E51101B7D5F5B3B16207759 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Russ,

All of the highlighted changes you cited have been made in the next rev of the document.

Please excuse th e use of non-ASCII below, but it seems the easiest way to convey the point...

To me, the changes to these three paragraphs justify moving forward with this document.
   The CA MAY choose to MUST sign only one manifest with each generated private key,
   and MUST generate a new key pair for each new version of the
   manifest.  This form of use of the associated EE certificate is
   termed a "one-time-use" EE certificate.certificate.[RFC6487]

   2.  Issue an EE certificate for this key pair.  The CA MUST revoke
       the EE certificate used for the manifest being replaced.

   An authority MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.  An
   authority MAY perform a number of object operations on a publication
   repository within the scope of a repository change before issuing a
   single manifest that covers all the operations within the scope of
   this change.  Repository operators SHOULD MUST implement some form of
   repository update procedure that mitigates, to the extent possible,
   the risk that RPs that are performing retrieval operations on the
   repository are exposed to inconsistent, transient, intermediate
   states during updates to the repository publication point (directory)
   and the associated manifest.



_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--------------5E51101B7D5F5B3B16207759-- From nobody Fri Oct 8 09:42:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102FD3A081B for ; Fri, 8 Oct 2021 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 lY-nE945fVWT for ; Fri, 8 Oct 2021 09:42:47 -0700 (PDT) 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 E57D63A080B for ; Fri, 8 Oct 2021 09:42:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7D5B1300C84 for ; Fri, 8 Oct 2021 12:42:47 -0400 (EDT) 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 2810zkjr8jQt for ; Fri, 8 Oct 2021 12:42:44 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8AC69300B19; Fri, 8 Oct 2021 12:42:43 -0400 (EDT) From: Russ Housley Message-Id: <4DA71F27-265F-4785-9E36-4FD851F5323D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_04813E4C-FD4D-409F-9CAF-EA5D14C386A1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 8 Oct 2021 12:42:40 -0400 In-Reply-To: <496be631-b9b3-0df4-0eb1-a7f71a00a57a@verizon.net> Cc: Randy Bush , SIDROps Chairs , Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org To: Stephen Kent References: <496be631-b9b3-0df4-0eb1-a7f71a00a57a@verizon.net> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 16:42:51 -0000 --Apple-Mail=_04813E4C-FD4D-409F-9CAF-EA5D14C386A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steve: Yes, indeed, they have. I was responding to the questions about = rollback. I do not want these to be rolled back. Russ > On Oct 8, 2021, at 12:16 PM, Stephen Kent wrote: >=20 > Russ, >=20 > All of the highlighted changes you cited have been made in the next = rev of the document. >=20 >> Please excuse th e use of non-ASCII below, but it seems the easiest = way to convey the point... >>=20 >> To me, the changes to these three paragraphs justify moving forward = with this document. >> The CA MAY choose to MUST sign only one manifest with each = generated private key, >> and MUST generate a new key pair for each new version of the >> manifest. This form of use of the associated EE certificate is >> termed a "one-time-use" EE certificate.certificate.[RFC6487] >>=20 >> 2. Issue an EE certificate for this key pair. The CA MUST revoke >> the EE certificate used for the manifest being replaced. >>=20 >> An authority MUST issue a new manifest in conjunction with the >> finalization of changes made to objects in the publication point. = An >> authority MAY perform a number of object operations on a = publication >> repository within the scope of a repository change before issuing = a >> single manifest that covers all the operations within the scope of >> this change. Repository operators SHOULD MUST implement some form = of >> repository update procedure that mitigates, to the extent = possible, >> the risk that RPs that are performing retrieval operations on the >> repository are exposed to inconsistent, transient, intermediate >> states during updates to the repository publication point = (directory) >> and the associated manifest. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_04813E4C-FD4D-409F-9CAF-EA5D14C386A1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Steve:

Yes, indeed, they have.  I was responding to the questions about rollback.  I do not want these to be rolled back.

Russ


On Oct 8, 2021, at 12:16 PM, Stephen Kent <stkent@verizon.net> wrote:

Russ,

All of the highlighted changes you cited have been made in the next rev of the document.

Please excuse th e use of non-ASCII below, but it seems the easiest way to convey the point...

To me, the changes to these three paragraphs justify moving forward with this document.
   The CA MAY choose to MUST sign only one manifest with each generated private key,
   and MUST generate a new key pair for each new version of the
   manifest.  This form of use of the associated EE certificate is
   termed a "one-time-use" EE certificate.certificate.[RFC6487]

   2.  Issue an EE certificate for this key pair.  The CA MUST revoke
       the EE certificate used for the manifest being replaced.

   An authority MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.  An
   authority MAY perform a number of object operations on a publication
   repository within the scope of a repository change before issuing a
   single manifest that covers all the operations within the scope of
   this change.  Repository operators SHOULD MUST implement some form of
   repository update procedure that mitigates, to the extent possible,
   the risk that RPs that are performing retrieval operations on the
   repository are exposed to inconsistent, transient, intermediate
   states during updates to the repository publication point (directory)
   and the associated manifest.



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

--Apple-Mail=_04813E4C-FD4D-409F-9CAF-EA5D14C386A1-- From nobody Fri Oct 8 09:53:48 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6545B3A0870; Fri, 8 Oct 2021 09:53:45 -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 KfEjWkwZSfFO; Fri, 8 Oct 2021 09:53:40 -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 EC3EC3A0962; Fri, 8 Oct 2021 09:53:29 -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 1851186B; Fri, 8 Oct 2021 16:53:26 +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=1633712004; bh=MhaIxMNWXtBL7DJLZ33myfidNIOIbHnNGFOylxZCdzk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=xczh2VqQKhjl359Qn3X0L262Xq+Q7ggAFkUTSwebIbvAfxXnceSu7AFZddQJQeQzw 61/ddxJ6FcZsT8Pil5ULpJEDB3SJZoQl4lxSgwI6pkTJ08Bme9wI2Ao/aZXjbvg7RZ kWdBsSNg8cPwnSRpWqenPRD1vyzjPyXwc5afvFjUYcQXitlMe3Bp6O6QQYavp7YwN8 h7dO+472Og1ph6cZLN7UrHrOvvnwxosY9bMC41P1Ry7lcsQTlt7VyFe0jwJcWMkubC 6p907dneWFEYlvqx0qj8cqBC2orTvD/ftMR0ARh4Hcdg/0goHyQaDwbCmBKAzY0+u1 i9ojahgblzArQ== 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 In-Reply-To: <5058d0ba-6869-001c-fafc-4fc563411c99@verizon.net> Date: Fri, 8 Oct 2021 18:53:20 +0200 Cc: Russ Housley , Randy Bush , SIDROps Chairs , Christopher Morrow , SIDR Operations WG , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <56D721D6-CC40-4B54-8741-5F5A8106167E@nlnetlabs.nl> References: <5058d0ba-6869-001c-fafc-4fc563411c99@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 16:53:46 -0000 > On 8 Oct 2021, at 18:18, Stephen Kent wrote: >=20 > I think the text below, which is in the new rev of the document, = addresses your request: It does. Thanks!= From nobody Fri Oct 8 15:02:40 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01E13A0A85 for ; Fri, 8 Oct 2021 15:02:37 -0700 (PDT) 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 CWRuciB8ZkjJ for ; Fri, 8 Oct 2021 15:02:33 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2066.outbound.protection.outlook.com [40.107.107.66]) (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 01F903A0AB0 for ; Fri, 8 Oct 2021 14:59:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QbEUaSpe3vEJsgnhZrEMwf1XZHz6I503Ni9rCKCCLNAWrTuki4gytQuFWyPtmJCFoAlK2jKCWi0zNDqBg2+qrRljh4v00yqWl4dcfzChGa/CjbHmIe/9d971PF5TG1P4gV/UNbhdrEYVN1uzNaex7BzFs2EwoMkG+tK137bNN0/SdGd+Ku8pzd1eKU6UmnDafxcyoAxxhUV7ECfZwtPNYP568oDMRAyNW6uGaW0ZxnCtYnNSBU137z35vHzGlU0ZcFViQgcrccwk2Cv890ZpYSUdZnxskcF2tmkg8LTnWs/u4lr8EoYvQj46vO9vEj7wJ9LxyR1SvcXb9hA2eWuuYg== 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=SShESCM02GFEBYCj7glkr9A2WByox+NuZ/KHinc+1Ks=; b=OWkuIN56R+2oVUpW6b2ofr+Wvua8xifA3kC9pkJZiXid5QvYrsEvQRcWO8564LaGX+M0KGI2YryB94w9CHfTMgL0Um8Td7tBTGmR5FI2i11SDZ06RdhA+HWiVGJLQFMjI8KesW9xcw73vOwNP9I7wjwpQ8oDMqgN+h14uck4AjQgt7plbuq9pm2J8HByKuj0ZT7u1OPExKatK5gPBs3G+uAibabPLq+Eb6WEW4zVGRhe4xWAxH9kdmkxcffEHSbydDnkPUJBpvhBfcsC8C7mxh/Jy43HcR4hEhcEWddZfdBuWDaf6bTc3LFBQlitwlO88qOtZU/2aEboX7TG3q+cvg== 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=SShESCM02GFEBYCj7glkr9A2WByox+NuZ/KHinc+1Ks=; b=fv4jgwRYwqtFrgPgGrSBtacumP8MQAoq2koI+/2JviVwQs/QDs9fKyjgX4e8NgtmQThaE6tV8HTYXgjwEUbTj90nsASL/7HMc6LyTBogjiZ16WHgR/2EMXKNLuptyw2juWyCe/NO1BP7AsghWeBIyoIdt362wP5cg0nMhaJAQZ4= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY7P282MB4012.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:1ef::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Fri, 8 Oct 2021 21:59:40 +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.4587.024; Fri, 8 Oct 2021 21:59:40 +0000 From: Geoff Huston To: "sidrops@ietf.org" Thread-Topic: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? Thread-Index: AQHXvEK25o6vHTzR0UKnmHLBMTn+pKvJpw+A Date: Fri, 8 Oct 2021 21:59:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05e1e729-52f6-469a-2105-08d98aa6eda8 x-ms-traffictypediagnostic: SY7P282MB4012: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yrX5bqzSdrJd69OrjQRfEuKho6O+fYKLiFGCEEi/7wmSoRpXuG/XNBY8e6Ki3/WkhwCNKkGhHImtWzPGN/NBOpF2RqEdplSCQRfKvR93rpeIDwub/0vnGClZ25V4CiWJxlpUTPsVwKJXb2RZB2aiu+/iuZNSt88HkbGpB0h+5fzPRtfRg9Ga2ixH/4cg9ZUX+Gy3LRfmY/cFkY9WSPzy0SV2/tkhJ82mzXEJU0H9cq6Tk9Q88h9jR1glLDf8INV9cuRcUn4cBAZ4fj2DsKvsU1egOw7piT6dw5ZFG2NkQ+GZYfsnsbeN1ikBq4TvcFJrrgCg4bWGjsegzW8A6Ctl++zQxE1pq1K/6jee+WzmF6Mikf1RzlqXL1rXaQawUuboEYxx927Xp4Q7l4+JxAfk80eQ2jCsEXWCHfiVaoncWai/Sz6tRoOy5VvnUeRPbC+pGZhcgX4r3Sz6rlV/pvJKydgLERHfIyN48uEG6IDTb3yiVwJJ48iNT4IaIToAwCaBGbUS6kfTUeMXg+5zrsqvjOoQyaoHCZI3kmxSGgxs2wJ3I6g2oeg3P8F3w39vhaTajBALGpF2TS4VUG64fwEIeNeam2ZqtRkoO2hSx8tOdsdGD3eE082ySdBYvz6XafF82EBulvIwBL955rktk0uhpp8iGAgtFyr6ADBN4Qdv2gJ8ruOP4Z/MMBDm3TVAt4avyf6gCzL3qD880YQlgvFUOjWjFE1gqFC96pXLECgIDBtLsBbvUCHv+e+KnQHS9nBSWcDOx6jJJ6vnV3V5tfq/moegih876ofrf4uW9/9Oez/DvFHPqal69zsXLjT0UdUv 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)(396003)(376002)(366004)(346002)(39840400004)(136003)(122000001)(8676002)(38100700002)(36756003)(86362001)(508600001)(6486002)(5660300002)(71200400001)(6512007)(33656002)(38070700005)(186003)(2616005)(2906002)(76116006)(316002)(66446008)(64756008)(66556008)(6916009)(53546011)(6506007)(966005)(66946007)(8936002)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YTlSbmYvb1Y5SEw0NHQvZng0aVdFMk9TaFRkRXQ1NE1qK3MySHhJRkFpc1Ix?= =?utf-8?B?VCtpcGZDQXNzd2RQalNVWUl6VElkMURjTmpDRGlyMFQ4S0RnTjhiTVZtcHNR?= =?utf-8?B?RFBwcitqRHhJWlpMVk5namdMeGt2a3hITTZkcThHajhBZXJFd0dTa3d0ajly?= =?utf-8?B?ak5wK3I4cTB3MzdPQ3dOejBKZ294QnQ2WEgwdHFTempkYktuNUU4SEhzUFAr?= =?utf-8?B?eVJmL2VIQS9hOVNTWkVyQ3htY21FZm1qSUJRc0hqdnNpUW5ndm54RE9iTXRi?= =?utf-8?B?WHdpWkl2USs5MmhvbkRCZEYzck1rQzhlTU1URE1yRGtyZ0dYcWxzQ3BvQnJ1?= =?utf-8?B?Q2RGdTRYMGRaSE1QNnNVeXgrWVVvcnBOY3hXNXNxVVBmV0w5WEVvZTlDMVZP?= =?utf-8?B?V2NaT2lnTGdZbnFnM21XeFdqWlpNL1o0cklQNndIdUxOcTlUYUlzdERNR0lW?= =?utf-8?B?K2hzZGwxWmdPSSszK2wrR2YxeFhoanJkYms3eWYzcG1mVHkxL3lCZ3FMUDJQ?= =?utf-8?B?RUhhdGUzU1phNkNkSmFIZUhJZWVIQkhIazVjM1RxcU4zQ1BWV20xSHQyZ3Rp?= =?utf-8?B?R0F5bUlsU2psdkJKck5xOVYyTjhVZ0ZaWWptclZlN3E3UXNZZlBzRkNzU0pm?= =?utf-8?B?UTIzaVA0WWJQbW8xTWRMRVJSWkFRcU5oY1JjTUE2ZlcxaHlJeDcvcGtlMVBq?= =?utf-8?B?eE1GejVRTVB0ZkNXRzZCdksyWFh4T0hWejM4UWR3enNKd0tWaWZHYlRabVl2?= =?utf-8?B?SWJwWlBYS0hBQ0s2RG03QytiYk9VajFkZzFzZ2dUZTJrZ01OeXk0em1leEc1?= =?utf-8?B?ckthL2JEeEtPenYxRzNLQVByZFhMeXlvRGVxd0t3eGJ2UWVKclJMRks4d3BD?= =?utf-8?B?aGJxa1cyZnhoWEQwcnBpZjdzbklYNXQ2ZXI5Ti9mZGtQSUV5WUVBOXgrbjZZ?= =?utf-8?B?L2hERVM0eHVFeVcyN2p1OHl5QnF3bzBFRzBxTmQ0S01MU3djZ3dsWS81b2ZR?= =?utf-8?B?ZjArblcwNnVJNndncXMrMEt6UTVocEx0NERZOEFhZE10ekM5SkpXelo4Vnpq?= =?utf-8?B?dDUrTXZKYW5pdU1yZnVWcC9jVGdyQU93ZEhmMkF6dE0vSzRVTlRFV2dCTnBT?= =?utf-8?B?MWg1MjFMV0d1cGluTTZLQ1JBL1dBU0YrSDdRbVBuRlVBOGRFWE9KTVZTVm1E?= =?utf-8?B?ZUFEbjdYUFdGeXpaeFlqeVJLZWNlMlVNcmNLajhnajJrcTg1TDl5K1NhRDRn?= =?utf-8?B?eXVBdjFNQUhsb25WaE9TeWVFT2JWK3ZWQ2tPVnpkcEgxL2I5QVJ0S0tONVY4?= =?utf-8?B?OXE4ZG5GdWc0aGpDQW91bFBWTElFblNobmtOd1RWSFNzdUlxN2VHTGdVUCtm?= =?utf-8?B?Y1Nha0RJNjhHYzArOTgyeURrTTBYVGpYRFMrZnNhRjVoQkl5T1dVeGtYVzcz?= =?utf-8?B?TzZyNEhiSERLTHJESjVaeU9ZSnEwMzBnTldCZkIvYXJseFZ6UTFCbjZBN3lr?= =?utf-8?B?bG1MSzY4dzBTbG80U1R2cGJqVEcydjZudDBQUXNqUlVFNW0rK1VKNU52anNL?= =?utf-8?B?UDB5c0ZEdjl3OW0vL0tadldlTTFKeUplTEw0Um9OdHJmRzVwSXVBZ282VW5M?= =?utf-8?B?T0pjQU5jYnd0ZGl0NER2SGRoS0N0T0RDK3NyYW05Q28zdjVJRDNEZWkrZWkw?= =?utf-8?B?T0JTSFdaUmxidllBamtFdEIxcGZaUDVhZ2JhbnkyWTFGTUc5S1lIdkFhb2lG?= =?utf-8?B?dStZcW13Sm1YNnV3UmRTNnk4UEhOYXFzU3lxVkFYSE8rM3ViMFBWVXJ1ZEFB?= =?utf-8?B?bWViU0MxTG5DdlNXZnp5aURDQ0RIblVISEhOWFl6K0ZzdzRhYzZXM1JHQ2Y3?= =?utf-8?B?ZzYrYlVhSHZ1R1Q3UlVDYTBPTFNDQXQ3dVV3SUVacEI4MWc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <22E3D54BC6AB5F4BA7F51B50AFCB46DA@AUSP282.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 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: 05e1e729-52f6-469a-2105-08d98aa6eda8 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 21:59:40.5451 (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: 0WWwLbb3olPU89P31r9TkDHp1L3i9gILrzLsWr1piJ2SxZVBVQ1vTqvf7oLMYGr8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7P282MB4012 Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 22:02:38 -0000 VGhpcyBzZWVtcyBsaWtlIGFuIG9kZCBhbmQgc29tZXdoYXQgZXh0cmFuZW91cyBhZG9ybm1lbnQg dG8gbWUuIFdoeSB3b3VsZG7igJl0IGEgQVNQQSBwdWJsaXNoZXIgc2ltcGx5IHJldm9rZSB0aGUg Y2VydGlmaWNhdGVzIG9mIHRoZSBBU1BB4oCZcyB0aGF0IGl0IHdhbnRlZCB0byDigJx1bnNheeKA nT8gV2hhdCBpcyB0aGUgcG9pbnQgb2YgbGVhdmluZyB2YWxpZCBkZXRyaXR1cyBseWluZyBhcm91 bmQ/DQoNCg0KPiBPbiA4IE9jdCAyMDIxLCBhdCAxMTo0NyBwbSwgSm9iIFNuaWpkZXJzIDxqb2I9 NDBmYXN0bHkuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4gDQo+ IFNpbWlsYXIgdG8gaG93IGluIFJQS0kgTWFuaWZlc3RzIHRoZXJlIGlzIGEgQmlnTnVtIGVtYmVk ZGVkIGluIHRoZQ0KPiBlQ29udGVudCB0byBoZWxwIGZpZ3VyZSBvdXQgd2hpY2ggb2JqZWN0IGlz IHRoZSAnbW9zdCBjdXJyZW50JywgdGhlcmUNCj4gbWF5IGJlIGJlbmVmaXRzIHRvIGFkZGluZyBz dWNoIGEgbnVtYmVyIHRvIEFTUEEgb2JqZWN0cyB0b28uDQo+IA0KPiBEb2luZyBzbyB3b3VsZCBj aGFuZ2UgdGhlIEFTTi4xIHRvIHRoZSBiZWxvdzoNCj4gDQo+ICAgIGN0LUFTUEEgQ09OVEVOVC1U WVBFIDo6PQ0KPiAgICAgICAgeyBBU1Byb3ZpZGVyQXR0ZXN0YXRpb24gSURFTlRJRklFRCBCWSBp ZC1jdC1BU1BBIH0NCj4gICAgaWQtY3QtQVNQQSBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBpZC1j dCBUQkQgfQ0KPiAgICBBU1Byb3ZpZGVyQXR0ZXN0YXRpb24gOjo9IFNFUVVFTkNFIHsNCj4gICAg ICAgIHZlcnNpb24gICAgIFswXSBBU1BBVmVyc2lvbiBERUZBVUxUIHYwLA0KPiAgICAgICAgQXNw YU51bWJlciAgICAgIElOVEVHRVIgKDAuLk1BWCksICAgICAgICAgIC0tIE5FVyBFTEVNRU5UDQo+ ICAgICAgICBhRkkgICAgICAgICAgICAgQWRkcmVzc0ZhbWlseUlkZW50aWZpZXIsDQo+ICAgICAg ICBjdXN0b21lckFTSUQgICAgQVNJRCwNCj4gICAgICAgIHByb3ZpZGVyQVNTRVQgICBTRVFVRU5D RSAoU0laRSgxLi5NQVgpKSBPRiBBU0lEIH0NCj4gICAgQVNQQVZlcnNpb24gOjo9IElOVEVHRVIg IHsgdjAoMCkgfQ0KPiAgICBBZGRyZXNzRmFtaWx5SWRlbnRpZmllciA6Oj0gT0NURVQgU1RSSU5H IChTSVpFICgyKSkNCj4gICAgQVNJRCA6Oj0gSU5URUdFUg0KPiANCj4gU29tZSBzdWdnZXN0ZWQg bmF0dXJhbCBsYW5ndWFnZSB0ZXh0Og0KPiANCj4gIiIiDQo+ICAgIEFzcGEgbnVtYmVycyBjYW4g YmUgZXhwZWN0ZWQgdG8gY29udGFpbiBsb25nIGludGVnZXJzLiBBU1BBIHZlcmlmaWVycw0KPiAg ICBNVVNUIGJlIGFibGUgdG8gaGFuZGxlIG51bWJlciB2YWx1ZXMgdXAgdG8gMjAgb2N0ZXRzLiBD b25mb3JtaW5nDQo+ICAgIEFTUEEgaXNzdWVycyBNVVNUIE5PVCB1c2UgbnVtYmVyIHZhbHVlcyBs b25nZXIgdGhhbiAyMCBvY3RldHMuDQo+IA0KPiAgICBTZWxlY3QgdGhlIENBJ3MgY3VycmVudCBB U1BBICh0aGUgImN1cnJlbnQiIEFTUEEgaXMgdGhlIEFTUEEgaXNzdWVkDQo+ICAgIGJ5IHRoaXMg Q0EgaGF2aW5nIHRoZSBoaWdoZXN0IEFzcGFOdW1iZXIgYW1vbmcgYWxsIHZhbGlkIEFTUEFzLCBh bmQNCj4gICAgd2hlcmUgQVNQQSB2YWxpZGl0eSBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNCkuDQo+ ICIiIg0KPiANCj4gTm90ZTogVGhlIGFib3ZlIGRvZXNuJ3QgZnVsbHkgcmVzb2x2ZSBhbGwgcG9z c2libGUgZHVwbGljYXRpb24NCj4gc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSBpZiB0d28gQ0FzIGFy ZSBlbnRpdGxlZCB0byBpc3N1ZSBzdGF0ZW1lbnRzIGZvciBhDQo+IGdpdmVuIEFTSUQsIHdoaWNo IG9mIHRoZSB0d28gdG8gcGljaz8NCj4gDQo+IFRob3VnaHRzPw0KPiANCj4gS2luZCByZWdhcmRz LA0KPiANCj4gSm9iDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBTaWRyb3BzIG1haWxpbmcgbGlzdA0KPiBTaWRyb3BzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KDQo= From nobody Fri Oct 8 15:12:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793A23A0AE0 for ; Fri, 8 Oct 2021 15:12:38 -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 (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 pgpSrl63cWI3 for ; Fri, 8 Oct 2021 15:12:33 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 425773A0AD7 for ; Fri, 8 Oct 2021 15:12:33 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id r10so33811000wra.12 for ; Fri, 08 Oct 2021 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=MBPjP2y2lsSc5dHgMG8TKEvC+bEhlHaIAQ0KoylqDi0=; b=qTQSxY3EDG0R2TAva1tX/7q3IHTbuBinOQqV7FzYEIWiP8kxyiY7qzl0BS9hIe81Al /kRpcLkob5BGETWj7XbuVeKu/LlEV4alJsudj8EpUbl9xgceE9k1LL8/ZystamYDUEJl dy1b5koQjMpfQ3ftDvkFasLqHsHdlwYs+w5Is= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=MBPjP2y2lsSc5dHgMG8TKEvC+bEhlHaIAQ0KoylqDi0=; b=tLnQp9OzC8wBb6iw5uyMEHYoiCAmqbzp/MzggMwUCXGyqOqpxWR0yfSaIDLDM9behV yUfh3PGihlyunPFxWyHbZHY1ZV7iddh+/wWfM3EtjCKfWXNqTFbpSKZ/WHUl9z/PtBuo qNjCwHYOtvEtBA5hinK1AP+DO4Xij9yqKw8TJ1GJdpDOrNu4bfWgRU1y3jt1JBK1oRyT iE0Ph00DQKDDZPRleQux6oo/ob2C56tqECuMcFgD7KPx4EK3R8lNA975SymBQ8snM4Rk uvRsz0ttCMuvWBaxB6WAmOO+M/kna/NvRCO1ywNzB1IMNZ5PntC85a7SnxPd+L4mvsHU NlsQ== X-Gm-Message-State: AOAM533ZtRk9GhkHwugt7pBiJ5XkYRPUl4Wr+F3IwHc83gFE5BXurNBG pvnS9VPXT5/TcL/MgTnnhqDg2Q== X-Google-Smtp-Source: ABdhPJy06aW0i47iVIasfQ4Lm3UIv6swUOKUgPXkum0GhF6hH4eUMzXPAJN44ew9Cf4UZXLdXhdK+g== X-Received: by 2002:a05:600c:1c07:: with SMTP id j7mr6110607wms.171.1633731149739; Fri, 08 Oct 2021 15:12:29 -0700 (PDT) Received: from bench.sobornost.net (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id a17sm537524wrx.33.2021.10.08.15.12.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 15:12:29 -0700 (PDT) Sender: Job Snijders From: Job Snijders X-Google-Original-From: Job Snijders Date: Fri, 8 Oct 2021 22:12:27 +0000 To: Geoff Huston Cc: "sidrops@ietf.org" Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-aspa-profile add ASPANumber? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 22:12:39 -0000 On Fri, Oct 08, 2021 at 09:59:40PM +0000, Geoff Huston wrote: > This seems like an odd and somewhat extraneous adornment to me. Why > wouldn’t a ASPA publisher simply revoke the certificates of the ASPA’s > that it wanted to “unsay”? What is the point of leaving valid detritus > lying around? Good observation on top of Tim's point, thanks Geoff. Kind regards, Job From nobody Sat Oct 9 08:22:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3239E3A09D9 for ; Sat, 9 Oct 2021 08:22:36 -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, 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 TY02M4muvXkg for ; Sat, 9 Oct 2021 08:22:30 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2074.outbound.protection.outlook.com [40.107.22.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 30D293A0983 for ; Sat, 9 Oct 2021 08:22:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EC3FNAKnCgRYl2mRbHq5jDJPC5MTcNO2w4WdxI2wKEVJ6jRsE2b+HcqCmmaR9bFBOTeG0l+xMuJPr4JtcC6dcENyEtofO0f2hJayO0nC++LtzG4T+OuQlYFxagmzphgYJ5OKbx8wfbtm1IANdmR4kaTcIH6mECfeyLzNBcfIhWuBBOcKubkerMXieDTj3VRkug2F726+mbnzQVNSEhV8rsT3wpOc0T5mbWVyzxdOEbUlJomNF3LGD6rQDCfqW/8jXko+MNXL0AYfdLzJT9bmVGVGo0mNX9zC4mW8jxIswf9PKL0hY7VkNu3bIHxcn/XJCU/XjjDcGTL4VLmToI3/LA== 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=GqyXrgqPvsFo+GZkfsh+X6qzOvb1AWBLFIKhnp/RGSw=; b=VlfuY/1z98CG6WhktAoAmX//dyfuFNSqySL1Bqj2gzRnYq8DyH2YLruVGMu07eplP6iHgPXvNnUh7ytxcPlnDWXuzXLIvpUSaXeNbpqgxprQzunVnitzpooKf3EPVM+hK4e0IQhndUVh4p5/voqgyyAj1DnP/SBIlczP3N0VbjoUvdcm1hksraLGVwrd0rMw6g+U8HNQa9DhRQreysD7ADHVPQfaJCM587d0MUfwAwIBvDcDSmjUNDToJmidN4pvIPesTBNunzkzrYlNi3f9wT1b+56DtlNw4+sDvgJ4cOIoEP2hZ3qzHsU+srExeD1YaDSaozS6BgKO3/cuYKAqZw== 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=GqyXrgqPvsFo+GZkfsh+X6qzOvb1AWBLFIKhnp/RGSw=; b=frD2Hygzsbgd+BL+KTKNq5SGaF3E3SnbMV0/q4KY3HUIEVFqF9I/fPw/50PRCKpT60iUYtwVx7OTHTKLroowqdsLt14UIhosfK44gU44aXcqa89rYpLI67zRNZqPaOuTfU2oEtargjyGe6TrsSYy42DhjVSt2qFh08SkZcnNGhk= Authentication-Results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1366.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Sat, 9 Oct 2021 15:22:25 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%7]) with mapi id 15.20.4587.025; Sat, 9 Oct 2021 15:22:25 +0000 Date: Sat, 9 Oct 2021 17:22:17 +0200 From: Ben Maddison To: Russ Housley Cc: SIDR Operations WG , Steve Kent , Tim Bruijnzeels Message-ID: <20211009152217.f4qub4txmtptrefr@benm-laptop> References: <20210930171302.m7b5utqceotecooc@benm-laptop> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <4E8ED276-A8A2-42FC-B0ED-9BB1EEB0C0BF@nlnetlabs.nl> <90554F86-FA27-4364-B13D-BBE7CA4885B1@vigilsec.com> <20211008075333.muhym3dbscuqmafu@benm-laptop> <26BD1B09-9EC6-44F9-B6F9-E4E8EEA1C640@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g5y2jgvucvtcq7wh" Content-Disposition: inline In-Reply-To: <26BD1B09-9EC6-44F9-B6F9-E4E8EEA1C640@vigilsec.com> X-ClientProxiedBy: CT2P275CA0007.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::19) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CT2P275CA0007.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24 via Frontend Transport; Sat, 9 Oct 2021 15:22:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5d247f6f-8858-4b8a-08b9-08d98b3898b1 X-MS-TrafficTypeDiagnostic: AS8P190MB1366: X-Microsoft-Antispam-PRVS: 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: fn4nv3fzHsSBXAy1Kw6y1E8f88p1Pf9xLgeGIH2+Kbl2K9lPWEgU3fV3/LgRpg4zRSqUZelQKHasi8kezXQ1uu5D/+J3G89xLSdrwngXzMQzKviQ2LgsIoyPE1fy3JFi8GHZ7rfMGpJIg2eeiJvXzBM+H9K2S6/iDPCe2Zj4GPAhkX2wdPKFpTONVuQvi+rJ/N4gGuU4XFpg5n2dA2YCnLXzemaHO7fsAmo12PxUCxaqmedLRoKJ8VxtyMc1mF1kBeNDHnyKL/cvyVYl0FE0eU8OZUH5VHA7uLu2/xFjJH4vn71ID5cj1tIJYUS6hn46pi1M0sZIZ1c0G7iA40gBjjF+CLj2cmyBs3RSBN1uwAsVGxTkQBjIq64EWdFQrnlamOU6SlSd8zA4SmABUmMcUjfsJzVYCTpGEarccwcx6aijMTdnzV6YCia3BvTj9dBNQuTjUPce78ad/aeBOIjUMMok51BbEFP+CR0H3T4XytqRkf1jddALh61GX6DUvTJvPu+9KZ5AuQaniu4dkjHz1LBIwh34oYo3H4pCqvvyu+DJZuBxNLyDOkXpBs+OL8hawQsFXcr0RWRI55DwSpTzy/dLBgJSbYnxVVUUpubgJwrnO3F5ZiPIhlw8VapJX323tY4t1sBbwPuKHbS0FdYvwvUKsO7sr/ZFfCZwphNqhfXclwIR5kZMYSEP4pZJZ89/V4Gxf8svw4tOt/Z/nU1Tonl1W5+nKgIFhi/+jIJrUYsgBkNXaxEv2iHT9ezL7mNu 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)(396003)(376002)(39830400003)(136003)(346002)(366004)(9686003)(54906003)(83380400001)(2906002)(316002)(956004)(186003)(8676002)(21480400003)(66476007)(66556008)(66946007)(6496006)(52116002)(4326008)(26005)(38350700002)(6916009)(38100700002)(5660300002)(86362001)(508600001)(8936002)(44144004)(33716001)(1076003)(6666004)(6486002)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wqDh4tQQFNmK3S++0JIIXLXWJf28p+KYRfEa9zKr4SWNEJfc+nJYnCDj5mTH?= =?us-ascii?Q?eDsRdzAXJLUpD18EO136v84pABIdqIB7NjR9mLE5byOAZeRh5uRs3vJA7d9Z?= =?us-ascii?Q?Wc7mPem1iO57aEBvfPze92L0nTH1aexpV9NJi8wriIiAoymlciQ43YIMDm8Q?= =?us-ascii?Q?n+38DvVMQi8JThIL5K3keEX2HL99DD+rsH/LxeNxiYGMT6Pfg58K1IZ9Lzu2?= =?us-ascii?Q?/S3cSPeKqtg6agfqTmlcadpE1wMHWNELhMIuAjV/L/tBlu/uGVFN5EYrwgpY?= =?us-ascii?Q?qgmouE990FGko+V97jPgoAzOaXPsoi6N6F6ByutRm5AFujZmJEYEHCh1rU/E?= =?us-ascii?Q?amaLarH70ct2zvSzHDfLk3cxnKi9YrR7FPhPwJzY3Thso2dXERDUoIOIP+Zd?= =?us-ascii?Q?OWerWSbh3/Lc/1RELlSI9e2uGjHFpIN9O+6pcr0xVIFbFKJ95p/ZqLsBxeeP?= =?us-ascii?Q?sdOd14iEqbkpXsUerEpjfHnRNnNRGlJqUThkGIaqB21UIYUoqDwqgezkBKi4?= =?us-ascii?Q?YR9ytNQoGrWEx/YfvU3BvknaD4533/bS1MIG5Ol54W4XXvwbjqUrDcibSEpz?= =?us-ascii?Q?EAURD3cH4WRiCXrf5tXO9f1L3oWpDGOOXAPx3KMr0c41AE80y6Hl+Mlw7pxM?= =?us-ascii?Q?ENncRswFtWKQzM5mz2DTa9cYlD5ksRbsfGdPMCcW/uCH454BgroQ9Hitt5+B?= =?us-ascii?Q?qUMmmAitSMWrJ07xmCc0lRJUGzf/p64CC7YHrp7HUJRDhdXOs6gRB7rRm1dj?= =?us-ascii?Q?/+4TAAbdUcy6C94Y1a6nbDoFR59pctwlW1yJ2s4iwXbwlJIgbcyEpdXq7KA1?= =?us-ascii?Q?ysRVRlm0UynbBxIniEQhmIrON1mq3u1nuACLa9iOqDVwUMKqlY3O5MNZ7Dut?= =?us-ascii?Q?+JVB8z+QJrA07ysaiiOseFpA+JVoGWi4fBPhOCO4Fed4WaUq9SmhYSjeuZ4i?= =?us-ascii?Q?7/3eL1tMEgkXWKVqYW6CeUgwxRfXrlmJ7PIGCTtJogbVVoK3RiG8NiiBVD63?= =?us-ascii?Q?u9VjcQxXYcVv0y7xRLtajHFkDpnNf1qXdZrPRKsExJrcXp0aHps3BY3ILDl4?= =?us-ascii?Q?QU3zumowkA2pSlKao7FpPQTJ12FSgEn0U7OawbF1WnGqsGKnq4eaPaUIwTS1?= =?us-ascii?Q?vR/EsJtkiYbCywVr8eJLFqpcvmGXPhZ9pufR20P/Nc1yg+CQMkoE9W0f4KDu?= =?us-ascii?Q?ccAqgWxg6LbCqg13odeWy8IJcDXZ1sdc6Sz0eeqiRPA/9KQkI6f0xXrO5kLB?= =?us-ascii?Q?zPN98RGGTnzItmVfAofpZoShw4D+Deut/URzLfqzgS1XEaF5pwgNK8ammryK?= =?us-ascii?Q?bzh/pqMz0alRk2A1Tni+H+JA?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 5d247f6f-8858-4b8a-08b9-08d98b3898b1 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2021 15:22:24.9139 (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: 8XbkXAloOUgPsI74at+KFA9ajj6fOe7zZBq0tz47m0NoQrJMYRGQCgxEsHNrW/RDL/YN6+5say6K6Jx52nRY/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1366 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2021 15:22:37 -0000 --g5y2jgvucvtcq7wh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Russ, On 10/08, Russ Housley wrote: > Ben: >=20 > Different ASN.1 libraries are better at checking various constraints. >=20 > For example, in pyasn1, these two are equivalent: >=20 > ver =3D rfc5280.Version(2) > ver =3D rfc5280.Version('v3') >=20 > However, it does not complain if a value that does not have a name is > encoded. That is, it just uses the named values as a more readable > way to set specific INTEGER values. >=20 Yup. But it was not accidental that I didn't use python for my example! > >=20 > I think all of them are roughly the same to implement, but I tend to > like the ability to talk about values like "v2" in the text. >=20 I absolutely agree in the case that one implements the necessary data structures by hand. However an ASN.1 compiler will usually generate the implementation for you, and will need to choose how to represent the ASN.1 types in the language's native types. My point was that we (module authors) should consider the hints that we give to compilers in order that they can make good choices. Cheers, Ben --g5y2jgvucvtcq7wh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmFhs6kACgkQOkYk/rSL aGBSRA//WPIDJOmgbcNXjdZt97I+Iju1wtHRSRxKubLZGdzpnOkmhpCPVwOIqxK2 hHakgJ1oKZ4SjxnK/3kK74Pk8rzD8PTuwMVlkQhEm5xaa1wpMomWDNFdecMH7qDG +1gDikOK+08qn8UDLK7tU42/kA0cTZqVUlXrPTYSFbLFf5N/jmkGLRGaLMiF27ks mh328ezziArsxR54EJh79yg4c/AYOgpH08Lp7mTwFUeV0Yh2RzXM/Oz3j/mJ8jiu o2Ph78QCL4rO4TybMcFZK83wZaosU2pAv+ioH46NV2q6yHnxYJv7BichJXCqsogJ 1diPBrh/aMJW6TXOWiapWg/DMUU7D6ZEVqP51iEFBx9QdQSorQwo/xlZhRcFDC2i 5eUb6UM65wSd1ptZL/sZpg8dmZcichjFtYWxLtNRzqkUGnce5xveGOxt6CZvV2KY lnAKZLG9T13BNSOekOtszaJ+uZ3tBefj0943uBKxauvpchEfM3pNEyAaBG3YFQdW rWCLEVehAVRs2vQT6vn7UxFqQFUm8pbos16DZHCOrNYKNd1XnpIDmtX74eluoFng bjGQ/zumsMffIKVrR9c/PEJJkQZmmZnyxFb4pTZNyoup3hRuqz2bJu+xtZ+3YZTV S3V7mNEO3nqhy+IFtwRwRa3HJDfakmAgK14L+NxDXYNf8fBlON0= =O+ka -----END PGP SIGNATURE----- --g5y2jgvucvtcq7wh-- From nobody Mon Oct 11 00:25:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789B53A0474; Mon, 11 Oct 2021 00:25:42 -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 whxbEeSb0Yrr; Mon, 11 Oct 2021 00:25:34 -0700 (PDT) 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 87C793A053E; Mon, 11 Oct 2021 00:25:33 -0700 (PDT) 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=GWaTDzp8spcN7dXjWjTcjJi44AlMS2MdU8tRQga4dVo=; b=o+scGv58F7rAx5gJk0oHWBYk kTRGlqlHLdvFak0keZPPz3SDwPC5tx2vWG1A9EthgBWk8qCncEIYGg8IWkBwrEskFKnbyRBgxnCA6 nM9YJ91/de/dEyPyMR0OZwwE8baRCmQYk030gcpoLt9cFPtnQaZceNYu9PHiI0iH16Hlhcg5cA4IN RjNvB2YON5z2cxk6j48FYOdZZMA2kMfbrrp8gNcKThraRnbGYBHwfbYxWFdGwpF0eNpgSpJPmsVSR nY9zgTNReuBcbzp+ak3wCNgoJdBjjZmDZRsNICDOc4AF+TyD9XomlzdOTEI0/D7vYVKzs2tPZ7xao Opc9WULtLw==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:39198) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mZpgg-0004W1-9U; Mon, 11 Oct 2021 09:25:30 +0200 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 ) id 1mZpgg-0006CO-6b; Mon, 11 Oct 2021 09:25:30 +0200 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 In-Reply-To: Date: Mon, 11 Oct 2021 09:25:29 +0200 Cc: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Morrow X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e11cd507f3cd5283cf4b3bc2591ad11f89 Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 07:25:43 -0000 Hi all, > On 7 Oct 2021, at 19:26, Christopher Morrow = wrote: >=20 > howdy folks! > This got some discussion before this WGLC message ,but none here... >=20 > So.. all good? stop? start? restart? > dance around a tree? comments on direction for this WGLC would be .. = good :) It looks good to me. The only gap I see is that there is no guidance (or mandatory checks) = on manifestNumber nor requiring monotonic increase of thisUpdate (since = there is no mandated syntactic constraint). This leaves open undetectable replay = attacks. Given that we have seen monotonic counters regress in the RPKI in the = wild [0], if we add such a check, I would prefer that we check for monotonically = increasing thisUpdate. But given that (a) an attack can already withold updates from a certain = point on, without the updates reverting and that (b) manifest expiry bounds the = time window for an undetectable attack, I think that we can skip addresing = this gap. Kind regards, Ties [0]: A snapshot of a non-hosted CA instance VM was made, it published = some RRDP deltas after the OS upgrade, later the snapshot was restored, causing = the RRDP serial to regress. From nobody Mon Oct 11 14:19:25 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5473A093D for ; Mon, 11 Oct 2021 14:19:23 -0700 (PDT) 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 oB4VMFjkcAlQ for ; Mon, 11 Oct 2021 14:19:20 -0700 (PDT) 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 10BBC3A093B for ; Mon, 11 Oct 2021 14:19:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ma2hV-0005D7-RW; Mon, 11 Oct 2021 21:19:14 +0000 Date: Mon, 11 Oct 2021 14:19:12 -0700 Message-ID: From: Randy Bush To: Geoff Huston Cc: "sidrops@ietf.org" , Keyur Patel In-Reply-To: References: <587B10C5-0C16-489C-B7F3-12AD4BECA1AA@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: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-rpki-rov-timing-05.txt - ENDS 10/12/2021 (October 12 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 21:19:24 -0000 geoff, reasonable questions. exogenous issues mean that at least i, for one, can not answer today. i suggest we leave this draft to mellow for a few months. ok? randy From nobody Mon Oct 11 15:28:11 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E43A0E83 for ; Mon, 11 Oct 2021 15:28:09 -0700 (PDT) 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 63nTWlZ58ECR for ; Mon, 11 Oct 2021 15:28:03 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2064.outbound.protection.outlook.com [40.107.107.64]) (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 D17AB3A0E90 for ; Mon, 11 Oct 2021 15:27:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eB5Ad8UJ5nZbeOUwy9qsOpLd0muokBWiLuR9H+sIE4Np+IW7hxVjZpUNQMA9wIwbkECPy1XTbmKHWDsAK7h/fZL8EuVpbqflhRvH/AidsGuYm6/31a/JXvDSACC+AEpk6DTGJlvDlL82/PzwVwS2HF6KkGumzWJHZhaPk3OeIXOcbykBYX3dRG85Rw8yIZUwqD3DeupAIO9WdF/YIh+eLumG62UKRpCR5LM+WdcbklE79neFVAPw4Qta+Sja7HlySlW1aw/6Li15ts7XRqJocptxyWjfJ1IX+aS1keCdY5fqXSxOkqwe6hypEM1dOERAa6Kjde4z2vEpAeIsOTSkqQ== 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=y8gnBXuqBU1G/RgFy5Yz+Rc2wBgiB5Hpwn7erAB9lzk=; b=Ju2YtRFR7B+SgAfp/YvXMA4vE+NWg61/w00N9AYnJfEYIk+sTTbFZIPP9I+sRxCpjyXvkqHWUjArd7UEVMHiwS/889xsS+gDygSYdF3Xs2FL5WJX5EsLW0o6Y59HF/8Nb2m+QNJOTZhFyh9Jd4ywSlbhWltGuJzbv/6ZEN/egKoAqEPfbYB3nf8UEE+jf1lHwFFpDvDb/7zrGdHOog20YdnmB0F1VeiitCPvhoNPPy7otywnLHR7YG2a6j23KcD29g4qlXpdYagpP+3617rgk+ArIPyFhUpNzbZ/t6kOb1Jd3rIc4OjLpMa6uJ0FqFI4SzlEcaaWEUBFGmJFoW2mtQ== 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=y8gnBXuqBU1G/RgFy5Yz+Rc2wBgiB5Hpwn7erAB9lzk=; b=fFE4j8WmCy6efLxBp2UYwALQdTuWXYdZWeLhmDXCURyIEaBy0ruch9R1SmEhSU7FMwDvuibfTs4/mFiL63uIvqYIDOZPQDSd8uS6kqDj+Mk9xinJPAu2cZ7NuT9tyR7dI3DgbaX8U0gxLKIVpZSuoi0lAwSbi4KcpeXItGZOq2o= Received: from SYZP282MB3169.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:176::18) by SY7P282MB3995.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:1ee::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Mon, 11 Oct 2021 22:27:25 +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.4587.025; Mon, 11 Oct 2021 22:27:25 +0000 From: Geoff Huston To: Randy Bush CC: "sidrops@ietf.org" , Keyur Patel Thread-Topic: [Sidrops] WGLC for draft-ietf-sidrops-rpki-rov-timing-05.txt - ENDS 10/12/2021 (October 12 2021) Thread-Index: AQHXsxdu44A+aBVb/kGKpJHcHChwm6u2+nQAgBdqogCAABMOAA== Date: Mon, 11 Oct 2021 22:27:25 +0000 Message-ID: <0FBC292E-363E-4209-BD50-2C4F82DF222A@apnic.net> References: <587B10C5-0C16-489C-B7F3-12AD4BECA1AA@arrcus.com> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: psg.com; dkim=none (message not signed) header.d=none;psg.com; dmarc=none action=none header.from=apnic.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 018c3ce1-1e80-4948-2ddd-08d98d064d46 x-ms-traffictypediagnostic: SY7P282MB3995: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sOJkzswj8EBSpoUJZ8MT1SiVWC2SeaGyzZDz6KDtp/QiMnPMpnciAqeCIenRBXctzjuktQVosbkjTgl+K/JZ09vFm2BFGDH6IN4crU7dGnF6HUp68Mk7RGlMoD7pu0sFhsqV7Bnh8ZSaXj0qML7uIcmPAByNyDACy5XgrBRU3Vsxe3abboTODcK+IOD1JAF4017TIq7lNmAwvy2eZ/CvfJzuc5hcZXGLXYsj50iBqCzHn/sLiGJhpuSiQPMWeld/7pfJDj0L0DuMlTfhHEDGgGO/PjNFbHl/6IOL0v2Ix6OJMxPI2UlBDpR+8/gMXXgUZBvNR4U5szj7da2y6zvFRrKUpW69MMKlO8bvdu1+dp69G/Zk7l6dbDqMrcL61dzQM9vls+ljmpzBkduDwG77nSh+Dr36+C/kAchc+onTIj7hkXNvQJhXpV8gdLrrgcSQ/ejin/+eDM8j27E+G0/UB2lXVcAbPkgVK8C5qWsxKTYQKBm6NfGGfHKrDckZuO3AxAIOpYUP5XEc0eMDD+cIaFkwrFqsKerLNAuMCacKH4q4kC0pCPayqx12VPJq8vVJRPTs7Q2Q5ht/bQzlkpjjKMWJF4cPrWPTzvfWQ0B7lNQtonlkHAlHNn97pj8+WFfKG+3jfmnS9GJFrEzmaFLew1cXm+JVQv+CyZPrmwzMtsdrGnKD1ImWVSf9L6xbor13+/GRlekBeGdDdJAhV2iMW42xYCAW4oNlb6JKpVtC9B0= 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)(346002)(366004)(376002)(396003)(136003)(38070700005)(38100700002)(122000001)(8676002)(66556008)(186003)(6486002)(2616005)(66946007)(4326008)(36756003)(54906003)(5660300002)(8936002)(6506007)(64756008)(2906002)(71200400001)(66446008)(66476007)(53546011)(6512007)(76116006)(316002)(508600001)(4744005)(86362001)(33656002)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?aUTzdIkNJYtERCbg/3K6sLWF1XqpdMhT/MF4KxWFydT3ydPrLH6PWYWjxyHa?= =?us-ascii?Q?NCadpyU9yl5pEHEGuQe5J5M5i8RkTTWTzBWxAU4t9CLLJ9XhEO344FnsrA73?= =?us-ascii?Q?6kdndNJrkp1aM/TdKQQvgmQK/Pb6u6vi3F5rNlfmt0zE9urPAY/FkMb+QgjV?= =?us-ascii?Q?MJ6eyErfuD5ijkTHpeGbiShZslYqCQ1A+puwypd5obR+SHufTSIqm2snpcF+?= =?us-ascii?Q?aaqB2+Ef2fu8mFw2xCG/LIPS8RuA5y2HSVhTOtIkHw882PBUJdl1oIFmrPQW?= =?us-ascii?Q?xiB0WWdtfW85YAUaJ+GjdPK5AM6OGiJiUu+UdUulF0rIo6c3AfYxOHc1dqob?= =?us-ascii?Q?wtCmUyptmscQV8kPafCSsWMli2Bfdg0F4C1D8Uv/F0oEnpjCZVNtIPC6+zpW?= =?us-ascii?Q?C2rkGVmaoswj1iatAhBVLiHJhyhUMArh10KdZRIyCUV9mQ0f+FYKYZLuQN1O?= =?us-ascii?Q?g3i6XGD8Xjx+Hmmu4kjfdVC5B6Ru0V4Uzp8oUxDm+HhnIiC/EBIkWB0J/ssa?= =?us-ascii?Q?c22EQ+4isa/xf30301Z0EdkWru+xn/CxxHGRKzvBji3RSjHe+ZqWqdXVq0lE?= =?us-ascii?Q?PWmGIxZUSWoVrqJExcI7f65H4obaEdGxeL9E9m6g0XPBgUS/NpkBo7xklOPv?= =?us-ascii?Q?frir7l6TuSqHVyURR4puEJs6uwitCaGswm2oynFb5j6dVFyPyeh2Do6G7QOE?= =?us-ascii?Q?3KaDFScxH9FgtUGLdVCNH2Z4kdYGJ5DMDTrLffWHcK31ISm+uBJzN7YQo6lS?= =?us-ascii?Q?ubU1mNo/1+SNezQMYQhgCxNDGbtln+AoizPq8oD5z2TOLsOpgOsBQwlJeJb0?= =?us-ascii?Q?IhfYlW4a806S6H5CbcPTIVF1GhZO7FGXbrjV3gBT8OwnQ/hiaI/ZEO69UstG?= =?us-ascii?Q?Po+qSPdegBs3LDHOLsnlgIY4rELatNK6IwyRVFUWD0p6gsy1XX6GwYjS/eiU?= =?us-ascii?Q?ThCz6+ZXpd1sb4V6uEe/iwplqjnloaIH/uIJsIhEXtez5Z5rkCeh41Hkx71h?= =?us-ascii?Q?4OKAwSgT6Slx0Ox/Anxz9T78EWkltWdu24uQdJXvE9C+POH6f0YiQ9UyDW21?= =?us-ascii?Q?zzp9ZFDJTWiKSxcsyZign+FPnGS2vJ2cSMq7Tqa8EZT9MInH1f1EsIQnp6lp?= =?us-ascii?Q?MNrVAHVPdVLBrudxrdUXY10xCTI7M4xa0HIQHdci4MSaMxem6m/JLq/Jqbkq?= =?us-ascii?Q?GQxIw4pgCEKryuB6WwsimUKKZcXn4BkzAnNWOc2NkgC/V4o9Q/Wwm9OLKY6I?= =?us-ascii?Q?ZB2ukbrkeBJsU0sicpP2XeBDxdNKgImyj5pTUx9KwIotIMJkIxWXuyoN//rw?= =?us-ascii?Q?jLDjGDm9WWby+2fOjnD3vRmasf8SSrfNCVsJaBOQtzY1KwNergvT4puQclbM?= =?us-ascii?Q?bjT6kj/T6I3yWZPiOn3FtQ9jeLlT?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: 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: 018c3ce1-1e80-4948-2ddd-08d98d064d46 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 22:27:25.4226 (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: /RTt8ZUIYuqjaM/AcpPVZPgJyl685iOu+0n8fibzDYsSb7OrJTIcVwirY1bdME/d X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7P282MB3995 Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-rpki-rov-timing-05.txt - ENDS 10/12/2021 (October 12 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 22:28:10 -0000 > On 12 Oct 2021, at 8:19 am, Randy Bush wrote: >=20 > geoff, >=20 > reasonable questions. exogenous issues mean that at least i, for one, > can not answer today. >=20 > i suggest we leave this draft to mellow for a few months. ok? Yep - agreed. The problem is about figuring out the parameters for a demand= pull architecture in a system whose scaling requirements are unclear. I will con= tinue to poke around in this space looking at the tradeoffs between responsivenes= s and scalability. regards, Geoff From nobody Mon Oct 11 16:19:04 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0433A10E8 for ; Mon, 11 Oct 2021 16:19:02 -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 8iqc4epkK_-f for ; Mon, 11 Oct 2021 16:18:57 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2086.outbound.protection.outlook.com [40.107.236.86]) (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 6433B3A10EB for ; Mon, 11 Oct 2021 16:18:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gxCks8qgKLUOTI0ww+tWVBAtwf/jW1MK69+rVTfIMX7x2N17g68ujS8v04T4JEpb7QNkApteawzuEfO/d+fiO0C/IzFReLYnw97Ndz/QjDtksvAkpCmmWzbIppRt2wW+jnCBM27AArxZZfZ4/tyvtPdQ+/AUObzAyOtd9LScy8UIAeq3w5k0tgBbxNaa9UaW8Au7qmWS3FZjxUteOP9Epnhk5uF7hYpeHtJ2ciCAv3YR9qdg83+xaiD+2A4c3IATij3UHm7TkbHrWuStxdyTJ3GN7KpZB7k/H6wCvM6i540hLI9aH+D9Cw2cK1nqx27H94HGFYZt4FxPWoHrse5ojg== 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=DgSb9Fuir7pSP2NqfKOd3IQWeJE0piybl3KwsxhaRmA=; b=Lt9+Rb1wtPpnB05PgfavEfZD56vkAeH66PO2O9un/v2oMc0JGvzxktnvq8iFmJa48CU3njtgxzDZXsJdsuTBXkBeJX/gYSBbw48CE2PdKIJrizYxZYMDbAYIc6ajVLf8rSYCCAHjZbfJTGaxmJljTbqTdK4GKS6T/yzLXLv9SfQNE1+jQ52apc6Hr787oAGLpRtQ47b/k3PStFiB5bV17WExcR8tqnWIq2BqZDCJ8CoIZUOxMZp3S2qWPbJvMcQT00Wkpatzb+g92CUEzT3wJFNQ+hbbbw3GhqAHH5qErABL4S/1Csyd+hOYl3cTVRkBlhYTOfwQYGAOHaUnNTdQjg== 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=DgSb9Fuir7pSP2NqfKOd3IQWeJE0piybl3KwsxhaRmA=; b=stAqkFgtnSSUtxcizFxJSD3oJvbrHuAP1Ncuv2BRwqOGkXu4+dte+IRnHDWZBYalysLWlASG7U1jQYT2iyt+mmrPZgOmPF79UBYLMfaPC7JjEIJqa5zhctdywWPyKcGZLf7zNv6qrLsjQdIY34y9JeUO9KA79C6yD7Df0aMIvfU= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2965.namprd18.prod.outlook.com (2603:10b6:a03:10c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Mon, 11 Oct 2021 23:18:54 +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.4587.026; Mon, 11 Oct 2021 23:18:54 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 Thread-Index: AQHXvvZc+8YeGz+IwE2My04GI0GE2g== Date: Mon, 11 Oct 2021 23:18:54 +0000 Message-ID: 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: ceae9efe-13f4-48ba-4b64-08d98d0d7e9f x-ms-traffictypediagnostic: BYAPR18MB2965: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 25IMutrekgyV8GCoZEufwnK0Qu4NVoL2YzUNT26U3bdWx0Ybb6aUOyWqABAzPIq3tYdJ0ZHq5dIX8nkeAJnnSq6S2+e9W4rIGu61Tg9YqyLlFB38IrF+itIFM3bbtVAOISbCmv6aSeAlJR3Saj82eT2WpU5PR32uZETB4GhYY3ic+P+dvcji0MeVvTEaSSmureqHmnXrTFsEGHsMSyQ9m+nNvuW6inFLd0ZcMRJzuwXrb2AUTvqXun90E8u3ygwqcW2wLeSnUbM34rtRZIHgPDxpsdv1DWREvm62eAvqmZyL70ExI3tAr1N0KXA/zVxCsX993xQgy0+L3vJ9DrzAJ3Oa0Lwk3wEliME5WtJniywpKzZ95mipXb1ZEgGht8IunGQ4Fl462ANZvVPhNYHFs+0Kp9++unz/Omjd69pGe3BiV/Nztk1BwgX4Hla9iq1lzxm5Po5Ie3bkhXar53xkmll2b4P8oc6LlrPlBaF/X+cZQgi8WS4BjiymMWK0FgTfCzq9GM8Ani23tiq2KCIAR7ch46A/z+gbBI6hx8A2rSxGAy0r+j+O7zO4jMTeK0kDxtzRV0ZF3TCrG0nfSzdqw09WiWWsfmBrPpasdIRIEz4PPaR316WQkHFliuP0o8t/TlX0kn3IivOM+4SGnOXo6zis25r2CLwHItM70t7ShcAKd0cyzAEvQ8r+u5ixtQfSaUhU6vczuXgR0UIgCB8NtTLKYq3e3TBEKvN43JokOz9sI9Hg+TPCU2WEJPRsBDZ1S9hgXQjBGHDwgplLwk5r27KhV+zxI/jjo5X7Logj7O3EJtOxYHp/HqSiZAzIu6mg 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)(396003)(366004)(376002)(136003)(39830400003)(38100700002)(83380400001)(166002)(8676002)(8936002)(316002)(2906002)(86362001)(122000001)(66946007)(186003)(4744005)(6486002)(66446008)(64756008)(66556008)(66476007)(33656002)(38070700005)(76116006)(5660300002)(26005)(508600001)(71200400001)(2616005)(6506007)(36756003)(6512007)(966005)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bnNVcXQ1bWswaGRQUlhMRUpPdnJ2L1I2VUIxUkhNYVFSOGRQNVVaZEtua0pC?= =?utf-8?B?WW43Kyt0VHM0VE1kdjZkZVFtYi84cVZqV2dUM3pIVVBhRFo3VzdMR01mTkJ5?= =?utf-8?B?NFdFci8yR3BCbjhMcEV1RVY3WVBIdGVGa0NsazJlV1B2UE1nOGtDcm1qVVV0?= =?utf-8?B?QnQ0RjdoVDJlY2JKZkJ1eUsrOGx1akJVSFZvaEI4OC80M1MxME1URDRnaEhn?= =?utf-8?B?MzhpZ0dCMEJYbHp1bWhFYnZtL2dnRy9qU2txU2FMMC9kaUpZUUxXVldJWksy?= =?utf-8?B?Q09IN0NXTkxBYkJ4QnBLYklMUnhNVmJkR29IWVVlMkVVNFFpcDJQUmRycE0r?= =?utf-8?B?dGd0SWR0OWlxTFgzVkEwSU14Y01nNGdDK0t2ZW9pOTh2REhVUnNQRVVTMzNa?= =?utf-8?B?amhmNVhkWS91YklKckp5K21zMTVqWGUvUy9QakdYTGYzUGMwRURTelpjem40?= =?utf-8?B?L1VLSUxQekJsbit1Q0VjaCtpZzAwZ3RYWWt2T05FemxEejQ2RFE5L3hzdlhy?= =?utf-8?B?djF4S1BHRC94dmhpeEU3S0tzT2JvMGxmdjVXazNSZDRza2ltaEwweUlvRVlV?= =?utf-8?B?L0I2YnNOS3pORnUrZE9mNWZXNFcyTDBxNGhXR2xVa0xjbkhkNW9QdnBhZU9M?= =?utf-8?B?RHlPV1RPMCtoOUp0Q0p2anBSZHBlLzQ0Vi9uck9oQjlETXpBbHVtV1drZHhm?= =?utf-8?B?Mk84MnVVQUQ5YkROV1BpZEVFWVE2dmR6cGJHWGlEc1VJcUt3aHBDSk1FaEpz?= =?utf-8?B?L3NxTEgwVGdrQW1aUzlqd0xPeWdmQ2tFVWRaVnVBN0oxY3VtUERBck1JUlow?= =?utf-8?B?VEcwNStuckRvUHZHTkF1YUNKVFJyRG9LK1kzVDFVVDF4Ny94bDNTVnRMV1Fz?= =?utf-8?B?ZDdLTjBTUkNUaDJ3RnN0ZnloSE4vTHplMWR3d0tzNDFFNDk1NVRtV3NRNTdF?= =?utf-8?B?WGFLbmFheURjNzVkdklCOFphSHk3NU9LV2lYdENFZllEV3Fzd3lMUU9ESk50?= =?utf-8?B?VDFoTjcvUitFZXZNZGdiSzU5dCtUUllRK2x0Ni9laEFRUXp5MDZWRjM5elpI?= =?utf-8?B?MjlpZ2Fha0duZkl4RXVnclZGcHdqcDZvMWtVcFpZTGYyWDk2dGFXT0pFblYx?= =?utf-8?B?NDJUNkZGSDdEb1NrMWFEUHhIUGk1c2p0S2pyN0Ywa092UGZDR2ZUN2c5RG5C?= =?utf-8?B?U3JhcjgyOGJsN0F3R0xPUmJCTVBSRyttN0R2R1ZHZzhuMFFOdGt4SmJGamc3?= =?utf-8?B?UGc2d3poRm1ONGkrc3k0Y09zMGRLNC9FcG16dXI0QmtaMy9VT3dISDR4QSs2?= =?utf-8?B?b3RWZFNxZkJVSmtINkxrbFE1YTZPdnJlM3lZSkdyQlNxNmV4MzNBSys5NGFm?= =?utf-8?B?WG9uK0p4UEc1MGxnREY1SkIvU3lFaE03NTBNM0E2bUd5ZDF5c0dVM3VDTmRO?= =?utf-8?B?Q2gyMmdzdzE4Z1hrM1NlVmlvQ3hEeGhLKzBLbFRNakU4S2w0Y3V6UWcvRUM1?= =?utf-8?B?Z2lJV1VnbTFWYVQ0NHdVaTFnNW9URGJIaUVGcys2MlBrZXJvMDFvaTJjWUJF?= =?utf-8?B?NjVuNFpxcy9yVFdNb0JGUXlvNVVQOS9QVFlYSkMrTitUdW40ekRoMC9jM0Fz?= =?utf-8?B?dDVtdzZYWi9RSElCUkljM3I0VDR1TUg4MnhUeHNxY01NRm10WE82UTdwYzhk?= =?utf-8?B?bXlhbEVxVHlaM0JjbVRtMFRuWXhvbEE3S3E1b3VHSzhqZGFCSWxMc1gzSkVN?= =?utf-8?B?RU1FdmMvUnI0OWNjVnU3Sms3cVdaUnZJRTBLKy9UWXI2Vkc1K1FqTE9PWTBG?= =?utf-8?B?d21yR1R3MzJJRzVBTS95dz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D4551D7BDA7648419F6E0C3CA4AA0922arrcuscom_" 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: ceae9efe-13f4-48ba-4b64-08d98d0d7e9f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 23:18:54.7276 (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: UAM26LWmbkNYRtnwSoK7c0BFDv8nGhdqyhbajOU/1gqrEQSk6J7WxmAraeyyJ/xRFlSVbW/0HwMcLlqcsAcMog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2965 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 23:19:03 -0000 --_000_D4551D7BDA7648419F6E0C3CA4AA0922arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVk IGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOCwg4oCcVGhlIFVzZSBvZiBNYXhs ZW5ndGggaW4gdGhlIFJQS0nigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIg Y29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE9jdG9iZXIgMjV0aCwgMjAyMS4NCg0KVGhl IGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOC4gQXV0aG9ycywgcGxlYXNlIHJl cGx5IGluZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0 aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyAm IEtleXVyDQoNCg0K --_000_D4551D7BDA7648419F6E0C3CA4AA0922arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIEZvbGtzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0 LWlldGYtc2lkcm9wcy1ycGtpbWF4bGVuLTA4LCDigJxUaGUgVXNlIG9mIE1heGxlbmd0aCBpbiB0 aGUgUlBLSeKAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4g VGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldHTEM8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2lsbA0KIGVu ZCBvbiBPY3RvYmVyIDI1PHN1cD50aDwvc3VwPiwgMjAyMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0OjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4t MDgiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRy b3BzLXJwa2ltYXhsZW4tMDg8L2E+PC9zcGFuPi4gQXV0aG9ycywNCiBwbGVhc2UgcmVwbHkgaW5k aWNhdGluZyB3aGV0aGVyIHlvdSdyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIHRoYXQgaGFz bid0IGJlZW4gZGlzY2xvc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5hdGhhbGllLCBD aHJpcyAmYW1wOyBLZXl1cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_D4551D7BDA7648419F6E0C3CA4AA0922arrcuscom_-- From nobody Tue Oct 12 07:47:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306683A158A for ; Tue, 12 Oct 2021 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, 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 XL6A0W3-QhFL for ; Tue, 12 Oct 2021 07:47:51 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2125.outbound.protection.outlook.com [40.107.89.125]) (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 ECBBB3A08ED for ; Tue, 12 Oct 2021 07:47:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CFYLWXYHdtaioAnkpwLkLQOi3v8C7RpFAcH8agMp0v+XFOExAsnSzduziKqimT3JoOZz2hpKdqhyLEnhIq/G9TJfs/OzRx+4kD4QEkNiAx/Ez+5rF/DGryAILsjpyBGnJIevLxuZBOaKqDU0Yf/54CNtXbP7eAyWbONM2v5bEREAmrENcQ68/DMjMbhifAR17TGayF6UNXInYellksSHx4Pp+lEnd4T+efynjz3vG9UWW117KLIBPwtfBBEC6moeL2bYHoFsyGeEnf/pe+A0SPiFr/SFA1XH9j7X5Ax2jxk7XYHHJa9KqXId+Pv9rhpYY5afoncls55FOfOBQQFMEg== 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=x/4fcD6ACjry0nq8HEcJop6aYuG5pZNqPv485pH50XA=; b=UG3TsfY6Ll7WHiRoAk4Q/h1eJO9+1H/adnU85Zh+SwdO+VGPh3rV2c+C4A2FJO90r+UW4NRdnRr8Klm9Kv+iM7LgXye4/lDuNr4Yo7l+bV3ELFJi3SAjVrvM4LTMomOgb/hQ+FUzvmoMMSdbiQMU6HEGyRGLC5iM4u/CQhs5MainE2C0s6UPu4AXrZIROHVWFWFa63lcoYlGp/dqSr0YUqF08tegk/VorJcY5qab8TlSLYHBKfhxQvP25fRgv35xHpVHiIGldtPu6NhQRF8HblNihtga7krey8I5k5/Xg++53KevMZb6p6SeZ0AnWpe/AE/YYIxVHNoB5AnOEUBlEg== 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=x/4fcD6ACjry0nq8HEcJop6aYuG5pZNqPv485pH50XA=; b=nmqpbhw5CGtaYsKIxfQucYsmJaJyf9ilX5qQoIFIWenCB4PyPU9oCGtgQiojp/2SYttCv1i/CIHxvM9JM0sAP8avJcasodnfqicmZULkgJ1FOOeNQsMpJq2gRJGelk0cVURFvFiP4dJMHHLobOG0T3LjjDb4qE7LtOr8JMUutVU= Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB7824.namprd09.prod.outlook.com (2603:10b6:806:17d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Tue, 12 Oct 2021 14:47:48 +0000 Received: from SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::25bd:a917:ac07:2d87]) by SA1PR09MB8142.namprd09.prod.outlook.com ([fe80::25bd:a917:ac07:2d87%4]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 14:47:47 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "keyur@arrcus.com" , "sidrops@ietf.org" Thread-Topic: Re: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 Thread-Index: Ade/d8In3xVcL2dIRy6jpOFcZWfB3Q== Date: Tue, 12 Oct 2021 14:47:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 897a8b07-efbc-409b-a6eb-08d98d8f422f x-ms-traffictypediagnostic: SA1PR09MB7824: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QTpqT4vhZtQU8CyPFb4PnxHl7X+aXKoRLb0um/AL4dR0dR1sOaUU4vJDNxpQAkYlvgSd4ASAXdJjhP3FN2k3dX5U3PNqWE4gHpG3MWpEjw6G6N5lI050LwWrsHpV36e95hhe7PjZ+YrZfiA8waSUjhNrIUEFlDp8RMVOg8ZSSEVUD1RgG/+UN4cONwZRZbGjPXGvWw4x5cjnCIBkUUff7y9/T6+oCQky5Xx3FC//0hZzcBdoRP009QyVQ4jU9zx0b67fvCoWVEmU9/QG8ojLWUNwa2oXtM6pBfSN2b/2Qhiz888fOPpiV+Jwt7mVrRhYs8Lp8oSTtrpPH2PZfhF7qQiqZdYu1rpZGieGeOwt0S1L9PWS6+OipY5st9sB8OY5aC2vZnKfznE9+raCUc5EJ0KXC2NO3Ni5+huE2vmB1rGkI5LkUrnHwxL3d6KUqc+dingNPE+6/d9wwwc/hC1GATsJcrJ8yHR2wZtsOXpH8jqm6+uzkRU7Z+8BgoNpm/dcON9MAZO4aWQYSmMml7BBsKq/U021JTp/dnm43W1LjKnu7qrs7GoRODctxS+BltwQtfcUHlxPptHdhI4CjiXAkZt6t2PquY3m9YUwZQ0UBftQxExQKFwgfuCyjPMaHVLJYsTDWOYDmUdcyKuyr0WTO8NcQMC3MjyULxFd/ukoBdRAL0mjUZA95fu19SWL5LavfzoM9tHjDoWVij4mdlZ+ZgA/L9NE+K4SI73YCALmj/lgg2q8+PzBHzLdX2JLpZ9OgoTSJsHallUo7cpkJ5hjrVFPKIIJiuw28RiS62zzld8= 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)(66476007)(110136005)(64756008)(2906002)(66556008)(9686003)(66446008)(55016002)(508600001)(33656002)(4744005)(966005)(71200400001)(316002)(76116006)(8936002)(86362001)(26005)(186003)(7696005)(66946007)(6506007)(83380400001)(8676002)(122000001)(5660300002)(38070700005)(38100700002)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ek/NOYzMcp8pueP+TTsqmwUdDuhglzCk1/l84MpqdP/VXMFx3v9LS8OxuRyP?= =?us-ascii?Q?F41K4lADOcvWoU8WyJa66eHvja9+obtJps5uuH6VlOA5CNPGM6aXH8bNpALh?= =?us-ascii?Q?Yhj0XmGyV89/2yJr+7CMsxk7qZt3iNknv8BJGIKfxs3KN6+SFW3pztcvErtc?= =?us-ascii?Q?oXg6inRs6w9wHbTfDwrNIb2agWDu2XTR+EueS+ReOu/mvwW0nfCPkv1ybb+Q?= =?us-ascii?Q?Kt803IE9/CJ3Nv8M/q2EYMTRJzihr/PlEzzxZ/5v9GWGRtp/JIPvvQPO9KbM?= =?us-ascii?Q?QSCm7wcVf1UD7lGX+VT12wla18ab0HtKmKdynxDlZuV731mmglWRMgIjZFfs?= =?us-ascii?Q?JqFuLkt03h2ta1doBbyHDFq9ujTOiqtkpWfmCivFMUgrTm3G8e6ce5MLJV2D?= =?us-ascii?Q?AGhiBmgIB0cvQTzT+eV/y0yIm77I4smka31eLxuaZgmVZ9pHE75Xn7EXrCLt?= =?us-ascii?Q?Um4fLFFFGVIslHGkx6/gXVMn15B7yqqVcDKGptOvMfahjFhNw3OBkp+vZuvK?= =?us-ascii?Q?utqGOXHGwknt6Dpz/j9QsBuOGR3RsW/fbBmzwFgkJZZv6m4CCsbUNgBu+nvE?= =?us-ascii?Q?rbmhfrGEjqOaHjYVVTpnq9Mk8cfqHY+OTce8IQoAHLkceqaPvm2EbkmzLr/C?= =?us-ascii?Q?FsxWSzbxzsnbm+FW0NL3D78cCsUi1nQjQTcZgt8RxAo722L7uSmzZG+wCShf?= =?us-ascii?Q?ezVe+Lisif3nY4XUDya3qndf9oGvNoFPPMuNo1yWiC/bY6XWWFIbbj2Y8jwG?= =?us-ascii?Q?mtiM1z8sti6bjtQC4itSvTXajWPS18aVqGTqm457RgbTMYT5xYFIXOE8ePQ/?= =?us-ascii?Q?+P+XZxhyRUBSLt4ac6+eJv/VwlLiVDW9KN15CGyAxC6LObeWp23uYBuoIr9m?= =?us-ascii?Q?HiWoqO//8J35csLSEdFcIJGXAFatOQHXy7FEoqS4SHx3u8SVrrnRqVVAn55F?= =?us-ascii?Q?JftqM7Kz9tF8bPzst2Ly+SL7GrlfOkvRtjIfO0VddpyUnJeURUhwFitithbU?= =?us-ascii?Q?3I4xaxzr7Q7tmTbVomNphAgfoPf9TOwoCz85ufDejgjfAM9afo26XpAvgLgS?= =?us-ascii?Q?R0bV/eVHgCxy9n8xXlB8F+9mVU3dz61yyhN2UDebuB6E/T2SqmDUvAYxvfdB?= =?us-ascii?Q?ZOjldMSDMb15+Z3WD+0+QUxFQkHzyOVR8AgYS9jRoqO7E76iGVhpW0TYUzjM?= =?us-ascii?Q?2UYabjCGv9L7fu5sAI4wCqDOUo7k4GRT3mvNmVObYny6JsmaWUV7QQT6SsXL?= =?us-ascii?Q?nC7CqquyRy2l/IWFRVeYPUoOX4IXO5Gt1Eq5KoDrKb+Qmsjvwph0vXzxzNQJ?= =?us-ascii?Q?NK4=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR09MB81426EF2628D8ADBE2BFB96184B69SA1PR09MB8142namp_" 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: 897a8b07-efbc-409b-a6eb-08d98d8f422f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 14:47:47.8919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB7824 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 14:47:56 -0000 --_000_SA1PR09MB81426EF2628D8ADBE2BFB96184B69SA1PR09MB8142namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no IPR relevant to this draft that I am aware of. Sriram ----------------------------------------- Hi Folks: A working group last call has been requested for draft-ietf-sidrops-rpkimax= len-08, "The Use of Maxlength in the RPKI". Please reply to the list with y= our 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. Authors, please reply indicating whether you're awa= re of any relevant IPR that hasn't been disclosed. Regards, Nathalie, Chris & Keyur --_000_SA1PR09MB81426EF2628D8ADBE2BFB96184B69SA1PR09MB8142namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is no IPR relevant to this draft that I am awa= re of.

 

Sriram

 

-----------------------------------------= 

 =

Hi Folks:
 =

A working group l=
ast call has been requested for draft-ietf-sidrops-rpkimaxlen-08, “Th=
e Use of Maxlength in the RPKI”. Please reply to the list with your c=
omments. The WGLC will end on October 25th, 2021.
 =

The draft can be =
found at: https://datatracker.ietf.or=
g/doc/html/draft-ietf-sidrops-rpkimaxlen-08. Authors, please rep=
ly indicating whether you're aware of any relevant IPR that hasn't been dis=
closed.
 =

Regards,
Nathalie, Chris &=
amp; Keyur

 

--_000_SA1PR09MB81426EF2628D8ADBE2BFB96184B69SA1PR09MB8142namp_-- From nobody Tue Oct 12 08:02:36 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18FB3A0D01 for ; Tue, 12 Oct 2021 08:02:34 -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 (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 hHBKz_AiS43X for ; Tue, 12 Oct 2021 08:02:30 -0700 (PDT) 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 55C393A09B8 for ; Tue, 12 Oct 2021 08:02:30 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id d9so759259edh.5 for ; Tue, 12 Oct 2021 08:02:30 -0700 (PDT) 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=ADiXlVTS8RpNGQ9cTrs1xTdltU0gCghl+Eq4VzxA/AQ=; b=Ob7UpMDnHPNsbmfQhBzFrbyzZuukwPfQSBSLu9FJzimPk8DamFHYx/S1q1uR799Bt/ ZiC3ibarcVEzEl0H3yrIGlzAkcb6AEHMIc+cdHCSdyc2AwS5A3KraCRuOZGnJ4oYcmMp jUcO7w6Z92lMHyJs5q9CF80AKVM0u1VQ9GbOA= 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=ADiXlVTS8RpNGQ9cTrs1xTdltU0gCghl+Eq4VzxA/AQ=; b=b6HS35G2d4z0ZuKqdh/dZeoO7EcV6P5/UUGiD4HTn9VFD1Goqu6SQEXWldnc4KCfQ6 9NKBzPXc0bTocbb6SujvMYYpVd+MY3fvdjC8eJqX1kSW63CO6nWSZQh/vY8ZJlQwhSsD wCgQBbECPPuOOGBchXz33ecEeQHkpKDS19vG1ImPk0zwbGuaGongm9RUT1PaA7BhduLD YdnGwQM9xc2+W+V2s/dQSu2jqiJDNKGPw8i9LskISRcDpgBziKLxWStdSJL0ZwhVYPKb KksO8c0iPCcikfK2pokSTVVOOvrOjb08sq8guTt5SEYztEp83vPba9hYHNe0B4MyBk+I 7GcA== X-Gm-Message-State: AOAM530mGk7/88q6/Hnx2HH15xdetX1UAfRIMSKEP0wLy++DGKHq5W3w hZlBnDk4hPfmoGtzD9ESyAGXHyAQSCrsig== X-Google-Smtp-Source: ABdhPJwBrjuutcv/2IZDTkEMv5Q88Kx20LIO3UhV/QIpp3d9aaU2b5lMVTgncjdaEqOOPS/3oFX49A== X-Received: by 2002:a17:906:7848:: with SMTP id p8mr33813751ejm.212.1634050948063; Tue, 12 Oct 2021 08:02:28 -0700 (PDT) Received: from bench.sobornost.net (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id m9sm6131871edl.66.2021.10.12.08.02.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 08:02:27 -0700 (PDT) Date: Tue, 12 Oct 2021 15:02:26 +0000 From: Job Snijders To: Keyur Patel Cc: "sidrops@ietf.org" Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 15:02:35 -0000 Hi everyone, I am not aware of any IPR in relationship to this document. Kind regards, Job On Mon, Oct 11, 2021 at 11:18:54PM +0000, Keyur Patel wrote: > Hi Folks: > > A working group last call has been requested for draft-ietf-sidrops-rpkimaxlen-08, “The Use of Maxlength in the RPKI”. 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. 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 Tue Oct 12 08:37:38 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B163A0A01 for ; Tue, 12 Oct 2021 08:37:36 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 wCq79Idhtp1B for ; Tue, 12 Oct 2021 08:37:35 -0700 (PDT) Received: from sonic309-20.consmr.mail.ne1.yahoo.com (sonic309-20.consmr.mail.ne1.yahoo.com [66.163.184.146]) (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 41B7F3A09E9 for ; Tue, 12 Oct 2021 08:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1634053046; bh=5xOvbloR8/kGbrcl2scDqVTA3P6br4mSI1F8K6BZ4dc=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=GW4qMm9T1WkQizZe07CimG2M0O82x9URAcFjWvfRT5C4efRwfvt9GCQRnNfC+1wUEK1sKzG++J5RLHD0Z9owJQdKfzz1wd/HjGN+rhLDsppuDZ7y2PkzjcGBEfLKaERSUpgsH9fuSI87j9TrGuSQch7vp1nRISPaNEqV0T7dHGomTW4LMcQxxNbw/mZb+KI2zhOOz4zyeE4bhfmPLq9memBbnePx18pPmetKsbv9IEDzqpRYyOWqZw9Oi0ceuQJalhmYngINoSyxBGAROGq8vueo9mz5JcupSQhvPezpaKk2BFDEij5OPo4XeJOC20xic7y/8mbwzmvyF0N5sm5WZg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634053046; bh=hXU2DnMK1XvE+J3q1UfzTiOjXY4mypi2zA7u9W1/aV9=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=ktyQfRzBTTkef/FIvU8P5kIVKhu5rq7YXuQh16LdFl6cAFLl94LBCkLGyla3ulpcX80ZpvJPeE8tlSOPprUz78MuyD5u+RVKiLiIOL+4c0scC+wMBI056t234AUXd5ZguTZecIILpVWKfr0qoda4o+9UWkgYDYOzWP0EDXZ33ej8zNnY9YVOPRXLPL2868RD+aDsDAQPxVRJvrmSQEPU8g0X0NjIPs6HXkxRKt3BJDakPgOSplsVDBEBPXx9eww8kQnu4kN663dAoYaPZ54ym2zD2M+hBwBcpbfyD2OssmwBzX/Qf6esjVbm1+d1KbQIRqNRDOMQfAAIKLSypz/7hw== X-YMail-OSG: vytVt_oVM1lG24IGw9FytZ37j65MuUCT2qcsMtaC0HFsG3P98kzt.ly3Pft6oOp U0twaocq_FJy9_TFo2XrCWjurWZsYWJCyXA8Hy3nPP1HuDI1zulUGHPFcIuKPbxQd2oReIS6ivR9 PaEVyc9NXDecKe9WiVuJBXx0.A3CUp3Na70QCgH0lHuSBV4oMwv5t1xMtchm6h0bUGRqaQyLLhGg wY4LyvxmVBB_Mqbo_Dgr51dzToYjwJk_lJEGIysCt.xj4j1altPdW1fLDNWSOUrp_PyU8alFWSp2 yK_BoJ_.k5QSUdRvKmzZeOksRQkNjdZcEpQFP0zwbBd6yu2cQBmHKZ0Rnfnjx_OlHGchrNTm1Z7k igIbnwnsl5TSfz7bX5BKKYo84X7gO7gyx.prcy7fGvy_ntNztBoRRjU.GCvRm1FTNPRp0Khf9v8h 7v57lwHi6H5A6hoQmiiSvVdLa33xQJAN2hcyyWzEYwb5iAeuRWQytpQHSZpg8olWUhVVjFLYDir9 Qv0JTiggIFrAk3qkrbTcWkGYEystQsxuqJmXhstQEMOWn92XKAt6AoWYr.m8ebcLOz7Y8a4MQt52 sTjwp2XbSG8.NLM3XGn7X.n_NutBow1R_4wndoRT3NYqaD9F7LG0PVnyUfTYwBMsJjAx1refMrpc eC82GVMZKSl7U8EXq_Q.i4DoSN7M2tLzp7X9jX_zbnMJpeMGO0Dy9GbG5qpEO5o_R2yTXS.hZbI7 Fs3CRWOWFyc1aBpMFrh62_NND.6zQEXHokr1GdrJebwNzz_JRlDeiP26mbRsfE9RiIYSG9x4JTt9 _4dL0aOFrTQgsFp7GCKNyI_yJAWO8lZGacHVKngiQL_l35Amlu4mrQcj.pt9usVnGqa5i2E2AWWt ALQzzsXTZEwUkRpTa9qlaLQ3_pwmCXwfsHzbJI7fv5kMk9sWjUjb5P_SF44IOek9BGq4tV_CPkQs 6Rtuks5k6e0DzyZFifOAssJZj8TPpB8iwNvAwKRvIS.EXUKVDnAR7MQhf6MgG9cyvifwOeF4OsLP blE45tSqPI5.7TonEKEiqAnTyuxe4.KanV_X4seSqRt_aT4BXybolDraVttvyk5N8BiG3DnDLD2F JSilNpK1rSJT5VIyc2_qu8gEVaq.i9mXxcaSfARXdrx_uqjzPKK_.iNGPVTwLSSruY5ysK_Fm3M_ _ZrGHp34YWt3ejuEo_dSVdS54JqjdgTw7tZOiBfHTaaXb4LbEG1ri7yTGEgy77fe8wwVH_t25nx9 tr1uqKUlnkVAbMdWWx1gJxdH5ACI0KFiUvOqfMp8t6ZwwaWxQiVtyMtG2vUnJ_xjiFFwrfqQbSMq 0tOSHc0ULfSIWW.VJvoHfB4LWLY62xfCAf_zG_1AHf0_f4CDcajphCMAhokgmu5H7Zjrbn_1K0ar Ao1htJKVOTo5Y1C2QO2b28lCgwWZw9dla2_mg55LOc308UEYA9Xsg6Lq0tgzrcJO4SoXr7GVMHvB I50Z_0gDUwRlGU55FgI1dC4pM9OIbAQer8h_Lf4PRem_Ye6xExq7sAWrNhZJTwlvme_F6lll9LSH a8Gv7AErBWCdCJ2bU2RvZs146RaVOw8UtSvwG6dR8JXTZlTUM9wx2BdgT.lzmLBqiLusPTOmVjrn cV3aulN16f4oO3O0LfdkpO14nH7dCO78vkMxRZVI4k01JBMfD90o9Lwkpw0nvsavfIUy4hQ6ACs_ OtEdC6vH_W1cFcs6eTeEh7.8cvC6sZnw7kPbh2HzD40LYILUEGFUo_IEhYvaYizqI7e19IuAZu_I yFlg6278jtWI.DxaGF6NxXcsNBuBxY4fkei3576iyUvNZYTSeiuhw4_7SkFWm2G2OxNAoYaNWoow 8Do25M7RbKezod.KV2L2PNfDavDFkG3gYHceX6zAqU.e08_PEa1GrHEKTlMRwhCRlHX1yw.87uRv 3o1F7viDPYDFnWvSX5kuOwjGAzcMiLemZgjnqfAuH.5WtV5_KJgClG7xGVB.CrpVSVRwsjvpf_GS qfPm2Hs76a47S9GyM2VhXeyERXKQFm2LFiBO2vdnl5p123ZDbumCavJJhNn8ysBbT8gVgMKB1w2D PW9Dgu1tZhaas9nR3ceUhGNOihAXmOJfkd4mz.6tCUOB6EaI87DMJ6GKTov0KQsTmGl.oDrC28F0 eleu5N1H6kVrGn3F4UPrJiwny_4y.oAWFaj6d5ey86FIyzRqkcW5ZC9e_0NVIB.tn7MaJrXvUXZu Ifbfijwsye7K7a0yP.TMoQw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Oct 2021 15:37:26 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 90d428d94b6f4db3c6271b18327c8e3b; Tue, 12 Oct 2021 15:37:24 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------lN80EL6GvVPXMTjNDgB09ynK" Message-ID: Date: Tue, 12 Oct 2021 11:37:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: sidrops@ietf.org References: From: Stephen Kent In-Reply-To: X-Mailer: WebService/1.1.19116 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 15:37:37 -0000 This is a multi-part message in MIME format. --------------lN80EL6GvVPXMTjNDgB09ynK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ties,Hi all, > ... The only gap I see is that there is no guidance (or mandatory checks) on manifestNumber nor requiring monotonic increase of thisUpdate (since there is no mandated syntactic constraint). This leaves open undetectable replay attacks. I added the following text to the discussion of the manifestNumber in 4.2.1: The issuer MUST increase the value of this field monotonically for each newly-generated Manifest. Each RP MUST verify that a purported “new” Manifest contains a higher ManifestNumber than previously-validated Manifests. Given that we have seen monotonic counters regress in the RPKI in the wild [0], if we add such a check, I would prefer that we check for monotonically increasing thisUpdate. the thisUpdate field is a time/date, so a "monitonic" increase is not the appropriate language. I added the following text to the thisUpdate description in the same section. *The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest. * *Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated.* * * * * *Steve * --------------lN80EL6GvVPXMTjNDgB09ynK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Ties,Hi all,
...
The only gap I see is that there is no guidance  (or mandatory checks) on
manifestNumber nor requiring monotonic increase of thisUpdate (since there is no
mandated syntactic constraint). This leaves open undetectable replay attacks.


I added the following text to the discussion of the manifestNumber in 4.2.1:

The issuer MUST increase the value of this field monotonically for each newly-generated Manifest.

Each RP MUST verify that a purported “new” Manifest contains a higher ManifestNumber than previously-validated Manifests.


Given that we have seen monotonic counters regress in the RPKI in the wild [0],
if we add such a check, I would prefer that we check for monotonically increasing
thisUpdate.

the thisUpdate field is a time/date, so a "monitonic" increase is not the appropriate language.

I added the following text to the thisUpdate description in the same section.

   The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated.



Steve

--------------lN80EL6GvVPXMTjNDgB09ynK-- From nobody Tue Oct 12 09:24:24 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267243A163F for ; Tue, 12 Oct 2021 09:24:21 -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, 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 wsNl0jF8jR4w for ; Tue, 12 Oct 2021 09:24:15 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 087D73A091C for ; Tue, 12 Oct 2021 09:24:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jzgQ4KaR8vMj+D9U1klRsctZL6x+K2UHy7YxA/3YPmQwNa8HL+UKPw6O1w1d3hu1MAz8oSGezfjSZgdub3vaWO1nrAokWQNEosriDyH7UMgmSsKIEuVX0cm5VAR4ytmlVFCWAGMHyytc1sJ8uI/7IY2GFGKyOCxz0DFuLuMUCAnZ/eV1Cu4fqQ1Kf9T/5jz+Wv8x/fipK5bbyYzn9kNLidAWvC6HOZXGkpAV+CNQgWL0FmWAXQE5IufdfTlncvI4cXAIBcuw69fuDQkY1B84Q8YRE7M7sZzn0K6SEZ5qUKtyBj8CMXpeyqge9/ItuuhZm9GkX4NmS/TlbUO7/YVU8A== 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=/DYeQid+VfCfFoVnvr03/GDxI1xgDvxljfd34OtJojs=; b=VVwHzthlIcZ8YTrXywM6Tm4GMa4qxFjMnB4nNHkf/fcZapv+jTU7H/MIyE9SpqheL7nxO38e2ajwiPI0YHjMf0W6pY5/IPbo0gZRmnw30ZEbYlSFTRX6RUrHEytuKAnR7zbC5hNU22R3KQ6Db+tv5fPZwBX/6htyQqfZubp1xD32swdAuT83O6DkPJcRiW+L5NLzD4ZsK9QtwXrYV+LRYs6hOWffJOGO0nuHqHSbx/7b3OuIaGN7g0WUKAJo/7e/5iD4VzRf18Ji8fb+EMRDPDnGvt05qzuQH3OKOcT5E46lP3kGuqJ0OEbTIH6k5exwzzNcM4OgabfOjzMG5fxkUw== 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=/DYeQid+VfCfFoVnvr03/GDxI1xgDvxljfd34OtJojs=; b=G32zwRKtsiOEStxEogZN83ZIwJNe7h8oGP1ypqnvOAAPLt9Qh9gKScOMnxqZ61mrCfrTp1NUIC3xnj+1UUJpTpKboRJLhd2uEUX2F3SnZ+eMbp40nYnh113hj6+og+zpOtRMwIfCRSlfxEVxw96yG1uFkwbQQbYyVrhCW1D4TPs= Authentication-Results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=workonline.africa; Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) by AS8P190MB1542.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3f4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Tue, 12 Oct 2021 16:24:05 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%7]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 16:24:04 +0000 Date: Tue, 12 Oct 2021 18:23:57 +0200 From: Ben Maddison To: Keyur Patel Cc: "sidrops@ietf.org" Message-ID: <20211012162357.gszpzzrshkertfmw@benm-laptop> References: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5zkaoddfbw2yqeaa" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CTXP275CA0027.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::15) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CTXP275CA0027.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18 via Frontend Transport; Tue, 12 Oct 2021 16:24:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 233e3a2c-0bc6-4261-579b-08d98d9cb556 X-MS-TrafficTypeDiagnostic: AS8P190MB1542: X-Microsoft-Antispam-PRVS: 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: fyej6CC00L432NZ8dCn/BGrEibVI/mroJpCbHwxQIoBLJI1xr0RNh1BnI/RB9XXBfLdeXIPWaKE1hr3mgdH101ZwfAjNW80kqKqSqT9YkbNQiWfd7c6ubzz+m/lKWxnypre25sEYJLed1ietQpvpaYX6kQozIZLxrfb/XOpwqOTF01PyYqesJ+gI72sPDHNci43Veeo5Qk0ClOjXoIhqMC3wjgKQwRM3dJ7mvPF60Fe215watuH7GX1+aJssJlQsqaX8Z8urs6VwKPO68JiemEXv/gixo4uOBssCWG/L+qEL7F5ahpvV5IHQ9ZhQQXJldsBbawyrMlwzPSX1IDepV92/pKnJGBSbKZ9L+b59vrY3vqH1D1ng2Jl4bJVP7V+HVyu/gVYCjppQ0bBTnRWr/rB7JGQutaiav7ha4CrTO0o/VONeWiqeNEPH8XkVwsA12Toan5nYCyLjEwx9zkUDbTe5fQCNHXn9AUshv3mD71KN/dKyWFvpJ6SHPIerSWzE9vHEh+Lo0vTN5suDE1YRDz00qPjaY3e+4IhbSst/girihv2sW6XMH2Iq5uI8w6jdU+SlufysogjDbHUb07edpsW82i8XL2Bui/D5dQ7S6vgvxJnyOM/PaNQK5Qe7Zl5nC3rHcPDRqGP1m9BvTpNylncNIz5AfNHAiLFNGO/pue6UMQdNjG/OZXPJxmwAJdx7OWFd1s4GjXwb1utoN5SuRr2vO2I1elMSVq7HSbYNTnTVLgroecsGVMB6iYGQ2vk1xynhG0yQHAerk5MoXJVb0fXsaAMcHJucYl1lWrsWz9bWsJorLzPNe3ZhKTqVjrwVJygyT9Op9O5MByEdslXgMQ== 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)(396003)(376002)(366004)(39840400004)(136003)(1076003)(66946007)(66556008)(66476007)(3716004)(21480400003)(86362001)(38100700002)(38350700002)(9686003)(6486002)(6916009)(33964004)(966005)(5660300002)(956004)(8676002)(8936002)(44144004)(26005)(508600001)(186003)(83380400001)(6496006)(6666004)(33716001)(316002)(2906002)(52116002)(4326008)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NmRYQlBGWldKNlVpbjlqV1ZpU0paTlE1cHFwdzRzeGx5YU1iN09JNXR5T2oy?= =?utf-8?B?NjRETmwxNFFjWUFXMHBoRnoxL05hY3N0bHdlTHVkdVZnTWw2ZTMzc3JkVXF0?= =?utf-8?B?eEsrYmZHdEdCZVdxT1pkNzd2WmM0VXAzTnlzRlBIeUNxOXVIOG1sZHBhdzRL?= =?utf-8?B?L0xibDgzTkpBREhlaTlGcFUveG1OaDZUR1RSSWRSUm0zUzNYcDB4WDlEbWtI?= =?utf-8?B?RU5wUGhrRlNUcVRtbG82WER6cDE5MGx5UWJHVVczZE1aQ3F1ajArcllSNHF1?= =?utf-8?B?TkRyZDNicS9YSkhYalNHclplaUxoajZzb0JSR2p2RWhxKzM3Sy8wMXVKUWtE?= =?utf-8?B?KzlNSDUydkhON1V5aGJDK3F5eW5IM3phWElrOUpIVVJHa3oyNVUrSEFmcDNs?= =?utf-8?B?cCtOREhsL0VJc0FVbWRTRXAyb0ExVmlaVTlNRlAwclY3VW4xenJRRlpjVUM0?= =?utf-8?B?VTNkWXh3ZlB0SjNpN0QzbEU2UDRVNmlteXRXYnAybTJ4a2tLMVFkMjZ0L0Jk?= =?utf-8?B?dmdNYzk1aE5qN3NmRjVUaXZkODNMTlN5SE1BekR5NzVqc3FBditMNVU0VGk3?= =?utf-8?B?eUVWOUJ4RjRIZzZIdUkwRzI3TXl6KzlNOFRzeTJBLzY5UCtpckxlakJMQmJO?= =?utf-8?B?VVVnU2QxT2RFWUJQTDlsUFpPMFZuSjhVUXdYTDlaMWhDVnV6UWNIc0hidTMz?= =?utf-8?B?TUdCakl4Rm43R2tLOEN2MllRUmE1cS9IaVY0YnV3Z1pBMDJES0NRckIvaXF1?= =?utf-8?B?UG9xSUtyTHIydmMwVTR1YU5CU3BqWDQ0TEN2Nm1NS2lJMTNkUGZidUxQejdT?= =?utf-8?B?a1oxRmluU0NnbUNyMUdjSkdzRUxOT1RXTDI4RUYxQUpEdnZzVjBMYVJzSFJI?= =?utf-8?B?V2lhTDlrTXZJK1d5bVVRZ2NyTVEwcE5XM285bDY5RUwxTjk2Q1VUOVV6UnVw?= =?utf-8?B?QmNEZmFKc1RUK29QNHJkcUZaZUdpSzZITVVRYUhYWHJXanpITUllcjB2dk1X?= =?utf-8?B?NGNxdk1IeVh6Z0NTSzdpYzgydDRlb2VvcW10d05MdUg4M2pRUnNhM3dEaTda?= =?utf-8?B?TEc5TVE0MHgrMlJKQ3JtUjRZbE1UclgveFBlbXlmeHBrb3I0QU90U0kxZnJZ?= =?utf-8?B?OFlaem15YU51eUtRMGFad0c4MFAwSTFQaGxZeTJQNVZ5T1E5SXoxRW5lcHRH?= =?utf-8?B?K2RkSW5TVml2Tm1XL08rQXd2amtKTDlkMDFvdmQ0eGpTWG1uVGpWKzZLK1N3?= =?utf-8?B?cXRRdUQrbkNXQVI0UTV2TG84YVEyU2JtTjNSMmVHK25rWmlFNkpENytCNkoz?= =?utf-8?B?aUEwT1VhdGo3aFVpL2k2SUxETXdySldpSVJEeUZYUjZjdXJYN1hrdmhKRWZw?= =?utf-8?B?NTFIVjlBQUo0Z0crZ25oY3NRY0pRcDM2cHljN0paZGozdDA2bWs1L25vWkcr?= =?utf-8?B?VEo5dGg4eDZmbUJrZmdjRGFQaElBNFJpclA5djVBN3lzVmk5V0pkQ2RXQXMx?= =?utf-8?B?bzBUUzBEc2pRRFpBSUNhNGRKMFdReXpCaDR2RklHaEhUcC9sUTlmZHpJcENO?= =?utf-8?B?QnJkWUtvYU1WNlgvUkVOT01qNG5GN1lVQTR3K0ZnQk5zdk1wM0VkdVJJaU5G?= =?utf-8?B?UEdta0krVVQ4TWdCNnFGYkFsbUpQNkZCdzFjWlF1UC81MWlLMnpnTVYvUWZ1?= =?utf-8?B?amthS0ZzdXFUeThyZldyZ1o2Z1MwMlE5L0lXWUNVdUZGeVJHM1pXalJYWHU0?= =?utf-8?Q?YZKPN/ljYZRs4Xs05+Er1pCnhn9z4YInF1JlMTL?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 233e3a2c-0bc6-4261-579b-08d98d9cb556 X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Oct 2021 16:24:04.8406 (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: czCFlZkPFtd7Y78NAdyzC2eMWwfoAPS8B4AVInn6wviSuVO0gvd7dX+DhpsCjoayc8N7ELts7fAJVM2yifIN+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1542 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 16:24:21 -0000 --5zkaoddfbw2yqeaa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Keyur, I am not aware of any undisclosed IPR relevant to this document. Cheers, Ben On 10/11, Keyur Patel wrote: > Hi Folks: >=20 > A working group last call has been requested for draft-ietf-sidrops-rpkim= axlen-08, =E2=80=9CThe Use of Maxlength in the RPKI=E2=80=9D. Please reply = to the list with your comments. The WGLC will end on October 25th, 2021. >=20 > The draft can be found at: https://datatracker.ietf.org/doc/html/draft-ie= tf-sidrops-rpkimaxlen-08. Authors, please reply indicating whether you're a= ware of any relevant IPR that hasn't been disclosed. >=20 > Regards, > Nathalie, Chris & Keyur >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --5zkaoddfbw2yqeaa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmFltp0ACgkQOkYk/rSL aGAZShAAjGjrXBRhjoH/RcwHQCCMSJLCzpH/p41W3ZTd1vfXW69YRFdGLRj5qp5M 85p03JKiykk0Ao1t09DHyJwOidyviyd03AkEv4o+C6zNiV3I4AR3O5SaQxi/Y5X1 MDFc/hwj/T72z3zJ0Olv835nJ5aipAWHuFXoT0kpXQGXRZf8jKiegMYI+TDXy2UL kwkqmwdGY7jhudpXy4YqPxhhr43KEhxf4/VM5idl3iPAOe5ogHb8mA3I9THUBdQe 6oSidRl3/8HPC/H8BOkxjHco3Xt2Er+asc5tfJduXZ1w1U7xL4JB0XdvMUzxpCmn Hj/+menstTCwOjNoqtTskQFZrzsuo++TBGhjcTc6jd78e8BxQXbLSNdg3eLsqiSO aChWuQQUwikDIO7n2Tddty5RVhLQt4g3JmQhKuIiH1W9w+e8uV8Pxc3BHpBmdsIa l2OZ8ydSWG+RWahUUex8kvz13X7so54wv3xiqlc+cdNA3/mzMJCTGeiaATgBrUEi s5gOD6H/kgZJBOYLc3rME1nvY4jI+WWxHXMSdJxjJX4RqypOrlk79ONe3Qz4Lbh2 gAw65ler2Bnd0k28XNAAFxKVXq4+0xiajBxS/Wi0GqYUijF5g6K/gldl7ZW1KUZC YtgqwLkZk/uKI9371NWqplsnvFV+sSFaJ0GqX7hwmVwRXCfF9bQ= =CBfN -----END PGP SIGNATURE----- --5zkaoddfbw2yqeaa-- From nobody Wed Oct 13 00:02:36 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054393A0E73 for ; Wed, 13 Oct 2021 00:02:33 -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, 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=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 DiwRaRphmxft for ; Wed, 13 Oct 2021 00:02:28 -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 36ECC3A03F3 for ; Wed, 13 Oct 2021 00:02:28 -0700 (PDT) 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=r8Xz2VkBfwtKADqxVpeKfD1jrGjiNHn/T3byUtqrEgw=; b=qIYn5i2HocHz1Tq5l6AzpQPd Ek0/2u5iWNbwk3ctff0uVJB3l8//uTXh/1AHr5v5tJgBNL0qlP8VjE4Ji681mwbOFR/k+7QY1kMSZ isc9NW8uC9Q24kEsMEvRKzs+J46UlAAuiQVPexPHPeqTk4vjVgkXl98UycEPB6/0hTLhOkzR86neC DDgwOhoq8KJrhxVnp0daG4oKXolS3amqdP5Z874ODL1lxkyxRf5hoxRSC49tDZ9OD2ovX1zS7l3g1 fmo7Bw3wwiJHEaUlI8NBdL0zFrhIpSbU7WLTlnoh8e2WiZy6NmBHSBrJ0BG+vCPLg/lh9QX3y+LWN 3X5+yn5UDg==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:49630) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1maYHM-0006UE-1I; Wed, 13 Oct 2021 09:02:20 +0200 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 ) id 1maYHL-0005uN-V0; Wed, 13 Oct 2021 09:02:19 +0200 From: Ties de Kock Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BE19F453-7183-4158-BC56-470CCC8E3141" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 13 Oct 2021 09:02:19 +0200 In-Reply-To: Cc: sidrops@ietf.org To: Stephen Kent References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e12989d470f8b95007e9acdb905f38f0a2 Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 07:02:34 -0000 --Apple-Mail=_BE19F453-7183-4158-BC56-470CCC8E3141 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Steve, all, > On 12 Oct 2021, at 17:37, Stephen Kent = wrote: >=20 > Ties,Hi all, >> ... > The only gap I see is that there is no guidance (or mandatory checks) = on > manifestNumber nor requiring monotonic increase of thisUpdate (since = there is no > mandated syntactic constraint). This leaves open undetectable replay = attacks. >=20 > I added the following text to the discussion of the manifestNumber in = 4.2.1: >=20 > The issuer MUST increase the value of this field monotonically for = each newly-generated Manifest.=20 > Each RP MUST verify that a purported =E2=80=9Cnew=E2=80=9D Manifest = contains a higher ManifestNumber than previously-validated Manifests. >=20 > Given that we have seen monotonic counters regress in the RPKI in the = wild [0], > if we add such a check, I would prefer that we check for monotonically = increasing > thisUpdate. >=20 > the thisUpdate field is a time/date, so a "monitonic" increase is not = the appropriate language. >=20 > I added the following text to the thisUpdate description in the same = section. >=20 >=20 > The issuer MUST ensure that the value of this field is more recent = any previously-generated Manifest. Each RP MUST verify that this field = value is greater (more recent) than the most recent Manifest it has = validated. These two changes look good to me. My previous concern about the impact this would have on CAs revert to = older objects (as seen in the wild) is no longer a concern for me. A CA can = mitigate that risk by using the typical serial generation strategies that = incorporate the time (e.g. unix_time_millis || 64b_of_random) - or just not losing = state. -Ties --Apple-Mail=_BE19F453-7183-4158-BC56-470CCC8E3141 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Steve, all,

On 12 Oct 2021, at 17:37, Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:

Ties,Hi = all,
...
The only gap I see is that there is no =
guidance  (or mandatory checks) on
manifestNumber nor requiring monotonic increase of thisUpdate (since =
there is no
mandated syntactic constraint). This leaves open undetectable replay =
attacks.


I added the following text to the discussion =
of the manifestNumber in 4.2.1:

The issuer MUST increase the value of this = field monotonically for each newly-generated Manifest. 
Each = RP MUST verify that a purported =E2=80=9Cnew=E2=80=9D Manifest contains = a higher ManifestNumber than previously-validated = Manifests.

Given that we have seen monotonic =
counters regress in the RPKI in the wild [0],
if we add such a check, I would prefer that we check for monotonically =
increasing
thisUpdate.

the thisUpdate field is a time/date, so = a "monitonic" increase is not the appropriate language.

I= added the following text to the thisUpdate description in the same = section.


   The issuer MUST ensure that the value of this field is = more recent any previously-generated Manifest. Each RP MUST verify that = this field value is greater (more recent) than the most recent Manifest = it has validated.

These two changes look good to me.

My = previous concern about the impact this would have on CAs revert to = older
objects (as seen in the wild) is no longer a = concern for me. A CA can mitigate
that risk by = using the typical serial generation strategies that incorporate = the
time (e.g. unix_time_millis || 64b_of_random) - = or just not losing state.

-Ties

= --Apple-Mail=_BE19F453-7183-4158-BC56-470CCC8E3141-- From nobody Wed Oct 13 01:04:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3EF3A1502 for ; Wed, 13 Oct 2021 01:04:20 -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 sxzgjuBkLmt6 for ; Wed, 13 Oct 2021 01:04:15 -0700 (PDT) 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 442C73A1139 for ; Wed, 13 Oct 2021 01:04:14 -0700 (PDT) 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 5B2F22C3 for ; Wed, 13 Oct 2021 08:04:10 +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=1634112249; bh=5Uva5cweii63bOOtaMwt3d3kdRFGJF1d5ySHSeLFoak=; h=From:Date:Subject:To:From; b=B5Kou9ki9lcswTn6eW5JOe15AulX17Hvn6EC/Mp7t5hlo8bIyMKQnDId+4iywTagM oIPaBjY3T49qcgCI8218c3Se5fGlsBYZqkivq6TTTMMvLH6Mk6US5mk5+8FL5uvAxs QWwQCuz5ZRVmj9DCfwWlN8msrPQ7A3X1GR+XQ3O58fE9KJ5u0ty86Vvu5dnjPHoXrB E94cGjNWgJYK3fJ7czhqc0Xm7MFna+MIKioL71OSs1SdGLO5hhu5TJsFjCI3RZRnwM uNZ7gat9/AYGy2/Jzf8tN/klKaopLDi0VQKka2d/ukW6oy0DF/7KMZ0CefRoYPpa3t VnSPZpS3nUy0Q== From: Tim Bruijnzeels 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: Wed, 13 Oct 2021 10:04:08 +0200 Message-Id: To: SIDR Operations WG Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 08:04:21 -0000 Dear all, Whilst implementing a proof of concept we found some issues in the ASPA = -06 profile that we believe could be improved on. The current definition in -06 is as follows: ct-ASPA CONTENT-TYPE ::=3D { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } ASProviderAttestation ::=3D SEQUENCE { version [0] ASPAVersion DEFAULT v0, aFI AddressFamilyIdentifier, customerASID ASID, providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } ASPAVersion ::=3D INTEGER { v0(0) } AddressFamilyIdentifier ::=3D OCTET STRING (SIZE (2)) ASID ::=3D INTEGER This implies that we need one object for each AFI. The size of the = providerASSET sequence can become very large. Plus, theoretically, one could have a = sequence of AS0-4294967295, resulting in a 16GB sequence. I understand this would be = an extreme and perhaps non-sensical case, but still there is room for = improvement here. We propose to change the profile to the following: ct-ASPA CONTENT-TYPE ::=3D { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } ASProviderAttestation ::=3D SEQUENCE { version [0] ASPAVersion DEFAULT v0, customerASID ASId, providerASID CHOICE { ProviderASSet, SET OF FamilyProvider } } ASPAVersion ::=3D INTEGER { v0(0) } FamilyProvider ::=3D SEQUENCE { aFI AddressFamilyIdentifier, providerASSet ProviderASSet } AddressFamilyIdentifier ::=3D INTEGER ProviderASSet ::=3D SEQUENCE OF ASIdOrRange ASIdOrRange ::=3D CHOICE { id ASId, range ASRange } ASRange ::=3D SEQUENCE { min ASId, max ASId } ASId ::=3D INTEGER =20 aFI AddressFamilyIdentifier, This definition uses the same approach defined in RFC 3779 sections = 3.2.3.4 and below to allow encoding ASNs more efficiently. Furthermore, it allows that we have one ASPA object per customerASID, = and that we do not need to repeat ourselves in case the ProviderASSet is the same for all AFIs. One more question.. does it make sense to allow AFI values other than = IPv4 and IPv6? Looking at the RTR draft ASPA PDU it does not, and therefore = we should perhaps limit the valid choices in the profile as well. Kind regards Tim From nobody Wed Oct 13 01:06:54 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B973A1502 for ; Wed, 13 Oct 2021 01:06:51 -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 RAXlSCfggIIX for ; Wed, 13 Oct 2021 01:06:46 -0700 (PDT) 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 5EF5F3A14FD for ; Wed, 13 Oct 2021 01:06:45 -0700 (PDT) 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 E0D3F2C3 for ; Wed, 13 Oct 2021 08:06:43 +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=1634112403; bh=vfoWmX4C+JiVxQCAbwh0R8+0Oe9If/Tdm/W5QjMf//g=; h=From:Date:Subject:To:From; b=w7kPuA/7ew/+vvfxa7vskl+14roZNwul5tFwQVrRHv+j7DFnj7SfeeMr5Jd8FizDg Drx8anPE9r8amq8oadcIqnbZul+80ZFTaQIVyIK07q8DsGU/YW+yk+vtcidElE3gcu n+wF2qV3fABNJKj+uCrWTlKtVoir6LoYpI0hxoq0i/vrKt9TiXYsME91iPqBvEmFEk zkN/Jj6y2uhOkrbKDpYaYTCvliZXLiOHAl+eWmi90nIzEZCn8nN6Fac1fpoNrMlcs6 3k6v+HOompMGAHU/LMsf4C/ytTaTlhVFJz/HCSgEVFkDNcemsxD9Ow/gvKUFG5xerU Y78p603ZTHR3g== From: Tim Bruijnzeels 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\)) Date: Wed, 13 Oct 2021 10:06:42 +0200 Message-Id: To: SIDR Operations WG Archived-At: Subject: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 08:06:51 -0000 Dear all, draft-ietf-sidrops-8210bis-03 defines the ASPA PDU as follows: 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 11 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | | | Flags | zero | Provider AS Count | | | | | +-------------------------------------------+ | | | Customer Autonomous System Number | | | +-------------------------------------------+ | | | Provider Autonomous System Numbers | | | ~-------------------------------------------~ I believe that there is a potential issue here with very large ranges of providers. Theoretically up to 2^32 four byte providers ASNs could be specified. Because of the length of the provider AS count field that is limited here to 2^16 - still a large number. Would it make sense to support ranges as well? To avoid sending everything as ranges (which would cause some overhead) we could have: 0 8 16 24 31 .-------------------------------------------. | Protocol | PDU | | | Version | Type | zero | | 2 | 11 | | +-------------------------------------------+ | | | Length | | | +-------------------------------------------+ | | | | | Flags | zero | Provider AS Count | | | | | +-------------------------------------------+ | | | Customer Autonomous System Number | | | +-------------------------------------------+ | | | Provider Autonomous System Numbers | | | +-------------------------------------------+ | | | | | reserved | reserved | Provider Range Count| | | | | +-------------------------------------------+ | | | Provider Autonomous System Range Start | | | +-------------------------------------------+ | | | Provider Autonomous System Range End | | | ~-------------------------------------------~ Kind regards Tim From nobody Wed Oct 13 02:09:08 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7573A115D for ; Wed, 13 Oct 2021 02:09: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 (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 S8hFg-SIuYPj for ; Wed, 13 Oct 2021 02:08:58 -0700 (PDT) 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 8B6AB3A05F0 for ; Wed, 13 Oct 2021 02:08:58 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id g10so7382271edj.1 for ; Wed, 13 Oct 2021 02:08:58 -0700 (PDT) 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=qNQpyNPm+KtW2nulzhvDaDhfGCqA1oYom139FDQpn34=; b=NYKKOBDFLZVAGkL0A78m/d2LWvy6atx62DB7cNyp24HpTcRQuGMvgjYiJRp3Ux4qGp cWD2509wc0L1wWYnwzxKhSdw9iaULYhSUe5FAHfQk6wSOEOaEeUForphtvRDwK6z8eTu hiWWnv3EZnAcYaDOLEfp6a/Q7scYnsm7wLiw8= 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=qNQpyNPm+KtW2nulzhvDaDhfGCqA1oYom139FDQpn34=; b=Jget2m8JO+DHAXbjAXdftvogAU9n80svF2vrJIzTc0o372MxZa1hufkJi+Sk4djayR RrP9fEk+V9wME4SLshYGY/rovtLxXCJdsnMGLRgHsJ96BsqoFxPN9AtAxonrMj4pwuHP kh3ytoPar0RRE7PVCIdGO+Mc8nF1TAlPZeYUtII+r/LiyuuDeEOtGWMJOhzKrNXQIxVk 8BIMpHjd4Ip8wK0e0quYQq/GBkVphBpExOY7FFO4KAJJmEW38o4YZjyJPgL73gaaTtgv XeVzLJmbcRLahi+UVVXqRsKAqF68FocRldLl3+0PDNGHJPppmig18CpZ+cvN3THag0xZ 7HlA== X-Gm-Message-State: AOAM532L4jgaftvHM/PfsQAvoF9MzjYuwSY5s8drIQDlKhDpVSNb6dT3 jtScxlAzZKRT913aYz/HG0ez5qaT3iC9RQ== X-Google-Smtp-Source: ABdhPJxu7+Wi0Aicx5HUvWRYBVBJUROJ0rIjigULRZy03KFM5fZ+l8pERjz+8JGidaLanGtRpPO5tw== X-Received: by 2002:aa7:dbd2:: with SMTP id v18mr7683030edt.315.1634116136090; Wed, 13 Oct 2021 02:08:56 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id w15sm6292317ejb.4.2021.10.13.02.08.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 02:08:55 -0700 (PDT) Date: Wed, 13 Oct 2021 11:08:54 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 09:09:03 -0000 Hi Tim, On Wed, Oct 13, 2021 at 10:06:42AM +0200, Tim Bruijnzeels wrote: > I believe that there is a potential issue here with very large > ranges of providers. Theoretically up to 2^32 four byte providers > ASNs could be specified. Because of the length of the provider > AS count field that is limited here to 2^16 - still a large > number. > > Would it make sense to support ranges as well? To avoid sending > everything as ranges (which would cause some overhead) we could > have: Ranges do not make sense to me. Which ISP or IXP on this planet has a set of providers which coincidentally also form a coherent numerical range? Has anyone ever said "I buy transit from AS 1 upto including 1000"? Kind regards, Job From nobody Wed Oct 13 02:36:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30053A11D8; Wed, 13 Oct 2021 02:36:36 -0700 (PDT) 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, NICE_REPLY_A=-0.001, 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 EfQw21vCpsYH; Wed, 13 Oct 2021 02:36:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D322D3A118B; Wed, 13 Oct 2021 02:36:32 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19D9aSXU095901 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2021 10:36:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Job Snijders Cc: Tim Bruijnzeels , SIDR Operations WG References: From: Nick Hilliard Message-ID: Date: Wed, 13 Oct 2021 10:36:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 09:36:37 -0000 Job Snijders wrote on 13/10/2021 10:08: > Has anyone ever said "I buy transit from AS 1 upto including 1000"? More to the point, what would happen if someone created an object which stated that they bought transit from AS1 up to AS4294967294? Nick From nobody Wed Oct 13 02:50:55 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18493A09B5 for ; Wed, 13 Oct 2021 02:50:52 -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=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 Y5MbQ1VRJoCK for ; Wed, 13 Oct 2021 02:50:48 -0700 (PDT) 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 0EFBA3A152D for ; Wed, 13 Oct 2021 02:50:47 -0700 (PDT) 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 611D492; Wed, 13 Oct 2021 09:50:40 +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=1634118639; bh=+3v2G7Oi3QQy8bZgZYegcBykpzGhmzaDguqdx9zV7io=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=rv10PsP5QFvMP+OoffAZmnQO03bbIVZL4z2cuXZXbfzXie5QR1xp4wPGHCBE0Hi1T Utg0P5I3xA7nWn3uWEsqFRLcpFaTok6u3ABeWU9HCIOMe3vtdRL+5PdL2EADzE42p4 Ap7Eryntv0Qj+39nXnIQKDkZGk4ey54pc8kuLephEVxZ36/YI6zOvRoSmczhpR7PSp ATO5wcWZ6ZtvQfsbqse8G0cEUTwF8LSiGDHusYPjYLkoaOM/7OZHySGpdW1CIwUxGX isWfnHTDtxyA4Oj42nQbJ4cJeNwH6eBlc6b1S/kl846DzpFLoAz0+8KsyCJjfhlTz8 qZ6B4sfPPcVYA== 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 In-Reply-To: Date: Wed, 13 Oct 2021 11:50:36 +0200 Cc: Job Snijders , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> References: To: Nick Hilliard Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 09:50:53 -0000 > On 13 Oct 2021, at 11:36, Nick Hilliard wrote: >=20 > Job Snijders wrote on 13/10/2021 10:08: >> Has anyone ever said "I buy transit from AS 1 upto including 1000"? >=20 > More to the point, what would happen if someone created an object = which stated that they bought transit from AS1 up to AS4294967294? Indeed.. ..or if.. - they want to say (for misguided reasons) consider *any* ASN after me = valid - they want to authorise all private ASNs - they hold a range of public ASNs - they are bad actors and want to see what this would do to your RP, RTR = session and/or router stack. Regarding the latter support for ranges only gets you so far of course.. = as they could have ranges of 2 elements, one blank, and repeat ad nauseam. That is still a 170kb = message (2/3 of 64k * 4b=10). Limits may be desirable somewhere, but of course any limit would be = arbitrary even if it's reasonable. I don't claim to have the full answer, but I think this needs some = consideration. >=20 > Nick >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 13 02:56:22 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC17C3A1558 for ; Wed, 13 Oct 2021 02:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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] 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 MXtNCrRPspk5 for ; Wed, 13 Oct 2021 02:56:17 -0700 (PDT) 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 15B373A1551 for ; Wed, 13 Oct 2021 02:56:16 -0700 (PDT) Received: (qmail 57324 invoked by uid 1000); 13 Oct 2021 09:56:09 -0000 Date: Wed, 13 Oct 2021 11:56:09 +0200 From: Claudio Jeker To: sidrops@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 09:56:20 -0000 On Wed, Oct 13, 2021 at 10:36:27AM +0100, Nick Hilliard wrote: > Job Snijders wrote on 13/10/2021 10:08: > > Has anyone ever said "I buy transit from AS 1 upto including 1000"? > > More to the point, what would happen if someone created an object which > stated that they bought transit from AS1 up to AS4294967294? Since this is a nonsensical request the ASPA draft needs to be adjusted and just plain not allow it. Please stop adding features that are complex to implement and not needed. BGPsec has the same issue of supporting AS ranges for no valid reason. It only adds an attack vector to the protocol. -- :wq Claudio From nobody Wed Oct 13 03:08:22 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062DA3A156D for ; Wed, 13 Oct 2021 03:08:21 -0700 (PDT) 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 PtdZPlDU9lgx for ; Wed, 13 Oct 2021 03:08:16 -0700 (PDT) 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 4A5E03A1572 for ; Wed, 13 Oct 2021 03:08:15 -0700 (PDT) Received: (qmail 83793 invoked by uid 1000); 13 Oct 2021 10:08:12 -0000 Date: Wed, 13 Oct 2021 12:08:12 +0200 From: Claudio Jeker To: sidrops@ietf.org Message-ID: References: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 10:08:21 -0000 On Wed, Oct 13, 2021 at 11:50:36AM +0200, Tim Bruijnzeels wrote: >=20 >=20 > > On 13 Oct 2021, at 11:36, Nick Hilliard wrote: > >=20 > > Job Snijders wrote on 13/10/2021 10:08: > >> Has anyone ever said "I buy transit from AS 1 upto including 1000"? > >=20 > > More to the point, what would happen if someone created an object which= stated that they bought transit from AS1 up to AS4294967294? >=20 > Indeed.. >=20 > ..or if.. >=20 > - they want to say (for misguided reasons) consider *any* ASN after me va= lid This is most probably abuse and so should be prevented. Please show real live prove that this is absolutly necessary for some case of operation. > - they want to authorise all private ASNs Private ASNs should not show up in the DFZ. Again this does not improve ASPA adoption and so it should just not be allowed. > - they hold a range of public ASNs How large of a range are we talking here? Even with a range of 100ASNs can be easily encoded individually without any problems. Please remember that the BGP implementations also need to implement the checks and having a mix of range and indiviual ASNs will not help them. Again it is better to keep it simple. =20 > - they are bad actors and want to see what this would do to your RP, RTR = session and/or router stack. This is the reason why ranges should just not exist. They add complexity and make the hole system more error prone. > Regarding the latter support for ranges only gets you so far of course.. = as they could have ranges > of 2 elements, one blank, and repeat ad nauseam. That is still a 170kb me= ssage (2/3 of 64k * 4b=10). > Limits may be desirable somewhere, but of course any limit would be arbit= rary even if it's reasonable. >=20 > I don't claim to have the full answer, but I think this needs some consid= eration. >=20 I think real world data needs to show that ranges are indeed needed and not only an extension that will be abused. --=20 :wq Claudio From nobody Wed Oct 13 03:14:36 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500FF3A158E for ; Wed, 13 Oct 2021 03:14:34 -0700 (PDT) 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, NICE_REPLY_A=-0.001, 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 XP6QH2CBlPo1 for ; Wed, 13 Oct 2021 03:14:31 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CEF3A11EF for ; Wed, 13 Oct 2021 03:14:29 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19DAEE0w000544 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2021 11:14:14 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Claudio Jeker Cc: sidrops@ietf.org References: From: Nick Hilliard Message-ID: Date: Wed, 13 Oct 2021 11:14:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 10:14:35 -0000 Claudio Jeker wrote on 13/10/2021 10:56: > Since this is a nonsensical request the ASPA draft needs to be adjusted > and just plain not allow it I would be in favour of this for exactly the reasons you mentioned. It adds nothing useful. Nick From nobody Wed Oct 13 03:17:58 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C143A159E for ; Wed, 13 Oct 2021 03:17:57 -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 CXxKDecXynRy for ; Wed, 13 Oct 2021 03:17:51 -0700 (PDT) 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 15E313A159B for ; Wed, 13 Oct 2021 03:17:43 -0700 (PDT) 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 7A8DC2FC; Wed, 13 Oct 2021 10:17:40 +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=1634120259; bh=YGJVa6yOyaaQKKh4bUg02gccGUAHDXQQ7+KhBOVowbE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=i2jtiy7cPyQt/HAvCnIn9P5+Ut5uHXOQA3u6POXZu+v/P/oKaTidzqibsfzi4iXii sJQbtw5kTaJeBs1noj+7Sa1JZ5H4Gc+BR1mI3ZIrTsjha0lty1erBC+YMb/o7vSFPK bPhonR/VZtLnUUvxT4876cAxo+tXotLjoUjT1JCBG8XUVuugweC4YBxwBWgfAajWNH X+GDroSWRHCsaQ3DBR8eKut4wGigeuuyCt0K2t6l2vk9JLII/HFJdssiQwYVFPHNZY rf3v0XfABKEDdBiKhHomVYo7F6V9ltrs8kltbkj2453qKz/KR3cQt1dSbRPBnK+W1M KYTnyB2r/xiIw== 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 In-Reply-To: Date: Wed, 13 Oct 2021 12:17:36 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <26E80679-7B2A-474B-87F1-D22674B22C98@nlnetlabs.nl> References: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> To: Claudio Jeker Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 10:17:57 -0000 > On 13 Oct 2021, at 12:08, Claudio Jeker = wrote: >=20 > On Wed, Oct 13, 2021 at 11:50:36AM +0200, Tim Bruijnzeels wrote: >>=20 >>=20 >>> On 13 Oct 2021, at 11:36, Nick Hilliard wrote: >>>=20 >>> Job Snijders wrote on 13/10/2021 10:08: >>>> Has anyone ever said "I buy transit from AS 1 upto including 1000"? >>>=20 >>> More to the point, what would happen if someone created an object = which stated that they bought transit from AS1 up to AS4294967294? >>=20 >> Indeed.. >>=20 >> ..or if.. >>=20 >> - they want to say (for misguided reasons) consider *any* ASN after = me valid >=20 > This is most probably abuse and so should be prevented. Please show = real > live prove that this is absolutly necessary for some case of = operation. >=20 >> - they want to authorise all private ASNs >=20 > Private ASNs should not show up in the DFZ. Again this does not = improve > ASPA adoption and so it should just not be allowed. >=20 >> - they hold a range of public ASNs >=20 > How large of a range are we talking here? Even with a range of 100ASNs = can > be easily encoded individually without any problems. >=20 > Please remember that the BGP implementations also need to implement = the > checks and having a mix of range and indiviual ASNs will not help = them. > Again it is better to keep it simple. >=20 >> - they are bad actors and want to see what this would do to your RP, = RTR session and/or router stack. >=20 > This is the reason why ranges should just not exist. They add = complexity > and make the hole system more error prone. >=20 >> Regarding the latter support for ranges only gets you so far of = course.. as they could have ranges >> of 2 elements, one blank, and repeat ad nauseam. That is still a = 170kb message (2/3 of 64k * 4b=10). >> Limits may be desirable somewhere, but of course any limit would be = arbitrary even if it's reasonable. >>=20 >> I don't claim to have the full answer, but I think this needs some = consideration. >>=20 >=20 > I think real world data needs to show that ranges are indeed needed = and > not only an extension that will be abused. Ranges here, and in the ASPA profile encoding, do not cause the problem. = They are a way to encode consecutive ASNs more efficiently. If you want to have a limit on the amount of provider ASNs that can be = validly specified, then I have no objection to that - I just said that limits = will de-facto be arbitrary. It's still better though in my opinion to have = well defined limits even if they are arbitrary - otherwise implementations will each = invent their own. If there is a reasonable limit then the RTR PDUs can remain simple, but = I would still argue for the encoding (other thread) because it's cheap to do and = well understood - it leverages RFC 3779 and is not inventing anything new. Tim >=20 > --=20 > :wq Claudio >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 13 03:32:56 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11583A15A5 for ; Wed, 13 Oct 2021 03:32:51 -0700 (PDT) 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, NICE_REPLY_A=-0.001, 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 haRMgpnMD7xo for ; Wed, 13 Oct 2021 03:32:48 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4741B3A159D for ; Wed, 13 Oct 2021 03:32:47 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19DAWWWf002734 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2021 11:32:33 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Tim Bruijnzeels Cc: Claudio Jeker , sidrops@ietf.org References: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> <26E80679-7B2A-474B-87F1-D22674B22C98@nlnetlabs.nl> From: Nick Hilliard Message-ID: Date: Wed, 13 Oct 2021 11:32:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: <26E80679-7B2A-474B-87F1-D22674B22C98@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 10:32:53 -0000 Tim Bruijnzeels wrote on 13/10/2021 11:17: > Ranges here, and in the ASPA profile encoding, do not cause the problem. They are a > way to encode consecutive ASNs more efficiently. agreed but there are few, if any, real-life cases where asn ranges would be used as a primitive in terms of specifying routing policy, and in particular if the ASN ranges specify lists of providers. I'd be quite keen to see this explicitly disallowed in terms of ASPA. If it's not there, the tiny potential handful of organisations who might ever need this would be inconvenienced to a minor extent. If the feature is there, it complicates overall end-to-end processing and opens up a bunch of really messy corner cases which would need to be explicitly disallowed in code anyway (unless you wanted code stacks to explode arbitrarily). Nick From nobody Wed Oct 13 03:41:37 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128AF3A1595 for ; Wed, 13 Oct 2021 03:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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] 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 FXgfX4OIfeYn for ; Wed, 13 Oct 2021 03:41:29 -0700 (PDT) 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 E1E893A121C for ; Wed, 13 Oct 2021 03:41:28 -0700 (PDT) Received: (qmail 18738 invoked by uid 1000); 13 Oct 2021 10:41:25 -0000 Date: Wed, 13 Oct 2021 12:41:25 +0200 From: Claudio Jeker To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 10:41:35 -0000 On Wed, Oct 13, 2021 at 10:04:08AM +0200, Tim Bruijnzeels wrote: > Dear all, > > Whilst implementing a proof of concept we found some issues in the ASPA -06 > profile that we believe could be improved on. > > The current definition in -06 is as follows: > > ct-ASPA CONTENT-TYPE ::= > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > ASProviderAttestation ::= SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > aFI AddressFamilyIdentifier, > customerASID ASID, > providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } > > ASPAVersion ::= INTEGER { v0(0) } > > AddressFamilyIdentifier ::= OCTET STRING (SIZE (2)) > > ASID ::= INTEGER > > This implies that we need one object for each AFI. The size of the providerASSET > sequence can become very large. Plus, theoretically, one could have a sequence of > AS0-4294967295, resulting in a 16GB sequence. I understand this would be an > extreme and perhaps non-sensical case, but still there is room for improvement > here. > > We propose to change the profile to the following: > > ct-ASPA CONTENT-TYPE ::= > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > ASProviderAttestation ::= SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > customerASID ASId, > providerASID CHOICE { > ProviderASSet, > SET OF FamilyProvider > } > } > > ASPAVersion ::= INTEGER { v0(0) } > > FamilyProvider ::= SEQUENCE { > aFI AddressFamilyIdentifier, > providerASSet ProviderASSet > } > > AddressFamilyIdentifier ::= INTEGER > > ProviderASSet ::= SEQUENCE OF ASIdOrRange > > ASIdOrRange ::= CHOICE { > id ASId, > range ASRange } > > ASRange ::= SEQUENCE { > min ASId, > max ASId } > > ASId ::= INTEGER > > aFI AddressFamilyIdentifier, > > > This definition uses the same approach defined in RFC 3779 sections 3.2.3.4 > and below to allow encoding ASNs more efficiently. > > Furthermore, it allows that we have one ASPA object per customerASID, and > that we do not need to repeat ourselves in case the ProviderASSet is the > same for all AFIs. > > One more question.. does it make sense to allow AFI values other than IPv4 > and IPv6? Looking at the RTR draft ASPA PDU it does not, and therefore we > should perhaps limit the valid choices in the profile as well. Adding ranges here does not solve your porblem of extremly large sequences. There is no enforcement that consecutive ASIds need to be range encoded so if I want I can still encode 1..4294967295 as individual ASids. It also does not solve the problem of 16GB cer files being deployed clogging up all RP clients. All it does is adding extra complexity. There is indeed a need for limits not only in the ASPA object but also all other RPKI X.509 profiles. You can play the same games with .roa, .cer, .mft files. -- :wq Claudio From nobody Wed Oct 13 05:48:26 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB8C3A07BC for ; Wed, 13 Oct 2021 05:48:22 -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 Jl2S6fvafUqu for ; Wed, 13 Oct 2021 05:48:17 -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 5A4E13A090F for ; Wed, 13 Oct 2021 05:48:16 -0700 (PDT) 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 625DC2C3; Wed, 13 Oct 2021 12:48:13 +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=1634129292; bh=bWlEvDbMpJIWgm41k5ky4owtvBz9zsvCKcbD+q1ZHG0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OeG4I+k+e9qhLPbgeewveZq6onI4FU2C1wTy9x5ARfikaH5+Jr2YdiXAodKGUJIxU CigoSMwVFLYoPLXcSrnrS6PCIkaxtB/vIHaWmqdPZ0kBIkYmuVRI2zpcytBVwT9YFu ONmASWhMhM656ZPunSJwSsyjRngUSNMI2xqsM4HG4FCT3NY2we9mWq28AAqRJn84DL N/blAoj9YWEgBFHWk+WZh76rDUWTb4P6PAXFMXqcJMbujhpb57uvw1kKJVmtj33b2g wnBPi51LM2FpWIiREElHr11myuFiBgUiR9FDcanij3y2Du4l3WvDWeNWKyJJbatR+r OC5ei9c54Peww== 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 In-Reply-To: Date: Wed, 13 Oct 2021 14:48:10 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> References: To: Claudio Jeker Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 12:48:23 -0000 > On 13 Oct 2021, at 12:41, Claudio Jeker = wrote: >=20 > On Wed, Oct 13, 2021 at 10:04:08AM +0200, Tim Bruijnzeels wrote: >> Dear all, >>=20 >> Whilst implementing a proof of concept we found some issues in the = ASPA -06 >> profile that we believe could be improved on. >>=20 >> The current definition in -06 is as follows: >>=20 >> ct-ASPA CONTENT-TYPE ::=3D >> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>=20 >> id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } >>=20 >> ASProviderAttestation ::=3D SEQUENCE { >> version [0] ASPAVersion DEFAULT v0, >> aFI AddressFamilyIdentifier, >> customerASID ASID, >> providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } >>=20 >> ASPAVersion ::=3D INTEGER { v0(0) } >>=20 >> AddressFamilyIdentifier ::=3D OCTET STRING (SIZE (2)) >>=20 >> ASID ::=3D INTEGER >>=20 >> This implies that we need one object for each AFI. The size of the = providerASSET >> sequence can become very large. Plus, theoretically, one could have a = sequence of >> AS0-4294967295, resulting in a 16GB sequence. I understand this would = be an >> extreme and perhaps non-sensical case, but still there is room for = improvement >> here. >>=20 >> We propose to change the profile to the following: >>=20 >> ct-ASPA CONTENT-TYPE ::=3D >> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>=20 >> id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } >>=20 >> ASProviderAttestation ::=3D SEQUENCE { >> version [0] ASPAVersion DEFAULT v0, >> customerASID ASId, >> providerASID CHOICE { >> ProviderASSet, >> SET OF FamilyProvider >> } >> } >>=20 >> ASPAVersion ::=3D INTEGER { v0(0) } >>=20 >> FamilyProvider ::=3D SEQUENCE { >> aFI AddressFamilyIdentifier, >> providerASSet ProviderASSet >> } >>=20 >> AddressFamilyIdentifier ::=3D INTEGER >>=20 >> ProviderASSet ::=3D SEQUENCE OF ASIdOrRange >>=20 >> ASIdOrRange ::=3D CHOICE { >> id ASId, >> range ASRange } >>=20 >> ASRange ::=3D SEQUENCE { >> min ASId, >> max ASId } >>=20 >> ASId ::=3D INTEGER >>=20 >> aFI AddressFamilyIdentifier, >>=20 >>=20 >> This definition uses the same approach defined in RFC 3779 sections = 3.2.3.4 >> and below to allow encoding ASNs more efficiently. >>=20 >> Furthermore, it allows that we have one ASPA object per customerASID, = and >> that we do not need to repeat ourselves in case the ProviderASSet is = the >> same for all AFIs. >>=20 >> One more question.. does it make sense to allow AFI values other than = IPv4 >> and IPv6? Looking at the RTR draft ASPA PDU it does not, and = therefore we >> should perhaps limit the valid choices in the profile as well. >=20 > Adding ranges here does not solve your porblem of extremly large > sequences. There is no enforcement that consecutive ASIds need to be > range encoded so if I want I can still encode 1..4294967295 as = individual > ASids. It also does not solve the problem of 16GB cer files being > deployed clogging up all RP clients. All it does is adding extra > complexity. >=20 > There is indeed a need for limits not only in the ASPA object but also = all > other RPKI X.509 profiles. You can play the same games with .roa, = .cer, > .mft files. I'd say you can play different games with all those types. You can go = wide, deep and large. I think it would be useful to discuss those things as = well but I will leave it aside for now. Where this was coming from is that we have this definition in -06: providerASSET SEQUENCE (SIZE(1..MAX)) OF ASID } And no mention of a limit. So my suggestion was done on the premise that large ranges could be valid - and even non malicious. If we would have the following instead then the discussion would be very different: providerASSET SEQUENCE (SIZE(1..N)) OF ASID } If N<1000 ranges are overkill. If N =3D=3D 65535 as the RTR PDU allows, = then we could consider leveraging the tried and tested compression mechanism from RFC 3779, already implemented and understood by all RPKI CAs and = RPs. It would really help to get operator and/or researcher feedback on what = a reasonable value for N could be. But I would say that even choosing some value now, would allow us to build up experience before making this an = RFC. Now that you are here, how about the AFI question? I believe that we = really only need IPv4 and IPv6. So, if it's pure simplicity you want without = the use of 'CHOICE', and you do not mind duplication (in most cases this = would just be handful), then you could also have: ct-ASPA CONTENT-TYPE ::=3D { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } ASProviderAttestation ::=3D SEQUENCE { version [0] ASPAVersion DEFAULT v0, customerASID ASId, providersV4 ProviderASSet, providersV6 ProviderASSet, } ASPAVersion ::=3D INTEGER { v0(0) } providerASSET SEQUENCE (SIZE(1..N)) OF ASID } ASID ::=3D INTEGER Where N =3D some reasonable value. > --=20 > :wq Claudio >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 13 06:42:20 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934B23A0982 for ; Wed, 13 Oct 2021 06:42:16 -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 (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 96_GMJ6CmJCO for ; Wed, 13 Oct 2021 06:42:09 -0700 (PDT) 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 AC17B3A0AA6 for ; Wed, 13 Oct 2021 06:41:57 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id t16so10416229eds.9 for ; Wed, 13 Oct 2021 06:41:57 -0700 (PDT) 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=02XXEukWBH1mCHU/Wjgrs63Y2s5feL4w2XZwmuEgivw=; b=xhoIuouGN7EWbhdbaGxoe/oEl2Y+QuyA/6EMrWRg8sgTahVF1a4DJyKeGI2lLD/1bO EcjjLCDRIKqrOzwp4uWirpZryLelxZNbmSLMxV5Eup+DQG6z0tfEO9X/DCvyXKmbk4ND YcfDbOZozgPLabJ4ppBgOFHzhKq9dp4Y+a4wA= 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=02XXEukWBH1mCHU/Wjgrs63Y2s5feL4w2XZwmuEgivw=; b=w313zuCtefVfxxrEPja1x76GZ5P8LZb8ZB7H4lUBFCb3Fq8eELmz43MBlFtI2U3Jfk EBEquy6zVjHB4Mt8LlHbdjtA41F2VzmAfRW5lB5thn7eLXpAmQpfR1iqWEWev2napgey 2u0BtV00VIge7a2BWYrckkFjhwpDDaRGYXBqd4zGKb0Scnys6eLoSoi0hMlH0HnrsD/H Bw10utPp7QFNRve5uqYMqXmEzCfqvQkxUI6sx66KcgRGj3BYqZ1xnxBiZtI3bVDDZeqa aq5YsJnnIrq6NJc3GS2ip+N4udK05Con/c2yfozdrGdOMiZOYZEl3l6A6vzMAE1oWGzr fSvg== X-Gm-Message-State: AOAM531slVvpV2HSl3L9i+3TFnmr7ULBnUZqi+4HVNb6MprSz7WoCE7v eJRaOTVB00pciCgKeB+dtsnwBRf8lkJqlmXg X-Google-Smtp-Source: ABdhPJw6Z7pRXjomV72RktxIlcHP7OD6Vjwv5OxlkeQCCQJGe8tIPyHBObuZWE5v4n+0wGzgrrLKUQ== X-Received: by 2002:a17:906:1510:: with SMTP id b16mr42191288ejd.332.1634132507323; Wed, 13 Oct 2021 06:41:47 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id l16sm6711205eje.67.2021.10.13.06.41.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 06:41:46 -0700 (PDT) Date: Wed, 13 Oct 2021 15:41:45 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: Claudio Jeker , SIDR Operations WG Message-ID: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 13:42:17 -0000 On Wed, Oct 13, 2021 at 02:48:10PM +0200, Tim Bruijnzeels wrote: > If N<1000 ranges are overkill. If N == 65535 as the RTR PDU allows, > then we could consider leveraging the tried and tested compression > mechanism from RFC 3779, already implemented and understood by all > RPKI CAs and RPs. What compression mechanism are you referring to? > It would really help to get operator and/or researcher feedback on > what a reasonable value for N could be. But I would say that even > choosing some value now, would allow us to build up experience before > making this an RFC. I don't think we can know any reasonable value for N. I'm not really in favor of adding arbitrary limits to the protocol specification itself. > Now that you are here, how about the AFI question? I believe that we really > only need IPv4 and IPv6. So, if it's pure simplicity you want without the > use of 'CHOICE', and you do not mind duplication (in most cases this would > just be handful), then you could also have: > > ct-ASPA CONTENT-TYPE ::= > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > ASProviderAttestation ::= SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > customerASID ASId, > providersV4 ProviderASSet, > providersV6 ProviderASSet, > } > > ASPAVersion ::= INTEGER { v0(0) } > > providerASSET SEQUENCE (SIZE(1..N)) OF ASID } > > ASID ::= INTEGER Is the above ASN.1 complete? Kind regards, Job From nobody Wed Oct 13 06:50:07 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441793A09DB for ; Wed, 13 Oct 2021 06:50:06 -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 (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 2kQ2dhGc4bgf for ; Wed, 13 Oct 2021 06:50:01 -0700 (PDT) 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 293C03A09D6 for ; Wed, 13 Oct 2021 06:50:01 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id w14so10415355edv.11 for ; Wed, 13 Oct 2021 06:50:00 -0700 (PDT) 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=7VJHephBXmaZkGMbamS+vojowfiBQMjW+3pOkrUiCiU=; b=uT0OXcA6jBuVbFZo0NazM+lEqtgEg/xCQiHB53LYvX4o/Se5xPC81SrVvmkT1+DfB5 2ZOj4xTZTMAtb63v6TD724agfIw4jc5bhIkLp3w/0hrNJLkfNU2nXlzEw18PUIhJL6lh Of4JvpugSJw+zoJeT6SgiIM32cUqWF5Xb7AFs= 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=7VJHephBXmaZkGMbamS+vojowfiBQMjW+3pOkrUiCiU=; b=68cc2IhOYKStAcx8kYyoX8M2zorsyYrz08hsibQ6ddQr+fWzjijmUBT9v8RwY6UYR7 HOWJKb+naQETeV9PqtQ39TqoMwXY4KWT6LLDakPRnEgBNPeeUPc0p86zRKNucHAjtCVC +ccp/rsR7wY4Ll4SbcwTO3LaT7Pv9OebRXKGQCUzTkjZJVbmZY2gFhz3SgCEtP6uoFsd vvmt3Uq0/eofqYICcsdzO3E7RCFZyCfYkUfZtPVjYXumRu2fD5a4n9eEIcYlZZmMd3Wj ROjlrbkztgzDZbKsnwKT7BuRs5s3l6DAcq3CAa44JigNoaPOpTToK6l0797kFw2c0xZW CoNw== X-Gm-Message-State: AOAM5327YoZParJGrO27LRfpfwdizqgbHgJYQ4PwSjKTeSmQ6D8NMpIP gtL16jqXxpst+nJtHzSVmn7gjw== X-Google-Smtp-Source: ABdhPJx2WPCnpwFYZ7t4i8Gaya+vp4ejZfVNv+X9EtKMYwfGsqXrHezAV3XoV2jWPCyLebg2/TcUqQ== X-Received: by 2002:a17:906:16d0:: with SMTP id t16mr40291794ejd.199.1634132999009; Wed, 13 Oct 2021 06:49:59 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id y4sm6853213ejw.3.2021.10.13.06.49.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 06:49:58 -0700 (PDT) Date: Wed, 13 Oct 2021 15:49:57 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: Claudio Jeker , SIDR Operations WG Message-ID: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 13:50:06 -0000 On Wed, Oct 13, 2021 at 03:41:45PM +0200, Job Snijders wrote: > > then you could also have: > > > > ct-ASPA CONTENT-TYPE ::= > > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > > > ASProviderAttestation ::= SEQUENCE { > > version [0] ASPAVersion DEFAULT v0, > > customerASID ASId, > > providersV4 ProviderASSet, > > providersV6 ProviderASSet, > > } > > > > ASPAVersion ::= INTEGER { v0(0) } > > > > providerASSET SEQUENCE (SIZE(1..N)) OF ASID } > > > > ASID ::= INTEGER > > Is the above ASN.1 complete? Ah, you replaced an 'afi' field with 'providersV4' and 'providersV6'. That indeed introduces a fair bit of duplication. How about an optional 'afi' field per provider AS? If the field is absent, the Relying Party will apply the information to both IPv4 and IPv6. If the 'afi' field is present, the value of the field specifies the only AFI for which the provider is providing to customerASID. Given that generally folks acquire dual-stack transit services, it might make sense to put the 'burden' on those operating with different sets of providers for IPv4 compared to IPv6. Kind regards, Job From nobody Wed Oct 13 06:58:31 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66543A09FB for ; Wed, 13 Oct 2021 06:58:28 -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 OWRUpcJ2AKsi for ; Wed, 13 Oct 2021 06:58:24 -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 D25793A09F0 for ; Wed, 13 Oct 2021 06:58:23 -0700 (PDT) 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 725592C3; Wed, 13 Oct 2021 13:58:20 +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=1634133499; bh=GTrOvF0Wb/y70SU6f01NsoFpW1HyjoBKvwAxfBM45S8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=K7B1gQfWKMBr6peyMHr01ocVUAaKkVRdAw6sLT05X6vlB9YKM0C23pB9/EXB2KzZh Jn6QooMwT7D2Xx6f/0mZcaJKtmlJWkiIWwM6ygYmxCX8Nlzeq/0KojA1JRR6tzgY8U r9suf+mWsKJhYs7czgoKN1q65t2WO4dzda0XM9TNxk5v9g3+DX5V8ccNHgJV7n+WRw 9p40cxVz+mWDC5oL7bcq//j6d1Gv0eLp43dFWEwCcL9DbBwmAiY7XSqtvabsnFKZCX hmZuvgYHTVFbw2IGBmoa6Gf4ZST+1bBaq5ZDuJkNCyWjejVnEmo5pJaKPIA1fVykja 2Lji7W66WP88Q== 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 In-Reply-To: Date: Wed, 13 Oct 2021 15:58:16 +0200 Cc: Claudio Jeker , SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 13:58:29 -0000 > On 13 Oct 2021, at 15:49, Job Snijders wrote: > > On Wed, Oct 13, 2021 at 03:41:45PM +0200, Job Snijders wrote: >>> then you could also have: >>> >>> ct-ASPA CONTENT-TYPE ::= >>> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>> >>> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >>> >>> ASProviderAttestation ::= SEQUENCE { >>> version [0] ASPAVersion DEFAULT v0, >>> customerASID ASId, >>> providersV4 ProviderASSet, >>> providersV6 ProviderASSet, >>> } >>> >>> ASPAVersion ::= INTEGER { v0(0) } >>> >>> providerASSET SEQUENCE (SIZE(1..N)) OF ASID } >>> >>> ASID ::= INTEGER >> >> Is the above ASN.1 complete? > > Ah, you replaced an 'afi' field with 'providersV4' and 'providersV6'. > That indeed introduces a fair bit of duplication. > > How about an optional 'afi' field per provider AS? > > If the field is absent, the Relying Party will apply the information to > both IPv4 and IPv6. If the 'afi' field is present, the value of the > field specifies the only AFI for which the provider is providing to > customerASID. Works for me as well. > > Given that generally folks acquire dual-stack transit services, it might > make sense to put the 'burden' on those operating with different sets of > providers for IPv4 compared to IPv6. Sure, in the end of the day the burden of encoding/decoding will be on the software. But I like the idea of applies-to-both-unless-stated-otherwise. The burden on the operator will be to do the stating rather than the actual encoding if you see what I mean. Tim > > Kind regards, > > Job From nobody Wed Oct 13 07:06:48 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C791E3A0881 for ; Wed, 13 Oct 2021 05:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=no 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 nSRT7IckJ9ZL for ; Wed, 13 Oct 2021 05:01:49 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 300BA3A0878 for ; Wed, 13 Oct 2021 05:01:49 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id g62-20020a9d2dc4000000b0054752cfbc59so3357970otb.1 for ; Wed, 13 Oct 2021 05:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fqbf9uPog64i54j3e/Wc2OSzuS8QJ13y6QnoxNhwxJc=; b=kfPfBKz+CySoY05rnsH+hETzvVB8BImYHe2DuEGerprfimucQ4y7t286TdtnOVRdPV tHbVFIbZ1FIiXqAcScL5ksCfzgxYpKXk0RziYPOL2B9W6CMAXhJ9LS/iqS8HJAl0aV3+ osJK+hpMmbtSlXC+W1ZgJHQc4REBOy2Ym+/M3AkNKYjDlZgkKhbRKPRv76YMf1bfIvE5 LxEAKFacS9PzLLW5vWtiZjn8d/a1G4e1mA6IrDt8U2fOWHkfEL0PbfY0bGpSck8u8rpE eCCrdXf2tcd0La4EKb4NP5lTLPbvspDD0DPfggcqe0hWCU4H2pSLdIZA+WHLCjJhJbSc 1twg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fqbf9uPog64i54j3e/Wc2OSzuS8QJ13y6QnoxNhwxJc=; b=ofD/B+XTBJJTPstZ8qBjy3JFolemK70P3kupSZ0UC0F5ar5cEdmKx1u8IbmbBvxkEF 6DJjI1UWzgUNkktq32/g3YWmh4IjCPal80mqUd7VmeJOK/aexUl528byhczSxKh3jEKm uE0atuG6YdWtfME/zhqgCsReqKmwJby2W+lPaPG9PBWxx5J52jD4Q8TppKM0oUjr1p91 QBLxBRvR5y7OLKoL2j4SGj8w60eWoMrYWqRiV2vl1h3nVmxrYqhf+UoV4/OFntiVPHAw jlnuqe6ZGDPYrNzViRryuPGIc752Tih0HdgF3i4fNaDNcNDq0KZ2hOji2SGBbo30rjk0 y8Lw== X-Gm-Message-State: AOAM531srigKARDZqHfetqRJ15EQvtTdaNmPdCFNcqXGDeeM5I3YUnth U4cMBhHxXXmm4DMpmnpR45Kr593f4ZcajNkGugc= X-Google-Smtp-Source: ABdhPJwbklaU5FDXG7JcMGiAfEaNw1RzpStAb+0VwUxcgqZWbBBiZHXg1MgGmdZ5oKoADRhf54D6s5ygE2iDoPJ29Us= X-Received: by 2002:a9d:609:: with SMTP id 9mr31231297otn.231.1634126507120; Wed, 13 Oct 2021 05:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6830:10d2:0:0:0:0 with HTTP; Wed, 13 Oct 2021 05:01:46 -0700 (PDT) In-Reply-To: References: From: Sharon Goldberg Date: Wed, 13 Oct 2021 08:01:46 -0400 Message-ID: To: Yossi Gilad Cc: "keyur@arrcus.com" , "sidrops@ietf.org" , "benm@workonline.africa" , "job@fastly.com" , "Sriram, Kotikalapudi (Fed)" Content-Type: multipart/alternative; boundary="000000000000f99be905ce3ab9df" Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 07:06:46 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 12:01:54 -0000 --000000000000f99be905ce3ab9df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is no IPR relevant to this draft that I am aware of. Thanks Sharon On Tuesday, October 12, 2021, Yossi Gilad wrote: > There is no IPR relevant to this draft that I am aware of. > > Kind regards, > Yossi > > >> >> >> ----------------------------------------- >> >> >> >> Hi Folks: >> >> >> >> A working group last call has been requested for draft-ietf-sidrops-rpki= maxlen-08, =E2=80=9CThe Use of Maxlength in the RPKI=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-i= etf-sidrops-rpkimaxlen-08. Authors, please reply indicating whether you're = aware of any relevant IPR that hasn't been disclosed. >> >> >> >> Regards, >> >> Nathalie, Chris & Keyur >> >> >> > --=20 --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --000000000000f99be905ce3ab9df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is no IPR relevant= to this draft that I am aware of.=C2=A0

Thanks Sharon=C2=A0


On Tuesday, October 12, 2021, Yossi G= ilad <yossigi@cs.huji.ac.il= > wrote:
There is no IPR relevant to this draft that I am awar= e of.

Kind regards,
Yossi
=C2= =A0

=C2=A0

-----------------------------------------

=C2=A0
Hi Folks:
=C2=A0
A working group last call has been requested for draft-ietf-sidrop=
s-rpkimaxlen-08, =E2=80=9CThe Use of Maxlength in the RPKI=E2=80=9D. P=
lease reply to the list with your comments. The WGLC will end on October 25=
th, 2021.
=C2=A0
The draft can be found at: https://datatracker.ietf.org/doc/html/draft=
-ietf-sidrops-rpkimaxlen-08. Authors, please reply indicati=
ng whether you're aware of any relevant IPR that hasn't been disclo=
sed.
=C2=A0
Regards,
Nathalie, Chris & Keyur

=C2=A0



--
---
Sharon Goldberg
Computer = Science, Boston University
http://www.cs.bu.edu/~goldbe
--000000000000f99be905ce3ab9df-- From nobody Wed Oct 13 07:09:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47C13A0A05 for ; Wed, 13 Oct 2021 07:09:41 -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 LBbMQCWkR87V for ; Wed, 13 Oct 2021 07:09:35 -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 A293E3A0A01 for ; Wed, 13 Oct 2021 07:09:35 -0700 (PDT) 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 A248D2FC; Wed, 13 Oct 2021 14:09:31 +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=1634134170; bh=tGOKRkifHcaSsYYZQD2k09Zw5VsJYbRNyN1hY2jay/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pnRbPH7YcDDb5Z3hrGPlJT3lI3TH76D6ptKG4g60G0boc7Tro7JBhI06XPxLmUeeK cfkO38Z3lBvOloP+65zX1EnZyI66dYegulP6I3NM5cXZ2AGsa/5Pr/Jbxh/LhFOYAE CaZoPNGrxhzzPtj9fvsFYcuGkrja+iUrhqKH9aWVGed3duXPNOuiIcOnqgUYxefbpU CyFh/IaWWZ6fo3EkP6v0Yz42pd6PvuaTXBUSY9Hldxrqk2o3qQRsMfRoMCixcW7e9C xhrIW03BCNglGh98+JP1P+Wn4FlsdmVsm4aP55IWL7eIgZoRclPdbqc96mb6LcbgKt bPyNIgsTp0KNA== 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 In-Reply-To: Date: Wed, 13 Oct 2021 16:09:29 +0200 Cc: Claudio Jeker , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 14:09:42 -0000 > On 13 Oct 2021, at 15:41, Job Snijders wrote: >=20 > On Wed, Oct 13, 2021 at 02:48:10PM +0200, Tim Bruijnzeels wrote: >> If N<1000 ranges are overkill. If N =3D=3D 65535 as the RTR PDU = allows, >> then we could consider leveraging the tried and tested compression >> mechanism from RFC 3779, already implemented and understood by all >> RPKI CAs and RPs. >=20 > What compression mechanism are you referring to? https://datatracker.ietf.org/doc/html/rfc3779#section-3.2.3.4 I called this 'compression'. I think that it's what it's trying to do, but perhaps it was cryptic. This says that contiguous series of AS identifiers MUST be combined into a single range. A range of two elements would a SEQUENCE containing two INTEGERS. This still takes more space than two single INTEGERs. But for ranges of 3 or more elements this saves space. By itself this does not enable listing 2^32 providers, but it enables doing so in a small object, which is more likely to be parsed and = validated. You could disallow ranges of course, but then you just get large = objects. You could consider this a feature, because at some point they become too large to swallow and this shields the remaining stack. But there is no = saying really which part of the chain will fail first. >> It would really help to get operator and/or researcher feedback on >> what a reasonable value for N could be. But I would say that even >> choosing some value now, would allow us to build up experience before >> making this an RFC. >=20 > I don't think we can know any reasonable value for N. I'm not really = in > favor of adding arbitrary limits to the protocol specification itself.=20= Generally speaking I agree with that. But if no limit is specified then things will break in different ways for different implementations. The ASPA object could become too large to the taste of Publication = Server X, but not Y. Or RP A, but not B. The resulting RTR PDU could be too large = for router by vendor M, but not router by vender N. >=20 >> Now that you are here, how about the AFI question? I believe that we = really >> only need IPv4 and IPv6. So, if it's pure simplicity you want without = the >> use of 'CHOICE', and you do not mind duplication (in most cases this = would >> just be handful), then you could also have: >>=20 >> ct-ASPA CONTENT-TYPE ::=3D >> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>=20 >> id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } >>=20 >> ASProviderAttestation ::=3D SEQUENCE { >> version [0] ASPAVersion DEFAULT v0, >> customerASID ASId, >> providersV4 ProviderASSet, >> providersV6 ProviderASSet, >> } >>=20 >> ASPAVersion ::=3D INTEGER { v0(0) } >>=20 >> providerASSET SEQUENCE (SIZE(1..N)) OF ASID } >>=20 >> ASID ::=3D INTEGER >=20 > Is the above ASN.1 complete? >=20 > Kind regards, >=20 > Job From nobody Wed Oct 13 07:39:00 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE343A0ADC for ; Wed, 13 Oct 2021 07:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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=-0.001, 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 wzEVrX7iljYJ for ; Wed, 13 Oct 2021 07:38:23 -0700 (PDT) Received: from sonic313-56.consmr.mail.ne1.yahoo.com (sonic313-56.consmr.mail.ne1.yahoo.com [66.163.185.31]) (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 A4B663A0B04 for ; Wed, 13 Oct 2021 07:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1634135901; bh=JhLX7kHugcSaFw+/6nrB0pkixFe0qvKcH8aPNXQrl58=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=iqrH044cC/9dQWsB5H6q2ZK+j4EexFGCxDGaspsdRaQCDeh54iBHpCNnsowYRLcaFi3IwF7qCobLc0NR4g94I2yKetG3hX4J7IymAOlSKTb3nX26A3/9fMvTSfPn4+1UPL6S3A99kmFXwU0Mjm2z+snlP9AHKPdZ8hWmNbVvLp6eNFLUQgGoxcwGKI0ieebfVwwS6eEZaERe156iZFlTpnI1aUF1Ky4AmY3X7WQhbcX4jpmZMWtMIfidspbMs6CLQTQX4jbrO1DwpalwJTbcSLyuFThxr2a50358UFOE5D59NegcJqTacmNsDuXkDDhLLKjh10w1MxIJG5pKpAjdww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634135901; bh=YixQcl7CI1UvdLoqyPtlbeom/+qVzXzZr4xQl0bwOvj=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=oesM5gWreYPEhAkWhTVL5N9ZgML2n1vF2duNIFQM5jnGyUG4stuPq7Eam3f1mApOeozifhRXbuMhwEu9aLr/DgKOprlQKA0c6/bLdfl4GbTQ5Y/Y0YeXbtFlOZAOJaPXaq6YMfv/sbbGe39F0vau5l886trWiZr8/J2mkp9ijqm1ytT2G/N/rM3nPe59Zcwsn1jGpN29mlfgmk1BJsB5E8le2jo8AwU6sGU40n44OVX13FvIf9Nrhb54hv0liDvTJK/QwyoZvrpZIDkFjrTAmi28pS2qFnYvQktCUwhH7KEvxHhjH8cR+suEMwKbdsO1by4lMuhmwFl6Dq5LgKzcAQ== X-YMail-OSG: H70j1AMVM1ngfp6yzpuJLLPUmS9h_Lj5IayWRGRzfjjqUPur2Tb35.KJ_bBgZJk SdU9Wsi5kH_E9P.K1tOOA1zCan_hQlhdDHRA2jq0OCjQfyrV.pc537IAExoDvCg1mNuqD8POQ4Rj NJoLte1UAMDSVZeUvgg2Nid9h5gnq849zYsY6.KIRWf32h_uag2DcLE_LoSj3Mygfhh3fBC9.Yt8 PHx_2Utal1ejDls1C.zhwITJQa.jtmf6G7vrtMPldvCxRE4kEQGi3pXGVBf4_nnXui30yF5JApur bQFfLhtfF2EIRQaFcF.Q9I.fAnlEqa5E3uH4NUxG1RboU0RbdCMJuUGB8A2W.I43VcxpdJrNdgVr UA4GPjJkbDhUo2rqkRO2WBCr_WNJ68dDwuZ5.jbYmdiVeVCyQczjewtooM9pJ0g4gtKgeVebUoZB UvYm1En6MV4TXF2nR6r4aZynIgSP762lGUup3OErNjD82RmOEUSARRzmGQF3Worl9xc0AgwuTzjv 1QE64Dfiwgakymw38hDSLPWby9Ghunly2.Besfc7.2e4LQBw5paTP1mOAgas_OiX9GZF_kwUOArq jqGOyE0JlvZz9oB.W.5KZ3OG00cjOg0LdpxxORDqIlm28LAoAOQOmeu6OaRQQkOJQDHId6FOt_kC jlI.Xyv5la5hOOWSYJ98HE_5ddgSJI76LCY5AzQvBSkxXbE5_d2VKghG7BEffEMX6haVM5xVlEpZ bdhWrs8GXqvjFjGXgF0qZgWeOsa.85MO0mDEWy5fEJDZ2u.JHW7xC5MhfQMh0_RFo8SNg3fY9P21 RMB1UvzkAKRoQQaC07uNqaUx5xRTvC2iT0a_7xKsc9w5uai_khvfWfnUhcAax0HpvFO2Nkmu4HON 5.uivlpuzIKN9zU4eKHlYkBMHDmZlBwqtrfOjmtOUr8yIrc2nbNdxG8Iq.izLF5p5A5bNJstHTUo tbHz.eo9D0QuOQxjEc.QcpIU3YqtflQQrUNSlC8FiiQpI180P0GB17jJoXlCwzolcxoOeunkerUm RP7SEgA9lZe.JI2zNCeDUJHvBiw4xKlP98dVy.PLppv4_oFqcuHPhQIxMTgpTgjIcdS._4hHEbkR ZxB9tShtWrFJfFhkMnJLftcG5c_a.jXRhkU4_MsLAFrcwTnUUlLilSTnegJMb0xylftEV5_9sSVo n07MAUKIQfGkFy9kkF928AIrdVXDMn8M_FBKwuApiQBuS9MlqDOwq3KKDhl9XqsO_s.WYmwYagL. dyc20BXX40pRcF1Dnw.ZgUxphxY6RH5Lg1Q_gRbam6ilepuhaTiJu0V5AF28zh.TXNpNXggKYCpm eqHTpomd40B1BXTlpqs2ddpsiuEGzzZQrax6bYdjNB.xWhAG8n7jakmt8J1xqrvZtCX5VEjKHeKT KN9oHnU7khp49YGTiQlgn2JNRlUmRFvuWLrJ8tAPql9HFCDxn.b0yVWtE4t_AfTP5hwdPZxIIf2n 2PVL5qYBzVjaSDwDQKMEeebqu9ozo_YWIlsPdgWckciprZ_LTWs5vnCMQ0H2lNLWRU5SYEmRrdJN RfGWJhzTQWzKFuVaryZLs7p_Z38UdRNRkIYp.5mTfrj6atD5_gr0vdfsJED.oqrzVVYmbx.5VzMB Yq9GmQPY9j1Rt72pob_BuncoHfk.8pEDtl9_HkpMuYWBRrJfliAxtvrsxUZLGQ7gnf3fc.pUw9nf J8eu8_C670HjQZSFYfAUZ9rIzHO98nmKlB9.CWC0NVuSqM1N8CqpGN3eyx8._RSx7xyiCpVLF49J Wyufy8pSYDXJ32QqW7PCVGDVKhSRZreMfnXhLDsA0eInWn4P82TUel2_3aBdIdQ9w54r.CTDr1DI Vvi7hlnr5U0HYo2ErooQX0DqLv3_5ZGQY1LEoKT3rKIeJsFjHIckh0DJFv2PhIaxojEwJ6BaqOnl 4uIMXfuII8T7GU9Z_OsLqGntN50mVp3d9XTChrflTG61YEoFVF71tw7rimZwva3AHKToP3Pu.Bqc FrAtiyop.st0aUuxlDB4WCkhsru6_c1_XhXmlJRHCzN3Q3HaIw9chtgz8BeKAud1f5CMH8BOrlmC SubQLHr8JthUG1zOVt276_ZhAt0fH8ap0EXI5NL0_z57aUsRM2eMOTepS3IKiEtcKwdTw6OYMXMU Q34TYpBPzKWBij7oZdHwlv7iAz77mtuPkopn1PrO3LHX11nGYCJov59kyH9RCYpJfKkEDpG8.0Yq fkqVpNnD39ns3Tv1.ilU5HKY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Oct 2021 14:38:21 +0000 Received: by kubenode544.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5a0d513d4e754c86834eb38c9bed3fef; Wed, 13 Oct 2021 14:38:19 +0000 (UTC) Message-ID: <99ef228b-03e9-8efb-8bb4-bc1e5a071e7e@verizon.net> Date: Wed, 13 Oct 2021 10:38:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: sidrops@ietf.org References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19116 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 14:38:33 -0000 Tim, > I called this 'compression'. I think that it's what it's trying to do, > but perhaps it was cryptic. > > This says that contiguous series of AS identifiers MUST be combined into > a single range. A range of two elements would a SEQUENCE containing two > INTEGERS. This still takes more space than two single INTEGERs. But for > ranges of 3 or more elements this saves space. the representation specified in 3779 was intended to yield a canonical form, essential for DER. Steve From nobody Wed Oct 13 07:47:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D085B3A0A8D for ; Wed, 13 Oct 2021 07:47:50 -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=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 bAqEqk7lz1id for ; Wed, 13 Oct 2021 07:47:46 -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 2BAD23A0A86 for ; Wed, 13 Oct 2021 07:47:45 -0700 (PDT) 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 863E02FC; Wed, 13 Oct 2021 14:47:42 +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=1634136461; bh=SiL4AquQraepn6ONZnm7x+FYDgi9F2u1SL+p1o+HdHI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pIRpMyKdKfyTNxV8F6Gzh/9m5SA4zOLfFlRRNbC1UmcQWpMUIcdAI5UJJUwj8MXev Egg/quA+KScwmdWoV/inSCvBpyqcb+Qlj+OMT2EslwRWatIXykGtmYxErfy7GMdWPE 9FqivWJmiNCrWvxmHrOvSZCeEdQplpWTUofxkr0jaicQp4UUGF7yjthObVr17ySSh8 uH6CT7Il1bGAijN5K3zhjJrGmVIONK2u6diYR0u9O2b2M2PKm3y6dphydklJCH90WD Qkq6qFdSmHkpsGJjt6VftTvn/gaY4hauP+AWxGag1lrKGctGrsvqukCEzW094axvdf V+/BQikGkLvKQ== 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 In-Reply-To: <99ef228b-03e9-8efb-8bb4-bc1e5a071e7e@verizon.net> Date: Wed, 13 Oct 2021 16:47:39 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <99ef228b-03e9-8efb-8bb4-bc1e5a071e7e@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 14:47:51 -0000 > On 13 Oct 2021, at 16:38, Stephen Kent = wrote: >=20 > Tim, >> I called this 'compression'. I think that it's what it's trying to = do, >> but perhaps it was cryptic. >>=20 >> This says that contiguous series of AS identifiers MUST be combined = into >> a single range. A range of two elements would a SEQUENCE containing = two >> INTEGERS. This still takes more space than two single INTEGERs. But = for >> ranges of 3 or more elements this saves space. >=20 > the representation specified in 3779 was intended to yield a canonical = form, essential for DER. Sure. That is the most important goal. For it to be canonical it just matters that it's clear what applies. = But, I am sure that it's not listing every single AS a separate INTEGER=20 by accident. That said, if compression indeed was the higher goal then it would have been best to encode series of 3 or more contiguous = elements as ranges and series of 2 elements as separate integers. Anyway, it is what is. I think it's relatively easy to apply here and might save some space here and there, but I am fine either way as long as large ranges are not supposed to be supported - which is what I am getting from the WG. >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 13 12:34:56 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77CE3A0C99 for ; Wed, 13 Oct 2021 12:34:46 -0700 (PDT) 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 34YLdrKIUiNb for ; Wed, 13 Oct 2021 12:34:44 -0700 (PDT) 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 292F43A0C7A for ; Wed, 13 Oct 2021 12:34:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mak1I-0002lM-On; Wed, 13 Oct 2021 19:34:32 +0000 Date: Wed, 13 Oct 2021 12:34:31 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: Tim Bruijnzeels , sidrops@ietf.org, Claudio Jeker In-Reply-To: References: <70E039E5-3C2B-4F31-BC9D-118069CA2AD9@nlnetlabs.nl> <26E80679-7B2A-474B-87F1-D22674B22C98@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: Subject: Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 19:34:53 -0000 >> Ranges here, and in the ASPA profile encoding, do not cause the >> problem. They are a way to encode consecutive ASNs more efficiently. > > agreed but there are few, if any, real-life cases where asn ranges > would be used as a primitive in terms of specifying routing policy, > and in particular if the ASN ranges specify lists of providers. excuse my terseness; but for the three corner cases on the planet, who the heck needs this rabbit hole? randy From nobody Thu Oct 14 05:00:22 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1B3A161E for ; Thu, 14 Oct 2021 05:00:19 -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 O9uz60Q6lWFR for ; Thu, 14 Oct 2021 05:00:13 -0700 (PDT) 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 246E13A1625 for ; Thu, 14 Oct 2021 05:00:12 -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 3288B53; Thu, 14 Oct 2021 12:00:06 +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=1634212805; bh=4cVQZUwY5WWKaotOsdQ/7w3CJ4vOap84iGJdnX9Z83c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JwT0jLU8xdapBy4bwCJLLFuTTQLmriQrfRteHpmG3sjWp125dX3VRCNmIHH9RCc1s UjqWaBawmhE8pB66EIsCxPE8ACG4aAHWUTBFF2jG0OI6LgAjzX6mFPgBMAtOc6PjIv DsJmdj7LcFzZZFyIU5nxKFiZJ4ny8Ag80luQ7TNtMzLJ+3FHBmvDJjcdSnLflw4ep7 j5LmCzLNCS4EAbD2r0+NSJl+4oZHwDLfVWw5sHNxd9AwCMUlT51P+NZAAngVFR6iEX NJQlyI8AjsFoz+KmU6bTdgiwx3GFuqAaY99y+y/xbM83/akxuxPttAzN7vlxGfCkG6 OdbTIBnkc8uVw== 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 In-Reply-To: <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> Date: Thu, 14 Oct 2021 14:00:02 +0200 Cc: Claudio Jeker , SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 12:00:20 -0000 > On 13 Oct 2021, at 15:58, Tim Bruijnzeels wrote: > > > >> On 13 Oct 2021, at 15:49, Job Snijders wrote: >> >> On Wed, Oct 13, 2021 at 03:41:45PM +0200, Job Snijders wrote: >>>> then you could also have: >>>> >>>> ct-ASPA CONTENT-TYPE ::= >>>> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>>> >>>> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >>>> >>>> ASProviderAttestation ::= SEQUENCE { >>>> version [0] ASPAVersion DEFAULT v0, >>>> customerASID ASId, >>>> providersV4 ProviderASSet, >>>> providersV6 ProviderASSet, >>>> } >>>> >>>> ASPAVersion ::= INTEGER { v0(0) } >>>> >>>> providerASSET SEQUENCE (SIZE(1..N)) OF ASID } >>>> >>>> ASID ::= INTEGER >>> >>> Is the above ASN.1 complete? >> >> Ah, you replaced an 'afi' field with 'providersV4' and 'providersV6'. >> That indeed introduces a fair bit of duplication. >> >> How about an optional 'afi' field per provider AS? >> >> If the field is absent, the Relying Party will apply the information to >> both IPv4 and IPv6. If the 'afi' field is present, the value of the >> field specifies the only AFI for which the provider is providing to >> customerASID. > > Works for me as well. Let me try to write out an updated section 3 capturing this and see if it works for you and others. Obvisously, feel free to change it, but it may help to look at text. I left the providerASSET max sequence size at MAX. As Claudio pointed out we can have a similar discussion on other limits. Perhaps it could be an idea to have a separate draft where limits are specified, which can then also be updated in future. I know that limits are arbitrary, but without them we will get issues because implementations and various components in the chain enforce their own, different, limits. So, on the whole I think it would still be best to specify them. updated text: 3. The ASPA eContent The content of an ASPA identifies the Customer AS (CAS) as well as the Set of Provider ASes (SPAS) that are authorized to further propagate announcements received from the customer. If customer has multiple providers they MUST be registered in a single ASPA object. This rule is important to avoid possible race conditions during updates. An ASPA is formally defined as: ct-ASPA CONTENT-TYPE ::= { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } ASProviderAttestation ::= SEQUENCE { version [0] ASPAVersion DEFAULT v0, customerASID ASID, providers ProviderASSet, } ASPAVersion ::= INTEGER { v0(0) } ASID ::= INTEGER providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } providerAS ::= { providerASID ::= ASID, afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL } Note that this content appears as the eContent within the encapContentInfo as specified in [RFC6488]. 3.1. version The version number of the ASProviderAttestation MUST be v0. 3.2. customerASID The customerASID field contains the AS number of the Autonomous System that authorizes an upstream providers (listed in the providerASSET) to propagate prefixes in the specified address family other ASes. 3.4. providerASSET The providerASSET contains the sequence (set) of providerAS that are authorized to further propagate announcements from the customer. 3.5 providerAS The providerAS contains the providerASId which specifies the AS number of a provider. Optionally it contains an afiLimit field which specifies an IP address family limit, in which case the provider is only authorized to propagate announcments for the specified address familiy. This specification only supports IPv4 and IPv6. Therefore, afiLimit MUST be either 0001 or 0002. From nobody Thu Oct 14 07:15:32 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F273A16C5; Thu, 14 Oct 2021 07:15:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163422093055.5218.7049827726010929590@ietfa.amsl.com> Date: Thu, 14 Oct 2021 07:15:30 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 14:15:31 -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 : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-07.txt Pages : 16 Date : 2021-10-14 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 14 08:07:50 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA03A0A6C for ; Thu, 14 Oct 2021 08:07:48 -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_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=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 mGr-g6-pnlyc for ; Thu, 14 Oct 2021 08:07:42 -0700 (PDT) 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 E18433A16F5 for ; Thu, 14 Oct 2021 08:07:40 -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=PF6qIAmluacmyldOSLwzFtPL5TE44f1xgQJM3NQgBmk=; b=OAbfSKtMy/Kl+9SQu9j3Af39 XwsC8G/WiXHi0ENiAopBrZX3Gp0wYoRvA24pHHfoXE/1gaRcft2iQMIbAUSx4yiir3V9MWu8diHHU lQsXvlk2S9xbnr61Yrmg4afQXjD9yDi+HcZRGq6RsvAudrWXLNzE4wLxWbv1jSzm2OVdwcCSOjAdg jTeGoZim4Rde18xnUiKuhhuCOFNqPDllotvZhSEQqm0TQncm6n6Ho9vOkEmtXPGSskGP65Mba9flX qezTNRVzzVQUDEAFg+lejO4Oqpn7F3RwiPfFOh/7Y0wvQq/S6faOr4rzHJUUS1H7gaZ0kri3Fv/KR 2ZlldC2pqg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:57804) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mb2KT-00068J-UI for sidrops@ietf.org; Thu, 14 Oct 2021 17:07:33 +0200 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 ) id 1mb2KT-00041L-Rd for sidrops@ietf.org; Thu, 14 Oct 2021 17:07:33 +0200 From: Ties de Kock 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: Thu, 14 Oct 2021 17:07:33 +0200 References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> To: SIDR Operations WG In-Reply-To: <163422093055.5218.7049827726010929590@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15f728f603411ac29cbe0509aaf842836 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 15:07:49 -0000 Steve, Thanks for adding text clarifying the handling of manifestNumber and = thisUpdate. > On 14 Oct 2021, at 16:15, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : Manifests for the Resource Public Key = Infrastructure (RPKI) > Authors : Rob Austein > Geoff Huston > Stephen Kent > Matt Lepinski > Filename : draft-ietf-sidrops-6486bis-07.txt > Pages : 16 > Date : 2021-10-14 While reading the diff I thought it would be good to discuss this on = list: > 4.2.1: >=20 > This field is an integer that is incremented (by 1) each time a > new manifest is issued for a given publication point. This = field > allows an RP to detect gaps in a sequence of published = manifests. I would really like it if we could leave this open and allow arbitrary increments. It's what is out there in the wild, and RPs can not check = anything against manifestnumber either: Not all of them are guaranteed to be = visible.=20 Strict incrementing counters are also a point of contention in = implementations due to database locking on the parent CA. Existence/absense of manifests of a compliant CA is visible through the = CRL. And it does not make behaviour of a sloppy CA invisible. I would also like to revisit 4.2.2. > letter extension. The extension MUST be one of those enumerated in > the "RPKI Repository Naming Scheme" registry maintained by IANA > [IANA-NAMING]. Since the content of the registry is dynamic, I think it would be good = to clarify that encountering an unknown extension must not result in a = failed fetch. If RPs become intolerant to new filenames using an extension not in the registry (for example .asa) would require a flag day.=20 While reducing ambiguity in the results that RPs have when processing = manifests is good I don't think rejecting unknown types is worth the downside. Kind regards, Ties From nobody Thu Oct 14 09:15:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964933A171A for ; Thu, 14 Oct 2021 09:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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=-0.001, 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 c2lLvtQKzitx for ; Thu, 14 Oct 2021 09:15:15 -0700 (PDT) Received: from sonic312-24.consmr.mail.ne1.yahoo.com (sonic312-24.consmr.mail.ne1.yahoo.com [66.163.191.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 E87B03A1726 for ; Thu, 14 Oct 2021 09:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1634228112; bh=wLbh76Kdupn+LtctpnfZX0Q4qb3QrplmRA1eoCBpx28=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=TvexBSSSYqIs0Y1Z75JXWiUqvPNk8wMBQ1FNPXDZHGCq8gVGoIeI0jI184FXXr6A3H0e6v/GPKrDeBPbsqn+dq4vY5IjFmR20SuAFeu0YTNOfjITIl+bJNSPHCL5ooJtXgcDW0i1G7OmD+igKZgW1RL+/oYUBiR/JLwI58rE/pOeer2X8svfdvtTCqu71SIbxVvrBDkOEHVAbYWmDox6dLjgKfiHy2osfa+xqUWHIOh8dgGnobko7p85K6KMjOXXuLZ0U8zR5xInkZS6twxZnM5SWf/Yx8EsN34fdWU78nMu71+9zBFj9fAcyEB38f3NLf/EEWU77K5hSvdTDJ1aug== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634228112; bh=YGI7j3q21fVeRmp281ZQaW7hltjkC2bcb3Me5WM8HKw=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=TPWYzTjq+7tcpdco8ezVLHFBIxonefaILLOTMYRIAvSxh0xtvTpr384JjqWwb2tFGc1yllmlAcNVjKXqFrRDxQhaIaWNYeQFZh4uZPhQfOj3QXlR1T7FikffqV+6FMpzp0SceSwhdxY/k1x7rTWtGM5CpibZIuSItTknZ5FW/yxNvnQWWA2a/d3nrg9QwLvhblq/+LZ+xEBzHniIfopniyDCh8ZO4MhyIYmm3blOAAJsgSAC+B+TM990AKCjdO2d9twZDI3eoWgFUIDf2flSV6iWiC56/Jpk49EFiq8mcsZHeGxTfYsx5ULQNjBHH2ROR+5lgSOJQhTqtBd++63fBQ== X-YMail-OSG: KFvbxE8VM1mpJL7sLJEEiIycMXe0sMg.7J.dFG496qDUyblmhJUusYv8Ber2vny T5xFSI3uJS9V1EEjgjjHQBTOjNRVlTkvPS78PV382pHujS54SqDVeSD_yd_i4KpIRYLbJgqPl2Ek laAOZ3090eFjHdxLLd8zz4djAhoZWrjah1tfTiib.lxOnoxUtCx19FGe6_OU1Rq7qQlHLDEPt3jW x9qJNhPGKrELbD6nsszsjq_fk0Vm3GMz8q0PR69Yt9ALnodlISaCCdyvXC0dt4CgS0QZ7lfjReuQ 5cARMTVgW7V1UNFDg3EYfgDiDf.YAU0zY5.BGETF.mAqryr3lSFuP4NCTvbrk5KuTz_PMGQn5ODG _hhX5a1iCFcIbFKhM.vOmLP1SC7GKrunRQa1E7gAaYG2lLtpBK0hKhv0e_5wFHau90BeVL8j_amV DgbAa8thQahO7bL3CVMkEtrPZLdIr7jNT0N783F3t1YNPn4SnG_w8e5Z03MdrlZcnkWZtTa5D1io Tf6dfuPYArZLgKoAW4nYbYEcZDOjCEeMt5UxTZTySpiUTDN77uhF.0Lm8YlGYEzsm8a8VnFTC5BU sw1HPlnGak2JHiUz1odtuqqDtGXAcVETkqruSGq1hHpFg5b6MIV5Ry3YR1jTphwsrHBjzj.FRD3I 7Jpvj7iXIrhZi7Ub11gEmWG8iXmkPObPELszb5lh9V4WkRD0DTHwSFMEULL_dBxOgIv4gWT7m3.K TMO9ZmjgV7QA.BcRaCxc7.PdWEFV7I0TXtDG0HgHLFQHl4VeU_ovBvR.Igk0e1ib5ozkwbJVNK7f k0Nlx1nffpcOf0ghkWoQtFsi77CPLvxeegt8yAuHnupTVmncm.FYkT.hfdHitiUEtZOx4z0A4HNI _4enY9UKu5ACiKbKfBDLWpWyFM5VaoLFtTHy7.XyIU5W8V4Cv0Q71ihV6r4LB6Nkls6S9EPkNtqu HHPceTvQ8KPOLb4ukb3UJWeu0hvRJ_G2uhFi7XzihMETFuSfDdqEpd950J3mP2teqipmrHlH2cBK t7H8gHxPCGSzzySS04js_EkBmch0z7u68fAm6j9suwnTfKOyOWYaDNljeaYk8fhhEXHsw5dRaz9Z iGLjQSBIm02GMfmzPUPASAiX5NyamofUjCXaH.u.B6CoEPd52o.Azsq8f00Chv2wV1bC6KjyGk3y nCydGDRwBc_DsJFIYkvUkMHZ2Z4pDIDhQL3Dvupx8oajAoTjyFaxm8VZcwYebW13tphZh8c9xWHw hch2KrSrw8KTxVxaaQMGkd4A4FDw8Y82uYPR2FGHA8t9ARqzPyFOrWAWiRcxA18OzlyG8aDB_BFb XNTS.wH2TY1X8IYzLXMwMWTHw8Qy.UJPI0KIj8LvUdmyy54IL1.cAJnOHQGg62jZA3oCWjDeAjku .CFDNt3zZ7jwnBNOIbnVVj1lGjBIDocRV.YEJXDFZ4K9roQVSa75_Rj4LwQm01J6DjK0WULuUTlI HB0G4.QYTZdJ9OPH8HxkjmQMhsJJD6wkhOzRv7Qj5ZeA_BLhl4hUmul1uKq2QluU6o1qUguksvke 60ao5O00gMM2CNtrOym_z8uST1tL6SE_JaSl0EKvk21v.raSdk8XONg3WWOL.9wf4_ojaHwGmxRv wnH6Bn8cfzsqFtihrYLxulPzQuJogdO55H91WhQyISMYPO8Uef82b5Nt_jo4qlQcrl4a7Ob8uuBp w.0GhBK5LUYq9t3bP5LCGFqqOmBIxqX3kqiONtIIFJHP4srzGgcsTLhxr06gznMxvTBMCLA2f2Ms bsihtA1X_aEFXOR_Mxf_SPsemo5eHCRQZ05Q2cMRCZDHsiu_1DvrI596PM8uQADn0Ul11j5_B826 VNvIgbwYom41KYrwWmY6AWZskzFuV._VrMxZUitQq4A6v39f40VZkPNyrHBBwFFv9bhaOq_Kdc6R fnbPDa5YQnnvoMRwfO06hkp_OQ0EN5U40mnxnjMt7IAxaoM5swDBM58srXuKH6BjkaQAryiII5WA W0gOa0y4hNr.zDfvQOPeQdv7jtxAF4ARtu0_HVLtkFTvMhFTpPq9MIMkyxKFMwrub8WeAjvouZZE ZUn2J5ccOsUpScT_nD_zNTYzVh7hw5ghM8tStoyshwK5Mr33VtyCe745CbQceRWfReeiBW18CHnn mJXZHRHPPHrOOcBZT7nAQcCKe8FDZFcEvJyzfrYAI8SglICXnpQGXvgLqVhWm_jIIXcoPa_zfQVA DQXOWtso_FKj57Y4y X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Thu, 14 Oct 2021 16:15:12 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID da71ecd6fc0cb7d68f03568ba211eec6; Thu, 14 Oct 2021 16:15:11 +0000 (UTC) Message-ID: <32d38c02-0a6f-a5cf-6160-71748e97a453@verizon.net> Date: Thu, 14 Oct 2021 12:15:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: sidrops@ietf.org References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19116 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 16:15:17 -0000 Ties, > While reading the diff I thought it would be good to discuss this on > list: >> 4.2.1: >> >> This field is an integer that is incremented (by 1) each time a >> new manifest is issued for a given publication point. This field >> allows an RP to detect gaps in a sequence of published manifests. > I would really like it if we could leave this open and allow arbitrary > increments. It's what is out there in the wild, and RPs can not check anything > against manifestnumber either: Not all of them are guaranteed to be visible. > Strict incrementing counters are also a point of contention in implementations > due to database locking on the parent CA. > > Existence/absense of manifests of a compliant CA is visible through the CRL. And > it does not make behaviour of a sloppy CA invisible. I made this change in response to a request from Ben Madison on 9/30. You did not comment on his suggestion then, or over the next 13 days. Why are arbitrary increments a "good thing?" Why are they out there now? Which CA's don't know how to count by 1? The text does not require that an RP verify that the increment is monotonic, just that the new manifest has a nigher number than any previously-validated manifests from the same issuer. I don't see a need to change this. > > I would also like to revisit 4.2.2. > >> letter extension. The extension MUST be one of those enumerated in >> the "RPKI Repository Naming Scheme" registry maintained by IANA >> [IANA-NAMING]. > Since the content of the registry is dynamic, I think it would be good to > clarify that encountering an unknown extension must not result in a failed fetch. > If RPs become intolerant to new filenames using an extension not in the > registry (for example .asa) would require a flag day. > > While reducing ambiguity in the results that RPs have when processing manifests > is good I don't think rejecting unknown types is worth the downside. This text has not changed since version 4, posted in May of this year. It's way too late in this process to comment on this now, almost 6 months later. Steve From nobody Thu Oct 14 09:24:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCAF3A1735 for ; Thu, 14 Oct 2021 09:24:41 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 edHkUfh4vxnj for ; Thu, 14 Oct 2021 09:24:37 -0700 (PDT) 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 B67623A1AF8 for ; Thu, 14 Oct 2021 09:22:56 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id t16so26385785eds.9 for ; Thu, 14 Oct 2021 09:22:56 -0700 (PDT) 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=feARxEiPCwCLzpBhtiKSvhBZvvruNroR9XnlX97ux+E=; b=u8rR/arisWCXWqKekSzfHniRfO4Wom+eV25setkJLx5rdpoOGbGzRCrwZM3QcSHUVR FBMkrKiJxmAyj5mR7XR2/6PCzQNZ91ifdEdpq1kXGHK1h3rRXbW6d7WAwuvFGiHuaLVe Xig/Z29tbUIHtzIvZUMkUHATeBcYUfoa40bN4= 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=feARxEiPCwCLzpBhtiKSvhBZvvruNroR9XnlX97ux+E=; b=szwF/Ge9NqrzqiQIJTX4/fuOvRvhr9euSEeCSKbFOZCfQK3rQEMmJlnYdeEsBkdChh AyLMn7tQQNre/WknSrKH9QLUNsWznhsGMa6Zi6r4p3Gt8mf25xUrFyTh8LAkf5HHG4vX YtP3Df3Lc8KqddDNeVmFKbCaOaaYhIaTMmLi3Fg+WuIymhl8bIruFeYG1YndXfz/Goo2 9cYjrHHa4+ZCgeg8vthWzdVprDBpTquuuNQjeG/h9sgbQtSRW+/tvXtmIClzldzXV6p4 xJU9vSjDnGht0iyJ0i8QwCY9f2dLqMsx16kwfeAlLk8gQYMc1BJzXsrzvVKLR9IpjAgG Vsgg== X-Gm-Message-State: AOAM530T6+kA1I3yDGrz6naRFYpb5usZK0DNv2MY4Or78Y2loMq2MQ70 brSHEzMGZqgFmIfulVKq7GScxQ== X-Google-Smtp-Source: ABdhPJy9f8Tk974PxXAG8RbYOnThrRW2e0jsiAr10Qg4TrjHi7YlH5wlOpBWP8Z/ye2/kRz+DflPiQ== X-Received: by 2002:a17:906:48ce:: with SMTP id d14mr5049704ejt.336.1634228574030; Thu, 14 Oct 2021 09:22:54 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id v13sm3033640edl.69.2021.10.14.09.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 09:22:53 -0700 (PDT) Date: Thu, 14 Oct 2021 18:22:52 +0200 From: Job Snijders To: Ties de Kock Cc: SIDR Operations WG Message-ID: References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 16:24:42 -0000 On Thu, Oct 14, 2021 at 05:07:33PM +0200, Ties de Kock wrote: > > 4.2.1: > > > > This field is an integer that is incremented (by 1) each time a > > new manifest is issued for a given publication point. This field > > allows an RP to detect gaps in a sequence of published manifests. > > I would really like it if we could leave this open and allow arbitrary > increments. It's what is out there in the wild, and RPs can not check anything > against manifestnumber either: Not all of them are guaranteed to be visible. But isn't that kind of the point though? To be able to detect whether an RP saw all of them, because it is not guaranteed an RP will have visibility into all of them? > Strict incrementing counters are also a point of contention in implementations > due to database locking on the parent CA. Can you elaborate on this aspect? > Existence/absense of manifests of a compliant CA is visible through the CRL. And > it does not make behaviour of a sloppy CA invisible. > > I would also like to revisit 4.2.2. > > > letter extension. The extension MUST be one of those enumerated in > > the "RPKI Repository Naming Scheme" registry maintained by IANA > > [IANA-NAMING]. > > Since the content of the registry is dynamic, I think it would be good to > clarify that encountering an unknown extension must not result in a failed fetch. > If RPs become intolerant to new filenames using an extension not in the > registry (for example .asa) would require a flag day. > > While reducing ambiguity in the results that RPs have when processing manifests > is good I don't think rejecting unknown types is worth the downside. A flag day can be avoided by putting the .asa object in its own Publication Point: then the PP fails on older RPs (which is not a problem), and works as expected on newer RPs. Since for (for example) the .asa object type the early allocation process is used, I think there is sufficient time between 'new idea' -> IANA registry update -> 'deployment in the wild'. RP implementers need to stay up-to-date on what RPKI object types currently exist, which seems reasonable. I think there is value in clear guidance on what RPs should expect and not expect. For example, rpki-client only attempts to sync currently known filetypes, this hopefully limits the (potential) garbage RPs pull in: https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1cd85 Kind regards, Job From nobody Thu Oct 14 10:22:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058E33A1758; Thu, 14 Oct 2021 10:22:39 -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 fw2c89UKB-1V; Thu, 14 Oct 2021 10:22:34 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 9688E3A1766; Thu, 14 Oct 2021 10:22:34 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id t2so1966496qtn.12; Thu, 14 Oct 2021 10:22:34 -0700 (PDT) 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; bh=4KG3UmYVfLFcHLO7H2ybRYBdDOxivKJrWR2hIM8/BTs=; b=BzSurIMiycn70ty9ZMZhSDSXanT6hcfTuldAqsv28nnuWkypCJPRyHYUzdXSqwugjt Xx7iL5IzoJWBV9eeufn2FO4DMSEdBDFkvre4RH1xC/yFw0O1+dH4WqM6nuIwZR31srcg 8qtKlF4ROlAIoETgNJlHpUhoexp5Y+i1oti+zI4wTJN5lbU2AXYfRrAcpGmVji9Wj5xf QHjQ8b36dCSiaTCuZQcOm4cwnQwNLBZGPR6xePchidQi1bJu6t3y+9milcqCkPSX+xci wi+70L9DIjea3WdWn4MmS+5VUsg0OXl8Ns1KLbqE6PlkQrOIaC8fmoo9725jsg/5HGbi jCkA== 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; bh=4KG3UmYVfLFcHLO7H2ybRYBdDOxivKJrWR2hIM8/BTs=; b=J4sYyFzR9/xZxIYog3rdYPfWYrhmaoHCnPWi5auN90TEXzzDIB3gKJAGCh1je2RqJ2 bdWNoLARCYrhrE5JwTbFbm8N6c/CckT2N8zVaBl2BrFryoCofoKxYRvysiu6AOhC06A1 yiRJt/eh0ktsU6lPB6z6bY3f6AuVtp5N4gtHIoKGxVPM3AfMTyOhYeacu+9FFtsVcwAN PgiJfkSv/UX+3P57FOGsJgiZiPO/yzuS11wJvcXNKY4cSCzmY20cIh+lbPr2EZ5AFt9p JMXPxTaF1MSgRAjPE54yaJjsTpygwNowPfJV/Bv13c+l01nqSy5COmIqXJgZQvBlnLMY E0Yw== X-Gm-Message-State: AOAM532alCvMRvzJMKL7kuqDB0Np8QbOwoRQMbFG5daAHLUOv1lTEsEQ vLbOoQXywrlw0ZSEf4pzbQa5SIzv0wrwj9IHjPaDsFd1 X-Google-Smtp-Source: ABdhPJw6/Og3lJURggZx0kgvITtVh20BwHxk2s4pHPAouWQxapQivOuTigSbjb8HbAj/wSoUWkYfZhiV5VzkELtBqAg= X-Received: by 2002:ac8:8c:: with SMTP id c12mr7992585qtg.12.1634232152006; Thu, 14 Oct 2021 10:22:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Thu, 14 Oct 2021 13:22:21 -0400 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6a61505ce53521b" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2021 17:22:39 -0000 --000000000000e6a61505ce53521b Content-Type: text/plain; charset="UTF-8" Backing up to the top of the thread.... I think there was some good conversation, small changes (acceptable to all parties) and consensus to move forward! So, please consider this a closing comment on the WGLC, I'll kick out a shepherds doc and push forward into the waiting arms of the (loving?) IESG. thanks! -chris co-chair-persona On Fri, Sep 24, 2021 at 1:58 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > WG Folks: > Please take this as a WGLC start for: > draft-ietf-sidrops-6486bis > > The abstract of such is: > "This document defines a "manifest" for use in the Resource Public Key > Infrastructure (RPKI). A manifest is a signed object (file) that > contains a listing of all the signed objects (files) in the > repository publication point (directory) associated with an authority > responsible for publishing in the repository. For each certificate, > Certificate Revocation List (CRL), or other type of signed objects > issued by the authority that are published at this repository > publication point, the manifest contains both the name of the file > containing the object and a hash of the file content. Manifests are > intended to enable a relying party (RP) to detect certain forms of > attacks against a repository. Specifically, if an RP checks a > manifest's contents against the signed objects retrieved from a > repository publication point, then the RP can detect "stale" (valid) > data and deletion of signed objects." > > The WGLC should finish on/about 10/11/2021 - Oct 11, 2021... There's > already one question/comment on-list for this WGLC a pointer to which is: > > https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc > > Please give the -06 version of the document a read/comment and if you have > opinions(about this document!) please express them on-list before Oct 11, > 2021 (10/11/2021) > > -chris > co-chair-persona > --000000000000e6a61505ce53521b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Backing up to the top=C2=A0 of the thread....

I think there was some good conversation, small changes (accepta= ble to all parties) and consensus=C2=A0to move forward! So,
pleas= e consider this a closing comment on the WGLC, I'll kick out a shepherd= s=C2=A0doc and push forward=C2=A0into the waiting arms of the=C2=A0
(loving?) IESG.

thanks!
-chris
<= div>co-chair-persona

On Fri, Sep 24, 2021 at 1:58 PM Christopher Morro= w <christopher.morrow@gm= ail.com> wrote:
WG Folks:
Please take this as a WGLC start for:=
=C2=A0=C2=A0draft-ietf-sidrops-6486bis

The abs= tract of such is:
=C2=A0 "This document defines a "manifest&qu= ot; for use in the Resource Public Key
=C2=A0 =C2=A0Infrastructure (RP= KI).=C2=A0 A manifest is a signed object (file) that
=C2=A0 =C2=A0contai= ns a listing of all the signed objects (files) in the
=C2=A0 =C2=A0repos= itory publication point (directory) associated with an authority
=C2=A0 = =C2=A0responsible for publishing in the repository.=C2=A0 For each certific= ate,
=C2=A0 =C2=A0Certificate Revocation List (CRL), or other type of si= gned objects
=C2=A0 =C2=A0issued by the authority that are published at = this repository
=C2=A0 =C2=A0publication point, the manifest contains bo= th the name of the file
=C2=A0 =C2=A0containing the object and a hash of= the file content.=C2=A0 Manifests are
=C2=A0 =C2=A0intended to enable a= relying party (RP) to detect certain forms of
=C2=A0 =C2=A0attacks agai= nst a repository.=C2=A0 Specifically, if an RP checks a
=C2=A0 =C2=A0man= ifest's contents against the signed objects retrieved from a
=C2=A0 = =C2=A0repository publication point, then the RP can detect "stale"= ; (valid)
=C2=A0 =C2=A0data and deletion of signed objects."
The WGLC should finish on/about 10/11/2021 - Oct 11, 2021... T= here's already one question/comment on-list for this WGLC a pointer to = which is:
=C2=A0=C2=A0https://mailarchive.i= etf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc

Please give the -06 version of the document a read/comment and if yo= u have opinions(about this document!) please express them on-list before Oc= t 11, 2021 (10/11/2021)

-chris
co-chair-= persona
--000000000000e6a61505ce53521b-- From nobody Fri Oct 15 04:25:22 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDA63A1258 for ; Fri, 15 Oct 2021 04:25:20 -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=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 dA0M3ovmcaOy for ; Fri, 15 Oct 2021 04:25:15 -0700 (PDT) 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 7D8273A1324 for ; Fri, 15 Oct 2021 04:25:15 -0700 (PDT) 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=euWNwPugVfa1Ev74MmFbgFrsgKLrnaeJMJ9GaSzYzro=; b=GufidmtpJW7LM/jmWMDTBavU Z5cTL0yzYofru5nJ0M35Tv4x9sjsP19owcv4Lz8pGMCgog3Ccoo0NBkGlAHUJP+llUwJKzCAO+Wgh hSvNLLqN0QEcRDedQOO0sBuiq73cAfhtKLZ+gX03AGb+5xKamZDGZxtVjyzLJJPE9PhtdQlNWJROY Nw6CV1fdIpYWZAdjOLtyCYQweKUkJC5utQQ39wzIc8iXSY+jer8tOA60In8xYp4u+cxncPKWSv4Tt KObEjyy3+EpT5XcYKWA3L+kXHJ5+AxRzVGiMhP//qH6mcdYoJKP4oiZOrS0lPnSGZOm/ODYGxD7yi HjyiwgKQ7g==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:33536) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mbLKj-00075d-SK; Fri, 15 Oct 2021 13:25:05 +0200 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 ) id 1mbLKj-00066w-Pd; Fri, 15 Oct 2021 13:25:05 +0200 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 In-Reply-To: Date: Fri, 15 Oct 2021 13:25:05 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> To: Job Snijders X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e107684ce214f72a64be66f8cec29c5fad Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 11:25:20 -0000 Hi Job, I don't expect changes to the draft this late in the process, but I = think it would be good to share these concerns. > On 14 Oct 2021, at 18:22, Job Snijders = wrote: >=20 > On Thu, Oct 14, 2021 at 05:07:33PM +0200, Ties de Kock wrote: >>> 4.2.1: >>>=20 >>> This field is an integer that is incremented (by 1) each time a >>> new manifest is issued for a given publication point. This = field >>> allows an RP to detect gaps in a sequence of published = manifests. >>=20 >> I would really like it if we could leave this open and allow = arbitrary >> increments. It's what is out there in the wild, and RPs can not check = anything >> against manifestnumber either: Not all of them are guaranteed to be = visible.=20 >=20 > But isn't that kind of the point though? To be able to detect whether = an > RP saw all of them, because it is not guaranteed an RP will have > visibility into all of them? What would an RP learn from this? Are there any attacks that this = visibility can prevent? Keep in mind that a malicious CA can sign whatever it wants. And that an = on-path attacker or malicious repository can make objects valid/invalid by = presenting different sets of objects (so there is no need to sign objects if you = want to remove objects from validation). At the same time, there are many legitimate scenarios in which an update = is never externally observable. So RPs can not 'learn' anything from it - = it will happen many times a day. I will describe a straightforward one below: We consider a CA that processed ~2K updates an hour in a repository. Two = objects on the same manifest are updated in short succession. After each update, = a new=20 manifest is issued. The CA supports RRDP and rsync. The updates are sent to a RRDP publication server synchronously = (unlikely for real implementations). The RRDP publication server processes the two = publish (w/ hash, so replace) operations before issuing the next delta. The = update is never visible in RRDP. The rsync repository is written to disk batch-wise and revisions are = kept around for two hours. The CA does not have the performance (e.g. disk space, = IOPS, iO bandwidth) to write all 2000 revisions an hour to disk. The rsync = repository is written after both updates are processed. The update is never visible = in rsync. In some scenarios (a lot of updates, or during a key-roll) you can even = have _many_ manifests that are not visible this way. TLDR: I argue that in the real world, (potentially many) manifest = updates will never be externally observable and that a malicious repository can often = cause the same result for RPs, without signed objects. At the same time RPKI has a beautiful property compared to the web PKI: = an object needs to be widely visible (and thus easy to detect!) to affect the = default free zone. If you have an attack scenario where you can detect the behaviour of a = malicious CA this way, while that attack can not be performed by an on-path = attacker, please elaborate. >> Strict incrementing counters are also a point of contention in = implementations >> due to database locking on the parent CA. >=20 > Can you elaborate on this aspect? It is an implementation detail about parallelism and fine-grained = locking (on DB level) that does not lend itself well to description on a list. For = manifests it likely is no real concern. For serial numbers our implementation needs = arbitary increments due to this concern. >> Existence/absense of manifests of a compliant CA is visible through = the CRL. And >> it does not make behaviour of a sloppy CA invisible. >>=20 >> I would also like to revisit 4.2.2. >>=20 >>> letter extension. The extension MUST be one of those enumerated in >>> the "RPKI Repository Naming Scheme" registry maintained by IANA >>> [IANA-NAMING]. >>=20 >> Since the content of the registry is dynamic, I think it would be = good to >> clarify that encountering an unknown extension must not result in a = failed fetch. >> If RPs become intolerant to new filenames using an extension not in = the >> registry (for example .asa) would require a flag day.=20 >>=20 >> While reducing ambiguity in the results that RPs have when processing = manifests >> is good I don't think rejecting unknown types is worth the downside. >=20 > A flag day can be avoided by putting the .asa object in its own > Publication Point: then the PP fails on older RPs (which is not a > problem), and works as expected on newer RPs. This is a lot of implementation work if there is no attack that it = prevents. It also forces a CA to triple (the CA needs to maintain the PP incoming = from parent plus two children) the number of manifests it needs to keep up to = date per CA, or update less often and open a longer window for replay = attacks. What do you think of his strategy: * RPs that do not download unknown extensions do not consider those = when validating a manifest. Unknown files can not result in a failed = fetch. * If a new object is "safe" (it does not change the meaning of other = objects such as GBR) we can add the object with the same manifest = version. * A new object profile that changes, to whatever degree, the effect of = objects on the current manifest, requires a new (minimal) version of the = manifest. >=20 > Since for (for example) the .asa object type the early allocation > process is used, I think there is sufficient time between > 'new idea' -> IANA registry update -> 'deployment in the wild'. >=20 > RP implementers need to stay up-to-date on what RPKI object types > currently exist, which seems reasonable. I think there is value in = clear > guidance on what RPs should expect and not expect. While I think people should update quickly, given the update rate I see = in data I think this is a tricky route to go. Updates are slow. For example: = despite a lot of effort there are still ~240 active RPKI Validator 3 instances out = there and about half of those appear to be builds from more than a year old = [0]. > For example, rpki-client only attempts to sync currently known > filetypes, this hopefully limits the (potential) garbage RPs pull in: > = https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1= cd85 That is a nice local improvement in security!=20 Kind regards, Ties [0]: Current numbers will differ - I read this from a chart with data up = to the first of september. >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Oct 15 07:40:08 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878A83A08DE for ; Fri, 15 Oct 2021 07:40:05 -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 (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 rnlqjZ2qejRH for ; Fri, 15 Oct 2021 07:40:01 -0700 (PDT) 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 D63693A0873 for ; Fri, 15 Oct 2021 07:40:00 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id y12so40509905eda.4 for ; Fri, 15 Oct 2021 07:40:00 -0700 (PDT) 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=SQwKg8460tQPrsXlyl7ZLRF+yOEbPXvPCv27XxKp6LQ=; b=PrnQewOp9rNXZxQ8dZd3Y6s/j+ZErhvY29+Na2rExQLwVG/ihDHcJlixN72cBtA/R7 muva0IAVMZLLk04wEq+CsZ6E4RUOQMLxpAbOafTt4g9iowMsnqDY9X4MHh/8wNM3OI9n lnWqUMyQ0pnebNr8Ul50XNpltwOXwYWcC68Qk= 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=SQwKg8460tQPrsXlyl7ZLRF+yOEbPXvPCv27XxKp6LQ=; b=7Vrh2TMzsCXCZEZsrhAT7V9msr5NqKBji0cWdTsfFTTbpQnInbCvXbDMl5WdGdjMjY 6YvJJVjiGTHyHWrYWnTZRS8gx2IQDm3ewxyqSx1knHm4Uk5JVOyzhHCIiFrazZd+JV4y i3ZAOrdDghSaKTauNaLkfyd18yVfjFmEt9xAp59wwvcRpdbrsnS8se3uf+rflzQaUq1X 4vWq6Z9+Y5PgAk12hzBVjRSbGpO2puKNVCvsUPviQ/okDvBB5kKhes3X+76CzEcL+l3l 6d8uBd5QErHjNoaP5rBlXOIGupgWWBJt1ebqxkgl1TLtd/8acMoTqFH2q9+BvwQ7k+l1 q7Sg== X-Gm-Message-State: AOAM530vMxeJpkSzLBisg+PmQZXp1eHO9Mjz3JBbL0c8llOQbyZ995wP hJ6vFPOavIefpNAaWKrYWKjpNA== X-Google-Smtp-Source: ABdhPJwR/z1YtukIg0O12b/YX3MN7pRWGR0AxAc+G9RkdpHS84sPlpfpoOOdKg8rE8R2dSR0IrOvWA== X-Received: by 2002:a05:6402:274c:: with SMTP id z12mr18932729edd.57.1634308768703; Fri, 15 Oct 2021 07:39:28 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id lb20sm4373187ejc.40.2021.10.15.07.39.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Oct 2021 07:39:28 -0700 (PDT) Date: Fri, 15 Oct 2021 16:39:26 +0200 From: Job Snijders To: Ties de Kock Cc: SIDR Operations WG Message-ID: References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 14:40:06 -0000 On Fri, Oct 15, 2021 at 01:25:05PM +0200, Ties de Kock wrote: > What would an RP learn from this? Are there any attacks that this > visibility can prevent? I consider it useful debugging information. > What do you think of this strategy: > * RPs that do not download unknown extensions do not consider those when > validating a manifest. Unknown files can not result in a failed fetch. > * If a new object is "safe" (it does not change the meaning of other objects > such as GBR) we can add the object with the same manifest version. The above strategy matches OpenBSD's RP implementation as far as I understand: when an unknown file type is encountered on a Manifest, a log message is emitted "unsupported file type: %s", after which the unknown file is discarded. Only recognized file types will be processed (currently: GBR, ROA, CER, CRL). > * A new object profile that changes, to whatever degree, the effect of objects > on the current manifest, requires a new (minimal) version of the manifest. Yes, in theory. This list discussed Manifest profile version numbers a few weeks ago. I think most agreed that deploying a change to the Manifest profile version at any point in the future, will be challenging. Kind regards, Job From nobody Fri Oct 15 08:21:32 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D765C3A09BE for ; Fri, 15 Oct 2021 08:21:25 -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 (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 HUyH6YZpAf8M for ; Fri, 15 Oct 2021 08:21:21 -0700 (PDT) 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 D12FD3A098B for ; Fri, 15 Oct 2021 08:21:20 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id t16so39471136eds.9 for ; Fri, 15 Oct 2021 08:21:20 -0700 (PDT) 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=LVxcZFmNK+kCJrh/4p36EasFpq5iQMrdc3JzWb87mGY=; b=FBczjE8lu0FoBrpy34dhXKQ2Hqt2Fp2D74H7fEmAbDWn5+R5PjhAWxjB06dSrUQ89C LMu54GYNYlqF1cupoCUIMDle+CUBKGgqYj/TGmLXOVEFUxMuOP15NTxVqFPnUdoILSVn 3KJCr+K+NGmSQZp1LqFltr0aCo6CarVruaXx8= 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=LVxcZFmNK+kCJrh/4p36EasFpq5iQMrdc3JzWb87mGY=; b=RQbXkovPRP7XEvgWWLup7In0MEL8BwhE0Hxbvds3I7GyoYRTDElYYkcQjAuhOTGCl2 f3XI7/ImAwvvyL3ysEEGNHjEWKmEWIW2tEkccQu6dzw+2XPgsubqLZoVHzURWBt2v7k/ fYOoVHarf2Cljl93Mj7zO8/WJlweVcU0tXKswNfiX5KXoMZ0F4GQjc0WzKT/nS02PKQK VTFRedaQy2yC6+l1/Bwjy+EIte5PQO1p8iGjqMHwLBovasI3gAGUfXxagRgKVQ6MYww7 ECTRKQQ4hakS2MCmZLnkLL9gHnSj5j56mBilZEIuKcXmMr4PyWjcbb10mWHqFQBsHymd xC3Q== X-Gm-Message-State: AOAM533BQjAdnYrZ+e+8m5EnL5eabPnokbgRI9xIKLBOYUyDGnX2Gi/D 2IliLmOroQUALNSSTOxTyhEJfQ== X-Google-Smtp-Source: ABdhPJzPxkZSL+YzzrVJxRtVaAEW3YE1RfHmFrxl2UwUzGMsPUoap9keWgmu7etCaHFDmHpTnerjuQ== X-Received: by 2002:a17:906:b208:: with SMTP id p8mr7700195ejz.477.1634311252885; Fri, 15 Oct 2021 08:20:52 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id u23sm4781258edq.36.2021.10.15.08.20.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Oct 2021 08:20:52 -0700 (PDT) Date: Fri, 15 Oct 2021 17:20:50 +0200 From: Job Snijders To: Ties de Kock Cc: SIDR Operations WG Message-ID: References: <163422093055.5218.7049827726010929590@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 15:21:27 -0000 On Fri, Oct 15, 2021 at 01:25:05PM +0200, Ties de Kock wrote: > Two objects on the same manifest are updated in short succession. > After each update, a new manifest is issued. The CA supports RRDP and > rsync. > > The updates are sent to a RRDP publication server synchronously > (unlikely for real implementations). The RRDP publication server > processes the two publish (w/ hash, so replace) operations before > issuing the next delta. The update is never visible in RRDP. Indeed in the scenario you describe one of the two updates itself is not be visible in RRDP/RSYNC ('because overtaken by events'), but what *is* visible is that an update was 'lost' somewhere. (knowing that 'loss' doesn't necessarily mean 'bad'). Visibility into 'update loss' can be valueable information to monitor over time in context of understanding pipeline efficiency. If a CA + publication server system (in normal operating mode) exhibits monotonic increments, but ... at specific timesofday/workloads shows gaps, it might warrant investigation by operators. Summary ======= Trusting CA's to increment monotonically for each new manifest, hopefully aids operators when they need to troubleshoot RSYNC/RRDP. And Stephen Kent confirmed that RPs are not required to verify monotonicity [1] ... so I think we are all on the same page? :-) Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/sidrops/tUU2jV1nVu18RepnXgKeWgXEvhs/ From nobody Fri Oct 15 11:55:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040653A09A3 for ; Fri, 15 Oct 2021 11:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, RCVD_IN_DNSWL_BLOCKED=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 wlwi0n7Hf7OZ for ; Fri, 15 Oct 2021 11:55:36 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2103.outbound.protection.outlook.com [40.107.91.103]) (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 C7B013A09A1 for ; Fri, 15 Oct 2021 11:55:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lrrLKBDA4Fy3t+kgFlZ3nVmZcEitaFKWKXIOOqM/vQJ6VnZ23DvGpj5vWiwSfXtVRfcacG/zsRZ9GF9CCH1oziu4b5zRpo3DHiWjyI2OADvJO/WrBamvSf/wj9FECqCgmBj37m+cZIKW8nyHMBrhmiL/pILGRbsG3ZKdwyHHWo3lzrM8/oRY2piYktU2e/Hpu2Z7HLiUX1T10bOVDK0wdpwxZSnai4ETAiSyZiFjIUfOtVWuXHEslkTPQqWv3F+QdsdWNXGptVOluGBgVn5sbXvBf7i3sE+m1c4ImFkg6/gOL2VDMJMxa75PrtOKZClra7B2+5YJWKpU6bwqRwCBpg== 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=glzGHM34YTG8cKTXst068AVJGIytPexh/EIFCUtk8eg=; b=XPVAdUb55CixwWF56GTjpd4SCZfwbtG8MQuBIYWrT8XuFU59T1ybSORFdxZ8VObGOaQ3yxrv0Und1A7buQf9hHkVeZfQHv2h41Zx9Y46vmjks8yqcy2LTsoxGYciKMysFISV4faIFNKkvBCKQrcpZ+GzchXINTJHvKCb4tnzdj2lOrTtey/s/yc88qq87LcuhlTCeeXHwB0rxBulKHIHpPoOCp+YCLMsCKI7zznl9/hFzd4V/TfgqRbfld73wn7hogWII11ydedr1Wu+qmP0nNlzGgRPv5MAq+4H1zqnW8ezpJ2TbwDOCeOCzKgW8+djn/LC5rUcFNeGkLxpKzQMAw== 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=glzGHM34YTG8cKTXst068AVJGIytPexh/EIFCUtk8eg=; b=czaailyfmnZsh1KIukk7QlKYyUpJwZUf4nOeWj2G1uXl/snsY928g8qWBIRHH68igaVfs3fAevZqvjDbQLtL1vQETJmmWdKKSqP/gcIjrzjOrrRyDMF5JYClR+rHdfaMum8XxzbzQmGHOH5OJZhWjtScQfKvWucKat9EgprrhBA= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB7313.namprd09.prod.outlook.com (2603:10b6:208:2a0::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14; Fri, 15 Oct 2021 18:55:34 +0000 Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::d103:8ee4:69c3:e2c8]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::d103:8ee4:69c3:e2c8%6]) with mapi id 15.20.4587.030; Fri, 15 Oct 2021 18:55:34 +0000 From: "Borchert, Oliver (Fed)" To: Claudio Jeker , "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" Thread-Topic: BGPsec suports AS Ranges? - Re: [Sidrops] ASPA provider ranges in draft-ietf-sidrops-8210bis-03? Thread-Index: AQHXwejJ7KggBEL0Y0y8eC2x4dGKNw== Date: Fri, 15 Oct 2021 18:55:33 +0000 Message-ID: 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: diehard.n-r-g.com; dkim=none (message not signed) header.d=none; diehard.n-r-g.com; dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54a4d360-57df-464a-3d55-08d9900d5e4c x-ms-traffictypediagnostic: BLAPR09MB7313: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QqgnGm3s+ZDP9GLf3N4vUngqE1VlYhABkPGmbqAOWRXM4ge+y3UoeBfA24T+qeB91+H/rEBatgOZZIndTyZy/agZMmsYZqomQNg4cAzr82qVxy9+DUw8obVdi5air1/QkNcC8gMTUSsQTPu1kWpY3y7KmFs1bzcDE4rLPT8SaasQ9mjBB7Og16WYKN3pNbdZFFl44DY5cCmMune08qaCpruPU+1PyOwia/7ugSfgDrFgK2yQ8RQGfG8ZCz4xtG2QWimOfkvR10dm0V3l4E9I51VTQ+6foVpKtGItr1IOHxnmS3RWkrUX5t8SPZeSbfzXMAOBgvWXhDqUe11ALqiYaCCj0b5237CX3qVJUGiThaGAxlDxXUmTDeKSzvwvYNo4uiYTo7KLFXTNckttGS0BwV0zrvjtuHzewwYRBTH26O2OcE1efFPeZQtLX1AWm1C7UgffZteBLeOpelFa5aQsGxo1s4KxXmGP8B/VZfq20XsgMYKD31zyoyDs8tLWDjHnUmcl73on/J6pES+Dl5sw37CuwG9ba4tMfkGW67x9VzY4Ot5NkWxEJxg9yTbyt4A2Vo9SyIuFl7sc9fABQJAjH9g6ATl9E2SOBMHZNXbAUIJ5LXPsxBtCdOKyf7MMB/lqEY/auZm1V7euhNM0V47DmyVJfs8+3yySNbDcuClolEj+pIhV3KpdOHQkPVD55eX6dHvnAwD363Sl8rhUnMnfe/ajaaBnCpWSqiLWML+iYdiW/kPGdYJLfbeleDtevskyH2Xay5Y6a9GS31f5owHfyreH3pGPLga+Z0lNKcT3IZMsxphkiqDP1lMjqVQ0+9cM 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)(6512007)(40140700001)(6486002)(5660300002)(38100700002)(83380400001)(38070700005)(76116006)(316002)(122000001)(36756003)(71200400001)(508600001)(82960400001)(45080400002)(8676002)(110136005)(2616005)(8936002)(2906002)(66476007)(66446008)(66556008)(33656002)(66946007)(107886003)(966005)(64756008)(4326008)(53546011)(6506007)(186003)(86362001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Y3VuVitrWHZ1NzlZNFdqZFk5ZmxDS3ZEVVQ2RE1QSkcvejRZZUdVRkI3T3Z4?= =?utf-8?B?SXpWdXZLUHhSRU9kdkNFK0ljSjR5em1zN3pkOXdKdmZ2WTh2by9UeGJueHlW?= =?utf-8?B?S0oyNE9zZXlWUTErckVTQVhuTWtTYmQxZlVDS0RJQnBXWkF0VkF2M09DR0N1?= =?utf-8?B?ckx6Z0VrR1NQZXdBcGxuS2NZS01UODRjV2RxT0NFbEdydTQ2V2tBYlU2cHFW?= =?utf-8?B?Kyt1SmtjQS90K0dKYldwRFk2NFN1R2xPUmtNaWdrY2VIOFI3eHVQK010QlZL?= =?utf-8?B?SWtCWG44WFdQcEtjL01jeUNKYVh1WWtkVHZacUFZZjIyVFBaSFVhN3kzUm5Y?= =?utf-8?B?NHovdzcxYkFMVDVBdm0xMUFyL2VaUUNBRXkxdFV2by9BWnhQWVNOQnR4cWdM?= =?utf-8?B?ZUJDVm9LQ1BIbkdTaXdvb3Y1eGIxQXRtRGQ4MFh0cG1WVXVOVjRESnJCQkZz?= =?utf-8?B?am1JZjBSOCt4Wm5XNEVTelc1YnNSMGpHWTV3bGNjaFAyTit4bThoZm9tNWJl?= =?utf-8?B?R253eUdRYlpBMGJ4T2tIQi9oUkUvTkp4RU1KbDl6TEYwVVBoSHRZU2doYjJM?= =?utf-8?B?RVZvV0tIdGxSUjF2RnBwV1lOTmlzN2lDWFZ4Sm5FTms0djgrNmdkcUwxWHRH?= =?utf-8?B?a3B2TXl0V3U2cGhVcEs2dFRIQTNSS1FONnpkNzY5bzFTTUVmU2pteEo4cC9G?= =?utf-8?B?NTZFMmVyajR0WlZUMjdaMlZ6QVplR000bUV6WkpEUWE3d01zeWM4VGQyNGRS?= =?utf-8?B?RkswTTRqSXdGOWo2U2VONTRyblpPa3RHNkkweHkrVnBDUnFwVG5aWTBaYlBK?= =?utf-8?B?VlB4YU5uYUxNWVd6eEdaQWFTNUF2aWxXemJVTlV5YktqM0Ywc2JSMVRkK01P?= =?utf-8?B?N0xoT2ZETzN0RHZjMkU4ZUlUZmVsaHpIYTk2TnRCSDZxcnFjVkVIRnJiOFVP?= =?utf-8?B?MjMxUHh0REVxUk9lbWdGNnZPU1lrV1ZlM3pqNnIwV1ZOc29pWm9tOHBNajl1?= =?utf-8?B?bS9VbjVzUUE5bnp3V09Cd0dFNWdOWDlDWjRSTWZsS0tGYzJGRUVXdVU1ZmJx?= =?utf-8?B?TDBXNzZqc1hjN245SWoxVGJKS1FaOVJlSnFhZnRxY2JXTXNUc3BuU21xU2xE?= =?utf-8?B?b2VIOTB0dzF1OE5XeTdDMnU5TXZzSzdWMGI1NDZnc1FUNDIzQ0NsN2ZkZE9O?= =?utf-8?B?TzFZUlprNHZPKzhBRkt1bkJKMUhxK3hLSndNU3lESUtjQlUvdXNKUUNIM0dr?= =?utf-8?B?TkVGUXc3cnJzamtxem4wWFoybWM3Mk1YSElKU05oZFlZRWtpZk9lRUVHWXRC?= =?utf-8?B?SW5BcExQa0JBVUhDVXNTMnd0MUVKejQzc05IS29jdWpZVlpldDAvMFk1UjhX?= =?utf-8?B?eVVkbWY0M3BpaURmaUxtTjM1VnovM1ZXd21hSjR4QVJsSFU3RzVxQTdqWUZy?= =?utf-8?B?WHM1WkJ4ZlUrcW91QlRKQVBBbUQ0TjdWWjUvcG9CSFpjVDZQQkp6OFYrc0x4?= =?utf-8?B?R3U3NWZUMWdIbUhaWlVqRVhMZGZZWmNMdllaTzFMOG14RTY1V0dDeitZaGYy?= =?utf-8?B?bWFIblZISHpwT0JiSHducERtZWcxSzlnSWdTZURmUk0wVndwRXBKOE1RUGgz?= =?utf-8?B?RlpCWVpKbUhZeHZGVlg4UitnTHNUVkkrK2tRSmVxMXYxZExlSFpJTFh0eHpS?= =?utf-8?B?Z2ZUUXVycHhlUkhyS2syekxKUnJ4aTdGc3ordE1TS3dubEVna3M2UHFiN1Na?= =?utf-8?B?WEpEREJGQ1BtN3M5Zm9hWVVEQ2hxRlQyYkNvcnVVMlRpR1d4UVBCczBZZlhi?= =?utf-8?B?RWxaVUdmZDBhM1FpRUVjZz09?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54a4d360-57df-464a-3d55-08d9900d5e4c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 18:55:33.9181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7313 Archived-At: Subject: [Sidrops] BGPsec suports AS Ranges? - Re: ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 18:55:42 -0000 SGkgQ2xhdWRpbywNCg0KSSBjaGFuZ2VkIHRoZSBTdWJqZWN0IHRvIG5vdCBoaWphY2sgdGhlIG1h aW4gZGlzY3Vzc2lvbiBzdGFydGVkIGJ5IFRpbS4NCg0KWW91IGJyb3VnaHQgdXAgQkdQc2VjIGFu ZCBtYWRlIGFuIGludGVyZXN0aW5nIHN0YXRlbWVudDogDQoNCiAgIiBCR1BzZWMgaGFzIHRoZSBz YW1lIGlzc3VlIG9mIHN1cHBvcnRpbmcgQVMNCiAgICByYW5nZXMgZm9yIG5vIHZhbGlkIHJlYXNv bi4gSXQgb25seSBhZGRzIGFuIGF0dGFjayB2ZWN0b3IgdG8gdGhlDQogICAgcHJvdG9jb2wuICIN Cg0KYW5kIEkgd2FzIHdvbmRlcmluZyBpZiB5b3UgY291bGQgcG9pbnQgbWUgdG8gd2hlcmUgaW4g UkZDODIwNSBvciBlbHNld2hlcmUgaXQgaXMgd3JpdHRlbiBvciBpbXBsaWVkIHRoYXQgQkdQc2Vj IHN1cHBvcnRzIHRoZSB1c2FnZSBvZiBBUyBSYW5nZXMuIE1vcmUgb3ZlciBhcyB5b3Ugc2FpZCBm b3Igbm8gdmFsaWQgcmVhc29uLiANCg0KSXQncyBzb21lIHRpbWUgdGhhdCBJIHdvcmtlZCBsYXN0 IG9uIEJHUHNlYyBpdHNlbGYgYW5kIEkgY2Fubm90IHJlY2FsbCB0aGlzIG5vciBkaWQgbXkgcXVp Y2sgc2NhbiBvdmVyIHRoZSBkb2N1bWVudHMgc2hvdyBtZSB3aGVyZSB0aGlzIGlzIG1lbnRpb25l ZC9pbXBsaWVkID8gDQoNCkp1c3Qgb3V0IG9mIGN1cmlvc2l0eS4NCg0KT2xpdmVyDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hl cnQsIENvbXB1dGVyIFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBh bmQgVGVjaG5vbG9neQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAu NjY4LjQxMTcNCg0KDQpPbiAxMC8xMy8yMSwgNTo1NiBBTSwgIlNpZHJvcHMgb24gYmVoYWxmIG9m IENsYXVkaW8gSmVrZXIiIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNq ZWtlckBkaWVoYXJkLm4tci1nLmNvbT4gd3JvdGU6DQoNCiAgICBPbiBXZWQsIE9jdCAxMywgMjAy MSBhdCAxMDozNjoyN0FNICswMTAwLCBOaWNrIEhpbGxpYXJkIHdyb3RlOg0KICAgID4gSm9iIFNu aWpkZXJzIHdyb3RlIG9uIDEzLzEwLzIwMjEgMTA6MDg6DQogICAgPiA+IEhhcyBhbnlvbmUgZXZl ciBzYWlkICJJIGJ1eSB0cmFuc2l0IGZyb20gQVMgMSB1cHRvIGluY2x1ZGluZyAxMDAwIj8NCiAg ICA+IA0KICAgID4gTW9yZSB0byB0aGUgcG9pbnQsIHdoYXQgd291bGQgaGFwcGVuIGlmIHNvbWVv bmUgY3JlYXRlZCBhbiBvYmplY3Qgd2hpY2gNCiAgICA+IHN0YXRlZCB0aGF0IHRoZXkgYm91Z2h0 IHRyYW5zaXQgZnJvbSBBUzEgdXAgdG8gQVM0Mjk0OTY3Mjk0Pw0KDQogICAgU2luY2UgdGhpcyBp cyBhIG5vbnNlbnNpY2FsIHJlcXVlc3QgdGhlIEFTUEEgZHJhZnQgbmVlZHMgdG8gYmUgIGFkanVz dGVkDQogICAgYW5kIGp1c3QgcGxhaW4gbm90IGFsbG93IGl0LiBQbGVhc2Ugc3RvcCBhZGRpbmcg ZmVhdHVyZXMgdGhhdCBhcmUgY29tcGxleA0KICAgIHRvIGltcGxlbWVudCBhbmQgbm90IG5lZWRl ZC4gQkdQc2VjIGhhcyB0aGUgc2FtZSBpc3N1ZSBvZiBzdXBwb3J0aW5nIEFTDQogICAgcmFuZ2Vz IGZvciBubyB2YWxpZCByZWFzb24uIEl0IG9ubHkgYWRkcyBhbiBhdHRhY2sgdmVjdG9yIHRvIHRo ZQ0KICAgIHByb3RvY29sLg0KDQogICAgLS0gDQogICAgOndxIENsYXVkaW8NCg0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgU2lkcm9wcyBt YWlsaW5nIGxpc3QNCiAgICBTaWRyb3BzQGlldGYub3JnDQogICAgaHR0cHM6Ly9nY2MwMi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9wcyZhbXA7ZGF0YT0wNCU3QzAxJTdDb2xp dmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M3NjAxYjdiOGFkZDY0ODIyNmEyOTA4ZDk4ZTJmYmY0 OSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc2OTcxNTgw MTc4MDQzMjElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2Rh dGE9UHIlMkJoWXhTS0VQVlpNSzl4UkhYdHp0ODJ0VFJ6M3pBRFBmTzBWMDhBaEVnJTNEJmFtcDty ZXNlcnZlZD0wDQoNCg0K From nobody Fri Oct 15 12:09:54 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6449F3A09DD for ; Fri, 15 Oct 2021 12:09:51 -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, 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 5D7nxULd6E5u for ; Fri, 15 Oct 2021 12:09:47 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 5BAE13A09D6 for ; Fri, 15 Oct 2021 12:09:47 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id r134so8851023iod.11 for ; Fri, 15 Oct 2021 12:09:47 -0700 (PDT) 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=cwuOUqlTh2Z0BCfv7rJsOU4imBMX0ADyHV+S8Tpe4HM=; b=JmiX1LTfXdAmn0TyrMuPmjbvXfaPZLtpH8ixHqRVUpxSAZ/R8eRpotk4m41kLXsyyp IkVqHvm749Xq+hz6fQwM1HqWVFp8yHw7TfeXymuERbbyICXaIylBnOefdf0s5dcgf5FC w3D1FMSmIPYsMr8ieQe3u/bhnOcV+jh20Mg0I= 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=cwuOUqlTh2Z0BCfv7rJsOU4imBMX0ADyHV+S8Tpe4HM=; b=wRRuEgIqvA1PtmHGm352ASWzf2isIE0z7ATVZ74q5VP7o66/AZxZ65oxLTSyPr4UtD mrXg8w+z5w5lZxL90F0RAWB66aTtHYShkxX/IrSKRRqr/rljwOo5T8Wz4B1QKrmiJOJV PM4hAyvsFxIMc6IizFdPv+QZbABHmWDiCLb4kESd59PSiri9C6KLBx00tBXRkiE0p9uz gbAxmvQzOao2pxUiwNyVJLa/UGHdRhX3S7UDdq+er7iAc7CFqyzkDKdNGtnuAiXFV/fO kFlG/cmT6aGsg29nbir2qz4+fAUEYbxbiNmnVK90l3oCc7EkPiHW+VfBG6Lc8HY3cNVe HqrQ== X-Gm-Message-State: AOAM530Y+fqJyGtzablY3UB6zAJQvlzGjjpRVvs7q/sOhaHdpkgQ6oe3 XlKC7/FrahmtmUDA9cjgzGYtjWSIEgJCOpg3uxf9FA== X-Google-Smtp-Source: ABdhPJzAMxQuKKDtZVT9SexfW5nnegNrcdCWep9RpGvoEemRMubh5WuX/5yS1VwKP3t5FjhspQn3zGol3GqNmtvv1sw= X-Received: by 2002:a05:6602:2d4d:: with SMTP id d13mr5020888iow.53.1634324984902; Fri, 15 Oct 2021 12:09:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Job Snijders Date: Fri, 15 Oct 2021 21:09:33 +0200 Message-ID: To: "Borchert, Oliver (Fed)" Cc: "Borchert, Oliver (Fed)" , Claudio Jeker , "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002c54c505ce68f0d1" Archived-At: Subject: Re: [Sidrops] BGPsec suports AS Ranges? - Re: ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 19:09:51 -0000 --0000000000002c54c505ce68f0d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oliver, Out of the three rfc3779 options (asid, range, or inherit), only =E2=80=9Ci= nherit=E2=80=9D was disallowed via https://datatracker.ietf.org/doc/html/rfc8209#section-3.1.3.5 So I ended up with a switch statement like here: https://github.com/openbsd/src/blob/08f6ba1906d01c4a24fa700d568400f71bcf961= 1/usr.sbin/rpki-client/cert.c#L1429-L1441 Kind regards, Job On Fri, 15 Oct 2021 at 20:55, Borchert, Oliver (Fed) wrote: > Hi Claudio, > > I changed the Subject to not hijack the main discussion started by Tim. > > You brought up BGPsec and made an interesting statement: > > " BGPsec has the same issue of supporting AS > ranges for no valid reason. It only adds an attack vector to the > protocol. " > > and I was wondering if you could point me to where in RFC8205 or elsewher= e > it is written or implied that BGPsec supports the usage of AS Ranges. Mor= e > over as you said for no valid reason. > > It's some time that I worked last on BGPsec itself and I cannot recall > this nor did my quick scan over the documents show me where this is > mentioned/implied ? > > Just out of curiosity. > > Oliver > > ----------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Office) +1.301.975.4856 > (GVoice) +1.240.668.4117 > > > On 10/13/21, 5:56 AM, "Sidrops on behalf of Claudio Jeker" < > sidrops-bounces@ietf.org on behalf of cjeker@diehard.n-r-g.com> wrote: > > On Wed, Oct 13, 2021 at 10:36:27AM +0100, Nick Hilliard wrote: > > Job Snijders wrote on 13/10/2021 10:08: > > > Has anyone ever said "I buy transit from AS 1 upto including 1000= "? > > > > More to the point, what would happen if someone created an object > which > > stated that they bought transit from AS1 up to AS4294967294? > > Since this is a nonsensical request the ASPA draft needs to be > adjusted > and just plain not allow it. Please stop adding features that are > complex > to implement and not needed. BGPsec has the same issue of supporting = AS > ranges for no valid reason. It only adds an attack vector to the > protocol. > > -- > :wq Claudio > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fsidrops&data=3D04%7C01%7Coliver.borchert= %40nist.gov%7C7601b7b8add648226a2908d98e2fbf49%7C2ab5d82fd8fa4797a93e054655= c61dec%7C1%7C0%7C637697158017804321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA= wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DPr%2= BhYxSKEPVZMK9xRHXtzt82tTRz3zADPfO0V08AhEg%3D&reserved=3D0 > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000002c54c505ce68f0d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Oliver,

Out of the three rfc3779 options (asid, range, or inherit), only =E2= =80=9Cinherit=E2=80=9D was disallowed via


<= div dir=3D"auto">Kind regards,

Job

On Fri, 15 Oct 2021 at 20:55, Borchert, Oliver (Fed) &= lt;oliver.borchert=3D40nist.go= v@dmarc.ietf.org> wrote:
Hi Claudio,

I changed the Subject to not hijack the main discussion started by Tim.

You brought up BGPsec and made an interesting statement:

=C2=A0 " BGPsec has the same issue of supporting AS
=C2=A0 =C2=A0 ranges for no valid reason. It only adds an attack vector to = the
=C2=A0 =C2=A0 protocol. "

and I was wondering if you could point me to where in RFC8205 or elsewhere = it is written or implied that BGPsec supports the usage of AS Ranges. More = over as you said for no valid reason.

It's some time that I worked last on BGPsec itself and I cannot recall = this nor did my quick scan over the documents show me where this is mention= ed/implied ?

Just out of curiosity.

Oliver

-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117


On 10/13/21, 5:56 AM, "Sidrops on behalf of Claudio Jeker" <sidrops-bounces= @ietf.org on behalf of cjeker@diehard.n-r-g.com> wrote:

=C2=A0 =C2=A0 On Wed, Oct 13, 2021 at 10:36:27AM +0100, Nick Hilliard wrote= :
=C2=A0 =C2=A0 > Job Snijders wrote on 13/10/2021 10:08:
=C2=A0 =C2=A0 > > Has anyone ever said "I buy transit from AS 1 = upto including 1000"?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > More to the point, what would happen if someone created = an object which
=C2=A0 =C2=A0 > stated that they bought transit from AS1 up to AS4294967= 294?

=C2=A0 =C2=A0 Since this is a nonsensical request the ASPA draft needs to b= e=C2=A0 adjusted
=C2=A0 =C2=A0 and just plain not allow it. Please stop adding features that= are complex
=C2=A0 =C2=A0 to implement and not needed. BGPsec has the same issue of sup= porting AS
=C2=A0 =C2=A0 ranges for no valid reason. It only adds an attack vector to = the
=C2=A0 =C2=A0 protocol.

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 :wq Claudio

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Sidrops mailing list
=C2=A0 =C2=A0 Sidrops= @ietf.org
=C2=A0 =C2=A0 https://gcc02.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailma= n%2Flistinfo%2Fsidrops&amp;data=3D04%7C01%7Coliver.borchert%40nist.gov%= 7C7601b7b8add648226a2908d98e2fbf49%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7= C0%7C637697158017804321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DPr%2BhYxSKEP= VZMK9xRHXtzt82tTRz3zADPfO0V08AhEg%3D&amp;reserved=3D0


_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000002c54c505ce68f0d1-- From nobody Fri Oct 15 15:39:25 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0699B3A0DC7; Fri, 15 Oct 2021 15:33:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433723700.17026.3840080010642808280@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:33:57 -0700 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 112 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:33:57 -0000 Dear Nathalie Trenaman, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (2:00 requested) Monday, 8 November 2021, Session I 1200-1400 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 70 Conflicts to Avoid: People who must be present: Chris Morrow Keyur Patel Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 18 02:07:20 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311453A0A3E for ; Mon, 18 Oct 2021 02:07:17 -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 8VI0hDm2tE8j for ; Mon, 18 Oct 2021 02:07:11 -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 0ACBF3A0A41 for ; Mon, 18 Oct 2021 02:07:10 -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 5C670224; Mon, 18 Oct 2021 09:07:06 +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=1634548025; bh=uVaI69u1yN4MXqhW66GE9KVxvfVYAb86HtOLE/V2Ob8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RhUoQsuoOHfEFVCgLsN1zuSTY3PfEGgBcDOSXyUPkdvE3qzGqQW7BvLLQnpApkHld dt5fADceCXCyUNGRTA7nMBqYC8AUG4ixIdX60mDly7AeYHiCMXMMG23NWK2GskMbF4 BUIdGIdypQRqZvwyZV6HK+TXEHAKd+afF9j2sayZLtCyZHf6ggyq5OghedzaQyCftY Cu0ALvXGPIDf2NLTQuUp5lpbCMiXtUs4q/cEfww0NcaTGEknz8Uz6Y3G7KsYr09qkC /ziaDqUv7q8CzBBmmaCSGwgZ81jX3mK+uYu5DLeff+tQKnZftn9Vs5iU5FSeN/HuiX cjuHksjpMfGKA== 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 In-Reply-To: <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> Date: Mon, 18 Oct 2021 11:07:02 +0200 Cc: Claudio Jeker , SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <0825BA24-AC44-4EF0-A9A7-DDEE0EC9DABA@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 09:07:18 -0000 Hi, There was a small bug in my proposed structure. We will need a sequence in the 'ProviderAs' definition, like so: providerAS ::= SEQUENCE { providerASID ::= ASID, afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL } Note that this means that the efficiency in terms of encoding is lowered a bit. In typical cases where users would specify a list of providers without any limitation with regards to AFI, we will get a sequence of sequence of asid. This imposes a slight overhead. But, to me this is not problematic. I think it's a small price to pay for having the simple concept of having a single list of providers, where any provider may be restricted if desired. These concepts tend to leak into the API and UI so I would optimize for understandability rather than byte level encoding efficiency. What I would want to add though is that each provider ASID MUST NOT occur more than once and that the providers MUST be sorted (low to high). Having them sorted makes it much easier for parsers to verify that each ASID occurs only once. Please let me know what you think. I am working on prototype code to support this model. I can share an example object if desired. Tim > On 14 Oct 2021, at 14:00, Tim Bruijnzeels wrote: > > > >> On 13 Oct 2021, at 15:58, Tim Bruijnzeels wrote: >> >> >> >>> On 13 Oct 2021, at 15:49, Job Snijders wrote: >>> >>> On Wed, Oct 13, 2021 at 03:41:45PM +0200, Job Snijders wrote: >>>>> then you could also have: >>>>> >>>>> ct-ASPA CONTENT-TYPE ::= >>>>> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>>>> >>>>> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >>>>> >>>>> ASProviderAttestation ::= SEQUENCE { >>>>> version [0] ASPAVersion DEFAULT v0, >>>>> customerASID ASId, >>>>> providersV4 ProviderASSet, >>>>> providersV6 ProviderASSet, >>>>> } >>>>> >>>>> ASPAVersion ::= INTEGER { v0(0) } >>>>> >>>>> providerASSET SEQUENCE (SIZE(1..N)) OF ASID } >>>>> >>>>> ASID ::= INTEGER >>>> >>>> Is the above ASN.1 complete? >>> >>> Ah, you replaced an 'afi' field with 'providersV4' and 'providersV6'. >>> That indeed introduces a fair bit of duplication. >>> >>> How about an optional 'afi' field per provider AS? >>> >>> If the field is absent, the Relying Party will apply the information to >>> both IPv4 and IPv6. If the 'afi' field is present, the value of the >>> field specifies the only AFI for which the provider is providing to >>> customerASID. >> >> Works for me as well. > > Let me try to write out an updated section 3 capturing this and see if > it works for you and others. Obvisously, feel free to change it, but it > may help to look at text. > > I left the providerASSET max sequence size at MAX. > > As Claudio pointed out we can have a similar discussion on other limits. > > Perhaps it could be an idea to have a separate draft where limits are > specified, which can then also be updated in future. I know that limits > are arbitrary, but without them we will get issues because implementations > and various components in the chain enforce their own, different, limits. > So, on the whole I think it would still be best to specify them. > > > updated text: > > > 3. The ASPA eContent > > The content of an ASPA identifies the Customer AS (CAS) as well as > the Set of Provider ASes (SPAS) that are authorized to further > propagate announcements received from the customer. If customer has > multiple providers they MUST be registered in a single ASPA object. > This rule is important to avoid possible race conditions during > updates. An ASPA is formally defined as: > > > ct-ASPA CONTENT-TYPE ::= > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > ASProviderAttestation ::= SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > customerASID ASID, > providers ProviderASSet, > } > > ASPAVersion ::= INTEGER { v0(0) } > > ASID ::= INTEGER > > providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } > > providerAS ::= { > providerASID ::= ASID, > afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL > } > > Note that this content appears as the eContent within the > encapContentInfo as specified in [RFC6488]. > > 3.1. version > > The version number of the ASProviderAttestation MUST be v0. > > 3.2. customerASID > > The customerASID field contains the AS number of the Autonomous > System that authorizes an upstream providers (listed in the > providerASSET) to propagate prefixes in the specified address family > other ASes. > > 3.4. providerASSET > > The providerASSET contains the sequence (set) of providerAS that are > authorized to further propagate announcements from the customer. > > 3.5 providerAS > > The providerAS contains the providerASId which specifies the > AS number of a provider. Optionally it contains an afiLimit > field which specifies an IP address family limit, in which > case the provider is only authorized to propagate announcments > for the specified address familiy. This specification only > supports IPv4 and IPv6. Therefore, afiLimit MUST be either > 0001 or 0002. From nobody Mon Oct 18 07:45:43 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A953A1455 for ; Mon, 18 Oct 2021 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.612, 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 dD4hBr7yh8X3 for ; Mon, 18 Oct 2021 07:45:32 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on20731.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::731]) (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 65FF23A059F for ; Mon, 18 Oct 2021 07:45:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V3EJmV9If+PJanna+z9QIPOk/yPFiMrbAmplK/GTa+3/njbPHTtIct5kx5Zjf6lEqK1FQ85aH03nf6GeKwSmzq1DxLQck4H6JKb5bSeiVCTlFv0LHmxpXvEUAVAlmHYMI6rmyXL7iGFf9zFxjoxols781jKNC6GlnalViyFU/jq5Z21tXAGgoLvzAoaH1f5vZFV+8MbPfDm5o9AFVwEwK/cf8ralyvgE/FKZQJe0YMTeMac0E76CEjMEb/hqFaXny2q3dtUuR5SgaWYLVFKw3ybr042Zb8TM2Vd/39C7aoS0yCV0IUisIuoiLlI28ZZIXq2C1DYKd/WBDUKGbyql9g== 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=XSqRUsF7Wtdi4Zo866KpdOi5lYhaZP0d5nwUuDZiQLg=; b=cGpwyzZLUKDm/Vnmd1U0MuiYgXSc4jQJHGicBIAbQkNDZHpUEN+35GBdrYkyJOPSUY8/0WrJ+PC4z0Wm4HrJauffHJbjm101CQQtd5h9B7BTbhKftfChpwdLzYEDCWLdvgBo+WiLZgQhyZsggRWgqK7KoxPHZmpiJWXLVU23wrmvUqUUCF+B1Qh7i6ywTtDcVyBSENvyhtc0Q/nqz0zhxEaAr6nrvO8LkRZlVYtqzo41/duUhQLvuZCtPiYJ5PLlmycVM5JFsomAlDRQW9Bst5xb0nC0Zkitvf7RG/C4xbpnd8LqaAqWAYrfTh5Ng6rUPQ3QvkxcO0Jg52jGRIkhCw== 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=XSqRUsF7Wtdi4Zo866KpdOi5lYhaZP0d5nwUuDZiQLg=; b=BmhW1ttvZJiLHRtQ3/ZZHoNnil49F6ARN+5hqN3hhU97VomhWm8OxapPlvlPld4Gn7LbbdqYK6s2E/nYGzHAsMZ6+7nvZwjgwH9CRc/MIXnG5HJ9VZOhemBx3YVoeT7BXVmdbCRk5GZZPEc4seW7ahSKZSRry7PTsUCNiJDj+K4= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6484.namprd09.prod.outlook.com (2603:10b6:208:2a1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Mon, 18 Oct 2021 14:45:26 +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.4608.018; Mon, 18 Oct 2021 14:45:26 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders CC: Claudio Jeker , "sidrops@ietf.org" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] BGPsec suports AS Ranges? - Re: ASPA provider ranges in draft-ietf-sidrops-8210bis-03? Thread-Index: AQHXwfhB11+ju7sT70msVcDFnzJErKvYlpQA Date: Mon, 18 Oct 2021 14:45:26 +0000 Message-ID: <347C0D64-849F-4021-AF35-7B165D9F590B@nist.gov> References: In-Reply-To: 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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0fe00c4e-9651-4dde-5839-08d99245ec78 x-ms-traffictypediagnostic: BLAPR09MB6484: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: 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: OW6CHIFQFtyaTst65lF58UTKLW4JSTx4HM+xfIkPFPGA4/JFN4H7xJJirAsgAcYEaEk+b2pDxTK6oEduOaFjLzdK5QeGQy7VTI3ZYgeLQ6iVjF8Lw68VWpcXdEzO1aBXGS4kB6l+/BDEzsxIb54ILRMvMTzJTY25TsOP7sAnp/HPQFLNukei2Lyvkp0m6EMRUlAEoUe0p2sOgi7SnA2Cc5VTCntWcvhG65xlruNZ7eW8YRCS7GBPH2cph8r/4rjmSW255nQWxupjVIFLhq4gTglkaN5a2ckLeEWgMQp/FRrb+RCm38ySa+6CeqKFbquf9txcEvRHJg0nD7propDErXdzk8DzfNpFedGfnIOen3UHJP42LIRcGbd8PezxIIsP7jL5yv0mf8KMbnqIpe1GMj9muU2UOAJvmeGf0dBbhdASGIINuydbOn6OeGCjzWqY5UHUZbLSTVepGVZ4IBixYQCEsMeF8+TfSXqXy/R6kBVnuox+KAXlH0zj5Qvw/Y1vMWWhrjHjQyjCNeOdiIdt0TVym8RPK7CzMOPFDWixY2wl6co5t3lq9Rvbu/UNriOwSI8SVHEUuy94Mj0iYFHUqyW9387iw5+Af5QVxTcH7AUQHF+KhRfJsFGVpqJpdRRFtf34nRZyvUWo2tIOlr7kQSI2NCG28WmUedmJdrtXp2XKyKidHMTCU7yKdUAo6U40SjCHZdkdLQ4rummpLYZndsZA3+VRhJs2rw5FVPERQrdW2BQtBweOmRGTkhN2xMjwR8Z5Ka+vD+dACjxytKE7xi/5WmizpV6RXA79Fm+l4fHRQLUVdfyGL0GtYgFDEhsW 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)(122000001)(8676002)(38100700002)(8936002)(66476007)(40140700001)(5660300002)(186003)(6512007)(71200400001)(6506007)(54906003)(82960400001)(6486002)(4326008)(2906002)(2616005)(45080400002)(83380400001)(166002)(33656002)(966005)(66556008)(76116006)(316002)(64756008)(53546011)(508600001)(66946007)(36756003)(38070700005)(66446008)(86362001)(107886003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SUxieTFFV2loek0wQ3BoRnFyWWttV1M0T1NVSk13SFRtaVBKSUxvK3ZaN0tR?= =?utf-8?B?MnI3YzFmK2c2cCtvMUFiL3NERUhlTzVvdEY3YUMxUFY5SXZKSisrRjM1ZFAx?= =?utf-8?B?dHZNRHpnQjZxVWhsUndOYkpRSkR6QXkwQ2R1Rmk5N1NhOGlkTkthTWFkWFVz?= =?utf-8?B?dmhvaVBuM1Z0Y1U2MjZ2L2UxQUova1NCWW02bkx0QlIxdHA1dVNRNW9OWlkx?= =?utf-8?B?UXpLQ3FIUm9jdHFQbXVrZVcwS3BraHRLQ2IxOFd4eE53aTgxVmQ5aEIxWkxN?= =?utf-8?B?NFhlc3Y0WGxVcmx2b29ma2cwNkwrRFBDOVVHMmtyM096WmFHVGxDWHJidDIy?= =?utf-8?B?WEx0eFkwNThTV1dVa0VlTSthYkxnaENTYlZXRUdyUk5MTk51ZG9NRFp3NzU1?= =?utf-8?B?d0pBOTNkR0xYNkhZbkt6eFlsU1BySjR4a1ZxWjJhRk9DNWVhWU9WS0tLd3ZJ?= =?utf-8?B?QzhjL3VvRTJSeEVucWFUNzN2dGZzeExFdEVDZGsvNVdld0R4ZmhVTHpESlBw?= =?utf-8?B?ZCtHSXVFTmpXeXNtbXhVaGo2ZnVwcWdYUTk0bmF5Y1RlbnI0RHBQVTVGclZV?= =?utf-8?B?cXQzeXl5RVEwS21OSXhabUJqa2V4c2ZOdGY3L00zNEtVeVMxQjBxeVN2ZURE?= =?utf-8?B?ZVlDWG5XbWtZcWg1bVV2aHVRTXNXd2NlZ3FOLzdOekhBalBjcWgzRUp0Tk85?= =?utf-8?B?SVFhL2ZyT21ES1FXVGc5R095RXJOUVgwOVFNbUhlOEo1RnNMOWI5Z1V4Vzk1?= =?utf-8?B?UXVETzBPVmRYZEUwL0FJckxheFBPT2tyZmRwdjhzdlQwejE3UFJ5dmpoWEl5?= =?utf-8?B?NDNLbllZb2tsQ3RkOURzTnp3TGNNMGVqYlRXSGMveDRvbm9jZUVJSFFhck5z?= =?utf-8?B?eUJSY2lPZHdJcHZTUU96U2dGcVVHUVdnOWJRci9QNUFJdCtEbG1wMSs2OWI0?= =?utf-8?B?cUxpSnhOSlpMWWVNd05pZ2dtenJJekNQSGVaWTFXNHhqK2JPbmJFcFZEQVZ6?= =?utf-8?B?WGFOSnlyOWJzSVhMSVZ4SVBxUjhyMVkzZEtCakVLQzhReXpuY3FZaTFWaWRM?= =?utf-8?B?THRVeWtmdkt0dXhFZndvY0NnZjltVkRGQzgwU29TSGFLZ0JPY2xnZGdrN3E0?= =?utf-8?B?aklObC9tbjZvSHFnK0QwWkNRTHJwdEg3TDdDdjBMZ0FBZUpjeFhmeHpLRTZR?= =?utf-8?B?a05tUkdhN0FFeHh6QzJYc0lPcUlTK29SNlVHL21WOGs1eDJXeFdlam1ZSXlk?= =?utf-8?B?YmJDeEI4R1pxLzEweFY5anRiQlZPampST29VRXRlMnJtMStuSGpkaEZKaExw?= =?utf-8?B?ZmRLa2NKdnJHRnFMYnI1TFlLRWdzQStyTnAvOWM3WXJlZWc4U29IdHZjKzB2?= =?utf-8?B?VjNYSkNYWGNxK1BZNVlORUdaWjJnV1U0R1F1MzZuNFdIK1NRcC9TOGhtaWJh?= =?utf-8?B?M2xWL1JpVE5Tb0F1cC9QTVBrd3k1ODVqQ0dxRGplaUpxaGhTYkU5ZlJLSmtD?= =?utf-8?B?am9ybFkxNjl3TlgwY3pPZjN2dFdpYkFUZW5QV1l6b3JSWm5ucXVYbitKR04y?= =?utf-8?B?VzcrcjZOYTBQUXEvYXRNQzkveko4NEhySWU2YjE4VmxJdW4xVmcydHgxQmlB?= =?utf-8?B?VTRpRlEvbWlXb0VTbHIySFlMWGt6WWtycHA1RDNQMUtjbGprTUg2TXY2ZzNu?= =?utf-8?B?TkhiSit6QVpkaEpyU2lNVzl6UGI0a3ZTMHNOQStFVlpEL3g0R2xEeHVUem9G?= =?utf-8?B?TzlrTnduWDZOOHJyc3dycnFGK3Nhcmo3cFlFR3JUL28zL3RLalZkUXBnWFdE?= =?utf-8?B?K2hGTDM0aWN1a0xXZlQvdz09?= Content-Type: multipart/alternative; boundary="_000_347C0D64849F4021AF357B165D9F590Bnistgov_" 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: 0fe00c4e-9651-4dde-5839-08d99245ec78 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2021 14:45:26.6139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6484 Archived-At: Subject: Re: [Sidrops] BGPsec suports AS Ranges? - Re: ASPA provider ranges in draft-ietf-sidrops-8210bis-03? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 14:45:38 -0000 --_000_347C0D64849F4021AF357B165D9F590Bnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9iLA0KVGhhbmtzIGZvciB0aGUgbGluay4NCg0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVy IFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9n eQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcNCg0K DQpGcm9tOiBKb2IgU25pamRlcnMgPGpvYj00MGZhc3RseS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpE YXRlOiBGcmlkYXksIE9jdG9iZXIgMTUsIDIwMjEgYXQgMzoxMCBQTQ0KVG86IE9saXZlciBCb3Jj aGVydCA8b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Pg0KQ2M6IE9saXZlciBCb3JjaGVydCA8b2xp dmVyLmJvcmNoZXJ0QG5pc3QuZ292PiwgQ2xhdWRpbyBKZWtlciA8Y2pla2VyQGRpZWhhcmQubi1y LWcuY29tPiwgInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtTaWRyb3BzXSBCR1BzZWMgc3Vwb3J0cyBBUyBSYW5nZXM/IC0gUmU6IEFTUEEgcHJvdmlk ZXIgcmFuZ2VzIGluIGRyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzLTAzPw0KDQpIaSBPbGl2ZXIs DQoNCk91dCBvZiB0aGUgdGhyZWUgcmZjMzc3OSBvcHRpb25zIChhc2lkLCByYW5nZSwgb3IgaW5o ZXJpdCksIG9ubHkg4oCcaW5oZXJpdOKAnSB3YXMgZGlzYWxsb3dlZCB2aWENCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODIwOSNzZWN0aW9uLTMuMS4zLjU8aHR0cHM6 Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGcmZjODIwOSUyM3NlY3Rpb24t My4xLjMuNSZkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzZkMjQy YjEyZDZmYTRlZDk3ODFhMDhkOTkwMGY2MTk0JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVj NjFkZWMlN0MxJTdDMCU3QzYzNzY5OTIxODAyMDIxNjM1MCU3Q1Vua25vd24lN0NUV0ZwYkdac2Iz ZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENK WFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPTUlMkJVUDhIJTJCRmRkeUJYZFBRVjZqZHVTNGJnNnhS cFNsdHNzNkdPdU05UWZnJTNEJnJlc2VydmVkPTA+DQoNClNvIEkgZW5kZWQgdXAgd2l0aCBhIHN3 aXRjaCBzdGF0ZW1lbnQgbGlrZSBoZXJlOg0KaHR0cHM6Ly9naXRodWIuY29tL29wZW5ic2Qvc3Jj L2Jsb2IvMDhmNmJhMTkwNmQwMWM0YTI0ZmE3MDBkNTY4NDAwZjcxYmNmOTYxMS91c3Iuc2Jpbi9y cGtpLWNsaWVudC9jZXJ0LmMjTDE0MjktTDE0NDENCg0KS2luZCByZWdhcmRzLA0KDQpKb2INCg0K T24gRnJpLCAxNSBPY3QgMjAyMSBhdCAyMDo1NSwgQm9yY2hlcnQsIE9saXZlciAoRmVkKSA8b2xp dmVyLmJvcmNoZXJ0PTQwbmlzdC5nb3ZAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbmlzdC5nb3ZA ZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIENsYXVkaW8sDQoNCkkgY2hhbmdlZCB0aGUgU3Vi amVjdCB0byBub3QgaGlqYWNrIHRoZSBtYWluIGRpc2N1c3Npb24gc3RhcnRlZCBieSBUaW0uDQoN CllvdSBicm91Z2h0IHVwIEJHUHNlYyBhbmQgbWFkZSBhbiBpbnRlcmVzdGluZyBzdGF0ZW1lbnQ6 DQoNCiAgIiBCR1BzZWMgaGFzIHRoZSBzYW1lIGlzc3VlIG9mIHN1cHBvcnRpbmcgQVMNCiAgICBy YW5nZXMgZm9yIG5vIHZhbGlkIHJlYXNvbi4gSXQgb25seSBhZGRzIGFuIGF0dGFjayB2ZWN0b3Ig dG8gdGhlDQogICAgcHJvdG9jb2wuICINCg0KYW5kIEkgd2FzIHdvbmRlcmluZyBpZiB5b3UgY291 bGQgcG9pbnQgbWUgdG8gd2hlcmUgaW4gUkZDODIwNSBvciBlbHNld2hlcmUgaXQgaXMgd3JpdHRl biBvciBpbXBsaWVkIHRoYXQgQkdQc2VjIHN1cHBvcnRzIHRoZSB1c2FnZSBvZiBBUyBSYW5nZXMu IE1vcmUgb3ZlciBhcyB5b3Ugc2FpZCBmb3Igbm8gdmFsaWQgcmVhc29uLg0KDQpJdCdzIHNvbWUg dGltZSB0aGF0IEkgd29ya2VkIGxhc3Qgb24gQkdQc2VjIGl0c2VsZiBhbmQgSSBjYW5ub3QgcmVj YWxsIHRoaXMgbm9yIGRpZCBteSBxdWljayBzY2FuIG92ZXIgdGhlIGRvY3VtZW50cyBzaG93IG1l IHdoZXJlIHRoaXMgaXMgbWVudGlvbmVkL2ltcGxpZWQgPw0KDQpKdXN0IG91dCBvZiBjdXJpb3Np dHkuDQoNCk9saXZlcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3QNCk5hdGlvbmFsIElu c3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCihPZmZpY2UpICsxLjMwMS45NzUu NDg1Ng0KKEdWb2ljZSkgKzEuMjQwLjY2OC40MTE3DQoNCg0KT24gMTAvMTMvMjEsIDU6NTYgQU0s ICJTaWRyb3BzIG9uIGJlaGFsZiBvZiBDbGF1ZGlvIEpla2VyIiA8c2lkcm9wcy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBjamVr ZXJAZGllaGFyZC5uLXItZy5jb208bWFpbHRvOmNqZWtlckBkaWVoYXJkLm4tci1nLmNvbT4+IHdy b3RlOg0KDQogICAgT24gV2VkLCBPY3QgMTMsIDIwMjEgYXQgMTA6MzY6MjdBTSArMDEwMCwgTmlj ayBIaWxsaWFyZCB3cm90ZToNCiAgICA+IEpvYiBTbmlqZGVycyB3cm90ZSBvbiAxMy8xMC8yMDIx IDEwOjA4Og0KICAgID4gPiBIYXMgYW55b25lIGV2ZXIgc2FpZCAiSSBidXkgdHJhbnNpdCBmcm9t IEFTIDEgdXB0byBpbmNsdWRpbmcgMTAwMCI/DQogICAgPg0KICAgID4gTW9yZSB0byB0aGUgcG9p bnQsIHdoYXQgd291bGQgaGFwcGVuIGlmIHNvbWVvbmUgY3JlYXRlZCBhbiBvYmplY3Qgd2hpY2gN CiAgICA+IHN0YXRlZCB0aGF0IHRoZXkgYm91Z2h0IHRyYW5zaXQgZnJvbSBBUzEgdXAgdG8gQVM0 Mjk0OTY3Mjk0Pw0KDQogICAgU2luY2UgdGhpcyBpcyBhIG5vbnNlbnNpY2FsIHJlcXVlc3QgdGhl IEFTUEEgZHJhZnQgbmVlZHMgdG8gYmUgIGFkanVzdGVkDQogICAgYW5kIGp1c3QgcGxhaW4gbm90 IGFsbG93IGl0LiBQbGVhc2Ugc3RvcCBhZGRpbmcgZmVhdHVyZXMgdGhhdCBhcmUgY29tcGxleA0K ICAgIHRvIGltcGxlbWVudCBhbmQgbm90IG5lZWRlZC4gQkdQc2VjIGhhcyB0aGUgc2FtZSBpc3N1 ZSBvZiBzdXBwb3J0aW5nIEFTDQogICAgcmFuZ2VzIGZvciBubyB2YWxpZCByZWFzb24uIEl0IG9u bHkgYWRkcyBhbiBhdHRhY2sgdmVjdG9yIHRvIHRoZQ0KICAgIHByb3RvY29sLg0KDQogICAgLS0N CiAgICA6d3EgQ2xhdWRpbw0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICBTaWRyb3BzIG1haWxpbmcgbGlzdA0KICAgIFNpZHJvcHNAaWV0 Zi5vcmc8bWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmc+DQogICAgaHR0cHM6Ly9nY2MwMi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9wcyZhbXA7ZGF0YT0wNCU3QzAxJTdDb2xpdmVy LmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M3NjAxYjdiOGFkZDY0ODIyNmEyOTA4ZDk4ZTJmYmY0OSU3 QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc2OTcxNTgwMTc4 MDQzMjElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpv aVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9 UHIlMkJoWXhTS0VQVlpNSzl4UkhYdHp0ODJ0VFJ6M3pBRFBmTzBWMDhBaEVnJTNEJmFtcDtyZXNl cnZlZD0wPGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJv cHMmZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M2ZDI0MmIxMmQ2 ZmE0ZWQ5NzgxYTA4ZDk5MDBmNjE5NCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVj JTdDMSU3QzAlN0M2Mzc2OTkyMTgwMjAyMjYyOTUlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMTAwMCZzZGF0YT1wcnY1UjVPVE5SSGZpJTJCM0YyYmkxZ2V2NXI1QmZsVWtXbUdl VkNMZk5kalklM0QmcmVzZXJ2ZWQ9MD4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNpZHJvcHNAaWV0Zi5v cmc8bWFpbHRvOlNpZHJvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpZHJvcHM8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc2lkcm9wcyZkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3 QzZkMjQyYjEyZDZmYTRlZDk3ODFhMDhkOTkwMGY2MTk0JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2Uw NTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzY5OTIxODAyMDIyNjI5NSU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPXBydjVSNU9UTlJIZmklMkIzRjJiaTFnZXY1 cjVCZmxVa1dtR2VWQ0xmTmRqWSUzRCZyZXNlcnZlZD0wPg0K --_000_347C0D64849F4021AF357B165D9F590Bnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: 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 ZmFtaWx5OkNvdXJpZXIiPkpvYiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+VGhhbmtzIGZvciB0aGUg bGluay4gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi Pk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5PbGl2ZXIg Qm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJs YWNrIj5OYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPihPZmZpY2UpICsxLjMwMS45NzUuNDg1NjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Kb2IgU25pamRlcnMg Jmx0O2pvYj00MGZhc3RseS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PkZyaWRheSwgT2N0b2JlciAxNSwgMjAyMSBhdCAzOjEwIFBNPGJyPg0KPGI+VG86IDwvYj5PbGl2 ZXIgQm9yY2hlcnQgJmx0O29saXZlci5ib3JjaGVydEBuaXN0LmdvdiZndDs8YnI+DQo8Yj5DYzog PC9iPk9saXZlciBCb3JjaGVydCAmbHQ7b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Jmd0OywgQ2xh dWRpbyBKZWtlciAmbHQ7Y2pla2VyQGRpZWhhcmQubi1yLWcuY29tJmd0OywgJnF1b3Q7c2lkcm9w c0BpZXRmLm9yZyZxdW90OyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtTaWRyb3BzXSBCR1BzZWMgc3Vwb3J0cyBBUyBSYW5nZXM/IC0gUmU6IEFTUEEg cHJvdmlkZXIgcmFuZ2VzIGluIGRyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzLTAzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBPbGl2ZXIs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T3V0IG9mIHRo ZSB0aHJlZSByZmMzNzc5IG9wdGlvbnMgKGFzaWQsIHJhbmdlLCBvciBpbmhlcml0KSwgb25seSDi gJxpbmhlcml04oCdIHdhcyBkaXNhbGxvd2VkIHZpYTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRw czovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZyZmM4MjA5JTIzc2VjdGlv bi0zLjEuMy41JmFtcDtkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3 QzZkMjQyYjEyZDZmYTRlZDk3ODFhMDhkOTkwMGY2MTk0JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2Uw NTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzY5OTIxODAyMDIxNjM1MCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT01JTJCVVA4SCUyQkZkZHlCWGRQUVY2 amR1UzRiZzZ4UnBTbHRzczZHT3VNOVFmZyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM4MjA5I3NlY3Rpb24tMy4xLjMuNTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TbyBJIGVuZGVkIHVw IHdpdGggYSBzd2l0Y2ggc3RhdGVtZW50IGxpa2UgaGVyZTombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL29wZW5ic2Qvc3JjL2Jsb2IvMDhmNmJhMTkwNmQwMWM0 YTI0ZmE3MDBkNTY4NDAwZjcxYmNmOTYxMS91c3Iuc2Jpbi9ycGtpLWNsaWVudC9jZXJ0LmMjTDE0 MjktTDE0NDEiPmh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuYnNkL3NyYy9ibG9iLzA4ZjZiYTE5MDZk MDFjNGEyNGZhNzAwZDU2ODQwMGY3MWJjZjk2MTEvdXNyLnNiaW4vcnBraS1jbGllbnQvY2VydC5j I0wxNDI5LUwxNDQxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+S2luZCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPkpvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5PbiBGcmksIDE1IE9jdCAyMDIxIGF0IDIwOjU1LCBCb3JjaGVy dCwgT2xpdmVyIChGZWQpICZsdDtvbGl2ZXIuYm9yY2hlcnQ9PGEgaHJlZj0ibWFpbHRvOjQwbmlz dC5nb3ZAZG1hcmMuaWV0Zi5vcmciPjQwbmlzdC5nb3ZAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBDbGF1ZGlvLDxicj4NCjxicj4NCkkg Y2hhbmdlZCB0aGUgU3ViamVjdCB0byBub3QgaGlqYWNrIHRoZSBtYWluIGRpc2N1c3Npb24gc3Rh cnRlZCBieSBUaW0uPGJyPg0KPGJyPg0KWW91IGJyb3VnaHQgdXAgQkdQc2VjIGFuZCBtYWRlIGFu IGludGVyZXN0aW5nIHN0YXRlbWVudDogPGJyPg0KPGJyPg0KJm5ic3A7ICZxdW90OyBCR1BzZWMg aGFzIHRoZSBzYW1lIGlzc3VlIG9mIHN1cHBvcnRpbmcgQVM8YnI+DQombmJzcDsgJm5ic3A7IHJh bmdlcyBmb3Igbm8gdmFsaWQgcmVhc29uLiBJdCBvbmx5IGFkZHMgYW4gYXR0YWNrIHZlY3RvciB0 byB0aGU8YnI+DQombmJzcDsgJm5ic3A7IHByb3RvY29sLiAmcXVvdDs8YnI+DQo8YnI+DQphbmQg SSB3YXMgd29uZGVyaW5nIGlmIHlvdSBjb3VsZCBwb2ludCBtZSB0byB3aGVyZSBpbiBSRkM4MjA1 IG9yIGVsc2V3aGVyZSBpdCBpcyB3cml0dGVuIG9yIGltcGxpZWQgdGhhdCBCR1BzZWMgc3VwcG9y dHMgdGhlIHVzYWdlIG9mIEFTIFJhbmdlcy4gTW9yZSBvdmVyIGFzIHlvdSBzYWlkIGZvciBubyB2 YWxpZCByZWFzb24uDQo8YnI+DQo8YnI+DQpJdCdzIHNvbWUgdGltZSB0aGF0IEkgd29ya2VkIGxh c3Qgb24gQkdQc2VjIGl0c2VsZiBhbmQgSSBjYW5ub3QgcmVjYWxsIHRoaXMgbm9yIGRpZCBteSBx dWljayBzY2FuIG92ZXIgdGhlIGRvY3VtZW50cyBzaG93IG1lIHdoZXJlIHRoaXMgaXMgbWVudGlv bmVkL2ltcGxpZWQgPw0KPGJyPg0KPGJyPg0KSnVzdCBvdXQgb2YgY3VyaW9zaXR5Ljxicj4NCjxi cj4NCk9saXZlcjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3Q8YnI+ DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5PGJyPg0KKE9m ZmljZSkgKzEuMzAxLjk3NS40ODU2PGJyPg0KKEdWb2ljZSkgKzEuMjQwLjY2OC40MTE3PGJyPg0K PGJyPg0KPGJyPg0KT24gMTAvMTMvMjEsIDU6NTYgQU0sICZxdW90O1NpZHJvcHMgb24gYmVoYWxm IG9mIENsYXVkaW8gSmVrZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaWRyb3BzLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmNqZWtlckBkaWVoYXJkLm4tci1nLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNqZWtlckBkaWVoYXJkLm4tci1nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgT24gV2VkLCBPY3QgMTMsIDIwMjEgYXQgMTA6MzY6MjdB TSArMDEwMCwgTmljayBIaWxsaWFyZCB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSm9i IFNuaWpkZXJzIHdyb3RlIG9uIDEzLzEwLzIwMjEgMTA6MDg6PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7ICZndDsgSGFzIGFueW9uZSBldmVyIHNhaWQgJnF1b3Q7SSBidXkgdHJhbnNpdCBmcm9tIEFT IDEgdXB0byBpbmNsdWRpbmcgMTAwMCZxdW90Oz88YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IE1vcmUgdG8gdGhlIHBvaW50LCB3aGF0IHdvdWxkIGhhcHBl biBpZiBzb21lb25lIGNyZWF0ZWQgYW4gb2JqZWN0IHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IHN0YXRlZCB0aGF0IHRoZXkgYm91Z2h0IHRyYW5zaXQgZnJvbSBBUzEgdXAgdG8gQVM0Mjk0 OTY3Mjk0Pzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgU2luY2UgdGhpcyBpcyBhIG5vbnNlbnNp Y2FsIHJlcXVlc3QgdGhlIEFTUEEgZHJhZnQgbmVlZHMgdG8gYmUmbmJzcDsgYWRqdXN0ZWQ8YnI+ DQombmJzcDsgJm5ic3A7IGFuZCBqdXN0IHBsYWluIG5vdCBhbGxvdyBpdC4gUGxlYXNlIHN0b3Ag YWRkaW5nIGZlYXR1cmVzIHRoYXQgYXJlIGNvbXBsZXg8YnI+DQombmJzcDsgJm5ic3A7IHRvIGlt cGxlbWVudCBhbmQgbm90IG5lZWRlZC4gQkdQc2VjIGhhcyB0aGUgc2FtZSBpc3N1ZSBvZiBzdXBw b3J0aW5nIEFTPGJyPg0KJm5ic3A7ICZuYnNwOyByYW5nZXMgZm9yIG5vIHZhbGlkIHJlYXNvbi4g SXQgb25seSBhZGRzIGFuIGF0dGFjayB2ZWN0b3IgdG8gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBw cm90b2NvbC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tIDxicj4NCiZuYnNwOyAmbmJzcDsg OndxIENsYXVkaW88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBTaWRyb3BzIG1h aWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOlNpZHJvcHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5TaWRyb3BzQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc2lkcm9wcyZhbXA7ZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3Yl N0M2ZDI0MmIxMmQ2ZmE0ZWQ5NzgxYTA4ZDk5MDBmNjE5NCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNl MDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc2OTkyMTgwMjAyMjYyOTUlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9cHJ2NVI1T1ROUkhmaSUyQjNGMmJp MWdldjVyNUJmbFVrV21HZVZDTGZOZGpZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzaWRyb3Bz JmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0M3NjAx YjdiOGFkZDY0ODIyNmEyOTA4ZDk4ZTJmYmY0OSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzAlN0M2Mzc2OTcxNTgwMTc4MDQzMjElN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRhPVByJTJCaFl4U0tFUFZaTUs5eFJIWHR6 dDgydFRSejN6QURQZk8wVjA4QWhFZyUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpTaWRyb3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTaWRyb3BzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U2lkcm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzaWRyb3BzJmFt cDtkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3QzZkMjQyYjEyZDZm YTRlZDk3ODFhMDhkOTkwMGY2MTk0JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMl N0MxJTdDMCU3QzYzNzY5OTIxODAyMDIyNjI5NSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1wcnY1UjVPVE5SSGZpJTJCM0YyYmkxZ2V2NXI1QmZsVWtX bUdlVkNMZk5kalklM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHM8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_347C0D64849F4021AF357B165D9F590Bnistgov_-- From nobody Thu Oct 21 01:40:12 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75BF3A1221 for ; Thu, 21 Oct 2021 01:40:08 -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 UzCnoCAYv5fA for ; Thu, 21 Oct 2021 01:40:02 -0700 (PDT) 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 B21383A121C for ; Thu, 21 Oct 2021 01:40:02 -0700 (PDT) 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=VPKzzwdhOfp8B958npga3Qug7tiwB+GOm/9xnhGgBKg=; b=qibYQTJWsvoeilhfU9DYfZHj gFmyvK2jM83ImeRM+wc21rCFtNFh5s9Mpfk2SK84vJYMjRxlDeMwc1Z60q77RZSJaqBYhbVCznjJO f96q4srNY+sLHLWGb7IQ/MVgJsCbwsMb9/nqF+TZ1tg2+0OVEs/yTICfzSOg9VFPhEhWNzC5mDFRZ rRtbhBbeeGN8j7zcHdThYz24QIU7KBo+Zh2pMCkasRpHp1K1NHdDc49PG/Pty5j0K8CUPGufYRuY8 nAUZF70uWPLC31bHHSSyATkrCOfOnLjQfNGfwkZRQAKmVBQ15wbRaRmufCb35XF1D/rZclnBZ7uKZ v7isk+auog==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:49602) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdTcD-0009in-LP for sidrops@ietf.org; Thu, 21 Oct 2021 10:39:57 +0200 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 ) id 1mdTcD-0003yE-IM for sidrops@ietf.org; Thu, 21 Oct 2021 10:39:57 +0200 From: Nathalie Trenaman 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\)) Message-Id: <27FC93B9-0AE7-4021-A4F8-948CF8B76C70@ripe.net> Date: Thu, 21 Oct 2021 10:39:57 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92ac6c01dde178b796a4ed5b68e58edc742 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 08:40:09 -0000 Hi all, 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 Regards, Chris, Keyur and Nathalie= From nobody Fri Oct 22 01:53:50 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2B3A09FC; Fri, 22 Oct 2021 01:53:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163489282491.21742.16231692563458154079@ietfa.amsl.com> Date: Fri, 22 Oct 2021 01:53:45 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 08:53:46 -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 : 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-01 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/ From nobody Fri Oct 22 02:03:35 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90C03A0A78 for ; Fri, 22 Oct 2021 02:03: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 USVH-HOFEvg5 for ; Fri, 22 Oct 2021 02:03:27 -0700 (PDT) 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 CC1EF3A0A1E for ; Fri, 22 Oct 2021 02:03:26 -0700 (PDT) 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 AF9FA52 for ; Fri, 22 Oct 2021 09:03:22 +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=1634893402; bh=tqWYzyEv1YU1G/YQaxXuXrGq8rjIVzpREgVd35+QxeY=; h=Subject:From:In-Reply-To:Date:References:To:From; b=TLMMQQ/GXJ15Ly6ZzMEubd3RSz4v5ikRS4qoTNbV9f0qmCoxZPOG6aJvhCiAiX895 p4nfuRfLqj/e9T1GX5TI+uVZ4aDbDziCJXAeQfUFqTiCsaEXWEyufhzCuPt6PaswDz tOQpxslAntbkzN9Iswbujma0KvuA2nqWL28M9wT1M39HMm/t6+aifkUcnQXSn8t8dW 2ysoiGLYmX6NxIuXoFC1fDPMhpDl4TfF+LBYZWc+isPmPcTFl9dknC3YayI83dhFsp mja1pPYaFKgP7gaWlIb8xCQOKqeAwNoSkFuAWhpWVGMX5x7mom2nZSf7kjnpW6QUO+ O0iecMpK4lWYA== 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 In-Reply-To: <163489282491.21742.16231692563458154079@ietfa.amsl.com> Date: Fri, 22 Oct 2021 11:03:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> To: SIDR Operations WG Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 09:03:34 -0000 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: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : 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 >=20 > 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. >=20 > In phase 0, today's deployment, RRDP is supported by most, but not > all Repositories, and most but not all RP software. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-prefer-rrdp/ >=20 > There is also an htmlized version available at: > = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-prefer-rrdp-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sun Oct 24 08:59:05 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EA3A0817 for ; Sun, 24 Oct 2021 08:59:02 -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 (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 ryoFSQkB3Ut7 for ; Sun, 24 Oct 2021 08:58:58 -0700 (PDT) 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 C46CE3A07B1 for ; Sun, 24 Oct 2021 08:58:57 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id l13so11360295edi.8 for ; Sun, 24 Oct 2021 08:58:57 -0700 (PDT) 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=QN2SP353Ju9FjP90H4nbRhsca018GAzxVbnkAx/ZQMU=; b=T2c7olgZfhr90GG3yjGw/AxFk1M6wE6/e8wXZiE+5AK1DhF/rM7MzEKDBaHekAQcyg BK5aIflwmQRChcDJJnAkzOmPIK9LcywHOoJcVzg9xrqmEC05xj0iu2QzF1k+iCo1gFvJ R60xbFh9wZbGVWjqm0sw8foVpstbKhZOCxJes= 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=QN2SP353Ju9FjP90H4nbRhsca018GAzxVbnkAx/ZQMU=; b=ls2veSr/Jrbjok6aJA/45OoRFxswaizLD5EjqWMvwkWjmpS8RLFDC3A9q+XLgWwFPN 9pXQNMlUbcygKWUtqXOY2mMjPXLGSCDpYVFOt3Gu0g3HDh1oHMN3D5+6NDj0i3vWezSU Sru/5/vMyIqvApSfd9I+jjSq9SOmWChDUb1o66s4dIy5R+j5TDjemQ06iYv8zN8JHF5j VEKZV5uzReENsUDYomVLBOP1yAUPeNDAsImxFQrRzilP1KGz1f2NbwFYdZIInVrqry5c JseglLwe2w3lYsB1XTpbovqWJfQGp5AgfgpDSGK9qxoAGqGGOEG8AyXlGZKcu/si8Sg4 TvQA== X-Gm-Message-State: AOAM530kfeP22Coh0YxoQhqDU6TS1zm+DIWE0gJ3pUyyjisM0EEs5C9J +9ylQ15ioh0f/kwZCFBbaFB9vg== X-Google-Smtp-Source: ABdhPJzykvvrThIb28wabYo2KAs/Wu+K5i9BbnJeAf07k4tXuALZjm8uRTQVw75eF7bh7SIkJ3hCXQ== X-Received: by 2002:a17:907:a413:: with SMTP id sg19mr15975434ejc.241.1635091134942; Sun, 24 Oct 2021 08:58:54 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id cb17sm7370edb.11.2021.10.24.08.58.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Oct 2021 08:58:54 -0700 (PDT) Date: Sun, 24 Oct 2021 17:58:52 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 15:59:02 -0000 Dear all, On Fri, Oct 22, 2021 at 11:03:20AM +0200, Tim Bruijnzeels wrote: > 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 Before applauding and promoting RRDP and slapping ourselves on the back... shouldn't we first attempt to resolve some flaws in the RRDP protocol? I know some of us are aware how trivial it is to use RRDP to cause RPs to have a very bad day. In retrospect it seems "Fear, Uncertainty, and Doubt" about rsync was an integral part of pushing the RRDP agenda. This has led to the unfortunate situation where some of us may have gotten blindsided by the new issues introduced by RRDP. Let's debunk some of the myths I've seen floating around: Lack of implementations? Seems there are multiple choices: https://rsync.samba.org/ (C), https://www.openrsync.org/ (privsep C), https://acrosync.com/ (C++). Security? ... I believe the modern day RRDP implementations may have received less scrutiny and review than good ole' rsync. Having found vulnerabilities in some RRDP implementations myself, I'm going to chalk the 'security' argument up as a red herring. Speed? In practise I oftentimes see RSYNC outperform RRDP. It should not come as a surprise that unmarshalling XML-wrapped Base64 encoded blobs and multiple HTTP roundtrips cost something somewhere. Consistency? Similar to how data inconsistencies can be observed on poorly managed rsync servers, it is possible (and has happened in practise) to mess up the RRDP streams too. RRDP as a protocol does very little to help detect/overcome inconsistencies. Debugability? Arguably direct immediate access via the rsync:// URIs to specific individual object beats having to download a snapshot or finding the right delta to get to the Signed Object of interest. DoS? Comparing an anycasted HTTPS service to an unicasted RSYNC service is comparing apples and oranges. If folks truly were concerned about this, surely they can anycast the rsync service too? Performance? It come to light that the world's largest repositories were served from terribly slow (wrong) backends, another issue at some point in time was lack of simple directory sharding in some repositories. It would be foolish to blame the protocol instead of the operator who simply misconfigure the service. Both RRDP and RSYNC appear to bring unique problems and features to the table. It seems to me that the best path forward is to encourage everyone to run both rsync and rrdp. Eroding support for rsync, or suggesting RRDP is an adequate replacement might harm the ecosystem. Mono cultures have strong failure modes. Until a THIRD fetching mechanism is defined (RRDP v2, or a flooding protocol like BGP?), I believe we need both RSYNC and RRDP. We should actively encourage operators to deploy both protocols. Kind regards, Job From nobody Sun Oct 24 10:24:32 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680153A003C for ; Sun, 24 Oct 2021 10:24:31 -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 TFNvQJUjYsR4 for ; Sun, 24 Oct 2021 10:24:26 -0700 (PDT) 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 BB95F3A0774 for ; Sun, 24 Oct 2021 10:24:25 -0700 (PDT) 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 BABE88B8; Sun, 24 Oct 2021 17:24:20 +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=1635096260; bh=ArVrDCfWuxls5yaAEvIn+DC/z4rAEHhgdzbrZ/TzgnA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Y7AlcaqeiW6axAysZhnLwbt10avy4XEqyPY1LbJhEy3V2l+kXSqrz3WXhSR0tSmUR 3KTEgHw4vzfPSPJXm251hUjgr86E0TXo63yToceOm0Pv4UsqmojME+ZZvXclncs0YH lHl+EV33QsIPo8lZoW01TBLxdgqg9oJw1+aTl1qY0tlLc8RPz8aiePidSKdo08KGl9 sK2YYnvyLOS+QbYg4ly6lKx+rYiK/nqc0WP3AXKe7f7Sb4+HGLi8iRjTjPI7pQ+2ac IKjFo8jtxeMJLkCIUO5nU6YNmmPZU7rVk+vfG9WMPjcM3eqb7rug+xr+4CjptNS/oV IVDl2WgA11cuw== 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 In-Reply-To: Date: Sun, 24 Oct 2021 19:24:15 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> To: Job Snijders Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 17:24:31 -0000 > On 24 Oct 2021, at 17:58, Job Snijders wrote: > > Both RRDP and RSYNC appear to bring unique problems and features to the > table. It seems to me that the best path forward is to encourage > everyone to run both rsync and rrdp. Eroding support for rsync, or > suggesting RRDP is an adequate replacement might harm the ecosystem. > > Mono cultures have strong failure modes. Until a THIRD fetching > mechanism is defined (RRDP v2, or a flooding protocol like BGP?), I > believe we need both RSYNC and RRDP. > > We should actively encourage operators to deploy both protocols. Actually.. that is exactly what this document says. Currently RRDP is optional. This document seeks to make it mandatory, and indeed preferred. Earlier versions of this document went further, but this has been removed. W.r.t. flooding using BGP. Geoff Huston has been advocating this idea for some time and I agree that this should be investigated properly. I think it could be a good option to flood the *relevant* data for BGP in the messages themselves. To make this work we would need to do a serious amount of work: e.g. a CA-router protocol so that relevant signed data can easily be added, and perhaps and RTR++ like offloading of received crypto information to validation software.. Still I think this should be the longterm game, because intrinsically having to download all information from repositories, where most information is irrelevant to the actual route, and any CA or repository can send RPs on a wild goose chase is problematic. I don't think it an RRDP v2, 3 or 16 can solve it. Tim From nobody Sun Oct 24 11:01:50 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7883A0863 for ; Sun, 24 Oct 2021 11:01:48 -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 (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 lA8lwU552q8T for ; Sun, 24 Oct 2021 11:01:44 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 8A9743A07CA for ; Sun, 24 Oct 2021 11:01:44 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id r12so312420edt.6 for ; Sun, 24 Oct 2021 11:01:44 -0700 (PDT) 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=00X1clvc+IoukMcVT1HemU2SVX/nv9loWnbKz43vYtc=; b=NZW2gk72al3fHQvMf+51WeNZkhEYHWyp/QXLnLDLI31N+839U4LzNWMtxqSgccf783 TVoNxtiXDrGTjMtBorni5nDYQbtsO5RvbvQsfrGIQFlCbYPrCtCUvUvyXZqNfGuvgziP 8Ph06dLICIN14T4WinnkI2cU3ywbXbT9pwu1Q= 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=00X1clvc+IoukMcVT1HemU2SVX/nv9loWnbKz43vYtc=; b=3VAT6Nz1vWDNms26a+O/0vSAaxjbzKtyJ1xFhtNeZouVRYaFo8AxweZDt+G3glq/Ik s9anb0mz8Ws67QaU0a5sg6wdTy21M57E0ILtKkfABeMdRZIkHOdTLd+WDou1PY+j7DA0 rZVx6j1mWWI/pbpi7HdfkMIOoVB0+pl3IljbogcgQuNE9K7vr2h3NpDE31PuNkSYp7t9 cJyvjO/PBo+pqyygJl8Owb95SWNSszw9aD1DP+g/wOc7xiUn1bBdhO/LJDxp5zCTDRUW 6n8fOfZElK+FyRPsFCIXb9L5hMhEKQ3le4jhUeDIWKv6Exw/TOC5zImDtAKQqOxOjW1y PQkA== X-Gm-Message-State: AOAM532uXm5UQTB5o7LP4e32cqy7Ob7y7deX7PfjyjXQlxknCWxopgbS UVs7N2GhCgg16L4bU6RGngiv9tXB3ON4ag== X-Google-Smtp-Source: ABdhPJzIqeE0NveDYvPP2q03PrzO/6cQvMGIXs+xCuk4DGQNblvNThdycNd5IHtyxWWLMPO551iwEg== X-Received: by 2002:a50:bf08:: with SMTP id f8mr18768875edk.400.1635098501230; Sun, 24 Oct 2021 11:01:41 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id p26sm7498511edu.57.2021.10.24.11.01.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Oct 2021 11:01:40 -0700 (PDT) Date: Sun, 24 Oct 2021 20:01:39 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 18:01:49 -0000 On Sun, Oct 24, 2021 at 07:24:15PM +0200, Tim Bruijnzeels wrote: > > We should actively encourage operators to deploy both protocols. > > Actually.. that is exactly what this document says. Section 2 "Motivation" first goes on to spread FUD about rsync, and then concludes that RRDP isn't perfect either. Eh.... yes, ok? If the authors wish to make RRDP and RSYNC 'more equal', you'll either have to be honest about the problems in RRDP, or the remove text suggesting rsync is not adequate. > Currently RRDP is optional. This document seeks to make it mandatory, > and indeed preferred. Earlier versions of this document went further, > but this has been removed. I don't really see the point of making it mandatory, especially when the benefits of RRDP appear to be somewhat exaggerated. Arguably RSYNC is the simpler of the two protocols, making for a great mandatory lowest common denominator. RRDP being optional, and preferred if available (aka the current situation) seems to strike a good balance. No new draft needed? > W.r.t. flooding using BGP. Geoff Huston has been advocating this idea > for some time and I agree that this should be investigated properly. > I think it could be a good option to flood the *relevant* data for BGP > in the messages themselves. To make this work we would need to do a > serious amount of work: e.g. a CA-router protocol so that relevant > signed data can easily be added, and perhaps and RTR++ like offloading > of received crypto information to validation software.. I'm skeptical about this working group's ability to pull off RPKIoBGP. There are very few (too few?) people who work on *both* BGP and RPKI implementations, *and* also have operational experience with both technologies. Hands-on experience with software development and BGP routers is a key prerequisite for this type of work. > Still I think this should be the longterm game, because intrinsically > having to download all information from repositories, where most information > is irrelevant to the actual route, and any CA or repository can send RPs > on a wild goose chase is problematic. I don't think it an RRDP v2, 3 or 16 > can solve it. Yes, the fundamental flaw is that RRDP/RSYNC both are 'pull' protocols. This means incentives are misaligned: in BGP if you send trash to a peer, the peer will disconnect you, which in turn hurts the bad actor. This is a wonderful property. On the other hand in the RPKI, there barely are any repercussions for CAs when sending bad stuff to RPs. Kind regards, Job From nobody Sun Oct 24 15:46:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617313A07AA for ; Sun, 24 Oct 2021 15:46:16 -0700 (PDT) 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 PPdUbwpNf1LC for ; Sun, 24 Oct 2021 15:46:11 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2043.outbound.protection.outlook.com [40.107.92.43]) (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 127B93A07A1 for ; Sun, 24 Oct 2021 15:46:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=duplhXH+D7N+tzONBNHPOE2PNdOcwgC6galY458VYFR/tG6Tx8z7/Wq+zVVCelO6lT3b2u2EszGMSXmMQldSGgT1z4JzYpdqUbbiPZt34/ZEa61oR4coYsjIzSdmE6qz3oZOLWxwWKpLRvk08YdPI6uXlZ1tc4l4/8gFb/vkYFHEMZo3hnJWtClBUz/RS30r5QjYiYU1jh1o/4HTiA98+TU8GQu4E4UITqedYbpbnYEp0grlnu5+MtDirHVMLy0JgGzyIMRtNENZ4kvTDc+rGjAazBGqefn9nUR+iTruV6NXhr+j9iTUmZm1LqNTReTNq0DDRnYAALcfD/fB1lueTQ== 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=grW77X/LIBhfCJ3WVL+TcNVQKJrl7hLzT+LyHh3ImtY=; b=R0N4VNTlmk+xxhfXiLTulsvqraxpzGxthee0RQojY1WLDZK95UhO+9oy/H5WzMHTvCLQTOzI3XISdua3sAL7hHLqi+WFxmCRfi011/pgZwyWh9pEBGOnaJOM/sbZMePys6AI8gHmv41oXHNaPrwIYVtb+V24j7V/973/b7APsWZ9GjF3+xuDXXQLxIYis8sVUrLYDyO3Oh6bBvgMOACYQ6BRjUtRqwuzpWmyA8mgefEC3Y1HlXgXNZg0F6lVYAfmsacZ1X+878uCelEiNhvc+wff8F+XS+aXjQhh4EpummNjqjysTljBYZJQEkEk2LDQufwVTV4qX6v5P3wfs9pmlg== 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=grW77X/LIBhfCJ3WVL+TcNVQKJrl7hLzT+LyHh3ImtY=; b=cTFyTJ79vK5rm0C9gz2uOHXGIpThZqNyj2xYVZqCT2nn9kKSorui7smQyBUB73hqJAzyHsy9qA6Zdwg5+0wRosqzYf3M5ctXhASAyjud5MnsfngFGoKxKaDh3mzyDTRZP2WET9P4uywvOGzuUl7iYhcJI9LZwKW0CCHRlAL0brU= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by SJ0PR18MB3898.namprd18.prod.outlook.com (2603:10b6:a03:2e8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Sun, 24 Oct 2021 22:46:07 +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.4628.020; Sun, 24 Oct 2021 22:46:07 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Closed -- WGLC for draft-ietf-sidrops-rpki-rov-timing-05.txt - ENDS 10/12/2021 (October 12 2021) Thread-Index: AQHXySjuNVwRJDoDZESY9LAiQeoyJg== Date: Sun, 24 Oct 2021 22:46:07 +0000 Message-ID: <887F0706-F7A8-49EE-8440-B35A99666441@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: c36bead6-526c-4dba-e24d-08d997401154 x-ms-traffictypediagnostic: SJ0PR18MB3898: x-microsoft-antispam-prvs: 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: uypIyr8GEeXBVqUJm1aC8ZY2+sdvg1fXZhlGeVNkeLxhE/GLmRtqjnrZCO9NO5Itg+ZxtWN0KpSIVTWwRWXCEHNP11oehrr998fQnm5Qs46hEn0eCjl2Z9RZ7RZBvLhJUS/5sN+XiwpJ5gkSaT0O4iMIBmfRflA1KpTFFhtEp8UDdcklbye7a/qX5IQUqe30YeUXpiWfoSOtqZCEa/ieFANL+pk/jzuesTw4hNeCNn2zxi0HLlFrlkIdxRjydDdv9CpWY66tcsQSbHkWEx+rgkMFildf/zNRH/QgiChOC4htN6ABb8WNCOQUrnJavAwZr2UrcWsqSstALJS9baKEQuwDhu0YphXURBWRsCOtRAYI6AQN2CME2cwrnpEBtLG/0kW5mT+QIzZ4tCRPYjf7DasZfqM0kDQ6+dGQYUPXB5ZxrQiTM4eiNmpLa/QgmaCQzAp5XtDex8RVIMIFPR5loRg0/nux7jCfsdo3R4K5DolmEVmoxlhRTfPm10j4GnJQOncJwSTuP47J0+Kin+yBsdDFIE9DWCojFUkpYR9KfP/G0kgRPWTmCcgj+hh/5H7iSG8isl3peYByspDXrgwYKG3Ezs8BjnukdQCF42uoLV4CGR4Tc/TPrcl/D4OfdED87XgPLdY/5RUJRtRaCuIl/WPQi54neupLFteIHso7J7dxSgAOJ+ZI+CMd0pE7PhtMh42B7atkU9vxkHMGURIywWAharFTfxZW5hUSe7EWDRx4RP/lYV1i9nu+2MNPLRlx1vXYIlm3GDpPtmPdczL7P4T6BtwkEJFh6N97m9p0RYlkV35WDIGlmTmNl1CFX6Bd 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)(376002)(366004)(136003)(396003)(39830400003)(6506007)(9326002)(4744005)(2616005)(71200400001)(66476007)(8936002)(26005)(2906002)(38070700005)(166002)(508600001)(6486002)(53546011)(66556008)(66446008)(966005)(33656002)(6512007)(76116006)(6916009)(316002)(122000001)(8676002)(5660300002)(186003)(86362001)(64756008)(38100700002)(36756003)(83380400001)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OGNzVko4S2x3cFdXbEZoY1NqeWJmL2orVVpUMy9SZTJ2UEJwL1pRbURsazZx?= =?utf-8?B?SUpLYjlBS2JrZEtqeTNNZ21SQUxBT3dUOUh2V2xtaTFERC9SQU50bXRPYW9L?= =?utf-8?B?SDVSTHMxdTZsdjdQa21xck0zVG1UZE5SRUhzSDgxcEIwWmZqTEtoVzhhTmpo?= =?utf-8?B?bzE0WkdsT1VJQWhRNDNhTHBnODBxMWYzWjNlV0hFRVZCTytkcktWemdVVGMz?= =?utf-8?B?SDUrWHZIOElFN01DQ0NGdEFlcjE2QnlvQzU3dWcvS0NWa0tCMHFDVWNMaUwr?= =?utf-8?B?dzhaVTFlaHM3NUR1VjZiejAweXdVbSsyN3VIZmFVYlk1R2FXWW1xTkh5ZXha?= =?utf-8?B?R2N0RG9EaGF5Q0ltOGJFY25kOGtHanZ5Z29QUFAxMkpZMSt5Wmdid29JZWQy?= =?utf-8?B?MlEwMDdKYmxqSkswMk1ZWjFIQjFrWVdGVlhhaUFjanpjZ1VNdlRMaHFZZkJI?= =?utf-8?B?cXpUSTh4ZDJKclNjc09ab25TOGxFanFnck9Fc0dFTnRuNTNlekxrTXBTbytJ?= =?utf-8?B?dUZXdGtGZmJWOVdLMmZaeDhPOGxLT0I2UVpOamIxaWFaZGF2eVJRU2ZsVHEr?= =?utf-8?B?dVl0SWhQRTY0cTAxRWxUbzBINDRQTXlOWDlxbE8zcUNRSE9CYnE1VXlWb3o5?= =?utf-8?B?MGlweVR0STdpdHI4N3ZEVkVobjBVaEEwUGR6UkUxSkpEd2dSWWsvMmFvRnNQ?= =?utf-8?B?S0NiVGpjdlo3RHBhak1RNVhXSlZXa0cwZFlrZ0V4Ky96bktZbURGUHRzdDdr?= =?utf-8?B?KzIydTFzVzN1bEJmUnd4N0QvMkFTSXNtSU51TmVlczdvYmNYanZVWGNUS09q?= =?utf-8?B?d3BNNnVCOG15OGtLNkpHdnVKeXhNUTFFQUxCUmpLY3R4RkJjbTM5SXFzN2w3?= =?utf-8?B?SjduT0ZDejVwb2ttcngxcy82S3A0ZmV5WE1WbTBVTmFXR1pDdjhSTEIwWkVU?= =?utf-8?B?amtnR3VjQzZJVjdzQzZEMkFEUE9nZVNiUTlETkszNS9oQjE2ekR1MW5VajdI?= =?utf-8?B?K0laTnhTVmZ3OXR6VDF5Sk1MSTBGYU93RVE2NTdPbjRLb1NuclZiZXhIencv?= =?utf-8?B?elVMa1JObTdkUisyM1BXVDhpZFZsazFKalZ4ODh2aHVuWVVkaUZBN3c5Mjgw?= =?utf-8?B?M1d0RHF2K2UzSE5MQkkvYmFVWFZGMmdIbTJLS3NyZUpseHdrNEFDdnl4ZEg2?= =?utf-8?B?RHNnVDhJbzBWTWxoM3RSbkMxWldvbll3L0lzQ0VOd2lvVVNmZGxRQVBtdnlj?= =?utf-8?B?VXNQdXJvbWtnTzFwbDZtMi9kOUlhQkFOblJ5NCtGQ1Z4eU9uUzBBOENWUXdI?= =?utf-8?B?ZWpjNlRhS0hzdVkrdWlUUytqZzMrY1Ryc0J4ZzQ5TTlKMWlXQUgyblhsYUNG?= =?utf-8?B?bEpES2xlbU9NNStrcEtleTYwczFJT2FIMVZXNFZkTmFyaG84dWJaY3c0WUd4?= =?utf-8?B?SXZnZ3lRUTdydTc5SlRrdyt1QlRXaEVFT0tqcExEY1k0UzJXVm1ZSldKSW9i?= =?utf-8?B?cURIcXNwcGNPTy9NRW1CS0JPZ253Y3k1alN2ZHJ1WWFJbkhUUXByYVdQTnR5?= =?utf-8?B?Q3lZNjhra2Y2SGdMQXpSb2dGeFMvK2s3U2tGZ1kxL3dJVEtYU3RpS2hGTndl?= =?utf-8?B?V1JPenpaYml5dXM3dVI5S3pxcE9Qa1lJNUpvanNYYnRhQ2tyc3lxTDJJem4x?= =?utf-8?B?c1FObTdTL1didlhxK2ljNEZ0bEpaYzlveGZZMjN4aHlyZVliRlpMSkk5cmZV?= =?utf-8?B?eFd3dlNHWC8reGZrUXZHTkNkeVVYL2FiQm1zc1BXcFNyMDJwaFQvejZpdkdm?= =?utf-8?B?dTNqc0pvTWg2cHh6bXRVeFNpQ3ZLK0pUWGV1clpMVi9yTWZNQWhUUUNQWkg2?= =?utf-8?B?TlZpcFl4SkFJbzR2SVl5QStHcm96c1ZIamVXTTRNSVZRcmJHYi9HbkZsOVI2?= =?utf-8?B?Z3o4L3Z4M3NCZmg1cWVJSmlhU29IeFM3d1dpV0cwQzBYQUczajBINm9NQ251?= =?utf-8?B?UUVhVmxlckNNanBUR05wK1BubXpST2dvY2hCNnNmMGVib1JBRlhtbXlKOUlT?= =?utf-8?B?RjRyZVF6SElQc0hLeDc3SUQ2TUprS2RxaUJCaEdEcXQrR1RlZ1c2RGdPTUFn?= =?utf-8?B?OENuZkgwTytXOEgzZnFoR1ZzaTliVGtGWnVnYkFMM3VSSWdYZk40bS9reUZp?= =?utf-8?Q?lRuUI2jvCOec4pYTNSDdcKA=3D?= Content-Type: multipart/alternative; boundary="_000_887F0706F7A849EE8440B35A99666441arrcuscom_" 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: c36bead6-526c-4dba-e24d-08d997401154 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2021 22:46:07.2233 (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: 3viKVaep2ulDsGoCyJVVP7U+4r9O7eSiuzfap7rz1j32qtwRIwrpnIjud6fZKwBTzN9tbDhhEN2ceokGRkUTEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB3898 Archived-At: Subject: [Sidrops] Closed -- WGLC for draft-ietf-sidrops-rpki-rov-timing-05.txt - ENDS 10/12/2021 (October 12 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 22:46:16 -0000 --_000_887F0706F7A849EE8440B35A99666441arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgbm93IGNsb3NlZC4g VGhlIHJlc3VsdCBpcyB0byBrZWVwIHRoZSBkcmFmdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQg Zm9yIG5vdyBhcyBtb3JlIHdvcmsgaXMgcmVxdWlyZWQgYmFzZWQgb24gR2VvZmbigJlzIGNvbW1l bnRzLg0KDQpCZXN0IFJlZ2FyZHMsDQpLZXl1cg0KDQpGcm9tOiBLZXl1ciBQYXRlbCA8a2V5dXJA YXJyY3VzLmNvbT4NCkRhdGU6IFN1bmRheSwgU2VwdGVtYmVyIDI2LCAyMDIxIGF0IDE6NDUgUE0N ClRvOiAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBXR0xD IGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1yb3YtdGltaW5nLTA1LnR4dCAtIEVORFMgMTAv MTIvMjAyMSAoT2N0b2JlciAxMiAyMDIxKQ0KDQpIaSBGb2xrczoNCg0KQSB3b3JraW5nIGdyb3Vw IGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtc2lkcm9wcy1ycGtp LXJvdi10aW1pbmctMDUudHh0LCDigJxUaW1pbmcgUGFyYW1ldGVycyBpbiB0aGUgUlBLSSBiYXNl ZCBSb3V0ZSBPcmlnaW4gVmFsaWRhdGlvbiBTdXBwbHkgQ2hhaW7igJ0uIFBsZWFzZSByZXBseSB0 byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIE9jdG9i ZXIgMTIsIDIwMjEuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ktcm92LXRpbWlu Zy4NCg0KQXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdh cmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVn YXJkcywNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQo= --_000_887F0706F7A849EE8440B35A99666441arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <3F180A31BA189D459870E071FCC32D5A@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 MTEuMHB0Ij5UaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIG5vdyBjbG9zZWQuIFRoZSBy ZXN1bHQgaXMgdG8ga2VlcCB0aGUgZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGRyYWZ0IGZvciBu b3cgYXMgbW9yZSB3b3JrIGlzIHJlcXVpcmVkIGJhc2VkIG9uIEdlb2Zm4oCZcyBjb21tZW50cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJlc3QgUmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+S2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgU2VwdGVtYmVyIDI2LCAyMDIxIGF0IDE6NDUgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPldHTEMgZm9yIGRyYWZ0LWlldGYtc2lk cm9wcy1ycGtpLXJvdi10aW1pbmctMDUudHh0IC0gRU5EUyAxMC8xMi8yMDIxIChPY3RvYmVyIDEy IDIwMjEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5IaSBGb2xrczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJl ZW4gcmVxdWVzdGVkIGZvcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5kcmFmdC1pZXRmLXNpZHJvcHMtcnBraS1yb3YtdGltaW5nLTA1LnR4dCwg4oCcVGlt aW5nIFBhcmFtZXRlcnMgaW4gdGhlIFJQS0kgYmFzZWQgUm91dGUgT3JpZ2luIFZhbGlkYXRpb24g U3VwcGx5IENoYWlu4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlDQogbGlzdCB3aXRoIHlvdXIgY29t bWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndp bGwgZW5kIG9uIE9jdG9iZXIgMTIsIDIwMjEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0 OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lkcm9w cy1ycGtpLXJvdi10aW1pbmciPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ktcm92LXRpbWluZzwvYT4uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGlj YXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24n dCBiZWVuIGRpc2Nsb3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pk5hdGhhbGllLCBDaHJpcyAmYW1wOyBLZXl1cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_887F0706F7A849EE8440B35A99666441arrcuscom_-- From nobody Mon Oct 25 01:04:54 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7160C3A09BB for ; Mon, 25 Oct 2021 01:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 6UGc45jxqKbh for ; Mon, 25 Oct 2021 01:04:48 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 7222B3A09BD for ; Mon, 25 Oct 2021 01:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1635149087; x=1666685087; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=tYVogCAKW1iG2iPenh2++wiQoH82mz2jPzTbN9nQE64=; b=oKAJ1sNElQzDVRYNgD81stzo8GlMgSMHYmXvCSMmJsz5JhWDje6wVYJz dOY+boGJR9ODeDLiI0qJ8Tph2hhVPxtMXirIMBmINVt+hV/3x8O0Zjkaa BdfVgAJeUSJEqmbo+ROo/yFVWoatdvvQAE3ziaodxMamqcpLaemGic7DI E=; X-IronPort-AV: E=Sophos;i="5.87,179,1631577600"; d="scan'208";a="150214240" Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-08.txt Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-pdx-2a-6435a935.us-west-2.amazon.com) ([10.43.8.2]) by smtp-border-fw-6002.iad6.amazon.com with ESMTP; 25 Oct 2021 08:04:37 +0000 Received: from EX13D10EUA003.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-pdx-2a-6435a935.us-west-2.amazon.com (Postfix) with ESMTPS id 1CB3542561; Mon, 25 Oct 2021 08:04:36 +0000 (UTC) Received: from EX13D10EUA002.ant.amazon.com (10.43.165.64) by EX13D10EUA003.ant.amazon.com (10.43.165.52) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Mon, 25 Oct 2021 08:04:34 +0000 Received: from EX13D10EUA002.ant.amazon.com ([10.43.165.64]) by EX13D10EUA002.ant.amazon.com ([10.43.165.64]) with mapi id 15.00.1497.024; Mon, 25 Oct 2021 08:04:34 +0000 From: "Korsbaeck, Fredrik" To: Ben Maddison , "sidrops@ietf.org" Thread-Index: AQHXugcABCDceka4IEqmxJ+08INTuavEnhiAgB79RIA= Date: Mon, 25 Oct 2021 08:04:34 +0000 Message-ID: <932F80D4-637C-4309-BE8D-401825987DF4@amazon.com> References: <163345164383.29745.16829346804069846582@ietfa.amsl.com> <20211005165017.rnlnro6wupxfewmd@benm-laptop> In-Reply-To: <20211005165017.rnlnro6wupxfewmd@benm-laptop> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.164.109] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpkimaxlen-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 08:04:52 -0000 SGFwcHkgdG8gc2VlIHRoaXMgb25lIGJlaW5nIGNsb3NlZCBvdXQgaGVyZS4gDQoNClRoaXMgaXMg c3RpbGwgcXVpdGUgYSBjb21tb24gcXVlc3Rpb24gaW4gdGhlIGNvbW11bml0eSBhbmQgcmF0aWZ5 aW5nIHRoaXMgZHJhZnQgd291bGQgbWFrZSBpdCBlYXNpZXIgZm9yIGV2ZXJ5b25lIHRvIHVuZGVy c3RhbmQgd2hhdCB0byBkbyBoZXJlLiANCg0KVGhhbmtzIEJlbiBhbmQgdGVhbSBmb3IgdGhlIGVm Zm9ydCEgDQoNCu+7v09uIDIwMjEtMTAtMDUsIDE4OjUxLCAiU2lkcm9wcyBvbiBiZWhhbGYgb2Yg QmVuIE1hZGRpc29uIiA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiZW5t PTQwd29ya29ubGluZS5hZnJpY2FAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgQ0FVVElP TjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9u LiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IGNhbiBj b25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQoNCiAg ICBIaSBhbGwsDQoNCiAgICBPbiAxMC8wNSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3Rl Og0KICAgID4NCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNJRFIgT3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi4NCiAg ICA+DQogICAgPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFRoZSBVc2Ugb2YgTWF4bGVuZ3Ro IGluIHRoZSBSUEtJDQoNCiAgICBBcyBwcm9taXNlZCBsYXN0IHdlZWssIHRoaXMgdmVyc2lvbiBh ZGRzIGEgc2VjdGlvbiAoNS4yKSBkaXNjdXNzaW5nDQogICAgdGhlIGNvbXBsaWNhdGlvbnMgdGhh dCBtYXkgYXJpc2Ugd2hlbiBhbiBvcGVyYXRvciBhdHRlbXB0cyB0bw0KICAgIGRlLWFnZ3JlZ2F0 ZSBkZWZlbnNpdmVseSBpbiB0aGUgZmFjZSBvZiBhbiBhdHRhY2suDQoNCiAgICBUaGFua3MgYWdh aW4gdG8gQWxleGFuZGVyIGZvciBwb2ludGluZyBvdXQgdGhlIGlzc3VlLg0KDQogICAgV2UgYmVs aWV2ZSB0aGF0IHRoaXMgaXMgbm93IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYW5kIHdvdWxkIGxp a2UgdG8gYXNrDQogICAgZm9yIFdHTEMuDQoNCiAgICBDaGVlcnMsDQoNCiAgICBCZW4NCg0K From nobody Mon Oct 25 05:28:17 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEB33A0A68 for ; Mon, 25 Oct 2021 05:28:14 -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 OhDTfCeWbYDZ for ; Mon, 25 Oct 2021 05:28:10 -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 BBEB03A0A9D for ; Mon, 25 Oct 2021 05:28:09 -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 BE0ADE3; Mon, 25 Oct 2021 12:28:02 +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=1635164881; bh=Flf6ajgp3Dg0ZrZOrj/5usOOcGaO1npWzAVeiuU3Kao=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=wcXeK8BrFs1p/sskCMc1J1gnd0Ppy2GDfqXea1FRzX12ZYyy95SgMAb5ztl8Mjc+n qey0fWDrdpJ44ZgDA9M05LIOHFce3mdz69YGpNt4I1jVfoijs3hWbDSBXUnFEglYIx XUHMjRy8VGFPp2sD3WWyFbWVI5dTnYi0dQ9WExiOe/ehCOh8sZ2ZHmwvgVJYOCeaFp 7dnHU+KtEyg+97BRCT2YV8HZIZOAJRABxbsHPF0/ZFndsbUzcZ+QeGEfbWp4qN/hCd YK/mY2m8VTlzJ4GK7eGGbD7pqwvmxQ1Evrlh6Wh3c/HQnLYY5mshLVpk2zEc5VJvPh 9aPr2IteEwYOQ== Content-Type: multipart/mixed; boundary="Apple-Mail=_6877939A-0EF7-41E7-8896-AC7291734340" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tim Bruijnzeels In-Reply-To: <0825BA24-AC44-4EF0-A9A7-DDEE0EC9DABA@nlnetlabs.nl> Date: Mon, 25 Oct 2021 14:27:59 +0200 Cc: SIDR Operations WG , Claudio Jeker Message-Id: <90186EF6-1FB9-4812-AF79-2D1F2221C188@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <0825BA24-AC44-4EF0-A9A7-DDEE0EC9DABA@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 12:28:15 -0000 --Apple-Mail=_6877939A-0EF7-41E7-8896-AC7291734340 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Job, all, I have running code - in a development branch - that adds basic ASPA support to Krill. See attachment for an example object. However, I have some open questions that I need answered before I can merge this, and deliver on my promise done at the last IETF that I would provide a public testbed. - Do we have an OID now? Sorry, if I missed it. I know one has been requested.. the attached object hijacks the ROA OID - so I could keep coding - but I need a real OID before merging. - Profile? I got no more replies to my suggested profile update. Any thoughts? I am happy to change this of course, but I have to say that I really like the user facing concept of having a single object for all provider ASNs with optional AFI restrictions for each *unique* provider ASN. As long as this concept does not change, I can easily change the underlying encoding. And, yes, if there are reasons to do this all differently after all then those changes could and would be made as well.. Kind regards, Tim --Apple-Mail=_6877939A-0EF7-41E7-8896-AC7291734340 Content-Disposition: attachment; filename=AS65000.asa Content-Type: application/octet-stream; x-unix-mode=0644; name="AS65000.asa" Content-Transfer-Encoding: base64 MIIImwYJKoZIhvcNAQcCoIIIjDCCCIgCAQMxDTALBglghkgBZQMEAgEwNwYLKoZIhvcNAQkQARig KAQmMCQCAwD96DAdMAkCAwD96gQCAAEwCQIDAP3rBAIAAjAFAgMA/e2gggaLMIIGhzCCBW+gAwIB AgIUXjnH+tFiNhxrz6tGqfXdFCbi3AMwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoQzY1NjZE NEJBQUI0RTA0QTg2NzE0QUFDRjBENTFBNEYyNjA4QUQyNjAeFw0yMTEwMjUxMDU3MDFaFw0yMjEw MjQxMTAyMDFaMIICLTGCAikwggIlBgNVBAMTggIcMzA4MjAxMEEwMjgyMDEwMTAwQzcwQjExNDZF QUVCMDc0RkNGRDEzRTNGOUQxOUEzMzRCQzk4RThBRDZBQzIwOEEzRjhDQkIyQzczRTJEQzY3Rjgw MTBGQzQ1NzVCNjFEMEQ4QTE5QzFFRDkyNjc3NDM1RjBGNUNBMkVBNTBGQjMzOEQ5MjQ5RTc4MjQw MTc2MEJFOTNDOTBFOUQ5N0ZEN0Y5QTIwQ0EzNjQ1RjJDNzM3RjZGMEY1OUQwMjE3NDhGQkVFODI5 OTEyM0VFRDVFMjIwNDExQkVDOTcwRUZEM0EzQjlEMjg4MTg1RUVEQ0E4OTIwMUY1MTI1OERFMTEy RjlFMTIyMEFFQTM0NDgwQTMwQTUyMzZGQkNCMUM0M0NEMEIxMzZDMDlBMkI1ODcxNDQyOTgxNjY3 OEJDMjQ4QkJEOTEwRjNGMTFEMzg5NjVGODI2MTAyOTQ1RTNDMTlERDY5RjhGNDZDMkVGREE1MThF RDk3MjU0QkEyQkJFREU1QkM2OTJFOUIxQTgyMEZBNTRDQzY5MDVFNjA5ODYwRjBDREVGRTVEQjRC OTQ3RUVCMjlFNzk2NkM3MkEzMjgwODlGNEM0MkM5OEIxNDI0RUExQzUyODQ0RkVBQkRDQTNBOEZB NDQ1QUI5QzZGRkExODg5NDg1NDlEOTQyM0ZFMjQzRjc3REVCMUY3NzZDOTA0NTkwMjAzMDEwMDAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwsRRurrB0/P0T4/nRmjNLyY6K1qwgij +Muyxz4txn+AEPxFdbYdDYoZwe2SZ3Q18PXKLqUPszjZJJ54JAF2C+k8kOnZf9f5ogyjZF8sc39v D1nQIXSPvugpkSPu1eIgQRvslw79OjudKIGF7tyokgH1EljeES+eEiCuo0SAowpSNvvLHEPNCxNs CaK1hxRCmBZni8JIu9kQ8/EdOJZfgmEClF48Gd1p+PRsLv2lGO2XJUuiu+3lvGkumxqCD6VMxpBe YJhg8M3v5dtLlH7rKeeWbHKjKAifTELJixQk6hxShE/qvco6j6RFq5xv+hiJSFSdlCP+JD933rH3 dskEWQIDAQABo4IBlTCCAZEwHQYDVR0OBBYEFNmMiPiF7/oBb8o0oOlGvz/hXAy/MB8GA1UdIwQY MBaAFMZWbUuqtOBKhnFKrPDVGk8mCK0mMA4GA1UdDwEB/wQEAwIHgDBZBgNVHR8EUjBQME6gTKBK hkhyc3luYzovL2xvY2FsaG9zdC9yZXBvL2NhLzEvQzY1NjZENEJBQUI0RTA0QTg2NzE0QUFDRjBE NTFBNEYyNjA4QUQyNi5jcmwwaQYIKwYBBQUHAQEEXTBbMFkGCCsGAQUFBzAChk1yc3luYzovL2xv Y2FsaG9zdC9yZXBvL3Rlc3RiZWQvMC9DNjU2NkQ0QkFBQjRFMDRBODY3MTRBQUNGMEQ1MUE0RjI2 MDhBRDI2LmNlcjBDBggrBgEFBQcBCwQ3MDUwMwYIKwYBBQUHMAuGJ3JzeW5jOi8vbG9jYWxob3N0 L3JlcG8vY2EvMS9BUzY1MDAwLmFzYTAYBgNVHSABAf8EDjAMMAoGCCsGAQUFBw4CMBoGCCsGAQUF BwEIAQH/BAswCaAHMAUCAwD96DANBgkqhkiG9w0BAQsFAAOCAQEAASFZ2AXgjwVYpuz+JE4h7Cfj hTPVcasO+hyrGnUh0EWsmKcpZB0VmTbet69vBGusGtfQtfBztxpnFBGElHhxL1UYRlGj4inDaEH6 KNyDfQH8qPu9hYDdNt95kbJPip2AYa0B4+++QB9IrPG1JU9CB+GFPPnZFmg3w8jbJOhbQEagIRgF NtTZ4nREXu1Ba/J7UxI9y0SbbX4rEdtdyTrOx7lGzdjY3pdvrgQej5ej3/CiO3O3Ylt2m6WWDJzD fmERce14V4gsmuSskqN7o9Okxp/UIbRDDOM6s0lp7YM86BMgdHMqcRno22BGW5dmGLQHCGYLDLF5 XQXDRePqJSzcfjGCAaowggGmAgEDgBTZjIj4he/6AW/KNKDpRr8/4VwMvzALBglghkgBZQMEAgGg azAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQARgwHAYJKoZIhvcNAQkFMQ8XDTIxMTAyNTExMDIw MVowLwYJKoZIhvcNAQkEMSIEIAfw22tA2Yrq3RGC0imkFkPejTtxXGHNVRzAxvsnjVjZMA0GCSqG SIb3DQEBAQUABIIBAAH7sJ9THlTfV4ZCXeTN7teq4JbbPJxgTxTHk+068voVrVld4lTRZ71W3qr0 bHPEdJ6XMKioTZb45J9bgGKJzmXFVwS2+BP4l3J5ETdg4ebsQ7DSfUjIJJ8qIYMZYJVYI51bwm7/ a3YKSJIbKrNsK1DJrwekb+w9tyzmEnitpgYAaEi8PS0xvhNSc4RVEjANLY9PN1kWKU9ZpKJWwKrj wjVLEYtE4uM3b7Xe1j6ZUB3GOexmES/zM2E59CHLbrG94U3wY51S3YUr5kx5/nu2zCBnlqlqql3c HqM2OFn3fE+XfVcSZmQJCAewunK46aegDWMpBDwEtYOPGLSvU7FrIUo= --Apple-Mail=_6877939A-0EF7-41E7-8896-AC7291734340 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 18 Oct 2021, at 11:07, Tim Bruijnzeels wrote: > > Hi, > > There was a small bug in my proposed structure. We will need a sequence > in the 'ProviderAs' definition, like so: > > providerAS ::= SEQUENCE { > providerASID ::= ASID, > afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL > } > > Note that this means that the efficiency in terms of encoding is lowered > a bit. In typical cases where users would specify a list of providers > without any limitation with regards to AFI, we will get a sequence of > sequence of asid. This imposes a slight overhead. > > But, to me this is not problematic. I think it's a small price to pay for > having the simple concept of having a single list of providers, where > any provider may be restricted if desired. These concepts tend to leak > into the API and UI so I would optimize for understandability rather than > byte level encoding efficiency. > > What I would want to add though is that each provider ASID MUST NOT > occur more than once and that the providers MUST be sorted (low to high). > Having them sorted makes it much easier for parsers to verify that each > ASID occurs only once. > > Please let me know what you think. I am working on prototype code to > support this model. I can share an example object if desired. > > Tim > > > > > > >> On 14 Oct 2021, at 14:00, Tim Bruijnzeels wrote: >> >> >> >>> On 13 Oct 2021, at 15:58, Tim Bruijnzeels wrote: >>> >>> >>> >>>> On 13 Oct 2021, at 15:49, Job Snijders wrote: >>>> >>>> On Wed, Oct 13, 2021 at 03:41:45PM +0200, Job Snijders wrote: >>>>>> then you could also have: >>>>>> >>>>>> ct-ASPA CONTENT-TYPE ::= >>>>>> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>>>>> >>>>>> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >>>>>> >>>>>> ASProviderAttestation ::= SEQUENCE { >>>>>> version [0] ASPAVersion DEFAULT v0, >>>>>> customerASID ASId, >>>>>> providersV4 ProviderASSet, >>>>>> providersV6 ProviderASSet, >>>>>> } >>>>>> >>>>>> ASPAVersion ::= INTEGER { v0(0) } >>>>>> >>>>>> providerASSET SEQUENCE (SIZE(1..N)) OF ASID } >>>>>> >>>>>> ASID ::= INTEGER >>>>> >>>>> Is the above ASN.1 complete? >>>> >>>> Ah, you replaced an 'afi' field with 'providersV4' and 'providersV6'. >>>> That indeed introduces a fair bit of duplication. >>>> >>>> How about an optional 'afi' field per provider AS? >>>> >>>> If the field is absent, the Relying Party will apply the information to >>>> both IPv4 and IPv6. If the 'afi' field is present, the value of the >>>> field specifies the only AFI for which the provider is providing to >>>> customerASID. >>> >>> Works for me as well. >> >> Let me try to write out an updated section 3 capturing this and see if >> it works for you and others. Obvisously, feel free to change it, but it >> may help to look at text. >> >> I left the providerASSET max sequence size at MAX. >> >> As Claudio pointed out we can have a similar discussion on other limits. >> >> Perhaps it could be an idea to have a separate draft where limits are >> specified, which can then also be updated in future. I know that limits >> are arbitrary, but without them we will get issues because implementations >> and various components in the chain enforce their own, different, limits. >> So, on the whole I think it would still be best to specify them. >> >> >> updated text: >> >> >> 3. The ASPA eContent >> >> The content of an ASPA identifies the Customer AS (CAS) as well as >> the Set of Provider ASes (SPAS) that are authorized to further >> propagate announcements received from the customer. If customer has >> multiple providers they MUST be registered in a single ASPA object. >> This rule is important to avoid possible race conditions during >> updates. An ASPA is formally defined as: >> >> >> ct-ASPA CONTENT-TYPE ::= >> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >> >> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >> >> ASProviderAttestation ::= SEQUENCE { >> version [0] ASPAVersion DEFAULT v0, >> customerASID ASID, >> providers ProviderASSet, >> } >> >> ASPAVersion ::= INTEGER { v0(0) } >> >> ASID ::= INTEGER >> >> providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } >> >> providerAS ::= { >> providerASID ::= ASID, >> afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL >> } >> >> Note that this content appears as the eContent within the >> encapContentInfo as specified in [RFC6488]. >> >> 3.1. version >> >> The version number of the ASProviderAttestation MUST be v0. >> >> 3.2. customerASID >> >> The customerASID field contains the AS number of the Autonomous >> System that authorizes an upstream providers (listed in the >> providerASSET) to propagate prefixes in the specified address family >> other ASes. >> >> 3.4. providerASSET >> >> The providerASSET contains the sequence (set) of providerAS that are >> authorized to further propagate announcements from the customer. >> >> 3.5 providerAS >> >> The providerAS contains the providerASId which specifies the >> AS number of a provider. Optionally it contains an afiLimit >> field which specifies an IP address family limit, in which >> case the provider is only authorized to propagate announcments >> for the specified address familiy. This specification only >> supports IPv4 and IPv6. Therefore, afiLimit MUST be either >> 0001 or 0002. > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_6877939A-0EF7-41E7-8896-AC7291734340-- From nobody Mon Oct 25 06:30:52 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2773A0856 for ; Mon, 25 Oct 2021 06:30:50 -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 (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 vrkPW_azqzb9 for ; Mon, 25 Oct 2021 06:30:46 -0700 (PDT) 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 7D6B83A08E3 for ; Mon, 25 Oct 2021 06:30:46 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id 5so27005708edw.7 for ; Mon, 25 Oct 2021 06:30:46 -0700 (PDT) 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=ad0vHpA1oAFhwWVVKSxDECdvjH9nyeH5xNby/uokyH0=; b=XRH0YU0UoICLsj4XCYFyNE/qllIt15dhPnE+VwJbWmVPO6NfGkGy3T46Csa0wGXp02 UoATUYPhYvzv2bkXXo1pMb07o35VxKELTO37BtAdx5e4hBE/k1V83QycjvD7F6FlfbCc PK9E05794iZp38PwJALZOAgye5XWIKHWzXUeE= 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=ad0vHpA1oAFhwWVVKSxDECdvjH9nyeH5xNby/uokyH0=; b=QmHOmciKv4Tymmon+Gl7rmI5BUXw/O6TYMoy8ZHMxbQD69/1KJIZxOJki/ZJLrpPyb 5LzQtPzQZQNAeQzvfMCZeM7PSSxPzdEjd6AHFrS31A3HPlcke6gIVWea4f8mWZA01dVZ WoC3K9CKS0dQfhn5YkyQhD5vVgOuXFt5+yan6BHI6UY1kIO4f2kZY3V1qSY64op+y3n9 8OHUYqV5+TkQOceFaHEldADvj/BvpQ8hKGTVi6iNcu2J9n1sqt8bQzWQJGZe0MnbH+Do LQ8KloIA/rUSnkuhWCZK+QXmlL4v1n9d7HKBrssWA/+sLzYgtQ/a0cwdZAD2E5HC+qdG h2zw== X-Gm-Message-State: AOAM5324ixWDDda0PSE8HsdgucGc21J99b4xVXwk+YlsmZOcIrNmGXcQ 5Rw5BBZOWL8IcljWxwHADD+rIQ== X-Google-Smtp-Source: ABdhPJyCOoXiTFpcvFtAGhhJsP/Qy7sB6K0+JzTE+/0dk6RVxjIL84yS9kzM4P+v6Dl5g2IjCeLPxw== X-Received: by 2002:a17:907:1dc6:: with SMTP id og6mr9693273ejc.459.1635168554367; Mon, 25 Oct 2021 06:29:14 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id mp9sm6147619ejc.48.2021.10.25.06.29.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 06:29:14 -0700 (PDT) Date: Mon, 25 Oct 2021 15:29:12 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: Claudio Jeker , SIDR Operations WG Message-ID: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 13:30:51 -0000 Hi Tim, To me this seems an improvement over the -06 profile. Thank you for putting this together. Russ? Ben? Azimov? Randy? One note in-line below On Thu, Oct 14, 2021 at 02:00:02PM +0200, Tim Bruijnzeels wrote: > updated text: > > > 3. The ASPA eContent > > The content of an ASPA identifies the Customer AS (CAS) as well as > the Set of Provider ASes (SPAS) that are authorized to further > propagate announcements received from the customer. If customer has > multiple providers they MUST be registered in a single ASPA object. > This rule is important to avoid possible race conditions during > updates. An ASPA is formally defined as: > > > ct-ASPA CONTENT-TYPE ::= > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > > id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } > > ASProviderAttestation ::= SEQUENCE { > version [0] ASPAVersion DEFAULT v0, > customerASID ASID, > providers ProviderASSet, > } > > ASPAVersion ::= INTEGER { v0(0) } > > ASID ::= INTEGER > > providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate so-called "transit-free" providers? > providerAS ::= { > providerASID ::= ASID, > afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL > } > > Note that this content appears as the eContent within the > encapContentInfo as specified in [RFC6488]. > > 3.1. version > > The version number of the ASProviderAttestation MUST be v0. > > 3.2. customerASID > > The customerASID field contains the AS number of the Autonomous > System that authorizes an upstream providers (listed in the > providerASSET) to propagate prefixes in the specified address family > other ASes. > > 3.4. providerASSET > > The providerASSET contains the sequence (set) of providerAS that are > authorized to further propagate announcements from the customer. > > 3.5 providerAS > > The providerAS contains the providerASId which specifies the > AS number of a provider. Optionally it contains an afiLimit > field which specifies an IP address family limit, in which > case the provider is only authorized to propagate announcments > for the specified address familiy. This specification only > supports IPv4 and IPv6. Therefore, afiLimit MUST be either > 0001 or 0002. From nobody Mon Oct 25 06:34:15 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832383A0906 for ; Mon, 25 Oct 2021 06:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 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=-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=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 uJ-ZYzS3ijDc for ; Mon, 25 Oct 2021 06:34:09 -0700 (PDT) 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 123763A08CB for ; Mon, 25 Oct 2021 06:34:09 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id y12so20273535eda.4 for ; Mon, 25 Oct 2021 06:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=/W2amPJuBCvW2j+1aMNiYo/MZz0h2iGXNmOgXI0CmaQ=; b=AWj/EheSAqVAlFtPGzPfG4rZ40Mm1pw5qTGsoGP88RsspcP7lF2NDQGi1CwUiZ1LtU bEWiojOdCIVUwtG/8twA5qWS1B4NrVXOfkRG2w5un+Vsh8rQklBjLUf6bUEBK0F33mr/ Saj1wp2E1/O4sX4I8hrw35OLymETJnPsJoEZIEBBLns0pGT27es18GK9/eSUN+UQl0hr 81J34A+FluEBd99dNC6AnyokCoe+3ul/9OUnH8FLH+LQMS8MeeI+6y68pIaXhwV0XobG zTOxZfTYCkz0PzBReQ32NvaPGlKziku8vjOSBr9a+bfhBAEzEi5atIeTQH1mm/lZcTxl Uw9w== 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 :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=/W2amPJuBCvW2j+1aMNiYo/MZz0h2iGXNmOgXI0CmaQ=; b=3KuWZnkYGLkffMDJma8LTY/XLIUhE3dIoetyWvrj3+Q16qwopCvElFzCCetuoKsrNX JXlYIj1vYAIBzg2LSdlWS709vAPTrxg3g4mZGgayxMnmzxf+mL8BMB/jRJvIEnDBRPad i5cjgClazysOYSh1d8uqY/9haKXbir72OPu9n+V2qSjNOEHsf4ZGj4qji8f5KlrF//iv 3CZ0eKaioZQpbJSqqda1mbBDQbE2i9KUlUuWBwUy/kyut3oGm5X7ZkyRJz1CZYq9IaNu AWTZkjq/Ka0lXsNc96lap1h3Eh5LjVKTSc2b+fFqYJm0vPdPYwhzEmxFKd4OlMLCQuTr oIiQ== X-Gm-Message-State: AOAM530Y7N445vEc9wkyWhMECK4F18KtFpx8zu7MqLrDCY399ylSJ4e7 nPSfiwr1RIQ7kgnZKNzRSOeSCpCEnHo= X-Google-Smtp-Source: ABdhPJxmceSnODKwT9yVvbRKisqFLyOJOt1/KO0ZpB3Yi0EhXb3X0rEvYmHbPnYE4Q7JW2b0mczWvg== X-Received: by 2002:a17:906:180a:: with SMTP id v10mr22770469eje.112.1635168765875; Mon, 25 Oct 2021 06:32:45 -0700 (PDT) Received: from [192.168.178.20] (f189051.upc-f.chello.nl. [80.56.189.51]) by smtp.gmail.com with ESMTPSA id r10sm3810905ejr.96.2021.10.25.06.32.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 06:32:45 -0700 (PDT) Message-ID: <5ca89618-a355-51d3-080a-72427385ec35@gmail.com> Date: Mon, 25 Oct 2021 15:32:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: sidrops@ietf.org References: <162992596529.24798.5873690532394887967@ietfa.amsl.com> From: Andrei Robachevsky In-Reply-To: <162992596529.24798.5873690532394887967@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 13:34:13 -0000 Hi, I read the latest version of the draft and I am not sure that the Downstream Path verification procedure (sec 5.2) is correct. The draft says: > The first unequal pair of AS_SEQUENCE segments that has an "Invalid" outcome of the customer-provider verification procedure indicates the end of the Upstream fragment. But the procedure described in items 3 and 4 seems to skip checking that the first downstream fragment of the path may return an invalid verification for the "reverse" ASPA (verify_pair(Seg(I), Seg(I-1), afi). By performing this check we can verify that that downstream customer indeed declared the top provider as its upstream. It seems to me that a similar verification of a "reverse" ASPA needs to be done when detecting a leaking customer L, since verify_pair(Seg(L+1), Seg(L), afi) will likely return "Unknown", but verify_pair(Seg(L), Seg(L+1), afi) may be "Valid". In this case we can confidently state that it is a leak and return "Invalid". Thanks, Andrei internet-drafts@ietf.org wrote on 25/08/2021 23:12: > > 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 : Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization > Authors : Alexander Azimov > Eugene Bogomazov > Randy Bush > Keyur Patel > Job Snijders > Filename : draft-ietf-sidrops-aspa-verification-08.txt > Pages : 15 > Date : 2021-08-25 > > Abstract: > This document defines the semantics of an Autonomous System Provider > Authorization object in the Resource Public Key Infrastructure to > verify the AS_PATH attribute of routes advertised in the Border > Gateway Protocol. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-aspa-verification-08 > > > 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 Mon Oct 25 06:45:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458BB3A1072 for ; Mon, 25 Oct 2021 06:45: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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=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 BvzX2Rm-mCgJ for ; Mon, 25 Oct 2021 06:45:26 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2077.outbound.protection.outlook.com [40.107.21.77]) (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 732FA3A0BE0 for ; Mon, 25 Oct 2021 06:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gsl5BjFoXfBWmMdaH1HHYaLJc3dTCVdeBT4KxuSAHBpSWpTLvHxyrRt7rGgPspeHYi/4FrsgJJBSzsJKgonEOFqHQW20yu/Bqklp0wocASU4i6s/hpdjiUha7W5vKat3cWntxpRUDeP4An+8m/1ymzeo541g8ziPtzMG5RUvQ0FZNr8s+z3kxBn7qe5x1SgzZiT0DyFMlTnkrhVizvhlZuYyNVQvrzJarVPu2HfxfSth8hPcn3X8CzS2w5e3RkuTS9mzRhtvs0b1b3MNPhnOLcCyYyIooHHunVVDJKdQ+pGAI1x+cY82hNeUKgs+0BbYjrSnKcQ5Q+dENnDLzTAFSQ== 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=Oil741zvZ4M7ORLDCDS/+/hi/momktUvavFxpgkb1eA=; b=U3P2EOzWLRMveW5ila7oW2ePhTDCNd8kPQuDG7Sqe9JPJSZZg5PEnzHwu+r7pYFt1bkU7QZeuzQlnAQDrpu3iA9erXdE8BOCUdR/p7ap+ApzRfOns4Gv3gm8bB2X1Oj78P2b4ua4ufJu4M1yFK4FiVcTeKY6VOVthecIuQxWe70lV9txs9TZBj6a3EIJC06dlTyLF6RL7E8si1ssxmXkT8Y17YvgFnP6IdQgVpWcqC4goel6H/J3DtYZ25PUlyNjOx1KqLU6GnpZ67icl7piujqcBwgQqPgS7cSNVVJpeynxq2zhCUanDqPkfM21tw9pRDU/1G3Dj9YESgOoUEM0qw== 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=Oil741zvZ4M7ORLDCDS/+/hi/momktUvavFxpgkb1eA=; b=GtZMJTs9E/6dNr77sj9AYAe7d8zRyZDEV4LAwc7Rv0UJWZulr0rB2Y7f+MJX44Fuy/ae4EyzOsCbpfj6PJuXPeo3iGzVGWWyQp1fvQYls0N5mwAxFqaB9Nfm/r1R6Vfoxn4Qcf5V74xtIaxepup0P5LkqHSqL3vXT/QLdDcW2f8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) by AM4P190MB0180.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:60::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.20; Mon, 25 Oct 2021 13:45:07 +0000 Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676]) by AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676%7]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 13:45:07 +0000 Date: Mon, 25 Oct 2021 15:45:01 +0200 From: Ben Maddison To: Job Snijders Cc: Tim Bruijnzeels , SIDR Operations WG , Claudio Jeker Message-ID: <20211025134501.xlbbr35qxdsif7so@benm-laptop> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t374up7pcj2prct2" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CTXP275CA0010.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::22) To AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CTXP275CA0010.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16 via Frontend Transport; Mon, 25 Oct 2021 13:45:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7d0c51a2-c82b-48eb-2ddd-08d997bda79e X-MS-TrafficTypeDiagnostic: AM4P190MB0180: X-Microsoft-Antispam-PRVS: 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: wjymL0xV0H8vDdoHCHWEHL9veZsKkJTkx8TctWMysoysK7N2710xeZk4Um8MSS6I65s9j1WaZfkSI6guL+7Saoe9leAvqo2zsWOpn1C3/hAZ5rbVaMyjkYYKURYlgUaWKxFHtG3XhA0M6lh4VxVjR82T1ak1Lq3XXxoKuhle/whd8JV2FI/PNvezu/se91F/UcMEYVS6Z0NTYe8DJPAXb6yvGc2PFY92sPwXpf0GZC2pQf27s/QqQeoqkexvY7ZsvHHbXpiCPAGW22MccHb/B3Uspq/bTKqqwMX5cY0+temD7MW1D5CzP2rtkkqfT7kF5YVvWa9tqKW9vGfDfEky2uOSGMX8PJDKvGG/adww/GQLqBw3mUWx/LadtNVmsRv1fOO0uL9/hmxSB5vU7CGEEEMmVgd296poLyZeBwX5pbSIc1JXhzv/8ubidfW9B2aoimeKb0eGy0OxxIIZvl14R7KehQorF7ZLx6cnyCr0fk/FI3+iA/if9KjU2Q9RCEy9MzeNJNhvVfET/t+KVpgzWbGT6/QK9/QG9+Uc7bs1Bpva57Ju9fnzDnPiUtkKDkDFErwW7Tm0amBcduPHTBibhUYUwMNPiqnbvucEKTfDTVhFng5iWQ7XAfenJCCc1lWAe2sde7YOu+I9s45IFHiJ2RxqTQREDBmkNNBjPdD7XDDaOhq2uarkwaLcgddW7hZ+q1p+yeZuTJtHN6gtcryROrD6n/fHSvRhLQfIV+x7C7pTjLZaDJ6JGUQ5ffr8tFCM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P190MB1073.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(376002)(39830400003)(366004)(346002)(136003)(396003)(86362001)(33716001)(6666004)(8676002)(6486002)(83380400001)(54906003)(316002)(66556008)(66476007)(21480400003)(1076003)(508600001)(38100700002)(66946007)(4326008)(186003)(44144004)(26005)(956004)(52116002)(5660300002)(6496006)(9686003)(2906002)(38350700002)(8936002)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?kldg+FSWuRcI3F81r4AKBm28c8TJIk3CO53PuNRoEHZ+ZISr2f2mUJ40rRMG?= =?us-ascii?Q?QhX/oc7FKXn5QS33fbR8zQzAfuumQBJ9aDHV1h0+kiDqyg1b7J+E48cL8cCc?= =?us-ascii?Q?2W6iJSfHlsgO9WiNaTQR35KbP14PelIWaEKtkPbAJRC+AtLoIF25tpTijxmx?= =?us-ascii?Q?38Fdu8ssmb2zs257ESfgJhpPuvwdXaYdci1SqNy/97Vo45qJgiN13XXnCE5O?= =?us-ascii?Q?6uAEwZNPw9ewQfrNVLo8Fnip/RgtNrOrBjPSgGVyKBPpt28zCjnmkoQXgBuA?= =?us-ascii?Q?N+Z9itynmy4VBiY6oK2Ly8QfLBztU4tuKEIPY5gf4vcBfK5ng02JuWxPqPu1?= =?us-ascii?Q?hkI4N8yNdXsty6W0Hd3Tj+gAK6Hi3HzrVc+2Hhjmcf7DjmE760UnnSgN5E+i?= =?us-ascii?Q?5eY+8SZCFItDdqF73+m9KB2eWQTRtrsxnAVcoRPITCDmu3MOLEkHq3KL4aze?= =?us-ascii?Q?SimPSDfdhJc1/7tldvMjfX9EGvt3Pi1bwOLf4LeG72dL637CrKWKEAT7QqT7?= =?us-ascii?Q?TtBlEvCfWUvIOTlETMHuD+Yk1pf3vgw73wUypF2WVNdalUqJOSWM7Xslzo8i?= =?us-ascii?Q?btKjBnkvmG+HlUiyofvgD0O7DrJfpZPsmkZX4FyusvunxVHJLJXOhPZLfnoc?= =?us-ascii?Q?Rc3zEdYtqe95FxkHJoL9kJ73i5TbLNNIZ1NtWOThbWDT+7PUBg+atF/jZCyu?= =?us-ascii?Q?HyuSDpnJP70C2j/BnoT9R4GAIJKC85m1aFaN1xr7+RRe5QB00VYnTveltpHX?= =?us-ascii?Q?cuLvwBYZNmGu33wU47GUDLywZvH2qOLHrZOF0BbzzxXLa2DhFJvFKXc8QCw3?= =?us-ascii?Q?676piyaGql8Ryfh2xxhwaCUGLV8tOM/RYNlDESUO8fyu7z+Q1qA46kpzQLOK?= =?us-ascii?Q?1gdabpgVB2FQYiZcb9YA5Bx1TdtBiEbQt2eZZ1+BU6XchQpKa/jalyLWYz/d?= =?us-ascii?Q?BuIV2wI0eUzgcWqV+XgI8MtjJCrjG89FVfznornJhA6P9o64refzWOvOH/O6?= =?us-ascii?Q?CcRoiaMgby2IlIIwtfuJaizSvvtKmuEYxHMDi9RBfWiQzEJn6i5u/JGldb7+?= =?us-ascii?Q?0tzUmwD0VPTKfcwvHEY8sChb0dWl4IBvS2AfqWBxUYGbo8os/RHuGA1sFCP2?= =?us-ascii?Q?wceeM2jO91qnVWdRUzLt3ujmibvtVtbJJkLGxOQcZ7jNW5NxubHhp9Yg0jFI?= =?us-ascii?Q?7eZIH/jaS/Cca7yn5zW3ZaV2fiRcVBuvP3mRA4jjgCGPJ0w0JFfwr2Mp7OFX?= =?us-ascii?Q?a/9AsTy1q4GDr2ziQ5OQF5BBEx7/IgQQjK55RhMqepp7BTsPbplg7PWsz1rV?= =?us-ascii?Q?jvL/2l9Dg/TAuFVJ8F8XKNw3j1bHU4BsnVzpZyKfdh2HwdNBK5A4B/0Ybaz5?= =?us-ascii?Q?0dQgq58c2y5gB/ikfACnQQb9foGhQqUk9jXeGLUZj4+fl0ggAMNnP85et/T+?= =?us-ascii?Q?R7XHT/Os88NpKI7OpoPM+FGVump/WcxogegLe4lH4W/QFkPwvRHd2hrg6jXU?= =?us-ascii?Q?QziTx6pjxbhXQO01KqTocSLkwUtv+Vkg8YPK9JNqRyASrxS6jn1A0NuwEBDK?= =?us-ascii?Q?aVwt1Djob7w/iIN66uL0+uGJYRugi9Kpsw1mUa/GVFTTAiHJqKWF/+WlwgsV?= =?us-ascii?Q?n9J14LySEo+ewIQrtj701uI=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 7d0c51a2-c82b-48eb-2ddd-08d997bda79e X-MS-Exchange-CrossTenant-AuthSource: AM9P190MB1073.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2021 13:45:07.0631 (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: gU+iRqPdUbBLQDrycVR4cfa7ec54lNKOTyu98KzL03bfuJ3INvI3ywUNqhXUGFiqJ8N06NtPlyKEGqLudqmcZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0180 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 13:45:39 -0000 --t374up7pcj2prct2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Job, Tim, On 10/25, Job Snijders wrote: > Hi Tim, >=20 > To me this seems an improvement over the -06 profile. Thank you for > putting this together. Russ? Ben? Azimov? Randy? >=20 Agreed. I think making per-afi distinctions the exception rather than the rule is a substantial improvement. > One note in-line below >=20 > On Thu, Oct 14, 2021 at 02:00:02PM +0200, Tim Bruijnzeels wrote: > > updated text: > >=20 > > > > =20 > > ct-ASPA CONTENT-TYPE ::=3D > > { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } > >=20 > > id-ct-ASPA OBJECT IDENTIFIER ::=3D { id-ct TBD } > >=20 > > ASProviderAttestation ::=3D SEQUENCE { > > version [0] ASPAVersion DEFAULT v0, > > customerASID ASID, > > providers ProviderASSet, > > } > >=20 > > ASPAVersion ::=3D INTEGER { v0(0) } > >=20 I still don't love the enum-style version, as we discussed in the context of manifests previously. Moreover, I can live with either enum-style or typedef-style, but we should probably pick *one* as a WG for consistency. > > ASID ::=3D INTEGER > >=20 > > providerASSET ::=3D SEQUENCE (SIZE(1..MAX)) OF ProviderAS } >=20 > hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate so-called > "transit-free" providers? >=20 Yes! For practical purposes, these are likely to be some of the most import objects that get issued. > > providerAS ::=3D { > > providerASID ::=3D ASID, > > afiLimit ::=3D OCTET STRING (SIZE (2)) OPTIONAL > > } > >=20 Cheers, Ben --t374up7pcj2prct2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmF2tN0ACgkQOkYk/rSL aGDTxA//XBE0bU0HaPvvN0rGoDGyzNv61emWiJAad4EHriv1K6hMSB8dj3gaofJQ kKC6He4tLtaA8SLhn1fm/gl+iIUf27IMU5rU910mW+UoLD4qTIY6PJI+XXboiFyg 0cc8O7sWUwqJTT5J2Zqzl7+a5tgwsoBSaUpeqxt2f/fuSl9O9VNmakHUTDQglMDW 2rsKsTvMZ7c6ed2HDkNYAlywTpFCOd9oi3EptrBNeawKtOrXr8wLE7cg1hnm+sdY ZLu+1IE5xdNiHRj3yXvke9H2RrOPdjLrBfagr7uRuR/95lBFtWmsu/bkXaTWZs4W 49c9xEeXFf4YOk2YYt+PL1aqpYX+obZu9cpi60LUIV+CtD1rKFrqlfXCl5XcwZqz i1W87kFu9z8ss0tFykEr3JAtYI7P6zICIpMhm7j6vxCoMvT/RJKkvULry0znPtLj 5FZPebxJ9Ps1nQScsy2X0QdhYRKi5SiKs9Mle/qlQHe5Kr62HQlOnFIOdvmO5q1L td68x0OIkfC2YPbp+PzenYmzUsC521MDLeuDuBsEA+3vY7Kk6YLkqVvMH8k60qfh rfx+uohJWKD1co6pdZ1lGwwJw/1aA1DJFot1q1RIKfGyQa0F5F7mWc9cRdS3lsga 7eIrikPMgwCaLvyKMEA5zClVq7bmdZtMijsXtaEJPL7PMiSWDIs= =Ylic -----END PGP SIGNATURE----- --t374up7pcj2prct2-- From nobody Mon Oct 25 07:02:52 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7A3A0ED7 for ; Mon, 25 Oct 2021 07:02:44 -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 (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 6-Yn2UFaVtOQ for ; Mon, 25 Oct 2021 07:02:38 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 B79F03A0E0D for ; Mon, 25 Oct 2021 07:02:28 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id f13so1297137ljo.12 for ; Mon, 25 Oct 2021 07:02:28 -0700 (PDT) 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=COJpDjsYJv9Uljf6KFqkbWrXFh4XkkMxm0J51mD+h6o=; b=GHFCqefPTcaYwzuae1g9spWYpDnfn8GdbMVPFoCq7kYdCTUOVq69dSoMbiOhXUz8WR NNAUuoms8Srir1cgYi91FUZI2QrGdxUesD8bG9EncydoPKl3xSP/lyPHoxpCX9t67S9V ppwgjdKWFdJdeRKjlIYVYZdz59cF7GlHDE4FA= 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=COJpDjsYJv9Uljf6KFqkbWrXFh4XkkMxm0J51mD+h6o=; b=8Fue9SsDL7wUKAIBpPw1W9IPG4ui8zHXU7NPhb6SSziAAPorcMPtl9MqyDSrFW/dYF OFy1ixR+JtobP7hKTqWfgDy2nX+ha7OdYmcbHUtyB4pP+KdS3E6teYhpZvDr9ebaEqAM O4w+aJC/peGoTw9loreIhCnemDJGBD9UOtbUaurnez5XQnMd3RCpGDlndITcSMKkitVY inU39G3m/y5Nr1vBPEQzBNCDwm+vBSRjUq9SBhkeRZEZy+BlY9QZzaTYyzN6fj8z0M65 kvHJfVFVNitL3V49pH+8HhiaYGV3G/0i/hq9T94pTaMvTgRWLkgXd9veb1FLFZmp/uL0 QzlQ== X-Gm-Message-State: AOAM532k/5Pkzaptp/URFFQCBEbjsXvcdlq2svd8N2+++sDHiITHQ362 Na8VJOhTRTeV2IlMDZ6ovN79Zn0aLQ7w76qX X-Google-Smtp-Source: ABdhPJz5MR7y8hakHXxWjITMlZ4awnJlh8n8cT717vRVKl1aOOLjhl9FXUc+0Y9Xa1/jx3DY+EMHpw== X-Received: by 2002:aa7:c1ce:: with SMTP id d14mr26962998edp.178.1635170533183; Mon, 25 Oct 2021 07:02:13 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id s16sm9544868edd.32.2021.10.25.07.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 07:02:12 -0700 (PDT) Date: Mon, 25 Oct 2021 16:02:11 +0200 From: Job Snijders To: Ben Maddison Cc: Tim Bruijnzeels , SIDR Operations WG , Claudio Jeker Message-ID: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211025134501.xlbbr35qxdsif7so@benm-laptop> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:02:50 -0000 On Mon, Oct 25, 2021 at 03:45:01PM +0200, Ben Maddison wrote: > > > providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } > > > > hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate so-called > > "transit-free" providers? > > > Yes! For practical purposes, these are likely to be some of the most > import objects that get issued. Hmmm, I just now remembered the verification doc suggests to use 'AS 0' instead of 'empty': https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification#section-6 Using 'AS 0' permits one to publish a statement that one is 'transit-free' in IPv6, but not in IPv4, or vice versa. I'm not enthusiast about how 'AS 0' is more and more overloaded, especially with negative trust anchors floating around. Kind regards, Job From nobody Mon Oct 25 07:03:53 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029F3A08B6 for ; Mon, 25 Oct 2021 07:03:51 -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, 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 PGC5n_mT6sHe for ; Mon, 25 Oct 2021 07:03:46 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (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 0641F3A084B for ; Mon, 25 Oct 2021 07:03:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J1VS5j9bgakzm/j86RCykzmQjKW53XNKnzzxe0FgrheZ60TVIvXS4OuR8MBOUS3RsNjO4m4zEJJh3u2NOIYI1sZM2bG6Fd7RaVZS4tlV2FABj1nGoJnQiA25Z5QfrpmU+zXu9Hqmd1zmRi3Y51EpNKFWie3Xre9Q15kp+2EytJFMSQjgk5dFAO5QFmauzkDx7sIu0waB/X4c+0bep+3RbQHdSr77bPXwrJI2wNcPAeIzZMKAFuyC2GbvocEz4yKKvwxLWZZrlm0dIGccDpGnVvD5MHSNjg1lA9KxejNKFg+Gn9ZAXbngJq6OU2eShehSfgO6MjUqVhc2y4K5xQkj1Q== 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=CMxOJUmvcJ7hNozymsuRHFbGGhot0PlzVcFGeUe9muM=; b=PYSD7WXwiUV0ZGHlcgesfYYqqrVSA78AW6ZffvyYea45rOYXesAnnKN+Lujl8G0yYSxGKaBmiYwMBSGYh9NM0RVTwHWmPPBn6uU989EQJz438uBLOM5gKI3w8yVuNRL8UPFPH/CnXEoWg+g3eBy5UNdbecJtnNLjV6ZAVTJfiJ52QrhlamHto4cgNS8jWbOvPGS8dFuh3vKlsRx1oyf3IxZsjqVyM3PxbQVQdI7SmyILVn6v8WMQU+2jzPPR77XHX5lL1c+R40Q9QZh0bOzWKPkzE7SY7RB5JbeGfT3k9IcVs2PtR4sngtCDHM4+W3FRqPLSo69w0mR9tT7opjgyAw== 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=CMxOJUmvcJ7hNozymsuRHFbGGhot0PlzVcFGeUe9muM=; b=AifvTx30FOQNFzvWBr0JNqvKlkQRRkyQ1iRHMMDzeubs8wVQxJWGGuFdfYxzwR2wJFEnO/zQ2ZSjoy0aQzpqVt9OAnqf4uygbkDkYaWXZHrfU5V/2U9XnwoXR+GT4FQsaA2VxEhsN29T0b6PCK+66hWgS4+7K4FPR/kNTgAhcY8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) by AM0P190MB0610.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:197::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Mon, 25 Oct 2021 14:03:18 +0000 Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676]) by AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676%7]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 14:03:18 +0000 Date: Mon, 25 Oct 2021 16:03:12 +0200 From: Ben Maddison To: Tim Bruijnzeels Cc: Job Snijders , SIDR Operations WG , Claudio Jeker Message-ID: <20211025140312.h5kdwq5ocnk3ufyu@benm-laptop> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <0825BA24-AC44-4EF0-A9A7-DDEE0EC9DABA@nlnetlabs.nl> <90186EF6-1FB9-4812-AF79-2D1F2221C188@nlnetlabs.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ye6rbyftzekd4naf" Content-Disposition: inline In-Reply-To: <90186EF6-1FB9-4812-AF79-2D1F2221C188@nlnetlabs.nl> X-ClientProxiedBy: CTXP275CA0028.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::16) To AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CTXP275CA0028.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18 via Frontend Transport; Mon, 25 Oct 2021 14:03:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b132e3cd-5792-4e4b-f8a8-08d997c031f5 X-MS-TrafficTypeDiagnostic: AM0P190MB0610: X-Microsoft-Antispam-PRVS: 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: VC8BKLikGQ0OjxpxafvbfFyHkAmSZisurFoHVZWksHO7vEzYjzo8wd5Zr4/vglYud/YSsSB4K7gOFtd7vISsrUmbhN2ME2Vm30AcCiBVcqr3Cof1cGeaB5fybcA3/Xl/F9AXXLKjuKlhtY2U5kP6H1PToBdZ8aOMBGIpp5Ox1fnuWrZNJrRHFMMICJCLAiiAZvLbxclowCzexoWivXADvXmWFadvIQ9mlgzAHt/X9/W1b1WRN3kmnKRFO0HIbwz7U11TEZkj//VKfeRvYo4/OKBz91L0qCGT8qCT42r+ucf0Dzr6NmpQlS9pJmqMsbNqcAkG6x2as/VJ0z3e/bv6euD/SxpHVjn2+5Aad9A515enbltJNMFqqY8Gjqz6KdPysaEAzSeRV7TB898ihfXv10lLybpvYSsuTTRYFQ6WBg7zD34nIQD8v8w+xdUCEWswXdyV+LfDeTK19A3SAH3V33ny8n+Uybaqdlr+MraE1pZqFS93+ang0iEVkvvoeSelJZRahDvupY8URXyIkEfBjjAM2ZRJ8yz8TeXLuay7Oe0wN0NjLhOzy2E9vyWG5ZvNp+sJxDHtAkU4mxSZfx2gsMrWHjbes1SVej9/UJptua+icVYTElWWp28yzM7A9mMSyMytnSgOIf2yJ+HgEbDHA1R829kqXrwLCXQhZp+JMk3BWGVYD3vaKtUkMxyaHNKvpLbTku0jUDlYRM+0CnVS+DJCiYc8orfaH74p4A+mwXK4qEZwkVN2WvADBm9pinHbX/b9ia/0R2rn2pcyOxE59w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P190MB1073.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(396003)(39830400003)(346002)(366004)(136003)(376002)(54906003)(83380400001)(5660300002)(9686003)(86362001)(26005)(21480400003)(6666004)(38100700002)(33716001)(1076003)(38350700002)(186003)(508600001)(4326008)(52116002)(66946007)(6486002)(44144004)(66556008)(8676002)(66476007)(316002)(956004)(6916009)(6496006)(2906002)(8936002)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5HeNXM7HGLeAcYzib1SHtSHvIvJj2BArUwQrfiZHLvM2ohxcsfoCjk+1XpLl?= =?us-ascii?Q?ByXKs/kxi3rRGOV7+jPK0U6ey4CJtgno4PB+TA1DnG4ZIfvAvgzec7r5pJGb?= =?us-ascii?Q?12tydDNcP7DQ6l6FpbqoltcjxLH6N5BVX0iaXLqGVCTBKpSYPsBEw+NypcLC?= =?us-ascii?Q?hNsdUy9iqkA2FaH8tiC14gm6MY2cyQxw18e8Rof54kDDU2Gzs5fwCyO9CA2L?= =?us-ascii?Q?2oTG40VDsAGFNzJh32c3ZMAoD70cgAuFf/a0Q9oxzUCiT8t+GkvjOS17t9L1?= =?us-ascii?Q?BPxBf/wRHDGtDYz4X9Tw4Ygv5EvLteyDfL+zKML+zu9xbJNtigl7buwnMjIi?= =?us-ascii?Q?2L2VeRs/Cj/n1/6SorjM3lZEuBjQEdTs9MXKueh1JBCrSHPt4K0xIAVyQY/h?= =?us-ascii?Q?jJTjAGV2zWpk7fPjq5/Pn61iZhKo9dvYSdAuVebzoDq2nom4CQ7TINVvP0c8?= =?us-ascii?Q?czD63WFupGNVyZ9l7Ow4uTC3ysLd47BgZSFpi8x2ub2g6CTZ3gScJqM7jKHV?= =?us-ascii?Q?DMz/q+s5gvXXTF0zSDIm6SDhBgqolvy6igCz9v4EcFeV1dTeMeELorWkBL1N?= =?us-ascii?Q?SprQmApjtkkJzDdfULpHzdcgj7o3DNCtwLNd8cPIEEY8n3kn2GpVg0Pi9Mhb?= =?us-ascii?Q?o4t5UX20BjeAhL+R8lqTLe14EMNsQM9lAass988Myy1J69SlKLMbNhAYQXQe?= =?us-ascii?Q?K73gU7AtPZ8uGuGo73SSCi29Nh1CZBpOUaXPdrRVqjXuAu6A0CaRTv1QSBOa?= =?us-ascii?Q?h9YHSs6H/4PDiELzXqeEiGuSSqnMfGw1qpFUvFEcSbX4SXxLmqbw+eiFYYkB?= =?us-ascii?Q?IXHifbyqMM6jH129Cxg7ZEGREye3Eo5R1CWXywinaylmv4Q6wgWkcjbVXASG?= =?us-ascii?Q?olyyzSn44qqRy8dIPTHoWY3XdB7/NSFrPXRWvJ4p/z4X8o74UpNXZBFmSe9C?= =?us-ascii?Q?qvNtReiKtn6spgoA499tEPq7nADk9Wc9f7TvsTyM0JNwxs3uIsjQhdRaXMYa?= =?us-ascii?Q?nNKIrGKh5xvxOuCmOEDafJefR2ajGXmKaL0upjFmY73OOzIsQijzfd76r/Eq?= =?us-ascii?Q?iJ6NFTqyQaxFXzlERE+wTOemh3Qy7kX5sfQBxfxFtT1gW64eobUKwkoxera+?= =?us-ascii?Q?WjK43XdQAR6HdpPH/QMC7hNmET84iEC3/is0MUuSgJTaOzPQuaMtFo6TQvs2?= =?us-ascii?Q?zunttSCPh19JtQyhYp9FPvAhXpqwjEnBJMEyQg9Z5dXitybSrxxpr9DxhaRs?= =?us-ascii?Q?/hbmrMbEsrQkKgnGaLK93x+ILG0C2YeDZg3KGpWKRvdEm3IoPdcSaPnjLl17?= =?us-ascii?Q?Jxy+0ZRv8An3QkeqoUzka3sVI7YQbSCaK01K+X5CRcXnq4mAO6NbVRBkc87p?= =?us-ascii?Q?gScHw7acIe8IO/ThC3jx2Of0o5kWhRGepQBI+03Dx4VB4jVmF11jeniLZvQx?= =?us-ascii?Q?mDnDFdgMmampP9cFVKcvP9qIQOk2yaRYDj9czDAtwkIWuLaRsK8wqZ/6XHtM?= =?us-ascii?Q?1AUvYyLbcc4XSey7/BBCHqxB6u7fYl4tmogJrGB1GnIsc83PR8Ox2KINvNK8?= =?us-ascii?Q?YR+/K9B5V2gSMUY5LKTPUemyBK7NZEf/uY+23GdYz+XFhvUE1wipnc2lQZy/?= =?us-ascii?Q?ckH861Ds8QCI5F238i/ltVc=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: b132e3cd-5792-4e4b-f8a8-08d997c031f5 X-MS-Exchange-CrossTenant-AuthSource: AM9P190MB1073.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2021 14:03:17.9345 (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: j98s2KKyrGQKWAHTM0zR91I6s7xhofvYx4g/24PDSt0UDP6k5Wv3zFgo0xK6CMEM/rQLXK9yP5cIEEHFxtXPZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0610 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 14:03:52 -0000 --ye6rbyftzekd4naf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tim, On 10/25, Tim Bruijnzeels wrote: > Job, all, >=20 > I have running code - in a development branch - that adds basic ASPA > support > to Krill. See attachment for an example object. >=20 Great news! What version of the profile does your demo object use? I guess your new proposed version, since I can't decode it using the -06 module? > However, I have some open questions that I need answered before I can > merge > this, and deliver on my promise done at the last IETF that I would > provide a > public testbed. >=20 > - Do we have an OID now? >=20 > Sorry, if I missed it. I know one has been requested.. the attached > object > hijacks the ROA OID - so I could keep coding - but I need a real OID > before > merging. >=20 rpkimancer-aspa is currently squatting on .73 for the module OID and .49 for the content-type OID. Perhaps use those in the interim, so that we can at least read each other's objects? > - Profile? >=20 > I got no more replies to my suggested profile update. >=20 See my last email. Cheers, Ben --ye6rbyftzekd4naf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmF2uSAACgkQOkYk/rSL aGDeMRAAnNoWnAzm+xG1MRQ7rvLjAn3b31gutvOYNDAxJ3ozY2xDONYMRs5bVVkR jiRITPHR/1SXdr93Kmnw7S4crj6wqIN3+sEBIEIA7Ctn6gESH28lI5IMkk37VbCM KExLoCnSz9B58wVAK7FsO0urPIsF0ILtZ5xYGVrlNFgMLnDUpl6dih1fUkTWfrne 9BA0wwZ+9PmuXh5+IlrCKslSfMNt+IjQ0kCmijN/lKASuS5xJ348wHN9xyfCUtgb xGm9xDk+snwAsr9RtiV22pR1URjLNYoIWiVToiBCK4URZbqTk17ksKjMAPwDVagb iQx9qEWEiewQYlSSPXvTC43oaPSDETiIFNt3bOeYyctuEkXJifIqtD9jUpf5BS49 tyTsAM+U/f/BLtTP2k7rnQFnPVKZdXhgXh9BFh3+1TWAUbdnFxnsuep9jsUrCrId 82yFLUlWzJCDk2YWKbnghoJxOhjOguhG1ZKXx+eSL4Z5AocwRBOwoAC9f5dKVSta a3Z2LFp8ItsJ8RxEIIZLHfMEGwIFhHLB4CT81KsEABUx60VlTYJTI/GpkivS0IOJ UnUfkzCZ8ygO5M0xBU4cTvsqO+UBt0lrzq6vyWqQ/hjkdh5Il9kCVLgFQe60vQAA Ph7Q3k8ZSUWp8AhscOR/y4tlikt+qY+VWlvAdJxQqlaJWZ63ntw= =bYWp -----END PGP SIGNATURE----- --ye6rbyftzekd4naf-- From nobody Mon Oct 25 11:38:01 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF343A073E for ; Mon, 25 Oct 2021 11:37:59 -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=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 rN8po0i6SyeO for ; Mon, 25 Oct 2021 11:37:55 -0700 (PDT) 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 5EB613A07D8 for ; Mon, 25 Oct 2021 11:37:55 -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 E3800E3; Mon, 25 Oct 2021 18:37:50 +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=1635187069; bh=xHuUW78IQzDpxpiYOJOh3TC1H6VqfGQ7jA9fMdbQYfA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JmApRY6hx6ZkRbpHQyHkiMLmmMJuDUQ99lFXmIbLAfEpY9ZlfnQ7X0m8c4LdYlrMS JACkgB1xV6RGg/aNH0NbbiqS/ZOaeOufajafmsXPKP5OiY19GACAI56HtXqsvUnMVi jww2wOEZ/bYI4B2ZpflY0s1ZxZIccaPuJmxvv0E/LY85/oxHPvl9tb7D6SQudCV7Y9 6jwnjgPLi4iffmmaxzJLzeHOcWzDuCe++J4zmxh/D4J2rEJwU9XZ2iM6rtnRNYJzQI 9N0SC9PA8vSg4i7uO8n4z5ozqRTXLrZgCrCFozGKBD9AYlVqsG2XeKxW0BAbtZov00 ktq5o+N90Cwsg== 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 In-Reply-To: <20211025134501.xlbbr35qxdsif7so@benm-laptop> Date: Mon, 25 Oct 2021 20:37:46 +0200 Cc: Job Snijders , SIDR Operations WG , Claudio Jeker Content-Transfer-Encoding: 7bit Message-Id: <44B98828-F79F-486D-AC6C-731682F548D0@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> To: Ben Maddison Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:38:00 -0000 Hi, > On 25 Oct 2021, at 15:45, Ben Maddison wrote: > > Hi Job, Tim, > > On 10/25, Job Snijders wrote: >> Hi Tim, >> >> To me this seems an improvement over the -06 profile. Thank you for >> putting this together. Russ? Ben? Azimov? Randy? >> > Agreed. I think making per-afi distinctions the exception rather than > the rule is a substantial improvement. > >> One note in-line below >> >> On Thu, Oct 14, 2021 at 02:00:02PM +0200, Tim Bruijnzeels wrote: >>> updated text: >>> >>> >>> >>> ct-ASPA CONTENT-TYPE ::= >>> { ASProviderAttestation IDENTIFIED BY id-ct-ASPA } >>> >>> id-ct-ASPA OBJECT IDENTIFIER ::= { id-ct TBD } >>> >>> ASProviderAttestation ::= SEQUENCE { >>> version [0] ASPAVersion DEFAULT v0, >>> customerASID ASID, >>> providers ProviderASSet, >>> } >>> >>> ASPAVersion ::= INTEGER { v0(0) } >>> > I still don't love the enum-style version, as we discussed in the > context of manifests previously. > > Moreover, I can live with either enum-style or typedef-style, but we > should probably pick *one* as a WG for consistency. I left this unchanged (I think, did I?). In any case, I agree that for consistency it's probably best to pick one. This is what triggered me to bring it up wrt manifests. But, I do not have strong preferences. > >>> ASID ::= INTEGER >>> >>> providerASSET ::= SEQUENCE (SIZE(1..MAX)) OF ProviderAS } >> >> hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate so-called >> "transit-free" providers? >> > Yes! For practical purposes, these are likely to be some of the most > import objects that get issued. > >>> providerAS ::= { >>> providerASID ::= ASID, >>> afiLimit ::= OCTET STRING (SIZE (2)) OPTIONAL >>> } >>> > > Cheers, > > Ben From nobody Mon Oct 25 11:38:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948CF3A0E13 for ; Mon, 25 Oct 2021 11:38:53 -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 ockk65rY5U7M for ; Mon, 25 Oct 2021 11:38:48 -0700 (PDT) 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 76BBC3A0DB8 for ; Mon, 25 Oct 2021 11:38:47 -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 9DD1FE3; Mon, 25 Oct 2021 18:38: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=1635187123; bh=F0gaz6FuRVuA4rTYi3fbbzTjR0+xkJALtZV8wFckvLM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RKinI3eJJgMKmqRZNazGKJdrunn7SD0Ft5N6n4j/8h5fa7DDgz+lNZVwyDZAsHzHE dLUDk7LEJ3M8ViwnUxDZpgbQ0WQfVAGz4JXAUY1aGAZ3z7HoYG1UUJqLq7NzlG8zFP 4vcwEnksU1lAsPmXQdAg6PtlhuRVYOL3HzG3s+GTSFJit6Gx3DbWYoLmw4i6HLQQoP tvMlhBAjSIHqoNVCJp2gytxc+sDMg7G5wDm5KhXgYXClazc7vBRG5HucrVpFVdBYLv 5VN+o0gxtQ3Yz2z8bTkSIzX8FcYrNv3iyABSlv70Ys3NUb1ip4qfOGz07gWySlNYxO nSv3GWjeLUsfw== 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 In-Reply-To: <20211025140312.h5kdwq5ocnk3ufyu@benm-laptop> Date: Mon, 25 Oct 2021 20:38:41 +0200 Cc: SIDR Operations WG , Job Snijders , Claudio Jeker Content-Transfer-Encoding: quoted-printable Message-Id: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <0825BA24-AC44-4EF0-A9A7-DDEE0EC9DABA@nlnetlabs.nl> <90186EF6-1FB9-4812-AF79-2D1F2221C188@nlnetlabs.nl> <20211025140312.h5kdwq5ocnk3ufyu@benm-laptop> To: Ben Maddison Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:38:59 -0000 Hi Ben, > On 25 Oct 2021, at 16:03, Ben Maddison = wrote: >=20 > Hi Tim, >=20 > On 10/25, Tim Bruijnzeels wrote: >> Job, all, >>=20 >> I have running code - in a development branch - that adds basic = ASPA >> support >> to Krill. See attachment for an example object. >>=20 > Great news! > What version of the profile does your demo object use? I guess your > new proposed version, since I can't decode it using the -06 module? It uses the proposed structure. >=20 >> However, I have some open questions that I need answered before I = can >> merge >> this, and deliver on my promise done at the last IETF that I would >> provide a >> public testbed. >>=20 >> - Do we have an OID now? >>=20 >> Sorry, if I missed it. I know one has been requested.. the attached >> object >> hijacks the ROA OID - so I could keep coding - but I need a real = OID >> before >> merging. >>=20 > rpkimancer-aspa is currently squatting on .73 for the module OID and = .49 > for the content-type OID. Perhaps use those in the interim, so that we > can at least read each other's objects? I can make a new version by the end of the week. The kids have school = holidays, so that means double shifts for the parents.. >=20 >> - Profile? >>=20 >> I got no more replies to my suggested profile update. >>=20 > See my last email. >=20 > Cheers, >=20 > Ben > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Oct 25 11:54:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9763A085B for ; Mon, 25 Oct 2021 11:54:44 -0700 (PDT) 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=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 PweTDU1Zk3eT for ; Mon, 25 Oct 2021 11:54:40 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::71d]) (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 C64493A10EE for ; Mon, 25 Oct 2021 11:54:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z7h4dMh04Fo+GY8W8IajOQxhv7eYVp4TmP6ZfNDw5xoMq+di9ZMk+EW3DjSPTj+amqY0sdt11wv1L/JQD5fS062bOBPpimT/h8ga3xaHhE7fjx0JDV6skiKSz6/tyI6exjk38TfhTyNzFmDj1oIsB38bvszYn5H7CbXGKH4Qhmp6wSIs1UlK7zsCnlymDgcqZHAIzortoidCeWS+G15wrRMQgQr/oSpHPFk0S0XbZXNOpCcF5BTtjOmCtZTD/5gpUzKgQtaqNhArDvQsmDyFbqWV5agle084encoPgoaQwtxGLup2wgYL4HYrOPORnLiRRCtq2laFem0pV7YyKhDLQ== 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=Snbdz0Pmu27+w6gP8idWfBSLWW9loKcwjBuUdbAoCXY=; b=U0q0Ia2lorxkjuj1DGcQF6dZMq553IXb+6u+9wKI/aiRfe9CRcO8m2Y9JDv0POCpLfedywi4IiloW4mLOJFbjDEaUzyndQElFgJkkRdYqXF89ZdcLqGoARIAObJlTaFJlZP4Nz1LtY7NvS2+J4NWju9eZPmbaWlppJOEEVKjoN7RY7RCwZ8I9FX9nXg6x/dRDfVbCNWF2rw98agNVH8nbdTpbsndCUGeWO/lm00ScJ/r4gPEBdLCxrLVsFeFA9OBTnWgUY1YDTbYvURrW/k+SWemSmZltkbXYuKyzZoU5NZzv0dnhAJirYynwfaL6svkvWHltesiZ9dCHxWr/TpBRQ== 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=Snbdz0Pmu27+w6gP8idWfBSLWW9loKcwjBuUdbAoCXY=; b=AN0Sia+ssaHp2VbdQz2ugCEBd3ulIdMEmFtjPT5Mq6PKdwbrXCgS/bT/HzacohGgevjUuxkmyQRzk8ETYzGxvOpc5Z/pUKXHwCR2MQVBx+mozZEcM1IqYfHhBmeUpMp02nzJf5KLlcFpIQkWvpYipJ+KCdumID7hbFq1nFP41Gg= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6948.namprd09.prod.outlook.com (2603:10b6:208:2a9::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Mon, 25 Oct 2021 18:53: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.4628.020; Mon, 25 Oct 2021 18:53:49 +0000 From: "Borchert, Oliver (Fed)" To: Keyur Patel , "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends 25/October/2021 Thread-Index: AQHXydGl/yea+j7xZUGElG+cGkVP3g== Date: Mon, 25 Oct 2021 18:53:48 +0000 Message-ID: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> 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: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e641058-a52b-4e81-f34d-08d997e8c7d6 x-ms-traffictypediagnostic: BLAPR09MB6948: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XUMZN6wvHNp87/8sRrkedrIztQdLQhYz8zFBAutgkB55HtkrQfqRrZmLtdDStKKiAdQePMHdlMMa1MuMQMtnWox4sTr77ractIoaTAp+Bu4NyB7vDEoJPewCj91LkBS4Jer8xfbKIH/v19VKKTnI1ynv442TG88VOdxuQVd+n3vW+I9VTqjvHQJwC+FFTBPAPD8xLZPUeiq1kYvam3k/dbLsB4x+5/mmgM/kec4KErsSzOtI6rA5N9+R77EFh2icW9zKEoR1niVOSm89/bZ87huCy83edVCAxZbFcPOqFwDMghN60r7pX9GrdmMUpWyMrQWwEm4tkWl59mHLAKo+j/OA2DCKO+r83OzAEKYYfI0f2lXmnOjJRF1D2dHXQO94/cwtxJgC0qa42KAbVRlctt50rhiZqKe6eir8mIAlfFFc7g5o59UnR/zeP0OzLSx4xdQnbs7cZHYt355keKeWlmNqqQf+4dyA3qHykptsf4f/JMX/mb2j/V4tAhEfwoR8OCDSZbA7r2AJdXhvPbAgW+rqReQFxorUHHhsLHnB1TTPGoLTkC9s93MbviFpdFeeMwHQgny6r/DSiSEX4ZbeNPH5wn4nlfIRChXg71AuE1NSGW/558W7mNfgF6im0H1nUsmGXZXCSPen5YTDboCQyUHO3Hh/giVTD2kWQs5MPs4eENLhxZK0mFQBpsmGUtUYg0kYszcwF+59e9F2x/2HyH1VwVQEd2azLVh7cwMP+TBV/9wh4jMjVtQ3JUmoKP4+t9TPb4wv7sTpLFIKTosMYnygPcokT+SP4S+tG/EMtCFSMzpukTtuwZU4hz3DMWsS 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)(2616005)(966005)(71200400001)(83380400001)(508600001)(40140700001)(166002)(8676002)(82960400001)(6486002)(107886003)(4326008)(36756003)(38070700005)(5660300002)(186003)(53546011)(6506007)(64756008)(4744005)(110136005)(66476007)(6512007)(316002)(66946007)(76116006)(86362001)(122000001)(66556008)(38100700002)(33656002)(66446008)(8936002)(2906002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RzdIa2JFNEtJL2MraGdwUXQrUlphMDljTUsrbVMwTWRUa1REK3l0VS9MNkFL?= =?utf-8?B?L1YxcmM1VllKQmpkSlZIL0tIUFRDSUVJOTZNbFFpZmRzUGlTU2ZsSTBIby9p?= =?utf-8?B?Mkx4YS9JOU9ZUG9tWXpXK1FUQnhia0pnb0N2c0UvekJKcG55ZVRxd1BKQ0Fx?= =?utf-8?B?VVhiZzI2dDhrVzRCUkF3M0M1dTJyYUdPaEJjL2t6TVR4NHVqbU92UEtmdmdK?= =?utf-8?B?dHBvdks1bDRkMTVnK3lZVFpqN21sblp6U0tsMTRHZ2sweWZ3MUtSWmtSVjNZ?= =?utf-8?B?Q2xxNEdHUHpobG0vblF2UkNJQ1A0UmVmL0t1NVhXM2l1OHpCdFhGeStZYlZo?= =?utf-8?B?NE5sMVdBUDJOYVkxUGFOR1FtOEgrQlRhSXR4V1AyNTNNZHZNVmVTbjl3aVhO?= =?utf-8?B?b3UwVkNhazVFVkpBTis2aElVbXQ0NkU3b2hRbDRrc2xNODJ0N1BlM3lRMEFa?= =?utf-8?B?N0JBZG5sKzJWanRvQm9rWnowYkRiaXk0OVJQaHlQclR6THBnS1p0aWRUdExX?= =?utf-8?B?QjJzVjNPdU1tQ1RNMkpXZm9UcHpCT2hwZDdIL2h3MXdrYmRQNEluMDQwNFFV?= =?utf-8?B?OVdEcGJSRTBEMmtKZTJTT3YzekxESG5QYlJxMUkrNFU5T0ROS2c3ZzJBeUE2?= =?utf-8?B?N3dyZ280OFlQYkNXeERZam8zYmN2RkRubmNHNkhTd2t1SW1qSURpdGNXUC9B?= =?utf-8?B?eHVlZU5mbTdHS2gvLzlrWms1aU1paGVaMjRHdzN4Z2ZsZUJabFZYV25TS0V4?= =?utf-8?B?Qk1mS2xrT1N5U0gxdHN4TG0xUVdXTXhUTjNORURpUW9xUUc2SUFTOW1NQjBh?= =?utf-8?B?a3V5aDdWcGNpRFhqS1B1TUxiWWJLdm9mZFZuWnBqM1p6RC9IWW9sV3I4ckpM?= =?utf-8?B?aS8veDhINlVGQ1EyaWMrb3pEczJVZXVSNTNQSDNLZVJBbkpZUDhRWDJKeWNv?= =?utf-8?B?UzJVSXRUQjdhVHRMUWwxWFVramVja3ovc2hqdXF6L3U5aHRSdkExd1VDQVAx?= =?utf-8?B?SitLSitkMUViTTgvN1ZrRi9TeWlXZHhtb2VhK1BheFI3S1F4ZVNBSW1zV1Vw?= =?utf-8?B?OURBODJYZnJQTW8vdjg0cW95cVZSSUNYR1BTbDE1ekpOaFltVEZDWjYzRjRV?= =?utf-8?B?TFJNSysyU01jOUxoSlo1VUdrZFMyNUVVSS9TUTNaYUtFL1RRZitZRkFDQzdX?= =?utf-8?B?R1NpTGNwaC91bHVsNCtqRGFWbTNxbXg3cjRHOEltVUM4UGF5RGtRSEJBNVFF?= =?utf-8?B?YlhwbXY5ZVBYQmVXY290ME5jQ3J6V2xFM2hiUlNvSFNwQjJQc1psSlhCcTVQ?= =?utf-8?B?OXVQblJKaTBzVWE3cy9MV05sMllsMzd1TTg4WUZFYzJTYXM5cnl3a3hvM2NG?= =?utf-8?B?N2pUa0hDYU5pYktVWVVzOXlsOFpWaVJQWWt4dlRuUVA0UTlKOXBIcXNYeHpx?= =?utf-8?B?SmtZTUJLU05UaEFYR2pLTG11dXdIU3dUUmVpZ3ZmZjF3UzhSWkpsMnlXbUZt?= =?utf-8?B?dE1rV2dMRER2RjN4UjQ1QUQrMW9EQU8wbGRIT0RqclJ1NlVINWRoSXp6OGdZ?= =?utf-8?B?cjd5YmQ0c3ptTHNsQWw1NXkxcmwwQnBuK1JjQXEwMkE5b1BvTmhCU2pFQWtV?= =?utf-8?B?SjdZaWp1bVV1a0hpY0tRN3VBNE1aaDF3NnVxS1FNc2RxUnBVTk55dllzNTA2?= =?utf-8?B?UENLNUg1RkorbUpwQ3pMeUFQN3BXSk9haTJ3Tkp5bS9KTWZnQWZ6NVhPMWE1?= =?utf-8?B?ZTZmbmNWWkdFenpvd1ZiMnFEcmZ3Z0Q0Q2lUMXJzMExjKzkrNDRldXhhUDQy?= =?utf-8?B?ekswcVFldXFsNUJUN1hOdz09?= Content-Type: multipart/alternative; boundary="_000_00E18520A5354CC8A28756FB2F164E14nistgov_" 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: 6e641058-a52b-4e81-f34d-08d997e8c7d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 18:53:48.9321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6948 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:54:45 -0000 --_000_00E18520A5354CC8A28756FB2F164E14nistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgdG8gbW92 ZSBvbiB0byB0aGUgbmV4dCBzdGVwLA0KDQpPbGl2ZXINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2Np ZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5DQoo T2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCihHVm9pY2UpICsxLjI0MC42NjguNDExNw0KDQoNCkZy b206IFNpZHJvcHMgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtleXVy IFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDExLCAyMDIx IGF0IDc6MjAgUE0NClRvOiAic2lkcm9wc0BpZXRmLm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbU2lkcm9wc10gW1dHTENdIGRyYWZ0LWlldGYtc2lkcm9wcy1ycGtpbWF4bGVuLTA4 IC0gZW5kcyAyNS9PY3RvYmVyLzIwMjENCg0KSGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBs YXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1h eGxlbi0wOCwg4oCcVGhlIFVzZSBvZiBNYXhsZW5ndGggaW4gdGhlIFJQS0nigJ0uIFBsZWFzZSBy ZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9u IE9jdG9iZXIgMjV0aCwgMjAyMS4NCg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1h eGxlbi0wODxodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOCZkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hl cnQlNDBuaXN0LmdvdiU3Q2VjOGU4YjE5ZmQ4MTRlOGU4NzZmMDhkOThkMGRhNzc1JTdDMmFiNWQ4 MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzY5NTkxMjA3MTk0MDk4MCU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPXNpd2FnaFpxeE5S NTgzNWtiWU9Ca2NWRWxBYlNtRHlGeVpDNndkMnl2eUUlM0QmcmVzZXJ2ZWQ9MD4uIEF1dGhvcnMs IHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuDQoNClJlZ2FyZHMsDQpOYXRoYWxp ZSwgQ2hyaXMgJiBLZXl1cg0KDQoNCg== --_000_00E18520A5354CC8A28756FB2F164E14nistgov_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJ Y29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5JIHJlYWQgdGhyb3VnaCB0 aGUgZHJhZnQgYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgdG8gbW92ZSBvbiB0byB0aGUgbmV4dCBz dGVwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3Vy aWVyO2NvbG9yOmJsYWNrIj5PbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPk5hdGlvbmFsIElu c3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oR1ZvaWNlKSAr MS4yNDAuNjY4LjQxMTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+U2lkcm9wcyAmbHQ7c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYg b2YgS2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i Pk1vbmRheSwgT2N0b2JlciAxMSwgMjAyMSBhdCA3OjIwIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVv dDtzaWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5bU2lkcm9wc10gW1dHTENdIGRyYWZ0LWlldGYtc2lkcm9wcy1ycGtpbWF4 bGVuLTA4IC0gZW5kcyAyNS9PY3RvYmVyLzIwMjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Y2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1 ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtc2lkcm9wcy1ycGtpbWF4bGVuLTA4LCDigJxUaGUgVXNlIG9m IE1heGxlbmd0aCBpbiB0aGUgUlBLSeKAnS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGgg eW91ciBjb21tZW50cy4gVGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPldHTEM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+d2lsbA0KIGVuZCBvbiBPY3RvYmVyIDI1PHN1cD50aDwvc3VwPiwgMjAyMS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0OjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2Nj MDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRh dGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtc2lkcm9wcy1ycGtp bWF4bGVuLTA4JmFtcDtkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3 Q2VjOGU4YjE5ZmQ4MTRlOGU4NzZmMDhkOThkMGRhNzc1JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2Uw NTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzY5NTkxMjA3MTk0MDk4MCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1zaXdhZ2hacXhOUjU4MzVrYllPQmtj VkVsQWJTbUR5RnlaQzZ3ZDJ5dnlFJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lkcm9wcy1ycGtpbWF4bGVuLTA4PC9h Pjwvc3Bhbj4uDQogQXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhlciB5b3Un cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5hdGhhbGllLCBDaHJpcyAmYW1wOyBLZXl1cjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_00E18520A5354CC8A28756FB2F164E14nistgov_-- From nobody Mon Oct 25 11:55:38 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5633B3A0809 for ; Mon, 25 Oct 2021 11:55:36 -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=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 yHhF_X-z86dR for ; Mon, 25 Oct 2021 11:55:30 -0700 (PDT) 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 E5A883A07AC for ; Mon, 25 Oct 2021 11:55:29 -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 DCC40E3; Mon, 25 Oct 2021 18:55:22 +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=1635188121; bh=PtDIfXUxUT8qbm2YIFTr5aSsZB13rwngstDLQMGnn0g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JadV38Q3vnZBnMnl8bfw/Y2HrMMeKYetynCLy7b+tUeMnKVI/ja0rvkCBL27W0egI Ot7cd7HVDdZ03W0QH3qtl8zvgnktHc3I3FxiUUnCrBkOYhj+WVH7CSDfqLxiHhIofQ QzVtekuzW0V9dXxxyPWmhDNnJwuzifm54e7+coWcYi8bysWtqrIQPha/QRO47U8d0l ECunw6Fx1a1R9bYLRZqqYj07vwIM0s0PymWPkZbUI6AwBlhXlekqG/Nqd6rqpgO/AZ EeyV4WXsVdmdv/CL7k/etaZFazeNRA5zCuJZXEk/zaPckxxoffSoWTb0JuvMNfZr7R dP3u3y3/quBVg== 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 In-Reply-To: Date: Mon, 25 Oct 2021 20:55:19 +0200 Cc: Ben Maddison , SIDR Operations WG , Claudio Jeker Content-Transfer-Encoding: quoted-printable Message-Id: <311C5F80-5BF8-41B0-92C5-C34DFE7B8731@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> To: Job Snijders Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:55:36 -0000 > On 25 Oct 2021, at 16:02, Job Snijders wrote: >=20 > On Mon, Oct 25, 2021 at 03:45:01PM +0200, Ben Maddison wrote: >>>> providerASSET ::=3D SEQUENCE (SIZE(1..MAX)) OF ProviderAS } >>>=20 >>> hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate = so-called >>> "transit-free" providers? >>>=20 >> Yes! For practical purposes, these are likely to be some of the most >> import objects that get issued. >=20 > Hmmm, I just now remembered the verification doc suggests to use 'AS = 0' > instead of 'empty': = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification= #section-6 >=20 > Using 'AS 0' permits one to publish a statement that one is > 'transit-free' in IPv6, but not in IPv4, or vice versa. >=20 > I'm not enthusiast about how 'AS 0' is more and more overloaded, > especially with negative trust anchors floating around. >=20 If I had to make a guess I would say that this was done to simplify the data structures in routers and/or RTR PDUs. But it's a guess.. My preference would be to go for explicit, rather than an overloaded AS 0. So an explicit empty SEQUENCE would work better for me. It also avoids the issue where one might find both AS0 and other provider ASNs. On the other hand it would no longer be possible to express = 'transit-free' in IPv6, but not in IPv4, or vice versa. I don't have a strong preference here... I think this should come from router implementers and network operators - what would be most intuitive to them? > Kind regards, >=20 > Job From nobody Mon Oct 25 13:49:46 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8313A0898 for ; Mon, 25 Oct 2021 13:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 RRey0_AY6iSu for ; Mon, 25 Oct 2021 13:49:40 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 925713A0DB9 for ; Mon, 25 Oct 2021 13:49:14 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id a26so1241408pfr.11 for ; Mon, 25 Oct 2021 13:49:14 -0700 (PDT) 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=F/FMFx1StYV3zR8UCS1ahK0HbmnfWsj+E4ykyEOvazc=; b=Q05hqJiH5bQOgmSq17PHBCYvZCEpOWXZJHdI2DcUC/wP/ZhqG3MN2flKkxAYsGE6Ig 60D26AL0sII+xLQqCprsQI9fiU1a1MsqCBjBE8EvYhwrr1rEPbUKZPbYP1OodtHzHPH+ 6J6kfu6j3RXHOkcYQdRmJeBXlsGHvRZrhFSKm9OCaZNxEfniuj1YwesUJRuofx3GBcXB PQId8zDpqIVcbZE8XXki83j4BgQMy2ZraZx2bNJkr7JNN1LpV5F6cQniRVJcu9Df8Rgm okTHsNxjWC7aS/Yywj6DsgpdyMCRpiHsJqhxcWS91bLFUuHwrJzcjGBEtQ6obMH/P1MC 6UEg== 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=F/FMFx1StYV3zR8UCS1ahK0HbmnfWsj+E4ykyEOvazc=; b=Z+FFTCqgPDbRbglKZ4Q3ZV00wGUxhboqxzJe6f/hNvh/PivKSdxOhQ7jEOmBty67Y7 SyJn9o+CEFbdr+RcpqBAZg+0Ah6dMTBGo2bStoWq5axJO6nB6ZiCaFB/9eB88850xr81 Cwn27p6Ywrdwc0/cXppkvV7cGNN/7+7F+bgORCEYeRhM5Z63eRevVl0jGxWuObpWGq7y IPDViOLyg8/6tC+UgDRogwMLyiVb5Ww0o9X5OkEcjHethzKmw7uR0+FVTNk/DdlHIfnv DZVA/KA9Pe3WOLI0nXGNXx0M5XI8xJidkrb5WCizYnhFOAFFzexA2FqBgSaxJQian4i4 31xQ== X-Gm-Message-State: AOAM530MJy/glfmQWJdvqHW0+17LjMbuTs9BSmXtcvYQCEGhIgNwRCD3 Bgi1sHRVG8Rrrndntgj/iqVnr0d/TBP4pdLUEVWJNyKzzVE= X-Google-Smtp-Source: ABdhPJwtgsq5SgWTWGVF9Qs+b8tKTLhnYwc4AOjTp1dHJeNehAXtNh9bo8b4jBlJbU2F7odLmfNR9S1F2GzCTJDXfLg= X-Received: by 2002:a05:6a00:984:b0:47b:f5b0:7226 with SMTP id u4-20020a056a00098400b0047bf5b07226mr6754372pfg.62.1635194952594; Mon, 25 Oct 2021 13:49:12 -0700 (PDT) MIME-Version: 1.0 References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> <311C5F80-5BF8-41B0-92C5-C34DFE7B8731@nlnetlabs.nl> In-Reply-To: <311C5F80-5BF8-41B0-92C5-C34DFE7B8731@nlnetlabs.nl> From: Alexander Azimov Date: Mon, 25 Oct 2021 23:49:01 +0300 Message-ID: To: Tim Bruijnzeels Cc: Job Snijders , SIDR Operations WG , Claudio Jeker , Ben Maddison Content-Type: multipart/alternative; boundary="00000000000049b74605cf337ef1" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 20:49:45 -0000 --00000000000049b74605cf337ef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, My reason for keeping ASPA0 was not about the technical side. It's about 'expected behavior'. We have ROA0, and developers and network engineers that got used to it and its semantics. ASPA0 has much in common here, and originally it even shared very similar text structures in its description. We can make it as EMPTY SEQUENCE, we will have a better structure but sacrifice 'expected behavior'. IMO we don't need an 'ideal' structure, we need an easily understandable structure, and a corresponding link to ROA0 will be helpful. PS: the combination of ASPA0 and other provider ASNs doesn't look like an issue for me. =D0=BF=D0=BD, 25 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 21:55, Tim Bruijnz= eels : > > > > On 25 Oct 2021, at 16:02, Job Snijders wrote: > > > > On Mon, Oct 25, 2021 at 03:45:01PM +0200, Ben Maddison wrote: > >>>> providerASSET ::=3D SEQUENCE (SIZE(1..MAX)) OF ProviderAS } > >>> > >>> hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomodate so-calle= d > >>> "transit-free" providers? > >>> > >> Yes! For practical purposes, these are likely to be some of the most > >> import objects that get issued. > > > > Hmmm, I just now remembered the verification doc suggests to use 'AS 0' > > instead of 'empty': > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verificatio= n#section-6 > > > > Using 'AS 0' permits one to publish a statement that one is > > 'transit-free' in IPv6, but not in IPv4, or vice versa. > > > > I'm not enthusiast about how 'AS 0' is more and more overloaded, > > especially with negative trust anchors floating around. > > > > If I had to make a guess I would say that this was done to simplify > the data structures in routers and/or RTR PDUs. But it's a guess.. > > My preference would be to go for explicit, rather than an overloaded > AS 0. So an explicit empty SEQUENCE would work better for me. It also > avoids the issue where one might find both AS0 and other provider ASNs. > On the other hand it would no longer be possible to express 'transit-free= ' > in IPv6, but not in IPv4, or vice versa. > > I don't have a strong preference here... I think this should come from > router implementers and network operators - what would be most intuitive > to them? > > > > > > > Kind regards, > > > > Job > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 Best regards, Alexander Azimov --00000000000049b74605cf337ef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

My reason for keeping ASPA0 was= not about the technical side. It's about 'expected behavior'.= =C2=A0
We have ROA0, and developers and network=C2=A0engineers th= at got used to it and its=C2=A0semantics.=C2=A0
ASPA0 has much in= common here, and originally it even shared very similar text structures in= its description.

We can make it as EMPTY SEQUENCE, we will have a b= etter structure=C2=A0but sacrifice 'expected behavior'.=C2=A0
=
IMO we don't need an 'ideal' structure, we need an easily = understandable structure,=C2=A0and a corresponding link to ROA0 will be hel= pful.

PS: the combination of ASPA0 and other p= rovider ASNs doesn't look like an issue for me.

=D0=BF=D0=BD, 25 = =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 21:55, Tim Bruijnzeels <tim@nlnetlabs.nl>:


> On 25 Oct 2021, at 16:02, Job Snijders <job@fastly.com> wrote:
>
> On Mon, Oct 25, 2021 at 03:45:01PM +0200, Ben Maddison wrote:
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0providerASSET=C2=A0 ::=3D SEQUEN= CE (SIZE(1..MAX)) OF ProviderAS }
>>>
>>> hmmm... shouldn't SIZE(1..MAX) be SIZE(0..MAX) to accomoda= te so-called
>>> "transit-free" providers?
>>>
>> Yes! For practical purposes, these are likely to be some of the mo= st
>> import objects that get issued.
>
> Hmmm, I just now remembered the verification doc suggests to use '= AS 0'
> instead of 'empty': https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-a= spa-verification#section-6
>
> Using 'AS 0' permits one to publish a statement that one is > 'transit-free' in IPv6, but not in IPv4, or vice versa.
>
> I'm not enthusiast about how 'AS 0' is more and more overl= oaded,
> especially with negative trust anchors floating around.
>

If I had to make a guess I would say that this was done to simplify
the data structures in routers and/or RTR PDUs. But it's a guess..

My preference would be to go for explicit, rather than an overloaded
AS 0. So an explicit empty SEQUENCE would work better for me. It also
avoids the issue where one might find both AS0 and other provider ASNs.
On the other hand it would no longer be possible to express 'transit-fr= ee'
in IPv6, but not in IPv4, or vice versa.

I don't have a strong preference here... I think this should come from<= br> router implementers and network operators - what would be most intuitive to them?





> Kind regards,
>
> Job

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


--
Best regards,
Alexander Azi= mov
--00000000000049b74605cf337ef1-- From nobody Mon Oct 25 14:42:02 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D318A3A0C92; Mon, 25 Oct 2021 14:42:00 -0700 (PDT) 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 umm94fCyCqyM; Mon, 25 Oct 2021 14:42:00 -0700 (PDT) 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 E13FA3A12BD; Mon, 25 Oct 2021 14:41:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mf7iT-0001QC-5P; Mon, 25 Oct 2021 21:41:13 +0000 Date: Mon, 25 Oct 2021 14:41:12 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: References: <163489282491.21742.16231692563458154079@ietfa.amsl.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:42:01 -0000 > Mono cultures have strong failure modes. Until a THIRD fetching > mechanism is defined (RRDP v2, or a flooding protocol like BGP?), speaking of mono-cultures and insanely tightly bound interdependence. randy From nobody Mon Oct 25 14:44:02 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9F93A0783; Mon, 25 Oct 2021 14:44:00 -0700 (PDT) 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 2ku-0T1EvUCP; Mon, 25 Oct 2021 14:43:57 -0700 (PDT) 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 BC0F13A040D; Mon, 25 Oct 2021 14:43:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mf7kz-0001QW-M1; Mon, 25 Oct 2021 21:43:49 +0000 Date: Mon, 25 Oct 2021 14:43:48 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: Ben Maddison , SIDR Operations WG , Claudio Jeker , Tim Bruijnzeels In-Reply-To: References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> 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: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:44:00 -0000 > I'm not enthusiast about how 'AS 0' is more and more overloaded, > especially with negative trust anchors floating around. indeed. using a special value as a sentinel also has an interesting history. randy From nobody Mon Oct 25 14:45:16 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C126D3A1051 for ; Mon, 25 Oct 2021 14:45:07 -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 (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 M6-hL0zpdXp5 for ; Mon, 25 Oct 2021 14:45:03 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 719B73A0E61 for ; Mon, 25 Oct 2021 14:44:58 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id r12so5323521edt.6 for ; Mon, 25 Oct 2021 14:44:58 -0700 (PDT) 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=7V4wLxEZJaq60HjLqUWbnUt594cFIwz5uX/gVhfA78U=; b=H6LLVHd1BFmpOr8rIs8ns0gIqLCyNb/AIJgZF5h3mB55Lt1kHR+jDUYKhXWFjkTsI0 QOZdhdzwoYL5dvepfXxP4DYlDeXgJFY4CBij/ftgq39mnVj88v3L1/jEAYn8RNIg9h4K Aqkj69FfuXWpXgQUcLJIOmSrUwSjMfrTHcJ9w= 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=7V4wLxEZJaq60HjLqUWbnUt594cFIwz5uX/gVhfA78U=; b=cJy4ctNy27zRlgTMc2E1Uxb2jKXbq1jMTUr9uaQ9p7GdZXjfqQh8iJZlMZWTFegAkJ CU760cekeGVTPXm1uX7oPBC2QQiYzLGe4NdM9Fob4xqk8xc6l1aSRprJlxm8SFJ+H+S8 9YkuLZ1Sat/gUzK0tr514URxMMajcXj+jUP/L1ta/gRMmwmmA55ZNo3AULhQQGzFuFy/ Vk8CGklYLGh9KvQgjWE/K4mgLurOLZihFcpEChgkyUXPU7VQQm6FAL5WdCrkEqQ//dHX TdwA07mVp2b/z5VSS3vMCKdLzUs+OKqADT9ZwUzsFQjICfvN+S+3hYIRFW4pQO277Ik6 fNWw== X-Gm-Message-State: AOAM530H6hJlLVZzmT8iLrpIDk/XlRCggpx2BR+ZyY9gFRGAiKjRAbsE SUsfM5KLo4SyLFZ6JI0rT9lCmgBv8RNCmfiR X-Google-Smtp-Source: ABdhPJzjTas8pmg9/urIQeI4yWou9sUJuoFf6R3vs7IwkmYDkqa24Z/2ThJ8h8s0OutLLjOWQl9Mbg== X-Received: by 2002:a05:6402:190f:: with SMTP id e15mr30648918edz.310.1635198295380; Mon, 25 Oct 2021 14:44:55 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id p23sm10200195edw.94.2021.10.25.14.44.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 14:44:55 -0700 (PDT) Date: Mon, 25 Oct 2021 23:44:53 +0200 From: Job Snijders To: Randy Bush Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:45:15 -0000 On Mon, Oct 25, 2021 at 02:41:12PM -0700, Randy Bush wrote: > > Mono cultures have strong failure modes. Until a THIRD fetching > > mechanism is defined (RRDP v2, or a flooding protocol like BGP?), > > speaking of mono-cultures and insanely tightly bound interdependence. Yes, I appreciate you waving a warning flag here and do not ignore it. What about a separate flooding mesh, in spirit of MSDP? Kind regards, Job From nobody Mon Oct 25 14:47:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E9D3A0E7B for ; Mon, 25 Oct 2021 14:47:34 -0700 (PDT) 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 WTQRwATJc1cs for ; Mon, 25 Oct 2021 14:47:31 -0700 (PDT) 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 40FA43A0E1A for ; Mon, 25 Oct 2021 14:47:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mf7oU-0001Rz-37; Mon, 25 Oct 2021 21:47:26 +0000 Date: Mon, 25 Oct 2021 14:47:25 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: References: <163489282491.21742.16231692563458154079@ietfa.amsl.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:47:41 -0000 >>> Mono cultures have strong failure modes. Until a THIRD fetching >>> mechanism is defined (RRDP v2, or a flooding protocol like BGP?), >> speaking of mono-cultures and insanely tightly bound interdependence. > Yes, I appreciate you waving a warning flag here and do not ignore it. > What about a separate flooding mesh, in spirit of MSDP? if we need three solutions to a problem that it is not clear that we have, the mind boggles at how many we would need for a real problem. :) randy From nobody Mon Oct 25 14:48:59 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175C03A0E95 for ; Mon, 25 Oct 2021 14:48:51 -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 (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 VlQdABA2aMUM for ; Mon, 25 Oct 2021 14:48:46 -0700 (PDT) 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 D04353A10EB for ; Mon, 25 Oct 2021 14:48:32 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id s1so4900785edd.3 for ; Mon, 25 Oct 2021 14:48:32 -0700 (PDT) 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=2KT1xgxBnihNloHO3cWIgfYuLWUR5X+ok/QgqxI3n9k=; b=YbDd7V0Mzs1DsLpe6ecGLGzu3msgS0G2A6f9cqmvFaBU7hB9JatPwLWAxCjVZ4uLw6 WofD2Kzggqze4s3uEdWh5r3luDA717ldE5XXhfktpCGfmVTI1w4J1E6wSnREABfV5OVf T2tNjd/rr/czAuUYBsU9n12/hck3jO45nnkn0= 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=2KT1xgxBnihNloHO3cWIgfYuLWUR5X+ok/QgqxI3n9k=; b=eqWNl8DW3Ng7+Ooo6tZNyorkORTB6LaDJdnG0ITuoES2lcIj5HrmHLRzxHgw4ZvjuD 4aH/1FHOWZKgfZg2CENHiZIL4afQ7g+9yGZP/8WCCsiihr44UIWHgThdNtrY/EiyJlZA an1VgDYMD6uhbEg547TiXQrpCcCz+FTmJPUj1fdr/YNSrBX47x3hl8NJx4B/O/N+Wken fypYHvG6xys0EqYAdU+17xZiFnukjV+nWqkPdRs+huazp20oQmCqYmv7GobMZ1pnXe9c Rm1Kl8e16Vk5MgIZ9t+tZxB0OVlynl6BwbMTieHlraIehogSOW1mZwyBHwtvZbHPqNK+ dBxw== X-Gm-Message-State: AOAM530D6PtDlLBFiC5II/2J5Tv2pk/nNFjxjb0pfKKhamWhzaWWV5T7 OH8JyNdHxzY790bD8dNH4hDsN4K6igVrJ76P X-Google-Smtp-Source: ABdhPJxqbhHej99Ag9X3ZmpHYYg13YMrZEclDz1MQtBzYAc52D4iA2V8MEO1NBRcHuboe34J1rxS2Q== X-Received: by 2002:a17:906:d0c9:: with SMTP id bq9mr26123392ejb.410.1635198510781; Mon, 25 Oct 2021 14:48:30 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id u14sm9810701edj.74.2021.10.25.14.48.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 14:48:30 -0700 (PDT) Date: Mon, 25 Oct 2021 23:48:28 +0200 From: Job Snijders To: Randy Bush Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:48:58 -0000 On Mon, Oct 25, 2021 at 02:47:25PM -0700, Randy Bush wrote: > >>> Mono cultures have strong failure modes. Until a THIRD fetching > >>> mechanism is defined (RRDP v2, or a flooding protocol like BGP?), > >> speaking of mono-cultures and insanely tightly bound interdependence. > > Yes, I appreciate you waving a warning flag here and do not ignore it. > > What about a separate flooding mesh, in spirit of MSDP? > > if we need three solutions to a problem that it is not clear that we > have, the mind boggles at how many we would need for a real problem. :) I'm arguing that three solutions need to exist, before one of those three can be deprecated. Kind regards, Job From nobody Mon Oct 25 14:54:30 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D48A3A0E89 for ; Mon, 25 Oct 2021 14:54:19 -0700 (PDT) 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 IniEr7IPxwpj for ; Mon, 25 Oct 2021 14:54:18 -0700 (PDT) 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 964C93A1658 for ; Mon, 25 Oct 2021 14:52:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mf7tI-0001Tz-N5; Mon, 25 Oct 2021 21:52:25 +0000 Date: Mon, 25 Oct 2021 14:52:24 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: References: <163489282491.21742.16231692563458154079@ietfa.amsl.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:54:19 -0000 >>>>> Mono cultures have strong failure modes. Until a THIRD fetching >>>>> mechanism is defined (RRDP v2, or a flooding protocol like BGP?), >>>> speaking of mono-cultures and insanely tightly bound interdependence. >>> Yes, I appreciate you waving a warning flag here and do not ignore it. >>> What about a separate flooding mesh, in spirit of MSDP? >> if we need three solutions to a problem that it is not clear that we >> have, the mind boggles at how many we would need for a real problem. :) > I'm arguing that three solutions need to exist, before one of those > three can be deprecated. and why not two or five? i.e. what is the logical argument here? btw, i agree that today's rrdp is weakly specified and often poorly implemented. but this does not make me want to rush to an Nth weakly specified and poorly implemented protocol. randy From nobody Mon Oct 25 15:02:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02BA3A11AF for ; Mon, 25 Oct 2021 15:02:39 -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 (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 I6wh3WtrrP9N for ; Mon, 25 Oct 2021 15:02:35 -0700 (PDT) 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 7B78F3A1117 for ; Mon, 25 Oct 2021 15:02:19 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id s1so5015344edd.3 for ; Mon, 25 Oct 2021 15:02:19 -0700 (PDT) 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=4EbhLhONVPZTrVzVv65Z/RDeZlwKbyFNL+iAiOfMVNU=; b=H/sdeYYKGcoOauoRyc298NG0rGBCke9GriG1s/pGjiPdMJmip+UrBfk1/YasyXq310 D+RShH/OKPMgmVPBJ12JhUd3t/CbT1Duav4pQspzLKDWbxFW6LWqzooAj+tBTvZhbMOU gAvu1AFzLcEHeAZEKwjLJ/VFOjACcdacLBh7g= 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=4EbhLhONVPZTrVzVv65Z/RDeZlwKbyFNL+iAiOfMVNU=; b=coEIAKnjSNibZFiJwBGsIsxitDsAzAk4VXeOAVTFkamfQZ+TIFMJsIFLYSGFyHwjNQ KRximky6q0Cywew8czDWN+NntRd7iYFf/jwoHIWzmAY4lzHNG1Tj6MPEG1bKZZOV/Ieu QdP8W5/kw+7LCvu/dJZgd8sXYN1MxflFTWqxfwn2Fs/exUktrKAUdQTIvXI2/OsGlmxj ++UjkB+fJe5RSgPVg6cUub0jcIAs/7RCJLClQEdGko7intg7zMV6U/Gsh3OCxe5cflKf /VHfs7mKKAIx/VgikvxYiyoKHQYbAXYysGPzPiSXNirvZ9c7M+N4+umNf9JZMrl07XhP epAg== X-Gm-Message-State: AOAM530cz2m+H4vxYZdkHKqR7tHEABDVkIC/qSzM9c7C8sUS1bdd5pqk Jh7zxxs1WtEwB0KBvvW/8y9hNzmkhRs7Yw== X-Google-Smtp-Source: ABdhPJxFrT4NS3qK/W9v6xlEPrOIB2fogQt3PeB1oPJVa7QVLl10r3j97X0t5xUkQl/TGwHWQBiVRw== X-Received: by 2002:aa7:c694:: with SMTP id n20mr4234008edq.31.1635199332932; Mon, 25 Oct 2021 15:02:12 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id f17sm1869068ejd.18.2021.10.25.15.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 15:02:12 -0700 (PDT) Date: Tue, 26 Oct 2021 00:02:11 +0200 From: Job Snijders To: Randy Bush Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 22:02:46 -0000 On Mon, Oct 25, 2021 at 02:52:24PM -0700, Randy Bush wrote: > > I'm arguing that three solutions need to exist, before one of those > > three can be deprecated. > > and why not two or five? i.e. what is the logical argument here? I argue the ecosystem needs at least two transports. Multiple transportation options hopefully increases overall availability and reliablity. > btw, i agree that today's rrdp is weakly specified and often poorly > implemented. Then why prefer it? Kind regards, Job From nobody Mon Oct 25 20:21:11 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CDC3A0CCF for ; Mon, 25 Oct 2021 20:21:09 -0700 (PDT) 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 0aowDJI3ckZ6 for ; Mon, 25 Oct 2021 20:21:06 -0700 (PDT) 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 940C73A0CA9 for ; Mon, 25 Oct 2021 20:21:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mfD1L-0002S4-MZ; Tue, 26 Oct 2021 03:21:03 +0000 Date: Mon, 25 Oct 2021 20:21:03 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: SIDR Operations WG In-Reply-To: References: <163489282491.21742.16231692563458154079@ietfa.amsl.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 03:21:09 -0000 >>> I'm arguing that three solutions need to exist, before one of those >>> three can be deprecated. >> and why not two or five? i.e. what is the logical argument here? > I argue the ecosystem needs at least two transports. which it has > Multiple transportation options hopefully increases overall > availability and reliablity. so a dozen would be lovely? where is the trade-off curve? and how many will be mti? perhaps this path is a bit of a mess. >> btw, i agree that today's rrdp is weakly specified and often poorly >> implemented. > Then why prefer it? social compromise. rand From nobody Tue Oct 26 00:13:18 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A513A11D6 for ; Tue, 26 Oct 2021 00:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 s0zOSAwOF_Lu for ; Tue, 26 Oct 2021 00:13:05 -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 0624A3A11C4 for ; Tue, 26 Oct 2021 00:13:04 -0700 (PDT) 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=aHmqJd5F/h59vXDSeciw0ZzAwaF6/3I7DEXAqdonvmA=; b=q15JT6OHUXc3GHOQLi6JJog3 U/OWAJ1t9TJSjZiDFuFnBvQ1g+039L/PN0/k9jxWDtguhgaU+oImLKqwj52N1rDc88eIXU/gf23xs 9GbCKrxdSkUPQZww2rtu7dec1gG+0FemUmQVG4t1aWGtfYRy8vsRXphH1u5jMwj0wDGF3D2dpaqhv /OhZiryPgYJpJAPZy6BGjf2sKrlxDpHb3oP1MFyRZ0kyFyFkSN4+HctqlvZYJi2f7Q7saHpVFgCQs vsmIcPHUNrICWR/9bkn5oRcpwaXg8yMpL2pNXXWfJFJKpScTLfLNgbBorSNKlIa1vyWTEa8ox9B1K FOVX4BLwVA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:48404) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mfGdq-0003cB-H6; Tue, 26 Oct 2021 09:13:02 +0200 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 ) id 1mfGdq-0001rF-D6; Tue, 26 Oct 2021 09:13:02 +0200 From: Ties de Kock Message-Id: <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6162ADAB-E906-4B48-AA24-18AD00A98838" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 26 Oct 2021 09:13:02 +0200 In-Reply-To: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> Cc: Keyur Patel , "Borchert, Oliver (Fed)" To: "sidrops@ietf.org" References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e17b74646b79a698c7a67ba624a088d10b Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 07:13:15 -0000 --Apple-Mail=_6162ADAB-E906-4B48-AA24-18AD00A98838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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) = wrote: >=20 > =20 > I read through the draft and believe it is ready to move on to the = next step, > =20 > Oliver > =20 > ----------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Office) +1.301.975.4856 > (GVoice) +1.240.668.4117 > =20 > =20 > From: Sidrops > on behalf of Keyur Patel = > > Date: Monday, October 11, 2021 at 7:20 PM > To: "sidrops@ietf.org " > > Subject: [Sidrops] [WGLC] draft-ietf-sidrops-rpkimaxlen-08 - ends = 25/October/2021 > =20 > Hi Folks: > =20 > A working group last call has been requested for = draft-ietf-sidrops-rpkimaxlen-08, =E2=80=9CThe Use of Maxlength in the = RPKI=E2=80=9D. Please reply to the list with your comments. The WGLC = will end on October 25th, 2021. > =20 > The draft can be found at: = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-08 = . Authors, please reply indicating whether you're aware of any = relevant IPR that hasn't been disclosed. > =20 > Regards, > Nathalie, Chris & Keyur > =20 > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_6162ADAB-E906-4B48-AA24-18AD00A98838 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 = RPKI=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-rpkima= xlen-08. 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

= --Apple-Mail=_6162ADAB-E906-4B48-AA24-18AD00A98838-- From nobody Tue Oct 26 02:10:25 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F93A1330 for ; Tue, 26 Oct 2021 02:10:23 -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, 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 DDX1z0N2vZS5 for ; Tue, 26 Oct 2021 02:10:18 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (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 2D2EF3A132E for ; Tue, 26 Oct 2021 02:10:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bu5U3R0H0ImPc0lbq6UgX7FyUkJ/ReTBiL6ResEEnUW9XahXJT4yJV9a5alDqh0yrBNLgF3Q2xJ6fllxnzXUb56s2LX7WZXymt86S+GOql1FQBgfljHQbfJ27Zu3Cx2mJjsBs4RmckTQ+ZiISFOzI7EgJV4sv0TDyO5E/g81g5LiWE/WDLG3WaokrnpsFNfMMzSStn5kgg+mOyCimTqEQapFtwtCY2IYB3vXkbRFVrUU7PK8Vao0T2hlM0rKf0Og0gv2u4mfA4zNnQWwnlYT+Y3lQlJP/pLQk7l53wRnB0DRtsRn0rMZUcdR634A/JMUIlsPVEI4+fab9A331kqPKA== 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=iu9EhRRNyvi7mKlC2slnc7PV1TL4PF6o4N0yfU60YL8=; b=GuW5eDxmzbdfjB01OI8RElk+BRayF9quZzPu433vrY1n0siS0cilqBoaD/XPO3mRVtnZDhOijCxoQ6UjA61KsokLaNzSEAE/mMDlJYEM/Q9qr2dTVmU6NVFykAdYRaieu2sosS3QPvOk4bqjx9RjORXWzUkRWO0+9Gd8GtkghrtfhkoxTcEJhRThoSpJ4AQl9yslcMYliAMUF226wYV6LDJL7aLmcQco0qTJcZF59atvedSgxoCl9XxoE/skrftK0WAvwL4J2gebj7QT9G0/U2OKGbYnmwK5CHVnCUT2tBwjvyK/WXfdYXF0ureAUaIfTOZKY1zW9dfpFlv5CC54tQ== 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=iu9EhRRNyvi7mKlC2slnc7PV1TL4PF6o4N0yfU60YL8=; b=crHNSQTb+p+xAy7uZgXDToUtheAK0MWVisFg5TrvqWrMI09Nnd5VkbuLD9m3HYLJA9enCsgK3kGw2nlDnOiQj0AglZ9OJNg6XikC+k6jcSR+6l/Up0Q2tpRqmQIsCNaz0U8uubqprHpAOi3dLCmafzdLUl4Cxm9f1LP4nfFDeso= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=workonline.africa; Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) by AM0P190MB0642.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:197::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.13; Tue, 26 Oct 2021 09:10:13 +0000 Received: from AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676]) by AM9P190MB1073.EURP190.PROD.OUTLOOK.COM ([fe80::8948:148:462b:5676%7]) with mapi id 15.20.4628.020; Tue, 26 Oct 2021 09:10:13 +0000 Date: Tue, 26 Oct 2021 11:10:06 +0200 From: Ben Maddison To: Alexander Azimov Cc: Tim Bruijnzeels , Job Snijders , SIDR Operations WG , Claudio Jeker Message-ID: <20211026091006.rbdm5jwq2w2leul5@benm-laptop> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> <311C5F80-5BF8-41B0-92C5-C34DFE7B8731@nlnetlabs.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n2wczdps3e76taoj" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CT2P275CA0034.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::22) To AM9P190MB1073.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::22) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CT2P275CA0034.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16 via Frontend Transport; Tue, 26 Oct 2021 09:10:12 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 84105a4b-999c-41e3-d4ec-08d998606ad8 X-MS-TrafficTypeDiagnostic: AM0P190MB0642: X-Microsoft-Antispam-PRVS: 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: ChwWcpF95XNlwrpnyZK4bnXv8C8e3ybUZAoz6gM63DlvgW7ZyT64Mq78St/t2sWdDbwrHwLk8uKyAT1AjOwRWNgNmbXuTaEL0Q7c+FsgnXoSRtGG+Ouu+EQ4e6aHTKw6aeycopr9tykOBESJCBheuezI2AqrfFrDy/gExtZRFS66thP6YvQ1AXUTl81zUmkOHpBgAZipKKL57efibB7+gnoiu9cBMp2n0rWfS6NMo4b4ev7AOujpzvPM6NRc/xGQQxlFc4SG9DmY63W8gWqkSCjh6ll1Hx5hrOCEGlrCXfZ+VYuJCZQXqPy7dp/iBgPOGNZ4PsAfTZQQYvu7dz3zymJ2Em4ierX/SY+Hl650gxrQbJpI6XPhzwc/bAADC16vTkm2FpU3kN1Nk3U1X4NSuFu1tcEF7PGBQBronAQvJL4H8ztidAbgGaMD0/xgp9qpQj7juoLT8UT5vSVqWMWqufv5QlMLAVfJq3gU0BGPl/85xN7H4dv9f3mh8FBrOeaYnQsXr1WQRxwVaPgPVuANmpAo7RCza5m54YA1cya9+xl5FjRiFakX19U2luopg7Rc879jgjk2oT0dYgET3y7pniz+aiazCOsx3ic3Wiq6+N/Kz8FRvCaKYshlBUfDEkcN54i0+XKSR1OneRZRRtWCoEJGDYgFz9hnD5kDdbUvcinKFsCoYchM/gO79+2EOdjPX/sqYUomtq186F0FFo05u02LmAHreEkiA4m41517bps9NVlVVfhiEjud2Cxqk87Z X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P190MB1073.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(376002)(39840400004)(136003)(396003)(366004)(346002)(4326008)(316002)(2906002)(6486002)(5660300002)(186003)(508600001)(33716001)(8676002)(33964004)(6496006)(44144004)(956004)(52116002)(1076003)(21480400003)(6916009)(6666004)(66476007)(66556008)(9686003)(66946007)(26005)(54906003)(8936002)(38100700002)(38350700002)(86362001)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a0xzRkN3VERUY0ZWQjlEQ2lEbDVCTm04ajhmeTFyU1VXWUg5b2pqRGREV09a?= =?utf-8?B?UmpvU2lLNHk4dVg0VmlBeTBXOFJHYkozOE9kT2YzUWpzTjdUNlo2WmVFY3dX?= =?utf-8?B?NVZpN1FjMWpCTDdUdE43Z3U1OE95bzc5OVQwMW5JQ1ZTaVdEQXkyeUpSZ2t2?= =?utf-8?B?RjNqb3AwNWRld1dtZDFCb1VTR2ZJc2lTOGFQZk5GQ2tKaFRsZDQ5YjljZURB?= =?utf-8?B?OXNJMk5aN2l6aUJ0OWhQVmtOZ0VxTllWalFLSS9YdDhoU1JQS2p5SjNuR1ds?= =?utf-8?B?Z05XU1lkZlZZR25rOFlsTWQ0Tk5Da2hUbisrZFNSOHM2K2s5dGM0ZFUvOG1w?= =?utf-8?B?L3VyNTRtSXM5Q2RxM1BrOTd1OVREeTFQNk91WG1wRXhJeC83K2h1cml1eEJy?= =?utf-8?B?TWxpTHJKOU0rSUJ0K0pocjhIU0U5MUtzUDBwOWVnWk1xYWpBQVBuYXpiNWc5?= =?utf-8?B?VzVDZTlZU29JaVozU2xzTHpsY2NpalJOUEZvSG1Iak00WWFTUVFJVHJubjVE?= =?utf-8?B?SGJqV2lsd3ZZUkljRDMvN2ltMERBT2ZGZ0pPd05JRDVvNW9QWHpMaHl5OHZB?= =?utf-8?B?cnFIcDZzMmk5MFBKOXViUzBQeCtUVlJzYUY0T3R0MkJ4TVdQQmJ6azZHby8r?= =?utf-8?B?eHdiN2Qzbjc5d0ZsMzBZcDhiSWUzY0ZIZ2dNZ1FEMHlyYkxka01yeHdsKzR4?= =?utf-8?B?dDlHK1FGN3pBaU84MzRpRE5VRWZMTWJMQW5QS25iYXlhaDNpQ2lNZGRlYTFl?= =?utf-8?B?cGx5TnhXWmZPV2huTjVSdVVkWVZ2VmZvdk9nVVhZUFY5dlpYMkVwREJhbUJv?= =?utf-8?B?Wk52QVM4eXFLMXVndksxNWROVkJWR1RIRHRGOGVTL0lmWjBObjNIMnBlTDhp?= =?utf-8?B?cWpZcjUyZGt3Yk1hZ0pnNFA1VC9FZndvSlZHV01MblQxTnNUYzhIZERFN0pl?= =?utf-8?B?Nksrclc1UytEZUUzUTNDaW14RjhyTUEzbHE0eThwaDhQTU4yV0h5Rk1mMkt3?= =?utf-8?B?dm5OSjlsUjQ3UTFvSmk5eXUrdU5qT1hKM0F3dmJFV0xVWUdBbTJRS3BVajIw?= =?utf-8?B?UjBoc1cwN2RpcHk0SzVTUTZlV0hqL1lTb0ovM1ZDeXJXUVI3dG0yaENEZTJh?= =?utf-8?B?NGVlQ1puQ2l2Ymh2NVFTTjhUNDFDa3IwVGhHYVk1bFVEUXBwbjFobVdydGRl?= =?utf-8?B?WE4xVFBZZmk4SndCUVhLNmxya2FNTlF1Z2VPc3Y5N0YrMGVRSTEvcWYzd2dz?= =?utf-8?B?a1N2Mll4UWhMYjFEZmIyaVZUYnc5bGxiYWQzV1ZVUTdLS0xCMzBDYlNkRnJN?= =?utf-8?B?QXo0c1RTc1JSYjM1QlJudGVQKzZMVnZvWVN0TS9RTTdyV0R0eTg4cGE5alRT?= =?utf-8?B?NTY5T2oyaW10bkZmT0FIQndIcUkvZ1hPZHB3UDJ6RFNLZys5Qjk1WWdlTTM0?= =?utf-8?B?OUdybkw5cytNenErd0R3TGtSNGtpR29Xck1KTjFaWjc1VXNKRm45R0hpallR?= =?utf-8?B?TjBBSTZPWDFORGJHUzlCYXBXUFpSb3NvSTBZYjFET3FqTjVKelpnUk5VbGEw?= =?utf-8?B?UUdxdEMveXhySGVnUC9qYVplaUtvTzBvOFpqNndKdTR3OUVXY2hhR095emY1?= =?utf-8?B?aXE5dnZreFVZNi9KTjBTUGF0SDlMQ25Kam9tSkFFb1AvckpLa1dqTlFvVWVu?= =?utf-8?B?d0JBK1ptYVVOTHMxUEc0SVRXR0dWeCtGSU1EdnR1UHB4NjFjdVlhQ1VqY1Bl?= =?utf-8?B?TXlIZFZiWGFVU2syWnAvTVg2bnZadXBIVG1Wems0by9taUo1ckFNLzhnT000?= =?utf-8?B?ckpXbk54TCtjMGJZSDVINjg3dHo5QlhaejRtZ2xSK0RDb1VZdFJETlZPUnUz?= =?utf-8?B?dEc4UVdkVUhITGQrczkrUVF2eUtIQ2pCcktPUWFqbUFrUm41NENwaFlUOUV0?= =?utf-8?B?TDhIT2VRcXpSSlFwbnlVdHVjbjB0eVBJcmpDZHJDWlNya1E3OHJzd01ndW1D?= =?utf-8?B?d3JmRUZvTS94L3BJc2d0QXZHejNGZkMyVWVqK3ZHMENtT2E2NGJDV1g0TVBT?= =?utf-8?B?Y0RHa0tNYlUrcStnM0FrT0x3QVdpZVZESDd1MFVGNElRSURGWGJYMWdxUnQ3?= =?utf-8?B?STZ0ckl3S3ZJVnJjekhRbVRzbVl0SzVQYzNPSjgrTHBtK0dhYTlHR2liN1lF?= =?utf-8?Q?D1R05Ser7wRvWYZvnJ3TOJU=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 84105a4b-999c-41e3-d4ec-08d998606ad8 X-MS-Exchange-CrossTenant-AuthSource: AM9P190MB1073.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2021 09:10:12.9669 (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: DL93E5lw7QF8nTZTAiImdYpxnhcpWVPhVXC4grzhYgvlEq7pRNCn4YCu1FbcrFUOb4FHpPPtQoYBCeGRdf3xIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0642 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 09:10:24 -0000 --n2wczdps3e76taoj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, Tim, On 10/25, Alexander Azimov wrote: > Hi all, >=20 > My reason for keeping ASPA0 was not about the technical side. It's about > 'expected behavior'. > We have ROA0, and developers and network engineers that got used to it and > its semantics. > ASPA0 has much in common here, and originally it even shared very similar > text structures in its description. >=20 > We can make it as EMPTY SEQUENCE, we will have a better structure but > sacrifice 'expected behavior'. > IMO we don't need an 'ideal' structure, we need an easily understandable > structure, and a corresponding link to ROA0 will be helpful. >=20 I understand the inclination to re-use the ROA semantics, but I think that an empty SEQUENCE OF is preferable in this situation. Intuitively, I'd say that the most natural way to assert that a set is empty is to create a signature over an empty set. This is different to the ROA case in a couple of respects: - ASId is an INTEGER type, which doesn't have a natural null-variant. The only way to introduce this would have been to make it OPTIONAL, which I would find confusing. A SEQUENCE OF on the other hand has a natural empty (and non-null) variant. - The semantics of the set {0, 65000} seem weird (and possibly contradictory). We don't run into this with ASId, since it's a primitive type. > =D0=BF=D0=BD, 25 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 21:55, Tim Bruij= nzeels : >=20 > > > > My preference would be to go for explicit, rather than an overloaded > > AS 0. So an explicit empty SEQUENCE would work better for me. It also > > avoids the issue where one might find both AS0 and other provider ASNs. Agreed. > > On the other hand it would no longer be possible to express 'transit-fr= ee' > > in IPv6, but not in IPv4, or vice versa. I don't follow. Surely { (65000, ipv4), (65001, ipv4) } means transit free in ipv6 but not in ipv4? Cheers, Ben --n2wczdps3e76taoj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmF3xe0ACgkQOkYk/rSL aGDtew/8C7TfsNs7QcOj7uRwg0WmV4IClmqB/4gH25wBiktXpi83nr0QVFEAFd5e LLmGfjr4FTQFcwtrWhSusVr3Rxd0GxzteJPMBv0Uu+9wE8Q6PCKv15T32+0s/3vI cE7C1MpJ03K+8SgJ+Z9yG6uhhVnA1sGfxvsgb2B5cWcV0r3a/0Pg4F6MhtCY9qEB I6tu+ISiLf2sLAQZUNGxszQ89rUkKg3rDWnEmWt6l4vRp4XPkAu59iLls3uo3/02 cdrbbWSMygGQ1rAxLTLfzSxCFKfNtwb9PV810dfkILvB0vYn6CQSd3EFABGpph2a ghdewRf1W0BU0uhTV0DFf21zfquXKEJ2edmHOrxOWLybUCk4y6RNB3yf/gjwrXLt UU05Bsq/G1E7JSqI2sDx2QWZfmbMWGvkemEUpXNmGMG55/1Q3ysRIcB2UUO3w/Os Q6aVOskvfia13eTh870/cTZlROiQ4RjxfE4Zm0qYKxbImaAaz3iDN2dXMbPgU+uf j6Sy3fGK89pJwnR9sth2EVWr/JtzhmWixhobqH8rnqGQReLEl8wCROLSMkly06Xq Ex9YtSJs+Tth5XlVLBJg1keHnwFCSrRFqZ/o79CDGmMCt1z5OE7NwkZYbgF9qGBK 5rn2pncviQKjTFEapk8UDIjKMwBrNxfUIe4DkXQCPVZf4Uh0/X4= =92g/ -----END PGP SIGNATURE----- --n2wczdps3e76taoj-- From nobody Tue Oct 26 02:43:36 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9893C3A0691 for ; Tue, 26 Oct 2021 02:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 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 1lxMVXoCWKv4 for ; Tue, 26 Oct 2021 02:43:30 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9203A060D for ; Tue, 26 Oct 2021 02:43:28 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19Q9hMW9009100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2021 10:43:22 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Ties de Kock Cc: "sidrops@ietf.org" References: <00E18520-A535-4CC8-A287-56FB2F164E14@nist.gov> <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> From: Nick Hilliard Message-ID: Date: Tue, 26 Oct 2021 10:43:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.51 MIME-Version: 1.0 In-Reply-To: <5B2CD457-E376-4B8C-B901-202ACC4C465C@ripe.net> Content-Type: multipart/alternative; boundary="------------7930442194BB4494BB08EC66" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 09:43:36 -0000 This is a multi-part message in MIME format. --------------7930442194BB4494BB08EC66 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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) >> > > 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 > > on behalf of Keyur Patel >> > >> *Date:*Monday, October 11, 2021 at 7:20 PM >> *To:*"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, “The Use of Maxlength in the RPKI”. >> Please reply to the list with your comments. TheWGLCwill end on >> October 25^th , 2021. >> The draft can be found >> at:https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpkimaxlen-08 >> . >> 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 list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --------------7930442194BB4494BB08EC66 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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=40nist.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, “The Use of Maxlength in the RPKI”. 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. 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 list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

--------------7930442194BB4494BB08EC66-- From nobody Tue Oct 26 03:22:04 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138943A0CF0 for ; Tue, 26 Oct 2021 03:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 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, MISSING_HEADERS=1.021, 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=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 DV3pnBVrAqp4 for ; Tue, 26 Oct 2021 03:21:58 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2C13A0D7D for ; Tue, 26 Oct 2021 03:21:58 -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 B67F7605D1 for ; Tue, 26 Oct 2021 10:21:55 +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=1635243715; bh=Rl/Yz7A5C97opAj1LfSnUE0yXEWgW1SyH0qGnDqs94o=; h=Date:From:Cc:Subject:In-Reply-To:References:From; b=vJJZ6cdz8E1KaC70Zz2iJ4q9ZXuelWnXm17zhNaLycBiaMvONPbq9+h9qqDzKoS5w RdiX4PdFZimtkHa5hmhOBPBR2YoOhUlnHubecf3WzU7cctzUVFrAXnTCeBW6nHa2ls AAcF5jIfu/1eacTl1HKNduNsArmLRcBSg0tSzHY74c6DwPfxeCvitJrOLOE+eleUWd dVrmrC4tKGSmc2tgpK/6GAmCtNNhiPCNuHB5beKIIgm5BK8bDd6m6MA19D/38tfwLi TROjaPOUn7dzEL2ADMaITmxnYeZP/afH0W5pBZdpXHsxQClGmJjSV9PXC5F9XsRtQT Z1oZCp6i+guzg== Date: Tue, 26 Oct 2021 12:21:54 +0200 From: Martin Hoffmann Cc: SIDR Operations WG Message-ID: <20211026122154.3891fe8b@glaurung.nlnetlabs.nl> In-Reply-To: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> Organization: NLnet Labs MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 10:22:03 -0000 Job Snijders wrote: > On Mon, Oct 25, 2021 at 02:52:24PM -0700, Randy Bush wrote: > > > I'm arguing that three solutions need to exist, before one of > > > those three can be deprecated. > > > > and why not two or five? i.e. what is the logical argument here? > > I argue the ecosystem needs at least two transports. Multiple > transportation options hopefully increases overall availability and > reliablity. On the other hand, two transports definitely create additional complexities in implementing software; deployment and operation of repositories, and troubleshooting of inconsistencies in data sets. I am not sure I agree that this cost is worth a hypothetical increase in availability. M. From nobody Tue Oct 26 07:11:26 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DBD3A0E1D; Tue, 26 Oct 2021 07:11:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <163525747938.22809.17601013181272609188@ietfa.amsl.com> Date: Tue, 26 Oct 2021 07:11:19 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 14:11:20 -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 : Problem Statement and Considerations for ROA containing Multiple Prefixes Authors : Zhiwei Yan Randy Bush Guanggang Geng Jiankang Yao Filename : draft-ietf-sidrops-roa-considerations-01.txt Pages : 9 Date : 2021-10-26 Abstract: The address space holder needs to issue an ROA object when it authorizes one or more ASes to originate routes to IP prefix(es). During the process of ROA issuance, the address space holder may need to specify an origin AS for a list of IP prefixes. Besides, the address space holder has a free choice to put multiple prefixes into a single ROA or issue separate ROAs for each prefix based on the current specification. This memo analyzes and presents some operational problems which may be caused by the ROAs containing multiple IP prefixes. Some suggestions and considerations also have been proposed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-considerations-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-roa-considerations-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 26 08:13:39 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67523A12A0 for ; Tue, 26 Oct 2021 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 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, 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 RW-sLr0BZPuy for ; Tue, 26 Oct 2021 08:13:32 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::71a]) (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 13D953A12B1 for ; Tue, 26 Oct 2021 08:13:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kJwXmNvMoc5UE82wRAoj7ACi9mIDiO4KBTLc3a8UC1gy5f1OxTuEwWBEisAmecvSshpW4+bjP1Nb9kHZSpD99O6/eoS3FNG+wZO18CyIsLGMIceXQttB9p4IplgSe/sBay5h7SVL3+e1wdodtq7mSZrfNL32FT04tyYwOv7iQI/qHIB7klEGqwR2BSXCZK7o3ItHqS9dg9tVVfpocTIBr0YdM6b/U1OCqb0CD+Dv06uL5F4QGkQkLvvFFi7TKhcL8uNy/ORwOlZyVQIz2yn1cYwemheSpuavmAs97LXhsGudDudlNPZBFx+byir0pVp3bsojqsFyT293xfZLHVe33g== 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=dJDxsrKB91iSMVTq2/SjAE8uofwhF3F5vWlkLbPjgXw=; b=OM7c0zBcVOfcaZya3hLW0i6WmaYerc5dGyKwjjgXJ68TRdqTWRu5fSroSbnpamrfEvQapS8UxpbPO9F0Tp1DNzTR8uj/szqVN1WBdau4E2nRQ8Nvd1F0t/aTxLLVaKvNSWJfyt6oi2XH+68CVc2jODce05ln6vBeiS5fNO7ewMrlpI4SVJLLWBtGOgr4+Ko9BODri37S/HFYuhH47i3UQIWNtCbyOBBT04ZEXBnMHiIH10dkj0AQDYB1uL+ZdA4uNHyhKV8RHU80f4O9gHkK7HsAAuM/cQBdq24hny822yC96vuqOcDsJD6UmtI19Op/NdbxVLXmi1tlJRziiSiL7w== 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=dJDxsrKB91iSMVTq2/SjAE8uofwhF3F5vWlkLbPjgXw=; b=roXqXdiqWrzr7S/gGyDdRuKPNtnWCX1qOqsATwTcXhXQ6xKFKSOiegE+bxcQA5T+JvNUEtleFSoYVOOGrELsPlfn8R9SaBNEN2JZCRf4iQqEcQseDIMzcchoUd0BoUd/qvZVkfHMdFN91oDaLzl4W8FprsSf8rTpJg3pKz3oa/Q= Received: from SA1PR09MB8142.namprd09.prod.outlook.com (2603:10b6:806:171::8) by SA1PR09MB8334.namprd09.prod.outlook.com (2603:10b6:806:174::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Tue, 26 Oct 2021 15:13:26 +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.4628.020; Tue, 26 Oct 2021 15:13:26 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Andrei Robachevsky CC: "sidrops@ietf.org" , Alexander Azimov Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt Thread-Index: AdfKcj+25lq3uE+qSCqyQJrZ+z+qXA== Date: Tue, 26 Oct 2021 15:13:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa58d8ed-9e2b-41c2-8564-08d9989328b5 x-ms-traffictypediagnostic: SA1PR09MB8334: x-microsoft-antispam-prvs: 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: nsc59S9D6T7xXk4IKmBxEnpaWWpyc4sHwziQGy9bhehKHIj7qdm8166KZqtcdpBT/IkYuBsUu+MFqM9BtESZ7s3TQ6uZCN1cqXrjaGZCBKq0bVO9Rup/nm3+d6apUu4DE3nMbvWeIsAI1rQ/OsHLjGF8nBYJEzvoW0SdiuBTLaEFU/sJ52q+jC4i6Emdr5KitMIw+ji+qpN5kOvjOZfBnwsFbeGXBMcivyMx779uEIU8eCdpcLnFxIU6ZuSZZsR/Gx+CjqgWC8LK1kZTYy1GQLaiOuaiUKdQMFVuGuXcQh9At+nvWVsjxZOiHrjb2kiTjvHLwj5geMNRkAQ9XCQnsAvAGG8fdvlvbLDOsctEEr6OdYMSVHXXaWbAebPA4IPl6UB0vNa3nk/+L0ymjg4Ovp0CNZK3u9/dTdReKVeQY8x3UiC0AOsOSAmp3Ry0DYJO/5X+Na7xBwFjGEVhHNY10i4x9U3pbndBktcT6TblZkGvfCxWhB2PH6J/pckevoj2mtK4vGbJJQwzWsDW431B4GumfORJgSUC6Lb/01emzoSWVlpJG9/8/6AWTGcC9evZQjxDMmlEZiZvOZyhjZ6rkCiQIWiUhXc9H7gvZnXeveO8BJW4lStMcnQRmT++XLGU8WeHMTVQHBCRAKnQaBgDh2LZR0HE/UoFUS21bmB+prcizXcJvAbZJYqfv+QLGFq4EoY8acJKbqHw8ZnkvsxVit1BuCJb31FbWJVN+EURRm3Y9VPQPBLD8OWWA7JLjPEX7B8TlELz++K7jT+j0fIDCFB52lX5Hw0LS7vKEIMkEg4PtODO3vHCqAQZsb46tV8N 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)(8936002)(9326002)(966005)(64756008)(66946007)(54906003)(508600001)(6506007)(82960400001)(66476007)(186003)(38100700002)(15650500001)(316002)(166002)(5660300002)(66446008)(66556008)(4326008)(9686003)(6916009)(122000001)(83380400001)(76116006)(71200400001)(7696005)(52536014)(55016002)(26005)(8676002)(2906002)(33656002)(86362001)(38070700005)(69594002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?smJ16XLT4O8p2v2GCia4NN5fcSPUd/DAe8hRW3wzRdBWUG/ob6RBNURAX3DC?= =?us-ascii?Q?SUhshPLak0y4JAsRHATcUINQFrbVq8bdKartCqK8TUGm8T4joL//tkzCk+og?= =?us-ascii?Q?mBpy882fEwLIKlK5eK9Uy6r5TYWdbh+EtO3N6tPESqUZDdLw5H6pI06Evuw8?= =?us-ascii?Q?267ztxijvgZKMVGL3DBSI7093dWAZySoQx0q1OjJerQ3c+2VjBq8+Hzxs1k5?= =?us-ascii?Q?Y2XMGmdn+nObVlfMmt9WUmMfDF2M21Gzis2qow1bRahSKce0jQ0CtsXzi9NJ?= =?us-ascii?Q?n8xPxlpaUMkxFmCpNC7ytdhEXpkE7QrTE4oETPMlpXijAjGurv3wm8Csg84a?= =?us-ascii?Q?d2i1N6/DiJTw2J3niD5tN+Wayt9U0EjXt7kFMEv9ERGS2Ea0Gy+Lx4dxCgt3?= =?us-ascii?Q?/rjF9qsxvvrLZDCCyIMb718phHP5O1Mit9wky7nB+zjrjConfgxLf2LlDAAq?= =?us-ascii?Q?2NbxuISMsY3SySjQREJIGrh6Cja6wrTPbyZWTvSGuFvawjip/MymF+EFvIeI?= =?us-ascii?Q?2uvfB96SECX8H4RNyW4OYLoJ/8LzdpY0NLaxYn9IYW5UyqQ2ddWYg7Z8mGcz?= =?us-ascii?Q?5ZVwOpXhNAJlfM8F36vy+9+8dOfhzopVT1cJhYbN5YvmZ8ONoVtPn2ESGvYt?= =?us-ascii?Q?2uwHH3nLPp5aM3M4SHpDkZ7j3WtzjlBbN6o9vHnZuOhaZKjW6mR71quyes7v?= =?us-ascii?Q?EUeb6U9Wutnj3twfFH5La1k4HaGvS4gzU5u6AQA2DNV7gxVrbVGTSDKn7oPK?= =?us-ascii?Q?R78dh+An+ofHX727WQpbbtw0LDLx6XOoY+I3sDwNYj52Da1BE1uwsoO7MV1/?= =?us-ascii?Q?+kR0R9DVIHYpZRnpQi4K8LRRp0Sdr+iRmOUOnbexHZ7RPIEeZmxa6h3Xgy3u?= =?us-ascii?Q?TbUPrvK3O7wzIe2ibw0rbOPQ/GthzuaZBAqHx0H3RH+PAikDpXr9hZk79oa6?= =?us-ascii?Q?FRWlQ0BxuiLf/mNFt+K2nz6wCu2NRpHzzbIVbuKyiiAkWJ9SDeiMWiPBFKtM?= =?us-ascii?Q?aH34YOiTbtHqYHNZYV6W9+9xVehSVvbow18YAC9XW3OG/5Jh34WH1THCN2U3?= =?us-ascii?Q?H9nxEO8lio9ymDOb5JTpU6/go+W1+0sR8vALDSu6dsB5zzMWjxsPXXfeD/ud?= =?us-ascii?Q?85Dk+XWuYjdrNZDX+DeRVBB1tpakQztK4jFHc9eGRePE/RPSxbhD5XVDM7t/?= =?us-ascii?Q?e0G1XOUytvr2T7M9xX/IvLZVtLEWD7a+51+N8UPYXNBpPMKjBQjH/JS1cDkV?= =?us-ascii?Q?42G7L5RrkMm+rp/vpm113sn739Emk9rBRu7Zba7nVyp1WLpdC5g6tAqPkU2t?= =?us-ascii?Q?fuxv3O36iQ2lyPdfZVfeKZUK?= Content-Type: multipart/alternative; boundary="_000_SA1PR09MB8142D84F1CF8716D53920CAB84849SA1PR09MB8142namp_" 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: aa58d8ed-9e2b-41c2-8564-08d9989328b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 15:13:25.8681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB8334 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 15:13:37 -0000 --_000_SA1PR09MB8142D84F1CF8716D53920CAB84849SA1PR09MB8142namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrei, There was a shortcoming identified with the ASPA downstream verification al= gorithm in January this year. I am not sure you are aware of it. The thread= is here: https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=3D1&index=3DxoBTzN1pl= ByFFq1ljj5i0vPAzIk I gave a presentation (joint work with Jakob Heitz) at IETF 110 SIDROPS: "O= n the Accuracy of Algorithms for ASPA Based Route Leak Detection" https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-srira= m-aspa-alg-accuracy-01 The shortcoming was in the sense that the algorithm was yielding 'Unknow" r= esults in some scenarios when it was "Valid". This was addressed and a revi= sed algorithm was agreed to in principle by several of us in SIDROPS (inclu= ding Alexander). You may glance through the presentation, specially the alg= orithm on slides 14 and 15. It was formally proven to work correctly. You a= re welcome to review it, and it should not have any of the issues that you = are thinking about. You may let us know if you agree. Alexander was busy so he simply refreshed the -07 draft to generate -08. So= , at this point, we are waiting for draft -09. A clear, simple wording of t= he algorithm for the draft is being worked on, including some new minor cor= ner cases. Sriram ------------------------------------------------------------------- Andrei Robachevsky Mon, 25 October 2021 13:3= 4 UTCShow header Hi, I read the latest version of the draft and I am not sure that the Downstream Path verification procedure (sec 5.2) is correct. The draft says: > The first unequal pair of AS_SEQUENCE segments that has an "Invalid" outc= ome of the customer-provider verification procedure indicates the end of th= e Upstream fragment. But the procedure described in items 3 and 4 seems to skip checking that the first downstream fragment of the path may return an invalid verification for the "reverse" ASPA (verify_pair(Seg(I), Seg(I-1), afi). By performing this check we can verify that that downstream customer indeed declared the top provider as its upstream. It seems to me that a similar verification of a "reverse" ASPA needs to be done when detecting a leaking customer L, since verify_pair(Seg(L+1), Seg(L), afi) will likely return "Unknown", but verify_pair(Seg(L), Seg(L+1), afi) may be "Valid". In this case we can confidently state that it is a leak and return "Invalid". Thanks, Andrei --_000_SA1PR09MB8142D84F1CF8716D53920CAB84849SA1PR09MB8142namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrei,

 

There was a shortco= ming identified with the ASPA downstream verification algorithm in January = this year. I am not sure you are aware of it. The thread is here:

https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=3D1&a= mp;index=3DxoBTzN1plByFFq1ljj5i0vPAzIk

 

I gave a presentati= on (joint work with Jakob Heitz) at IETF 110 SIDROPS: “On the Accurac= y of Algorithms for ASPA Based Route Leak Detection”

https://datatracker.ietf.org/meeting/110/materials/slides-1= 10-sidrops-sriram-aspa-alg-accuracy-01

 

The shortcoming was= in the sense that the algorithm was yielding ‘Unknow” results = in some scenarios when it was “Valid”. This was addressed and a= revised algorithm was agreed to in principle by several of us in SIDROPS (including Alexander). You may glance through the presentati= on, specially the algorithm on slides 14 and 15. It was formally proven to = work correctly. You are welcome to review it, and it should not have any of= the issues that you are thinking about. You may let us know if you agree.

 

Alexander was busy = so he simply refreshed the -07 draft to generate -08. So, at this point, we= are waiting for draft -09. A clear, simple wording of the algorithm for th= e draft is being worked on, including some new minor corner cases.

 

Sriram

 

-------------------= ------------------------------------------------

 

Andrei Robachevsky = <andrei.robachevsky@gmail.com> Mon, 25 October 2021 13:34 UTCShow hea= der

 

Hi,

 

I read the latest v= ersion of the draft and I am not sure that the

Downstream Path ver= ification procedure (sec 5.2) is correct.

 

The draft says:

> The first uneq= ual pair of AS_SEQUENCE segments that has an "Invalid" outcome of= the customer-provider verification procedure indicates the end of the Upst= ream fragment.

 

But the procedure d= escribed in items 3 and 4 seems to skip checking that

the first downstrea= m fragment of the path may return an invalid

verification for th= e "reverse" ASPA (verify_pair(Seg(I), Seg(I-1), afi).

By performing this = check we can verify that that downstream customer

indeed declared the= top provider as its upstream.

 

It seems to me that= a similar verification of a "reverse" ASPA needs to

be done when detect= ing a leaking customer L, since verify_pair(Seg(L+1),

Seg(L), afi) will l= ikely return "Unknown", but verify_pair(Seg(L),

Seg(L+1), afi) may = be "Valid". In this case we can confidently state

that it is a leak a= nd return "Invalid".

 

Thanks,<= /span>

 

Andrei

--_000_SA1PR09MB8142D84F1CF8716D53920CAB84849SA1PR09MB8142namp_-- From nobody Tue Oct 26 08:43:46 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620B83A13B1 for ; Tue, 26 Oct 2021 08:43:45 -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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, 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 60KWHcr7Iu34 for ; Tue, 26 Oct 2021 08:43:41 -0700 (PDT) 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 046013A13BF for ; Tue, 26 Oct 2021 08:43:40 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id h7so4361430ede.8 for ; Tue, 26 Oct 2021 08:43:40 -0700 (PDT) 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 :cc:references:from:in-reply-to:content-transfer-encoding; bh=0Lc31/g9GQwT4/z7PQCXl+xHT8iFUB7ZRVfHwbXGFKE=; b=Jsp1bjDPImEHT6O4AnraYlAFiAO0hgUkWZPhfnijJIsj6btul7+8Vf99helYhYU8V5 634O1WyIqtOKxvD8Qt7UMyYI1pQNBHXJ4S68xxBwVWUmkFxvVgKoTwHfiIdLCPW1GHkt Iy8J7I2sWhnPEmNhKxc5puiE92r6BJ/Ng6SiLknIAfSL/mPuJFnk2edgZcessJP12iRU LXPZliq1/jF7ZZJA8ZoMBtPl2A5PP3MpoNJQHdeDnhdgs9jDurB8yVwS0GsJ2vTRY3V5 bpd0QdYI4J4tZK7JhVrcd+s6kvaE3xMqZf/nXPfX8g3AWtgpG8hl8gxsftDK+cxoJuFx ZrjQ== 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:cc:references:from:in-reply-to :content-transfer-encoding; bh=0Lc31/g9GQwT4/z7PQCXl+xHT8iFUB7ZRVfHwbXGFKE=; b=VsvGumQOdo4ImaCXpbSJUxcr1ccxVJciOI2sOHNwxisA7129UIaK6zYbLKOCdmAbCv oofVOiQYUa5Vm1+IbKLIf54pouH4mfT2I5ZDkTPDZj5XzrrQK3rG5QdW7M5B1uW6T1qe zAw0m1IOoHFKb2mCg+1Fzzsz5V4/+7QqhWfrDdahgAQdzFSnvmaS5INQQIAwSZIKKOBH qTCBrsp/ZZXBZLsgOt+ISz4QLW+TcJjBmTT9XM9BqIsBeN82LKjAJ++4YDuYowefJTKn gJWm9fuWMszHeOdNqFcW6IHJlxJbyZyzPzzJzSNejxp+/Bq45YQdM2SttXaLlDe7ffjc F4sw== X-Gm-Message-State: AOAM53249nYlyO8Yg9EVc6Qw3+ZCbYNIjDzsRtQeR20dRazyh9srvXdx Y8KSn89SCewqWvwYD38vyWc= X-Google-Smtp-Source: ABdhPJwpfOzrAlpprYnDptpRHF/LHPQmenqRsMGjEg6/s+d6KZbxOa2yGMeZwgeZCHOSVUnViNAVgQ== X-Received: by 2002:a17:906:a986:: with SMTP id jr6mr31384623ejb.520.1635262864905; Tue, 26 Oct 2021 08:41:04 -0700 (PDT) Received: from [192.168.178.20] (f189051.upc-f.chello.nl. [80.56.189.51]) by smtp.gmail.com with ESMTPSA id j11sm4619277edt.49.2021.10.26.08.41.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 08:41:04 -0700 (PDT) Message-ID: Date: Tue, 26 Oct 2021 17:41:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: "Sriram, Kotikalapudi (Fed)" Cc: "sidrops@ietf.org" , Alexander Azimov References: From: Andrei Robachevsky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-verification-08.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 15:43:45 -0000 Hi Sriram, thank you! I should have paid more attention. Looking forward to the updated -09 Regards, Andrei Sriram, Kotikalapudi (Fed) wrote on 26/10/2021 17:13: > Hi Andrei, > > There was a shortcoming identified with the ASPA downstream verification > algorithm in January this year. I am not sure you are aware of it. The > thread is here: > > https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1&index=xoBTzN1plByFFq1ljj5i0vPAzIk > > > I gave a presentation (joint work with Jakob Heitz) at IETF 110 SIDROPS: > “On the Accuracy of Algorithms for ASPA Based Route Leak Detection” > > https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01 > > > > The shortcoming was in the sense that the algorithm was yielding > ‘Unknow” results in some scenarios when it was “Valid”. This was > addressed and a revised algorithm was agreed to in principle by several > of us in SIDROPS (including Alexander). You may glance through the > presentation, specially the algorithm on slides 14 and 15. It was > formally proven to work correctly. You are welcome to review it, and it > should not have any of the issues that you are thinking about. You may > let us know if you agree. > > Alexander was busy so he simply refreshed the -07 draft to generate -08. > So, at this point, we are waiting for draft -09. A clear, simple wording > of the algorithm for the draft is being worked on, including some new > minor corner cases. > > Sriram > > ------------------------------------------------------------------- > > Andrei Robachevsky Mon, 25 October 2021 > 13:34 UTCShow header > > Hi, > > I read the latest version of the draft and I am not sure that the > > Downstream Path verification procedure (sec 5.2) is correct. > > The draft says: > >> The first unequal pair of AS_SEQUENCE segments that has an "Invalid" outcome of the customer-provider verification procedure indicates the end of the Upstream fragment. > > But the procedure described in items 3 and 4 seems to skip checking that > > the first downstream fragment of the path may return an invalid > > verification for the "reverse" ASPA (verify_pair(Seg(I), Seg(I-1), afi). > > By performing this check we can verify that that downstream customer > > indeed declared the top provider as its upstream. > > It seems to me that a similar verification of a "reverse" ASPA needs to > > be done when detecting a leaking customer L, since verify_pair(Seg(L+1), > > Seg(L), afi) will likely return "Unknown", but verify_pair(Seg(L), > > Seg(L+1), afi) may be "Valid". In this case we can confidently state > > that it is a leak and return "Invalid". > > Thanks, > > Andrei > From nobody Tue Oct 26 18:48:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C633A1AAC for ; Tue, 26 Oct 2021 18:48:40 -0700 (PDT) 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, HTML_MESSAGE=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 hlandOt8Vd-j for ; Tue, 26 Oct 2021 18:48:35 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id AD27F3A1AAB for ; Tue, 26 Oct 2021 18:48:33 -0700 (PDT) Received: from CNNIC-THINK (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DJ0S3rr3hh9_4VAA--.32670S2; Wed, 27 Oct 2021 09:48:27 +0800 (CST) Date: Wed, 27 Oct 2021 09:48:24 +0800 From: "YAN Zhiwei" To: sidrops X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Mime-Version: 1.0 Message-ID: <2021102709482430541324@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart376104611650_=----" X-CM-TRANSID: AQAAf0DJ0S3rr3hh9_4VAA--.32670S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tr48Kryrtw1rCrykJFy7KFg_yoW8AF1Upa 95W3yrta4xGr4Fkayxuw1kAw15uas5WayDGa48J3W2y3s0gF1vvw10kF45AFyDJw12kr9F vF409rWYqr1vv3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB0b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xv F2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2eMNUUUUU X-CM-SenderInfo: h1dq6xplzhxq5fqqxugofq/ Archived-At: Subject: [Sidrops] Fw: New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 01:48:40 -0000 This is a multi-part message in MIME format. ------=_001_NextPart376104611650_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNClRoZSBmb2xsb3dpbmcgZHJhZnQgd2FzIHVwZGF0ZWQuDQpJbiB0aGlzIHZlcnNp b24sIHdlIG1hZGUgc29tZSBhbmFseXNpcyBvZiB0aGUgY3VycmVudCBST0EgZGF0YS4NCkFueSBj b21tZW50cyBhcmUgd2VsY29tZS4NClRoYW5rcywNCkJSLA0KDQoNCllBTiBaaGl3ZWkNCiANCkZy b206IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAyMS0xMC0yNiAyMjoxMQ0KVG86IEd1YW5nZ2Fu ZyBHZW5nOyBKaWFua2FuZyBZYW87IFJhbmR5IEJ1c2g7IFpoaXdlaSBZYW4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLXJvYS1jb25zaWRl cmF0aW9ucy0wMS50eHQNCiANCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXNpZHJv cHMtcm9hLWNvbnNpZGVyYXRpb25zLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBKaWFua2FuZyBZYW8gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N CiANCk5hbWU6IGRyYWZ0LWlldGYtc2lkcm9wcy1yb2EtY29uc2lkZXJhdGlvbnMNClJldmlzaW9u OiAwMQ0KVGl0bGU6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBDb25zaWRlcmF0aW9ucyBmb3IgUk9B IGNvbnRhaW5pbmcgTXVsdGlwbGUgUHJlZml4ZXMNCkRvY3VtZW50IGRhdGU6IDIwMjEtMTAtMjUN Ckdyb3VwOiBzaWRyb3BzDQpQYWdlczogOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1zaWRyb3BzLXJvYS1jb25zaWRlcmF0aW9ucy0w MS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXNpZHJvcHMtcm9hLWNvbnNpZGVyYXRpb25zLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLXJv YS1jb25zaWRlcmF0aW9ucw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNpZHJvcHMtcm9hLWNvbnNpZGVyYXRpb25zLTAxDQogDQpB YnN0cmFjdDoNCiAgIFRoZSBhZGRyZXNzIHNwYWNlIGhvbGRlciBuZWVkcyB0byBpc3N1ZSBhbiBS T0Egb2JqZWN0IHdoZW4gaXQNCiAgIGF1dGhvcml6ZXMgb25lIG9yIG1vcmUgQVNlcyB0byBvcmln aW5hdGUgcm91dGVzIHRvIElQIHByZWZpeChlcykuDQogICBEdXJpbmcgdGhlIHByb2Nlc3Mgb2Yg Uk9BIGlzc3VhbmNlLCB0aGUgYWRkcmVzcyBzcGFjZSBob2xkZXIgbWF5IG5lZWQNCiAgIHRvIHNw ZWNpZnkgYW4gb3JpZ2luIEFTIGZvciBhIGxpc3Qgb2YgSVAgcHJlZml4ZXMuICBCZXNpZGVzLCB0 aGUNCiAgIGFkZHJlc3Mgc3BhY2UgaG9sZGVyIGhhcyBhIGZyZWUgY2hvaWNlIHRvIHB1dCBtdWx0 aXBsZSBwcmVmaXhlcyBpbnRvDQogICBhIHNpbmdsZSBST0Egb3IgaXNzdWUgc2VwYXJhdGUgUk9B cyBmb3IgZWFjaCBwcmVmaXggYmFzZWQgb24gdGhlDQogICBjdXJyZW50IHNwZWNpZmljYXRpb24u ICBUaGlzIG1lbW8gYW5hbHl6ZXMgYW5kIHByZXNlbnRzIHNvbWUNCiAgIG9wZXJhdGlvbmFsIHBy b2JsZW1zIHdoaWNoIG1heSBiZSBjYXVzZWQgYnkgdGhlIFJPQXMgY29udGFpbmluZw0KICAgbXVs dGlwbGUgSVAgcHJlZml4ZXMuICBTb21lIHN1Z2dlc3Rpb25zIGFuZCBjb25zaWRlcmF0aW9ucyBh bHNvIGhhdmUNCiAgIGJlZW4gcHJvcG9zZWQuDQogDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogDQogDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KIA0KIA0KIA0K ------=_001_NextPart376104611650_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, all,
The following draft was updated.=
In this version, we made some analysis of the current ROA data.=
Any comments are welcome.
Thanks,
BR,
= =0A
=0A
YAN Zhiwei
 = ;
Date: 2= 021-10-26 22:11
Subject: New Ver= sion Notification for draft-ietf-sidrops-roa-considerations-01.txt
 
=0A
A new version of I-D, draft-ietf-s= idrops-roa-considerations-01.txt
=0A
has been successfully submit= ted by Jiankang Yao and posted to the
=0A
IETF repository.
= =0A
 
=0A
Name: draft-ietf-sidrops-roa-considerations=0A
Revision: 01
=0A
Title: Problem Statement and Consid= erations for ROA containing Multiple Prefixes
=0A
Document date: = 2021-10-25
=0A
Group: sidrops
=0A
Pages: 9
=0AURL:            h= ttps://www.ietf.org/archive/id/draft-ietf-sidrops-roa-considerations-01.tx= t
=0A
Status:         htt= ps://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/
= =0A
Htmlized:       https://datatracker.= ietf.org/doc/html/draft-ietf-sidrops-roa-considerations
=0A
Diff:=            https://www.i= etf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-roa-considerations-01
=0A 
=0A
Abstract:
=0A
   The address spa= ce holder needs to issue an ROA object when it
=0A
   a= uthorizes one or more ASes to originate routes to IP prefix(es).
=0A<= div>   During the process of ROA issuance, the address space hol= der may need
=0A
   to specify an origin AS for a list = of IP prefixes.  Besides, the
=0A
   address space= holder has a free choice to put multiple prefixes into
=0A
 = ;  a single ROA or issue separate ROAs for each prefix based on the=0A
   current specification.  This memo analyzes a= nd presents some
=0A
   operational problems which may = be caused by the ROAs containing
=0A
   multiple IP pre= fixes.  Some suggestions and considerations also have
=0A
&n= bsp;  been proposed.
=0A
 
=0A
  &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;    
=0A
 
=0A
 
= =0A
The IETF Secretariat
=0A
 
=0A
 
= =0A
 
=0A
=0A ------=_001_NextPart376104611650_=------ From nobody Wed Oct 27 01:35:45 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854993A085D for ; Wed, 27 Oct 2021 01:35:42 -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, 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 rgxtPwkcQrk3 for ; Wed, 27 Oct 2021 01:35:37 -0700 (PDT) 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 26E0C3A085C for ; Wed, 27 Oct 2021 01:35:37 -0700 (PDT) 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=w8LYAwOae0TIsVsr50OW8NFCDJuFYpKMQrA65Pt0XDc=; b=iAto6SZoIUmnpD1LEvEZvEhl SZcPOU8wjR+/egC9fvrH2TvuNBsszxgftfwpfH83pdfEHdh4hUbth6U+YoWjo00jvbRn8CT+GfgZj I2MQK5M1kM6p3wuPIO9PPEUdaAcpf7GmY37gWxYxw9R1DZthSO8Fl5gxdJjkhYXuo9fIdEUNsnYli vrIZ+p2OE0AZI5ppr+MP7k6JEERI3hpphgutBnjrmuDfDBzgwuLGNYHezRejP/Y86yaYkuk/tbQvn Y4iWC5BZ0zX3q6lmCutnj6/UxwUFZv39YKnVzABOW7IWHTwLfri5O5aQItX4eFXesLtQwaAfz89mG Rx51zY7zXQ==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:59172) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mfePF-0004FJ-GL; Wed, 27 Oct 2021 10:35:33 +0200 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 ) id 1mfePF-0001IQ-D9; Wed, 27 Oct 2021 10:35:33 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_63D6935B-14D9-4114-97A2-B00FE26C7FAD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Ties de Kock X-Priority: 3 In-Reply-To: <2021102709482430541324@cnnic.cn> Date: Wed, 27 Oct 2021 10:35:33 +0200 Cc: sidrops Message-Id: References: <2021102709482430541324@cnnic.cn> To: YAN Zhiwei X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e14c53a7ec4af47e9d0b5694eb7918c5a2 Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 08:35:43 -0000 --Apple-Mail=_63D6935B-14D9-4114-97A2-B00FE26C7FAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 27 Oct 2021, at 03:48, YAN Zhiwei wrote: >=20 > Hi, all, > The following draft was updated. > In this version, we made some analysis of the current ROA data. > Any comments are welcome. > Thanks, > BR, In the draft I read: > The potential influence of operations of ROAs containing multiple IP > prefixes on BGP routers must be considered. For the ROA containing > multiple prefixes, once increase or delete one pair > in it, this whole ROA must be withdrawn and reissued. Through > sychronization with repository, Relying Party (RP) fetches a new ROA > object and then notify and send all the pairs in = this > ROA to BGP routers. That is to say, the update of the ROA = containing > multiple IP address prefixes will lead to redundant transmission > between RP and BGP routers. So frequent update of these ROAs will > increase the convergency time of BGP routers and reduce their > performance obviously. Could you elaborate on the testing setup in which you observed this = situation? Because I would consider it a bug if a single prefix being removed = caused all VRPs on the ROA to be withdrawn and then announced again over RTR. I = decided to try to replicate this and I could not. What I do observed was: * (initial situation): A CA with one ROA with many prefixes for a = specific AS on an internal test environment for RIPE NCC RPKI dashboard. * The CA has roa for that AS with many prefixes in it. * (user): Deletes one prefix for that AS from the CA. * (system): re-creates the ROA (file), new ROA replaces old one * (system): ROA replaces (publish w/ hash for RRDP, in rsync the file = changes) the old ROA file * (rp): fetches new file, calculates new VRPs * (rp): sends a PDU for a single prefix, flags indicate it is a = withdraw In my opinion, if a RP or CA causes all pairs to be = withdrawn temporarily, it is a bug in the software stack. A CA can (and should) = publish this change without an intermediate state in which pairs disappear. Kind regards, Ties p.s. The software I used was: Routinator 0.10.1, RIPE NCC CA software = cb9e889f4, rpki-rtr-client, wireshark >=20 > YAN Zhiwei > =20 > From: internet-drafts > Date: 2021-10-26 22:11 > To: Guanggang Geng ; Jiankang Yao = ; Randy Bush ; Zhiwei Yan = > Subject: New Version Notification for = draft-ietf-sidrops-roa-considerations-01.txt > =20 > A new version of I-D, draft-ietf-sidrops-roa-considerations-01.txt > has been successfully submitted by Jiankang Yao and posted to the > IETF repository. > =20 > Name: draft-ietf-sidrops-roa-considerations > Revision: 01 > Title: Problem Statement and Considerations for ROA containing = Multiple Prefixes > Document date: 2021-10-25 > Group: sidrops > Pages: 9 > URL: = https://www.ietf.org/archive/id/draft-ietf-sidrops-roa-considerations-01.t= xt = > Status: = https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/ = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-consideration= s = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-roa-considerations-= 01 = > =20 > Abstract: > The address space holder needs to issue an ROA object when it > authorizes one or more ASes to originate routes to IP prefix(es). > During the process of ROA issuance, the address space holder may = need > to specify an origin AS for a list of IP prefixes. Besides, the > address space holder has a free choice to put multiple prefixes = into > a single ROA or issue separate ROAs for each prefix based on the > current specification. This memo analyzes and presents some > operational problems which may be caused by the ROAs containing > multiple IP prefixes. Some suggestions and considerations also = have > been proposed. > =20 > = =20 > =20 > =20 > The IETF Secretariat > =20 > =20 > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_63D6935B-14D9-4114-97A2-B00FE26C7FAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

On 27 Oct 2021, at 03:48, YAN Zhiwei <yanzhiwei@cnnic.cn> = wrote:

Hi, all,
The = following draft was updated.
In = this version, we made some analysis of the current ROA data.
Any comments are welcome.
Thanks,
BR,

In = the draft I read:

>   The = potential influence of operations of ROAs containing multiple = IP
>   prefixes on BGP routers must be considered. =  For the ROA containing
>   multiple prefixes, = once increase or delete one <AS, ip_prefix> pair
> =   in it, this whole ROA must be withdrawn and reissued. =  Through
>   sychronization with repository, = Relying Party (RP) fetches a new ROA
>   object and = then notify and send all the <AS, ip_prefix> pairs in = this
>   ROA to BGP routers.  That is to say, the = update of the ROA containing
>   multiple IP address = prefixes will lead to redundant transmission
>   = between RP and BGP routers.  So frequent update of these ROAs = will
>   increase the convergency time of BGP routers = and reduce their
>   performance = obviously.

Could you elaborate on = the testing setup in which you observed this situation?

Because I would consider it a bug if a single = prefix being removed caused all
VRPs on the ROA to be = withdrawn and then announced again over RTR. I decided to
try = to replicate this and I could not.

What I do observed was:
  * = (initial situation): A CA with one ROA with many prefixes for a specific = AS
    on an internal test environment for RIPE NCC = RPKI dashboard.
    * The CA has roa for that AS = with many prefixes in it.
  * (user): Deletes one prefix = for that AS from the CA.
  * (system): re-creates the ROA = (file), new ROA replaces old one
  * (system): ROA = replaces (publish w/ hash for RRDP, in rsync the file changes) the old = ROA file
  * (rp): fetches new file, calculates new = VRPs
  * (rp): sends a PDU for a single prefix, flags = indicate it is a withdraw

In my = opinion, if a RP or CA causes all <AS, ip_prefix> pairs to be = withdrawn
temporarily, it is a bug in the software stack. A CA = can (and should) publish
this change without an intermediate = state in which <AS, ip_prefix> = pairs
disappear.

Kind = regards,
Ties

p.s. The = software I used was: Routinator 0.10.1, RIPE NCC CA software cb9e889f4, = rpki-rtr-client, wireshark

YAN = Zhiwei
 
From: internet-drafts
Date: 2021-10-26 22:11
To: Guanggang Geng; Jiankang Yao; Randy Bush; Zhiwei Yan
Subject: New Version Notification for = draft-ietf-sidrops-roa-considerations-01.txt
 
A new version of = I-D, draft-ietf-sidrops-roa-considerations-01.txt
has= been successfully submitted by Jiankang Yao and posted to the
IETF repository.
 
Name: draft-ietf-sidrops-roa-considerations
Revision: 01
Title: Problem Statement = and Considerations for ROA containing Multiple Prefixes
Document date: 2021-10-25
Group: = sidrops
Pages: 9
URL:          = ;  https://www.ietf.org/archive/id/draft-ietf-sidrops-roa-consider= ations-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-conside= rations/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-co= nsiderations
Diff:         &nbs= p; https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-roa-cons= iderations-01
 
Abstract:
   The address space = holder needs to issue an ROA object when it
   authorizes one or more ASes to originate routes = to IP prefix(es).
   During the process = of ROA issuance, the address space holder may need
   to specify an origin AS for a list of IP = prefixes.  Besides, the
   address = space holder has a free choice to put multiple prefixes into
   a single ROA or issue separate ROAs for each = prefix based on the
   current = specification.  This memo analyzes and presents some
   operational problems which may be caused by the = ROAs containing
   multiple IP = prefixes.  Some suggestions and considerations also have
   been proposed.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;         
 
 
The = IETF Secretariat
 
 
 
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_63D6935B-14D9-4114-97A2-B00FE26C7FAD-- From nobody Wed Oct 27 03:40:50 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08093A0A46 for ; Wed, 27 Oct 2021 03:40:49 -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=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 odPL8vmJ_4pL for ; Wed, 27 Oct 2021 03:40:45 -0700 (PDT) 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 CB4DD3A0A63 for ; Wed, 27 Oct 2021 03:40:44 -0700 (PDT) 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 3CF6C95; Wed, 27 Oct 2021 10:40:39 +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=1635331238; bh=RGj0x/sYcEj0Nt4SS4pBw2IMh6uUi/k+jopyIvOJzJo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=GEzr5gVKQZH0PpR4c24uV7sXJVcAAjKrms08spDUV24VTCTbFsYkiGCKeHo+HiLe5 n5F//Px/YKTpCKVin6JKahjlBMyTVxLS5ZPTkn4GdEtVGpaAsZVrNL3sAEuUHlWil+ SQAbYyvHrEA9g4pazDf9CCHIES7sR5OpTJpAdWk6IVyfobLeeq01t1sloDqyLj9Xz0 r4MHqREOlu+JQ8eKIBOVlsGpJ6fahZrUL8+KicWSD8mLpJFi/1foNtJ6tm31jbMrJC qDA8NtGphx81oILLBN7zDPUci0Z+mFPs0zK4eAChuo/G2R8yJsFxTOa+19mnqT23YZ UB1W/R+Du6PZQ== 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 In-Reply-To: Date: Wed, 27 Oct 2021 12:40:36 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> To: Job Snijders Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 10:40:50 -0000 Job, group, > On 24 Oct 2021, at 20:01, Job Snijders = wrote: >=20 > On Sun, Oct 24, 2021 at 07:24:15PM +0200, Tim Bruijnzeels wrote: >>> We should actively encourage operators to deploy both protocols. >>=20 >> Actually.. that is exactly what this document says. >=20 > Section 2 "Motivation" first goes on to spread FUD about rsync, and = then > concludes that RRDP isn't perfect either. Eh.... yes, ok? > If the authors wish to make RRDP and RSYNC 'more equal', you'll either > have to be honest about the problems in RRDP, or the remove text > suggesting rsync is not adequate. I understand that you have a different perspective, but by using the term FUD I believe you are second-guessing my, and other people's motivation. I prefer that we can have this discussion while respecting each other's viewpoint. The fist motivation is based on the experience (and measurements and experiments) of repository operators. In the RPKI there is an asymmetry in the amount of RPs vs repositories. With *recursive* rsync the server needs to invest CPU and memory in a dialogue with each client to work out the optimal minimal delta, i.e. optimise for bandwidth. This is a scaling problem where server CPU and memory form a bottleneck. Yes, you can invest lots in multiple servers, multiple PoPs etc, but this asymmetry does not change fundamentally. What RRDP does, is that it protects the server. By letting the server publish immutable data (except for the notification file) the work is pushed to the client side, where it can scale in parallel. You don't have to use a CDN to benefit. A simple https proxy such as nginx can serve these files from memory, and the server bottleneck is bandwidth, not CPU/memory. The bandwidth bottleneck can be mitigated further by using a CDN, or your own distributed caching proxies. This is magnitudes easier and cheaper than scaling up rsync. So, while RRDP may not always give an immediate performance benefit to the clients, it does give great benefits to the server. The biggest benefit to the RPs is indirect: the server is just much less likely to become unavailable due to load or scaling issues. 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. All this said, if it helps to have a more constructive discussion on the content of suggested changes to RFCs in this document, by leaving the motivation out of the document itself, then that also works for me. >> Currently RRDP is optional. This document seeks to make it mandatory, >> and indeed preferred. Earlier versions of this document went further, >> but this has been removed. >=20 > I don't really see the point of making it mandatory, especially when = the > benefits of RRDP appear to be somewhat exaggerated. Arguably RSYNC is > the simpler of the two protocols, making for a great mandatory > lowest common denominator. RRDP being optional, and preferred if > available (aka the current situation) seems to strike a good balance. = No > new draft needed? First of all, let me remind you that this is a planning document. It has been stated multiple times that it may never become RFC. If it is = overtaken by events then this is a feature, and not a bug. That said, the document contains suggestion for updates to existing RFC that I believe are still relevant: - Fallback from RRDP to rsync When RRDP was specified the idea was that it would be highely available and equivalent to rsync content. Fallback was optional in the RRDP RFC. = As mentioned in 3.1 of prefer-rrdp the word 'could' was used in this = context. Since then the WG has made it clear that they want fallback to be = mandatory. I am not arguing against that here, but I believe that means that we = still need updates to the RRDP RFC to make this clear. And you will note that there is some additional text, based on operator feedback, to ask RPs to use preventive measures to prevent that they all fall back at the same = time. Furthermore it was found, that while it was clearly stated that the RRDP files MUST be available - this availability was treated as optional in = the experiment that demonstrated that not all RPs perform the fallback to = rsync. Because of that I believe that an update to 6481 is also warranted to = make it clear to repository operators that all access mechanisms should be treated as first class citizens. - Mandatory for RPs As said, the benefits of RRDP are mostly on the server side, but for = that repository operators need all RPs to support and prefer it. This seems to be the case today, but since this support is not mandatory this could change at any time. Because of this I think we need something like the text suggested in section 3.3. - Mandatory for repositories This is discussed in section 3.2. Personally I care less about this, because RPs need to support fallback to rsync anyway. I still think that repositories would do very well to protect themselves by having both RRDP and rsync. Since you said: >>> We should actively encourage operators to deploy both protocols. I am not sure that you actually disagree with this. Kind regards, Tim From nobody Wed Oct 27 04:48:34 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187673A10A9 for ; Wed, 27 Oct 2021 04:48:32 -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 (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 T2RdTo-mwAn0 for ; Wed, 27 Oct 2021 04:48:28 -0700 (PDT) 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 C954F3A0A20 for ; Wed, 27 Oct 2021 04:48:27 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id r4so9365590edi.5 for ; Wed, 27 Oct 2021 04:48:27 -0700 (PDT) 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=f7ZcDDA/PoQbV+bDfl68/kc48AQ5lDVPnRrakgiyNcM=; b=N6mY2R3WtIHZjqmOXORVeTC3XdLOO1tLExcbtgL/Oq4qpRmtsKNvTWld8uss/foPlt UykpdTu+imZnVQH7MoVZ0LlAYfSODKYcvn5ksx30sL79wxl1YNoKNF5WomZMhcKYenLE kNCqme0xGm0K9DdSOlc7e6EQXSCW7uuHCra+s= 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=f7ZcDDA/PoQbV+bDfl68/kc48AQ5lDVPnRrakgiyNcM=; b=XBtWN0Ro5sT5scwsIxlEAX0ehBhSNEfMD7ugXnHICI6i3xHQPhk9RMQY9Cc+iymk/6 AQcIhLrWhjrGzpnyuEm2zKSNyGbDvemo6cRN7c0H1L1mlLx6/8yTMOVJHyOz0Ds7xEKR V5Repk21icNgcDzbB6nrSLmlzl9+06zNL66LE5U2iA0b0FsCv3f52NnDiuEESyMuI6p6 WmcWQ6kqSAaDHktNzlQrIrlE17u7rl/BL2PuL+6+IYQJ2r9imMpkPxp9zpAE1iKu1gLf 6zcv4J/109oyxZweiJvr3Uvps+7vatdlpm12574h1K/9FRxCAkkN4Hn/9/UX0ibUR+2d g5/Q== X-Gm-Message-State: AOAM532RBunWOjDAbq1BC4uG5YCtJLodjLkQj7CvyHPa4t0AUIqoLihs XMc1Ro9pWGYzuskMuu9zHmgHmSWUoufcHiqD X-Google-Smtp-Source: ABdhPJys/qHAY/2qCRVqjGI5jVEi22z4WNJ33ReupkS4uzq4U1o0q67Bgj6S6Xy7FUjpPsw9lt4AEA== X-Received: by 2002:a17:907:8693:: with SMTP id qa19mr37742649ejc.154.1635335304644; Wed, 27 Oct 2021 04:48:24 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id p23sm13574203edw.94.2021.10.27.04.48.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 04:48:24 -0700 (PDT) Date: Wed, 27 Oct 2021 13:48:22 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 11:48:32 -0000 On Wed, Oct 27, 2021 at 12:40:36PM +0200, Tim Bruijnzeels wrote: > With *recursive* rsync the server needs to invest CPU and memory in a > dialogue with each client to work out the optimal minimal delta, i.e. > optimise for bandwidth. > > This is a scaling problem where server CPU and memory form a bottleneck. > Yes, you can invest lots in multiple servers, multiple PoPs etc, but > this asymmetry does not change fundamentally. You are holding it up-side down. The RIRs and NIRs are in an excellent position to absorb some of the computational cost. It is an excellent property that server and client have a dialogue to optimize the transfer. Why offload all cost to the RPs? > What RRDP does, is that it protects the server. Yes, and zero protection for RPs. > So, while RRDP may not always give an immediate performance benefit to > the clients, it does give great benefits to the server. I appreciate you admitting that RRDP is not performant. > That said, the document contains suggestion for updates to existing RFC > that I believe are still relevant: > > - Fallback from RRDP to rsync Given the fact that RRDP is optional, it logically follows a fallback to rsync is mandatory. Because rsync is the only mandatory-to-implement protocol. I don't see the purpose of this document. Kind regards, Job From nobody Wed Oct 27 05:06:48 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088893A10F1 for ; Wed, 27 Oct 2021 05:06:47 -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=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 QoOs8JX_0esb for ; Wed, 27 Oct 2021 05:06:42 -0700 (PDT) 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 43B6A3A10F2 for ; Wed, 27 Oct 2021 05:06:42 -0700 (PDT) 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=auUEPoCrUSGG7ONoR6HWuxJD8D78KfvmWFszdTV0uo8=; b=ZRIQ1CExMXf6KVV7lqmedLys gQ3ZE51UjtVurV3E0ogcYpaZ6Wv/p/3YcW5H86gqR7PCnjq0njiqnOwUnsGd9F7zGGYSV4W9AXnjc EsVE3zPOMnhDw8K9Y+zcX43Btsl1VYBuimip2FEqW9tZBoiViP3S/44vbRSTjVo0GXIeNj/nHMdyC RUcGeM67zNt6tK9LSPvB9XZppKQ4u8j7p7n7hx+IrhziCY23rPFPP17Mbp5187Nr1FytuSnJWuc2q 6Bmj8a1C3up9bpuVTyUKcV2sOqicVJ9dzImM/wTA51eXWgoFwA018WZ+Th1fPj8HALhdLMgXtx8Rt tsZYq8r9wA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:35316) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mfhhM-0003o9-N5; Wed, 27 Oct 2021 14:06:28 +0200 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 ) id 1mfhhM-0005gn-Jj; Wed, 27 Oct 2021 14:06:28 +0200 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 In-Reply-To: Date: Wed, 27 Oct 2021 14:06:28 +0200 Cc: Tim Bruijnzeels , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <10A7EE77-51E5-49F1-89C8-B3C927391430@ripe.net> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> To: Job Snijders X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e13d17c25c05bad6eee0c150c87512c0d2 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 12:06:47 -0000 Hi Job, > On 27 Oct 2021, at 13:48, Job Snijders = wrote: >=20 > On Wed, Oct 27, 2021 at 12:40:36PM +0200, Tim Bruijnzeels wrote: >> With *recursive* rsync the server needs to invest CPU and memory in a >> dialogue with each client to work out the optimal minimal delta, i.e. >> optimise for bandwidth. >>=20 >> This is a scaling problem where server CPU and memory form a = bottleneck. >> Yes, you can invest lots in multiple servers, multiple PoPs etc, but >> this asymmetry does not change fundamentally. >=20 > You are holding it up-side down. The RIRs and NIRs are in an excellent > position to absorb some of the computational cost. It is an excellent > property that server and client have a dialogue to optimize the > transfer. Why offload all cost to the RPs? >=20 >> What RRDP does, is that it protects the server. >=20 > Yes, and zero protection for RPs. I would at least say that it gives some protection to RPs. After you = (rightfully) pointed out that RPs should do TLS validation, at least it prevents MITM = attacks where an attacker could selectively remove CAs from validation. Pulling off the same for RRDP is harder (TLS certificates) and publicly = visible (CT logs). I do acknowledge that RRDP has several weaknesses. A na=C3=AFeve = implementation acts as if the server is trusted, and while that may have been feasible = without delegated RPKI, by now, it is a risk. Kind regards, Ties >=20 >> So, while RRDP may not always give an immediate performance benefit = to >> the clients, it does give great benefits to the server. >=20 > I appreciate you admitting that RRDP is not performant. >=20 >> That said, the document contains suggestion for updates to existing = RFC >> that I believe are still relevant: >>=20 >> - Fallback from RRDP to rsync >=20 > Given the fact that RRDP is optional, it logically follows a fallback = to > rsync is mandatory. Because rsync is the only mandatory-to-implement > protocol. >=20 > I don't see the purpose of this document.=20 >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Oct 27 06:08:58 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4655F3A0ADC for ; Wed, 27 Oct 2021 06:08:56 -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 yJXfSFGrhHpS for ; Wed, 27 Oct 2021 06:08:51 -0700 (PDT) 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 230533A0B02 for ; Wed, 27 Oct 2021 06:08:34 -0700 (PDT) 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 D452495; Wed, 27 Oct 2021 13:08:31 +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=1635340111; bh=VN23LvbNQVLK29spkdTZLP40yUvYtyiYqjejH5nfQeI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=WQUIbgcqQ6y4sOVrNOaHlurt5Z/N62ytzU8A4+bxEPuwOF4tXBHKoYeB/VTTxusm4 8t3w9cfTU9rXEM20yPUJXpr4KWKKR2bmJZITQz98x/hPS0A7Ja3alWUdQBczF28cCK 4WUF4v5KfZXV8nh7kqAtV+oCw8KMk/YAjgqf8lACT1aatoC2xYR8HPxhwgxhbxaPCT fKb4/+i5Jr3WdaZZFAAFuszlsUBWf2ExLCjd3Yaa29VvsW6lQ5ACka8aHaZLSbKMkN sGPhe7R4Y2Lk2hmz89fN3fZJMbyuy09d7gxff4lNZr5uE1iPaBTJ8BmFvuqj+QhP5b 07ZUKsL6umxzg== 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 In-Reply-To: Date: Wed, 27 Oct 2021 15:08:28 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> To: Job Snijders Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 13:08:56 -0000 > On 27 Oct 2021, at 13:48, Job Snijders wrote: > > On Wed, Oct 27, 2021 at 12:40:36PM +0200, Tim Bruijnzeels wrote: >> With *recursive* rsync the server needs to invest CPU and memory in a >> dialogue with each client to work out the optimal minimal delta, i.e. >> optimise for bandwidth. >> >> This is a scaling problem where server CPU and memory form a bottleneck. >> Yes, you can invest lots in multiple servers, multiple PoPs etc, but >> this asymmetry does not change fundamentally. > > You are holding it up-side down. The RIRs and NIRs are in an excellent > position to absorb some of the computational cost. It is an excellent > property that server and client have a dialogue to optimize the > transfer. Why offload all cost to the RPs? You forgot to quote a bit from my email: >> The biggest benefit to the RPs is indirect: the server is just much less >> likely to become unavailable due to load or scaling issues. I don't think there is a need to be overly dramatic about the cost for RPs. The delta is actually pre-calculated by the server. The remaining cost is mainly because of the size of some notification files, which has grown excessive in the wild. This is being addressed. The main challenge for an RRDP server is to get the balance right in the size of the notification file and the amount of deltas to support. If the server keeps too many deltas then the download and parsing cost becomes unreasonable. If it keeps too few then RPs who update infrequently will be forced to use snapshots. >> What RRDP does, is that it protects the server. > > Yes, and zero protection for RPs. ahh.. the straw man, nice >> So, while RRDP may not always give an immediate performance benefit to >> the clients, it does give great benefits to the server. > > I appreciate you admitting that RRDP is not performant. ahh.. the straw man, nice >> That said, the document contains suggestion for updates to existing RFC >> that I believe are still relevant: >> >> - Fallback from RRDP to rsync > > Given the fact that RRDP is optional, it logically follows a fallback to > rsync is mandatory. Because rsync is the only mandatory-to-implement > protocol. > > I don't see the purpose of this document. Except that 8182 specifically says 'could'. If you think that fallback is mandatory then I don't see why would object to an update to 8182 that makes this clear. > > Kind regards, > > Job From nobody Wed Oct 27 06:48:56 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4FC3A0C15 for ; Wed, 27 Oct 2021 06:48:54 -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 (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 7_y1sOofKy_c for ; Wed, 27 Oct 2021 06:48:49 -0700 (PDT) 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 343523A0C0E for ; Wed, 27 Oct 2021 06:48:49 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id y12so11031428eda.4 for ; Wed, 27 Oct 2021 06:48:49 -0700 (PDT) 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=T2LwPxrbYUepnrYaCf3pO9YNQXMsusYL48oszIOqf/U=; b=njyjTv936gcvqD+zZiQWToYwWoWhkkhVakfYKPS1Ka0MUZeUI/hA2y4HQWdsWa6MZz w5YEpWccT8xlBlTxfS3FdG1peJBZ1qoCxcLcPFLrZcvZ2tUS3PyBYgC8exS25bk3gUVV E5VO7Hkv8bYDgIUVBBpMPnLHyCm+QmSqrZikE= 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=T2LwPxrbYUepnrYaCf3pO9YNQXMsusYL48oszIOqf/U=; b=Y6zUHwH3ksXE7sYqQg5RuSBaT2rjRl1sF0BRfRFkCH2oBhY//5ilTjuaGL3JxJwH1J 8+W9Lf+mIdSRFnb4o6gal//flk/ver/bpDori86ofTAUO8QKV32DW7RZHkP9R5uTubYl AWimoR9lN+MmqkJ1yb7UCCjzSkqkf9EXJkWt2yhBN7De0irEa7JsJVHvUQlNiiaLvJKA iibwE6GSzCFmzt3xdMAY3fB+WhWc6aPfJ4jSLL7QmV6JbzvTzE0vvVSQvjbpO2AIeV1j ooZYEXbuhRz376FvB6FtOUrqrp/3nxQ7ZHcpjmPF6KgA+OqybGUJS8+ybEbwn+Mrvr0g 3Sjg== X-Gm-Message-State: AOAM532TMi6HxtTXONCJ5PNA0R3wE+QS+PVOi7xlLTxH8BTguA3wEa/q FQdTuoMkXgCSdKn4Y2O8+KM+2fyuntRfW/RW X-Google-Smtp-Source: ABdhPJw6WX7QPUiTQUBypdTdhrsMjmYPkKAjISzbPyR/PEDTvPUmM76jTuVvaIZmaAfaL4E/U+CLzw== X-Received: by 2002:a05:6402:b07:: with SMTP id bm7mr45159489edb.133.1635342526710; Wed, 27 Oct 2021 06:48:46 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id b19sm10735217ejc.107.2021.10.27.06.48.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 06:48:46 -0700 (PDT) Date: Wed, 27 Oct 2021 15:48:44 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 13:48:55 -0000 On Wed, Oct 27, 2021 at 03:08:28PM +0200, Tim Bruijnzeels wrote: > I don't think there is a need to be overly dramatic about the cost for > RPs. The delta is actually pre-calculated by the server. You appear to operate under the assumption that RRDP servers will always behave correctly, and in the best interest of RPs. This doesn't hold true. Software defects, bit flips, or even malicious attacks are possible. Kind regards, Job From nobody Wed Oct 27 10:53:38 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA33A0E7A for ; Wed, 27 Oct 2021 10:53:37 -0700 (PDT) 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 0YKrFzGAmcCw for ; Wed, 27 Oct 2021 10:53:34 -0700 (PDT) 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 853573A0E79 for ; Wed, 27 Oct 2021 10:53:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mfn7B-0007kA-9A; Wed, 27 Oct 2021 17:53:29 +0000 Date: Wed, 27 Oct 2021 10:53:28 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: SIDR Operations WG In-Reply-To: <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <5770C859-3413-4F92-A8B4-8562B4891201@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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 17:53:37 -0000 > The fist motivation is based on the experience (and measurements and > experiments) of repository operators. where can we find these data? would be useful to cite it in the next rev of draft-ietf-sidrops-rpki-rov-timing :) at the 10,000km level, all PPs experience the same RP query profile. i am not aware of load issues being experienced by operators of PPs. would love to hear of measurements. randy From nobody Wed Oct 27 19:12:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EDA3A17B5 for ; Wed, 27 Oct 2021 19:12:21 -0700 (PDT) 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 gYOVOj9h8aIk for ; Wed, 27 Oct 2021 19:12:20 -0700 (PDT) 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 46DCB3A17B7 for ; Wed, 27 Oct 2021 19:12:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mfutq-0000KD-Pi; Thu, 28 Oct 2021 02:12:15 +0000 Date: Wed, 27 Oct 2021 19:12:14 -0700 Message-ID: From: Randy Bush To: Ties de Kock Cc: sidrops In-Reply-To: References: <2021102709482430541324@cnnic.cn> 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: Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 02:12:22 -0000 > Because I would consider it a bug if a single prefix being removed > caused all VRPs on the ROA to be withdrawn and then announced again > over RTR. as it is within the specs, it depends on the implementation of the CA, the PP, and the RP. have fun setting up the NxMxL experiment :) > * (initial situation): A CA with one ROA with many prefixes for a specific AS > on an internal test environment for RIPE NCC RPKI dashboard. > * The CA has roa for that AS with many prefixes in it. > * (user): Deletes one prefix for that AS from the CA. > * (system): re-creates the ROA (file), new ROA replaces old one does the publication protocol have a Replace operation? i do not remember it. if not, it's either a create and a delete or a delete and a create. my memory is that ordering is not discussed. and things go wobbly from there. > In my opinion, if a RP or CA causes all pairs to be > withdrawn temporarily, it is a bug in the software stack. bug in what sense? protocol/rfc violation or just the normal ill advised coding? > A CA can (and should) publish this change without an intermediate > state in which pairs disappear. but it might not. luckily we have not seen questionalble programming practice in rpki implementations > p.s. The software I used was: Routinator 0.10.1, RIPE NCC CA software > cb9e889f4, rpki-rtr-client, wireshark thanks for actually describing your experimental setup. i wish we all were good about this. for me, the goal here is simplicity. to quote a friend with whom i agree I seem to remember you (Randy) jumping up and down about how operators don't give a rat's about the AS number per se, it's just a tool: operators think about this in terms of prefixes, and what operators care about are the prefixes, so arbitrarily stuffing a bunch of prefixes into a single object is premature optimization at the expense of simplicity and fate sharing. I think the original motivation was just trying to squeeze out as many bits as possible, on the theory that ROAs might end up being flooded inline via BGP, in much the same spirit as the bizarre encoding of prefixes as bit strings in RFC 3779. Once inline BGP flooding was off the table, size became relatively unimportant (RPKI objects are tiny compared to the average kitten video), so operational fate sharing and user interface simplicity seemed like more pressing issues. Of course, no bad idea ever dies, so there are people whining about wanting to stuff RPKI into inline BGP again.... as to that latter, have we learned nothing about overly tight coupling and interdependence from facebook? the lesson there is nothing new, just shoved in the world's face. privacy and security are not the same since snowden. wrapping things in a tightly over-bound harball should not be the same since facebook. but i digress. randy From nobody Thu Oct 28 00:20:44 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19123A0D5F for ; Thu, 28 Oct 2021 00:20:41 -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 4-UM8vi5uDmH for ; Thu, 28 Oct 2021 00:20:36 -0700 (PDT) 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 2BC103A0D23 for ; Thu, 28 Oct 2021 00:20:35 -0700 (PDT) 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=+FduZbfgcQorj4gsbjfO1nb0u8B14kHN8cdRr2XthfU=; b=TcI3DaKRLKHpWclmU+X1ipZC THeRhRtr55a/XIlopqGU9qC+sHwa2ga3CPcp6+HG2ixQQFVei8Zk4nhzW+gkazp2N79MbN1cPUSI/ Zk8dvgqx6r1I4qCDUbr5Lp4kws5iXvbS+QtfruTXbvb0j+C0mrC1bH/TqaytOS7VRIXZ1/4JwNknI QtvRrfKQLs68767l3ZzWrlC5Z0Nz4aKpntz8pEI6qbdSWvwAm6O/8NodnVpBG1lx5F/n2DLnZQT9s 2Kh4INye+y7TB0U7j2JvfeYHlfiQ8pPFjD0gP5f3yNou3wQphzLTYaDkpt7rzaJXgtsp5ZF5XpLLD kuxx/47fGQ==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:47610) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mfziC-0009P8-Ae; Thu, 28 Oct 2021 09:20:32 +0200 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 ) id 1mfziC-0005Vq-5n; Thu, 28 Oct 2021 09:20:32 +0200 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 In-Reply-To: Date: Thu, 28 Oct 2021 09:20:31 +0200 Cc: sidrops Content-Transfer-Encoding: quoted-printable Message-Id: <7F626E58-6ED9-4C14-BFC2-8D65BC422D1D@ripe.net> References: <2021102709482430541324@cnnic.cn> To: Randy Bush X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e14f7b21a4044e6af59004b7e37e80ba31 Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 07:20:42 -0000 Hi Randy, > On 28 Oct 2021, at 04:12, Randy Bush wrote: >=20 >> Because I would consider it a bug if a single prefix being removed >> caused all VRPs on the ROA to be withdrawn and then announced again >> over RTR. >=20 > as it is within the specs, it depends on the implementation of the CA, > the PP, and the RP. have fun setting up the NxMxL experiment :) Indeed, the number of permutations is not pretty. Since you need a = consistent set of objects for the RP to accept the content of a PP, I would focus = on the CA and RTR implementation when setting up the experiment. >=20 >> * (initial situation): A CA with one ROA with many prefixes for a = specific AS >> on an internal test environment for RIPE NCC RPKI dashboard. >> * The CA has roa for that AS with many prefixes in it. >> * (user): Deletes one prefix for that AS from the CA. >> * (system): re-creates the ROA (file), new ROA replaces old one >=20 > does the publication protocol have a Replace operation? i do not > remember it. if not, it's either a create and a delete or a delete = and > a create. my memory is that ordering is not discussed. >=20 > and things go wobbly from there. "publish with a hash", mismatching hash results in an error (rfc8181 = 2.2). In practice, an implementation needs to abort the whole operation if an = error occurs (iirc [1] does). Otherwise, updating a single object for a CA = would almost always [2] result in a consistency problem. I agree that ordering is under-specified in 8181. >=20 >> In my opinion, if a RP or CA causes all pairs to be >> withdrawn temporarily, it is a bug in the software stack. >=20 > bug in what sense? protocol/rfc violation or just the normal ill > advised coding? That depends on where it happens - and I had to look it up. If this = happens in an RTR pdu, I think this is a protocol violation since this is not the = minimal set of changes (rfc8210 5.3). >> A CA can (and should) publish this change without an intermediate >> state in which pairs disappear. >=20 > but it might not. luckily we have not seen questionalble programming > practice in rpki implementations It might not. But in that case, it would publish an intermediate state = that does not reflect the intent of the human operating the CA. Again, bug. >=20 >> p.s. The software I used was: Routinator 0.10.1, RIPE NCC CA software >> cb9e889f4, rpki-rtr-client, wireshark >=20 > thanks for actually describing your experimental setup. i wish we all > were good about this. >=20 > for me, the goal here is simplicity. to quote a friend with whom i > agree >=20 > I seem to remember you (Randy) jumping up and down about how > operators don't give a rat's about the AS number per se, > it's just a tool: operators think about this in terms of prefixes, > and what operators care about are the prefixes, so arbitrarily > stuffing a bunch of prefixes into a single object is premature > optimization at the expense of simplicity and fate sharing. >=20 > I think the original motivation was just trying to squeeze out as > many bits as possible, on the theory that ROAs might end up being > flooded inline via BGP, in much the same spirit as the bizarre > encoding of prefixes as bit strings in RFC 3779. Once inline BGP > flooding was off the table, size became relatively unimportant = (RPKI > objects are tiny compared to the average kitten video), so > operational fate sharing and user interface simplicity seemed like > more pressing issues. >=20 > Of course, no bad idea ever dies, so there are people whining about > wanting to stuff RPKI into inline BGP again.... >=20 > as to that latter, have we learned nothing about overly tight coupling > and interdependence from facebook? the lesson there is nothing new, > just shoved in the world's face. privacy and security are not the = same > since snowden. wrapping things in a tightly over-bound harball should > not be the same since facebook. but i digress. As a CA operator, "one prefix per ROA" is not simpler (and would cause = ~5x more objects to sign, transfer, and serve). I don't think this should be = blanket advice; it is a trade-off between failure modes (e.g. fate-sharing vs = ROAs expiring at a different time). The elephant in the room is fate-sharing = at the CA level and the brittleness that fate sharing by manifest lifetime = introduces. If routers frequently encounter the mass withdrawal + publication = described, a single prefix per roa may be a good workaround for that bug, and I would = support that if needed. Clarification from the authors on the situation where = this behaviour was encountered would help.=20 Kind regards, Ties [1] https://github.com/RIPE-NCC/rpki-publication-server [2] the exception that I can think of is the CA certificate signed by a = TAL's public key >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Oct 28 01:34:24 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151513A080E for ; Thu, 28 Oct 2021 01:34:23 -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 Uq6rPZu0bXTh for ; Thu, 28 Oct 2021 01:34:17 -0700 (PDT) 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 E7E413A080B for ; Thu, 28 Oct 2021 01:34:16 -0700 (PDT) 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 198FA97; Thu, 28 Oct 2021 08:34:08 +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=1635410046; bh=qWJswOdLSpFaFFEtvAzAdBS6hHbRPWTAdwCLCT5Ms0A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=w1MuHW2wjEmOE4v2E9LWkGQKpWl2B4depNsDB72bJk2WBmNzTFRAd4/mU6lzdn2Xj GMDxbpzVI7sRZPrFHOh/ws0JGfUCnRLTvjNOFfDcYNA42tCiBT5AtKx8XhTafIqUa9 ND0VwI5loY4Xrfrcd8IEolOSK43lrEE2qQLv+2K7B3husoIIpP3sUWO4rWO+ODxVS2 nDo/6rohZEhwaGrdwtqq/0xUUAYljpnHAyj7NC2o4LwVOx6VT5M4/fXLiJZz48a3Li 1wXMF+nXhzzPYdk4Yr8f8MV2zeUwnu0WQGiZ6YCQ5ZKclA4yO+SHsLOOgrern4FaU8 UBmNUOLApMqaQ== 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 In-Reply-To: Date: Thu, 28 Oct 2021 10:34:03 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: 7bit Message-Id: <81AEFAFD-795E-4D73-A02F-465A925FC534@nlnetlabs.nl> References: <163489282491.21742.16231692563458154079@ietfa.amsl.com> <476C2CFC-2CD2-4369-908E-EDD13048F351@nlnetlabs.nl> <5770C859-3413-4F92-A8B4-8562B4891201@nlnetlabs.nl> To: Randy Bush Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 08:34:23 -0000 > On 27 Oct 2021, at 19:53, Randy Bush wrote: > >> The fist motivation is based on the experience (and measurements and >> experiments) of repository operators. > > where can we find these data? would be useful to cite it in the next > rev of draft-ietf-sidrops-rpki-rov-timing :) https://www.ietf.org/proceedings/86/slides/slides-86-sidr-2.pdf https://www.ietf.org/proceedings/89/slides/slides-89-sidr-6.pdf > at the 10,000km level, all PPs experience the same RP query profile. i > am not aware of load issues being experienced by operators of PPs. > would love to hear of measurements. Please feel free to add your own. But bear in mind that the current load on a small PP where the majority of RPs will use RRDP if it is available, is not the same as the potential load of all RPs querying a large PP. The RIPE NCC repository today is 287MB in 73k objects, and looking at how it has been growing, it can be expected to get bigger. Especially if BGPSec would take off and/or ASPA is added. > > randy From nobody Thu Oct 28 01:57:38 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D9D3A08AE; Thu, 28 Oct 2021 01:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nhnpPZbaTkZ7; Thu, 28 Oct 2021 01:57:30 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964033A08A9; Thu, 28 Oct 2021 01:57:30 -0700 (PDT) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HfzrM6MBGz680vC; Thu, 28 Oct 2021 16:54:11 +0800 (CST) Received: from dggpemm100006.china.huawei.com (7.185.36.196) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 28 Oct 2021 10:57:26 +0200 Received: from dggeme757-chm.china.huawei.com (10.3.19.103) by dggpemm100006.china.huawei.com (7.185.36.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.15; Thu, 28 Oct 2021 16:57:24 +0800 Received: from dggeme757-chm.china.huawei.com ([10.6.64.72]) by dggeme757-chm.china.huawei.com ([10.6.64.72]) with mapi id 15.01.2308.015; Thu, 28 Oct 2021 16:57:24 +0800 From: "shenming (A)" To: "draft-ymbk-8210bis@ietf.org" , "randy@psg.com" , "sra@hactrn.net" CC: "sidrops@ietf.org" Thread-Topic: Some question about the ASPA PDU in draft-ymbk-8210bis Thread-Index: AdfL2cT1ITCyCDF6S8qp1iBGzFmiKg== Date: Thu, 28 Oct 2021 08:57:24 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.153.161] Content-Type: multipart/alternative; boundary="_000_d2dc10f8fdaa45709d4e43b93791ed50huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Sidrops] Some question about the ASPA PDU in draft-ymbk-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 08:57:36 -0000 --_000_d2dc10f8fdaa45709d4e43b93791ed50huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, According to the Section 3 of draft-ietf-sidrops-aspa-profile-06, the ASPA = content has AFI info. But the ASPA PDU defined in draft-ymbk-8210bis doesn't have AFI info. The two infomation is inconsistent. Perhaps is it the missing AFI information here? Best regards, Ming Shen This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, b= ut not limited to, total or partial disclosure, reproduction, or disseminat= ion) by persons other than the intended recipient(s) is prohibited. If you = receive this e-mail in error, please notify the sender by phone or email im= mediately and delete it! --_000_d2dc10f8fdaa45709d4e43b93791ed50huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors,

 

According to the Section 3 of d= raft-ietf-sidrops-aspa-profile-06, the ASPA content has AFI info.

But the ASPA PDU defined in dra= ft-ymbk-8210bis doesn't have AFI info.

The two infomation is inconsist= ent.

Perhaps is it the missing AFI i= nformation here?

 

Best regards,=

Ming Shen

 

This e-mail and its attachments= contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. A= ny use of the information contained herein in any way (including, but not l= imited to, total or partial disclosure, reproduction, or dissemination) by = persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or email immediately and delete it!

 

--_000_d2dc10f8fdaa45709d4e43b93791ed50huaweicom_-- From nobody Thu Oct 28 02:16:58 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73AB3A0901; Thu, 28 Oct 2021 02:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLMj7KhqBIGu; Thu, 28 Oct 2021 02:16:52 -0700 (PDT) Received: from smtpbg587.qq.com (smtpbg126.qq.com [106.55.201.22]) (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 AD2B73A0900; Thu, 28 Oct 2021 02:16:46 -0700 (PDT) X-QQ-mid: bizesmtp41t1635412600t3vlv52m Received: from smtpclient.apple (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Thu, 28 Oct 2021 17:16:39 +0800 (CST) X-QQ-SSF: 00100000002000C0L000B00A0000000 X-QQ-FEAT: dpyQmELDBxFAJRcwLm8RkM9C1S2slnQOriP8FRSIrPXfkFfIHFNmMtL7D6ZUF m9n22WDk6v0zgqG0TbSGXxF/RPzaYDT/wV1BTwDVrnb0nQYNang5OnyhoRDDLn4tcha98Dh wybWM56dO9IXYK2qfTIm8PzS4FC28I6L7KweZ/dE/vHVyEL9I3ueRAUqxpF7ZXAkGqwgu9R IlrlhiuAF7w+PBR2S/p2LAN8FiHI8FaczauFEYWhjYYStbsnFd49kx2xIpJOGlZ+dZn3XLD bLHKc8k/re4BXQ2NyfG4M1EkIgOxW1l6E71cxBn2nEZvV2YrUBe8vp/WJoEC+vEO/0I/4MZ RhZyUR2 X-QQ-GoodBg: 0 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Di Ma In-Reply-To: Date: Thu, 28 Oct 2021 17:16:38 +0800 Cc: "draft-ymbk-8210bis@ietf.org" , "randy@psg.com" , "sra@hactrn.net" , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "shenming (A)" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:juicybun.cn:qybgspam:qybgspam2 Archived-At: Subject: Re: [Sidrops] Some question about the ASPA PDU in draft-ymbk-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 09:16:57 -0000 Ming, draft-ymbk-8210bis does have AFI info as described in Section 5.12 (ASPA = PDU) where the FLAG indicates AFI. However, I think you are initiating a necessary discussion here. Section 5.12 (ASPA PDU) dose not give a instance for ASN AFI and = IPv4/IPv6 address FLAG seem not be in alignment with in which IPv4=3D1 = and IPv6=3D2 I am sorta confusing when we were working on its implementation. The authors might as well say more about this.=20 Di [IANA-AFI] http://www.iana.org/assignments/address-family-numbers. > 2021=E5=B9=B410=E6=9C=8828=E6=97=A5 16:57=EF=BC=8Cshenming (A) = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Dear authors, > =20 > According to the Section 3 of draft-ietf-sidrops-aspa-profile-06, the = ASPA content has AFI info. > But the ASPA PDU defined in draft-ymbk-8210bis doesn't have AFI info. > The two infomation is inconsistent.=20 > Perhaps is it the missing AFI information here? > =20 > Best regards, > Ming Shen > =20 > This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it! > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Oct 28 08:04:24 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19723A0905; Thu, 28 Oct 2021 08:04:22 -0700 (PDT) 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 1Yuegvj3sjIt; Thu, 28 Oct 2021 08:04:20 -0700 (PDT) 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 BDDB63A0906; Thu, 28 Oct 2021 08:04:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mg6x0-0002M3-U2; Thu, 28 Oct 2021 15:04:19 +0000 Date: Thu, 28 Oct 2021 08:04:18 -0700 Message-ID: From: Randy Bush To: "shenming (A)" Cc: "draft-ymbk-8210bis@ietf.org" , "sra@hactrn.net" , "sidrops@ietf.org" In-Reply-To: References: 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: Subject: Re: [Sidrops] Some question about the ASPA PDU in draft-ymbk-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 15:04:23 -0000 you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy On Thu, 28 Oct 2021 01:57:24 -0700, shenming (A) wrote: > > [1 ] > Dear authors, > > According to the Section 3 of draft-ietf-sidrops-aspa-profile-06, the ASPA content has AFI info. > But the ASPA PDU defined in draft-ymbk-8210bis doesn't have AFI info. > The two infomation is inconsistent. > Perhaps is it the missing AFI information here? > > Best regards, > Ming Shen > > This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > > [2 ] From nobody Thu Oct 28 18:04:10 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751F63A0821 for ; Thu, 28 Oct 2021 18:04:08 -0700 (PDT) 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 CK7heWOMNfqC for ; Thu, 28 Oct 2021 18:04:03 -0700 (PDT) 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 66CB33A0805 for ; Thu, 28 Oct 2021 18:04:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mgGJL-0003We-IO; Fri, 29 Oct 2021 01:03:59 +0000 Date: Thu, 28 Oct 2021 18:03:58 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG , North American Network Operators' Group 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: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 01:04:09 -0000 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 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 Thu Oct 28 19:01:10 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551F13A08CB for ; Thu, 28 Oct 2021 19:01:08 -0700 (PDT) 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, HTML_MESSAGE=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 0LhKLgBCG6nN for ; Thu, 28 Oct 2021 19:01:04 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2032B3A08CE for ; Thu, 28 Oct 2021 19:01:02 -0700 (PDT) Received: from CNNIC-THINK (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dp8DjbVXthE54XAA--.24370S2; Fri, 29 Oct 2021 10:00:59 +0800 (CST) Date: Fri, 29 Oct 2021 10:00:56 +0800 From: "YAN Zhiwei" To: "Ties de Kock" , randy Cc: sidrops References: <2021102709482430541324@cnnic.cn>, , , <7F626E58-6ED9-4C14-BFC2-8D65BC422D1D@ripe.net> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Mime-Version: 1.0 Message-ID: <2021102910005667608531@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart262603782625_=----" X-CM-TRANSID: AQAAf0Dp8DjbVXthE54XAA--.24370S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtry8XFWfZr15Ar4fKrWfKrg_yoWxKr15pF WFgw1xKFnrJ3W8J34kuwnrG3WY9rs5Gw43GF9Yg3y8CrZ8AFyI9r1IkF45uFW7Zwn3Jryj v34q9r1kZFn8ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Yb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjc xK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E 42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72 CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wCY 02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y 6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCT nIWIevJa73UjIFyTuYvjxUqRV1UUUUU X-CM-SenderInfo: h1dq6xplzhxq5fqqxugofq/ Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 02:01:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart262603782625_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIFRpZXMsDQpSUEtJIFJGQ3Mgc3BlY2lmeSB0aGUgY29tbXVuaWNhdGlvbiBwcm90b2Nv bHMgYmV0d2VlbiBkaWZmZXJlbnQgZW50aXRpZXMgKENBLCBQUCwgUlAsIEJHUC1Sb3V0ZXLigKYp IGFuZCB0aGUgZm9ybWF0IG9mIG9iamVjdHMuIEhvd2V2ZXIsIGRpZmZlcmVudCBpbXBsZW1lbnRh dGlvbnMgaGF2ZSBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZyBhbmQgZGVzaWduIGxvZ2ljIGR1cmlu ZyB0aGUgb3BlcmF0aW9uLiBUaGVuIGhvdyB0byBoYW5kbGUgbXVsdGlwbGUgcHJlZml4ZXMgdW5k ZXIgdGhlIHNhbWUgQVMgbWF5IGRpZmZlcmVudC4gDQpBcyBJIHRlc3RlZCB1c2luZyBEUkwtQ0Eg c29mdHdhcmUgd2l0aCB0aGUgZm9sbG93aW5nIDQgc3RhZ2VzOg0KDQoxLiBJbml0aWFsIHN0YWdl DQojIGNhdCBsb2FkX3JvYV9yZXF1ZXN0cyB0ZXN0LmNzdg0KMS4xLjEuMC8yNC0yNCAxMDAwMCAy NA0KMi4yLjIuMC8yNC0yNCAxMDAwMCAyNA0KI3Jwa2ljIC1pIHRlc3QgbG9hZF9yb2FfcmVxdWVz dHMgdGVzdC5jc3YNCg0KVGhlIFJPQSBjb250ZW50IGlzOg0KUk9BIFZlcnNpb246ICAgIDANClNp Z25pbmdUaW1lOiAgICAyMDIxLTEwLTI4VDA2OjQzOjMzWg0KYXNJRDogICAgICAgICAgIDEwMDAw DQphZGRyZXNzRmFtaWx5OiAxDQogICAgIElQQWRkcmVzczogMS4xLjEuMC8yNA0KICAgICBJUEFk ZHJlc3M6IDIuMi4yLjAvMjQNCg0KMi4gRGVsZXRlIGEgcHJlZml4DQojIGNhdCBsb2FkX3JvYV9y ZXF1ZXN0cyB0ZXN0LmNzdg0KMS4xLjEuMC8yNC0yNCAxMDAwMCAyNA0KDQojcnBraWMgLWkgdGVz dCBsb2FkX3JvYV9yZXF1ZXN0cyB0ZXN0LmNzdg0KDQpUaGUgUk9BIGNvbnRlbnQgaXM6DQpST0Eg VmVyc2lvbjogICAgMA0KU2lnbmluZ1RpbWU6ICAgIDIwMjEtMTAtMjhUMDY6NDQ6MjZaDQphc0lE OiAgICAgICAgICAgMTAwMDANCmFkZHJlc3NGYW1pbHk6IDENCiAgICAgSVBBZGRyZXNzOiAxLjEu MS4wLzI0DQoNCjMuIEluY3JlYXNlIGEgcHJlZml4DQojIGNhdCBsb2FkX3JvYV9yZXF1ZXN0cyB0 ZXN0LmNzdg0KMS4xLjEuMC8yNC0yNCAxMDAwMCAyNA0KMi4yLjIuMC8yNC0yNCAxMDAwMCAyNA0K DQojcnBraWMgLWkgdGVzdCBsb2FkX3JvYV9yZXF1ZXN0cyB0ZXN0LmNzdg0KDQpUaGUgUk9BIGNv bnRlbnQgaXM6DQpST0EgVmVyc2lvbjogICAgMA0KU2lnbmluZ1RpbWU6ICAgIDIwMjEtMTAtMjhU MDY6NDU6NDBaDQphc0lEOiAgICAgICAgICAgMTAwMDANCmFkZHJlc3NGYW1pbHk6IDENCiAgICAg SVBBZGRyZXNzOiAxLjEuMS4wLzI0DQogICAgIElQQWRkcmVzczogMi4yLjIuMC8yNA0KDQo0LiBy ZS1sb2FkDQojIGNhdCBsb2FkX3JvYV9yZXF1ZXN0cyB0ZXN0LmNzdg0KMS4xLjEuMC8yNC0yNCAx MDAwMCAyNA0KMi4yLjIuMC8yNC0yNCAxMDAwMCAyNA0KDQojcnBraWMgLWkgdGVzdCBsb2FkX3Jv YV9yZXF1ZXN0cyB0ZXN0LmNzdg0KDQpUaGUgUk9BIGNvbnRlbnQgaXM6DQpST0EgVmVyc2lvbjog ICAgMA0KU2lnbmluZ1RpbWU6ICAgIDIwMjEtMTAtMjhUMDY6NDU6NDBaDQphc0lEOiAgICAgICAg ICAgMTAwMDANCmFkZHJlc3NGYW1pbHk6IDENCiAgICAgSVBBZGRyZXNzOiAxLjEuMS4wLzI0DQog ICAgIElQQWRkcmVzczogMi4yLjIuMC8yNA0KDQpJdCBzaG93cyB0aGF0Og0KMS4gSW5jcmVhc2Ug b3IgZGVsZXRlIHRoZSBwcmVmaXggd2l0aGluIG9uZSBST0Egd2lsbCBjYXVzZSB0aGUgcmUtaXNz dWUgb2YgdGhlIFJPQSAoYm90aCB0aGUgdGltZSBhbmQgZmlsZSBuYW1lIGNoYW5nZWQpLiBUaGlz IHVwZGF0ZSBvZiBST0Egd2lsbCBsb29rcyBsaWtlIGEgbmV3IG9uZSBmb3IgdGhlIFBQIGFuZCBS UC4gVGhlbiB0aGUgQ0EgcmV2b2tlcyB0aGUgb2xkIG9uZS4gQW5kIGFjY29yZGluZ2x5IHRoZSBS UCBuZWVkcyB0byBzeW5jaHJvbml6ZSB0aGUgZGF0YS4gKE1heWJlIHRoZSBkZXNjcmlwdGlvbiBp biB0aGUgZHJhZnQgaXMgbm90IGFjY3VyYXRlIGVub3VnaC4gSXQncyBhcHBlY2lhdGUgaWYgeW91 IGNhbiBzdWdnZXN0IHRoZSBkZXNjcmlwdGlvbnMuKQ0KMi4gV2hpbGUsIHJlLWxvYWQgd2lsbCBu b3QgY2F1c2UgYW55IGNoYW5nZSBvZiB0aGUgUk9BIGZpbGUgYmVjYXVzZSB0aGUgc29mdHdhcmUg d2lsbCBjb21wYXJlIHRoZSBkYXRhIGluIHRoZSBjc3YgZmlsZS4NCg0KcHMuIEhlcmUgSSBhbSBu b3Qgc2F5aW5nIERSTC1DQSBoYXMgc2hvcnRjb21pbmcuDQpCUiwNCg0KDQoNCllBTiBaaGl3ZWkN CiANCkZyb206IFRpZXMgZGUgS29jaw0KRGF0ZTogMjAyMS0xMC0yOCAxNToyMA0KVG86IFJhbmR5 IEJ1c2gNCkNDOiBzaWRyb3BzDQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLXJvYS1jb25zaWRlcmF0aW9ucy0wMS50 eHQNCkhpIFJhbmR5LA0KIA0KPiBPbiAyOCBPY3QgMjAyMSwgYXQgMDQ6MTIsIFJhbmR5IEJ1c2gg PHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KPiANCj4+IEJlY2F1c2UgSSB3b3VsZCBjb25zaWRlciBp dCBhIGJ1ZyBpZiBhIHNpbmdsZSBwcmVmaXggYmVpbmcgcmVtb3ZlZA0KPj4gY2F1c2VkIGFsbCBW UlBzIG9uIHRoZSBST0EgdG8gYmUgd2l0aGRyYXduIGFuZCB0aGVuIGFubm91bmNlZCBhZ2Fpbg0K Pj4gb3ZlciBSVFIuDQo+IA0KPiBhcyBpdCBpcyB3aXRoaW4gdGhlIHNwZWNzLCBpdCBkZXBlbmRz IG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgQ0EsDQo+IHRoZSBQUCwgYW5kIHRoZSBSUC4g IGhhdmUgZnVuIHNldHRpbmcgdXAgdGhlIE54TXhMIGV4cGVyaW1lbnQgOikNCiANCkluZGVlZCwg dGhlIG51bWJlciBvZiBwZXJtdXRhdGlvbnMgaXMgbm90IHByZXR0eS4gU2luY2UgeW91IG5lZWQg YSBjb25zaXN0ZW50DQpzZXQgb2Ygb2JqZWN0cyBmb3IgdGhlIFJQIHRvIGFjY2VwdCB0aGUgY29u dGVudCBvZiBhIFBQLCBJIHdvdWxkIGZvY3VzIG9uIHRoZSBDQQ0KYW5kIFJUUiBpbXBsZW1lbnRh dGlvbiB3aGVuIHNldHRpbmcgdXAgdGhlIGV4cGVyaW1lbnQuDQogDQo+IA0KPj4gICogKGluaXRp YWwgc2l0dWF0aW9uKTogQSBDQSB3aXRoIG9uZSBST0Egd2l0aCBtYW55IHByZWZpeGVzIGZvciBh IHNwZWNpZmljIEFTDQo+PiAgICBvbiBhbiBpbnRlcm5hbCB0ZXN0IGVudmlyb25tZW50IGZvciBS SVBFIE5DQyBSUEtJIGRhc2hib2FyZC4NCj4+ICAgICogVGhlIENBIGhhcyByb2EgZm9yIHRoYXQg QVMgd2l0aCBtYW55IHByZWZpeGVzIGluIGl0Lg0KPj4gICogKHVzZXIpOiBEZWxldGVzIG9uZSBw cmVmaXggZm9yIHRoYXQgQVMgZnJvbSB0aGUgQ0EuDQo+PiAgKiAoc3lzdGVtKTogcmUtY3JlYXRl cyB0aGUgUk9BIChmaWxlKSwgbmV3IFJPQSByZXBsYWNlcyBvbGQgb25lDQo+IA0KPiBkb2VzIHRo ZSBwdWJsaWNhdGlvbiBwcm90b2NvbCBoYXZlIGEgUmVwbGFjZSBvcGVyYXRpb24/ICBpIGRvIG5v dA0KPiByZW1lbWJlciBpdC4gIGlmIG5vdCwgaXQncyBlaXRoZXIgYSBjcmVhdGUgYW5kIGEgZGVs ZXRlIG9yIGEgZGVsZXRlIGFuZA0KPiBhIGNyZWF0ZS4gIG15IG1lbW9yeSBpcyB0aGF0IG9yZGVy aW5nIGlzIG5vdCBkaXNjdXNzZWQuDQo+IA0KPiBhbmQgdGhpbmdzIGdvIHdvYmJseSBmcm9tIHRo ZXJlLg0KIA0KInB1Ymxpc2ggd2l0aCBhIGhhc2giLCBtaXNtYXRjaGluZyBoYXNoIHJlc3VsdHMg aW4gYW4gZXJyb3IgKHJmYzgxODEgMi4yKS4gSW4NCnByYWN0aWNlLCBhbiBpbXBsZW1lbnRhdGlv biBuZWVkcyB0byBhYm9ydCB0aGUgd2hvbGUgb3BlcmF0aW9uIGlmIGFuIGVycm9yDQpvY2N1cnMg KGlpcmMgWzFdIGRvZXMpLiBPdGhlcndpc2UsIHVwZGF0aW5nIGEgc2luZ2xlIG9iamVjdCBmb3Ig YSBDQSB3b3VsZA0KYWxtb3N0IGFsd2F5cyBbMl0gcmVzdWx0IGluIGEgY29uc2lzdGVuY3kgcHJv YmxlbS4NCiANCkkgYWdyZWUgdGhhdCBvcmRlcmluZyBpcyB1bmRlci1zcGVjaWZpZWQgaW4gODE4 MS4NCj4gDQo+PiBJbiBteSBvcGluaW9uLCBpZiBhIFJQIG9yIENBIGNhdXNlcyBhbGwgPEFTLCBp cF9wcmVmaXg+IHBhaXJzIHRvIGJlDQo+PiB3aXRoZHJhd24gdGVtcG9yYXJpbHksIGl0IGlzIGEg YnVnIGluIHRoZSBzb2Z0d2FyZSBzdGFjay4NCj4gDQo+IGJ1ZyBpbiB3aGF0IHNlbnNlPyAgcHJv dG9jb2wvcmZjIHZpb2xhdGlvbiBvciBqdXN0IHRoZSBub3JtYWwgaWxsDQo+IGFkdmlzZWQgY29k aW5nPw0KIA0KVGhhdCBkZXBlbmRzIG9uIHdoZXJlIGl0IGhhcHBlbnMgLSBhbmQgSSBoYWQgdG8g bG9vayBpdCB1cC4gSWYgdGhpcyBoYXBwZW5zIGluDQphbiBSVFIgcGR1LCBJIHRoaW5rIHRoaXMg aXMgYSBwcm90b2NvbCB2aW9sYXRpb24gc2luY2UgdGhpcyBpcyBub3QgdGhlIG1pbmltYWwNCnNl dCBvZiBjaGFuZ2VzIChyZmM4MjEwIDUuMykuDQogDQo+PiBBIENBIGNhbiAoYW5kIHNob3VsZCkg cHVibGlzaCB0aGlzIGNoYW5nZSB3aXRob3V0IGFuIGludGVybWVkaWF0ZQ0KPj4gc3RhdGUgaW4g d2hpY2ggPEFTLCBpcF9wcmVmaXg+IHBhaXJzIGRpc2FwcGVhci4NCj4gDQo+IGJ1dCBpdCBtaWdo dCBub3QuICBsdWNraWx5IHdlIGhhdmUgbm90IHNlZW4gcXVlc3Rpb25hbGJsZSBwcm9ncmFtbWlu Zw0KPiBwcmFjdGljZSBpbiBycGtpIGltcGxlbWVudGF0aW9ucyA8L2RyaXBwaW5nIHNhcmNhc20+ DQogDQpJdCBtaWdodCBub3QuIEJ1dCBpbiB0aGF0IGNhc2UsIGl0IHdvdWxkIHB1Ymxpc2ggYW4g aW50ZXJtZWRpYXRlIHN0YXRlIHRoYXQgZG9lcw0Kbm90IHJlZmxlY3QgdGhlIGludGVudCBvZiB0 aGUgaHVtYW4gb3BlcmF0aW5nIHRoZSBDQS4gQWdhaW4sIGJ1Zy4NCiANCj4gDQo+PiBwLnMuIFRo ZSBzb2Z0d2FyZSBJIHVzZWQgd2FzOiBSb3V0aW5hdG9yIDAuMTAuMSwgUklQRSBOQ0MgQ0Egc29m dHdhcmUNCj4+IGNiOWU4ODlmNCwgcnBraS1ydHItY2xpZW50LCB3aXJlc2hhcmsNCj4gDQo+IHRo YW5rcyBmb3IgYWN0dWFsbHkgZGVzY3JpYmluZyB5b3VyIGV4cGVyaW1lbnRhbCBzZXR1cC4gIGkg d2lzaCB3ZSBhbGwNCj4gd2VyZSBnb29kIGFib3V0IHRoaXMuDQo+IA0KPiBmb3IgbWUsIHRoZSBn b2FsIGhlcmUgaXMgc2ltcGxpY2l0eS4gIHRvIHF1b3RlIGEgZnJpZW5kIHdpdGggd2hvbSBpDQo+ IGFncmVlDQo+IA0KPiAgICBJIHNlZW0gdG8gcmVtZW1iZXIgeW91IChSYW5keSkganVtcGluZyB1 cCBhbmQgZG93biBhYm91dCBob3cNCj4gICAgb3BlcmF0b3JzIGRvbid0IGdpdmUgYSByYXQncyA8 YmxlZXA+IGFib3V0IHRoZSBBUyBudW1iZXIgcGVyIHNlLA0KPiAgICBpdCdzIGp1c3QgYSB0b29s OiBvcGVyYXRvcnMgdGhpbmsgYWJvdXQgdGhpcyBpbiB0ZXJtcyBvZiBwcmVmaXhlcywNCj4gICAg YW5kIHdoYXQgb3BlcmF0b3JzIGNhcmUgYWJvdXQgYXJlIHRoZSBwcmVmaXhlcywgc28gYXJiaXRy YXJpbHkNCj4gICAgc3R1ZmZpbmcgYSBidW5jaCBvZiBwcmVmaXhlcyBpbnRvIGEgc2luZ2xlIG9i amVjdCBpcyBwcmVtYXR1cmUNCj4gICAgb3B0aW1pemF0aW9uIGF0IHRoZSBleHBlbnNlIG9mIHNp bXBsaWNpdHkgYW5kIGZhdGUgc2hhcmluZy4NCj4gDQo+ICAgIEkgdGhpbmsgdGhlIG9yaWdpbmFs IG1vdGl2YXRpb24gd2FzIGp1c3QgdHJ5aW5nIHRvIHNxdWVlemUgb3V0IGFzDQo+ICAgIG1hbnkg Yml0cyBhcyBwb3NzaWJsZSwgb24gdGhlIHRoZW9yeSB0aGF0IFJPQXMgbWlnaHQgZW5kIHVwIGJl aW5nDQo+ICAgIGZsb29kZWQgaW5saW5lIHZpYSBCR1AsIGluIG11Y2ggdGhlIHNhbWUgc3Bpcml0 IGFzIHRoZSBiaXphcnJlDQo+ICAgIGVuY29kaW5nIG9mIHByZWZpeGVzIGFzIGJpdCBzdHJpbmdz IGluIFJGQyAzNzc5LiAgT25jZSBpbmxpbmUgQkdQDQo+ICAgIGZsb29kaW5nIHdhcyBvZmYgdGhl IHRhYmxlLCBzaXplIGJlY2FtZSByZWxhdGl2ZWx5IHVuaW1wb3J0YW50IChSUEtJDQo+ICAgIG9i amVjdHMgYXJlIHRpbnkgY29tcGFyZWQgdG8gdGhlIGF2ZXJhZ2Uga2l0dGVuIHZpZGVvKSwgc28N Cj4gICAgb3BlcmF0aW9uYWwgZmF0ZSBzaGFyaW5nIGFuZCB1c2VyIGludGVyZmFjZSBzaW1wbGlj aXR5IHNlZW1lZCBsaWtlDQo+ICAgIG1vcmUgcHJlc3NpbmcgaXNzdWVzLg0KPiANCj4gICAgT2Yg Y291cnNlLCBubyBiYWQgaWRlYSBldmVyIGRpZXMsIHNvIHRoZXJlIGFyZSBwZW9wbGUgd2hpbmlu ZyBhYm91dA0KPiAgICB3YW50aW5nIHRvIHN0dWZmIFJQS0kgaW50byBpbmxpbmUgQkdQIGFnYWlu Li4uLg0KPiANCj4gYXMgdG8gdGhhdCBsYXR0ZXIsIGhhdmUgd2UgbGVhcm5lZCBub3RoaW5nIGFi b3V0IG92ZXJseSB0aWdodCBjb3VwbGluZw0KPiBhbmQgaW50ZXJkZXBlbmRlbmNlIGZyb20gZmFj ZWJvb2s/ICB0aGUgbGVzc29uIHRoZXJlIGlzIG5vdGhpbmcgbmV3LA0KPiBqdXN0IHNob3ZlZCBp biB0aGUgd29ybGQncyBmYWNlLiAgcHJpdmFjeSBhbmQgc2VjdXJpdHkgYXJlIG5vdCB0aGUgc2Ft ZQ0KPiBzaW5jZSBzbm93ZGVuLiAgd3JhcHBpbmcgdGhpbmdzIGluIGEgdGlnaHRseSBvdmVyLWJv dW5kIGhhcmJhbGwgc2hvdWxkDQo+IG5vdCBiZSB0aGUgc2FtZSBzaW5jZSBmYWNlYm9vay4gIGJ1 dCBpIGRpZ3Jlc3MuDQogDQpBcyBhIENBIG9wZXJhdG9yLCAib25lIHByZWZpeCBwZXIgUk9BIiBp cyBub3Qgc2ltcGxlciAoYW5kIHdvdWxkIGNhdXNlIH41eCBtb3JlDQpvYmplY3RzIHRvIHNpZ24s IHRyYW5zZmVyLCBhbmQgc2VydmUpLiBJIGRvbid0IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGJsYW5r ZXQNCmFkdmljZTsgaXQgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBmYWlsdXJlIG1vZGVzIChlLmcu IGZhdGUtc2hhcmluZyB2cyBST0FzDQpleHBpcmluZyBhdCBhIGRpZmZlcmVudCB0aW1lKS4gVGhl IGVsZXBoYW50IGluIHRoZSByb29tIGlzIGZhdGUtc2hhcmluZyBhdCB0aGUNCkNBIGxldmVsIGFu ZCB0aGUgYnJpdHRsZW5lc3MgdGhhdCBmYXRlIHNoYXJpbmcgYnkgbWFuaWZlc3QgbGlmZXRpbWUg aW50cm9kdWNlcy4NCiANCklmIHJvdXRlcnMgZnJlcXVlbnRseSBlbmNvdW50ZXIgdGhlIG1hc3Mg d2l0aGRyYXdhbCArIHB1YmxpY2F0aW9uIGRlc2NyaWJlZCwgYQ0Kc2luZ2xlIHByZWZpeCBwZXIg cm9hIG1heSBiZSBhIGdvb2Qgd29ya2Fyb3VuZCBmb3IgdGhhdCBidWcsIGFuZCBJIHdvdWxkIHN1 cHBvcnQNCnRoYXQgaWYgbmVlZGVkLiBDbGFyaWZpY2F0aW9uIGZyb20gdGhlIGF1dGhvcnMgb24g dGhlIHNpdHVhdGlvbiB3aGVyZSB0aGlzDQpiZWhhdmlvdXIgd2FzIGVuY291bnRlcmVkIHdvdWxk IGhlbHAuIA0KIA0KS2luZCByZWdhcmRzLA0KVGllcw0KIA0KWzFdIGh0dHBzOi8vZ2l0aHViLmNv bS9SSVBFLU5DQy9ycGtpLXB1YmxpY2F0aW9uLXNlcnZlcg0KWzJdIHRoZSBleGNlcHRpb24gdGhh dCBJIGNhbiB0aGluayBvZiBpcyB0aGUgQ0EgY2VydGlmaWNhdGUgc2lnbmVkIGJ5IGEgVEFMJ3Mg cHVibGljIGtleQ0KPiANCj4gcmFuZHkNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+IFNpZHJvcHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3Bz DQogDQogDQo= ------=_001_NextPart262603782625_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Hello, Ties,
RPKI R= FCs specify the communication protocols between different entities (CA, PP= , RP, BGP-Router=E2=80=A6) and the format of objects. However, different i= mplementations have different understanding and design logic during the op= eration. Then how to handle multiple prefixes under the same AS may differ= ent. 
As I tested using DRL-CA software wi= th the following 4 stages:

= 1. Initial stage
# cat load_roa_requests test.c= sv
1.1.1.0/24-24 10000 24
2.2.2.0/24-24 10000 24
#rpkic -i test load_r= oa_requests test.csv

The RO= A content is:
ROA Version:    0<= /div>
SigningTime:    2021-10-28T06:43:= 33Z
asID:      &nb= sp;    10000
addressFamily: 1
     IPAddress: 1.1.1.0/24
     IPAddress: 2.2.2.0/24
2. Delete a prefix
# cat load_roa_requests test.csv
= 1.1.1.0/24-24 10000 24

#rp= kic -i test load_roa_requests test.csv

The ROA content is:
ROA Version:&nb= sp;   0
SigningTime:   = 2021-10-28T06:44:26Z
asID:   &= nbsp;       10000
= addressFamily: 1
     IPAdd= ress: 1.1.1.0/24

3. Increa= se a prefix
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24
2.= 2.2.0/24-24 10000 24

#rpkic= -i test load_roa_requests test.csv

The ROA content is:
ROA Version:&nb= sp;   0
SigningTime:   = 2021-10-28T06:45:40Z
asID:   &= nbsp;       10000
= addressFamily: 1
     IPAdd= ress: 1.1.1.0/24
     IPAdd= ress: 2.2.2.0/24

4. re-loa= d
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24
2.2.2.0/24-2= 4 10000 24

#rpkic -i test = load_roa_requests test.csv

= The ROA content is:
ROA Version:  &nb= sp; 0
SigningTime:    2021-10-28T= 06:45:40Z
asID:     &= nbsp;     10000
addressFamil= y: 1
     IPAddress: 1.1.1.0= /24
     IPAddress: 2.2.2.0/= 24

It shows that:
1. Increase or delete the prefix within one ROA will caus= e the re-issue of the ROA (both the time and file name changed). This upda= te of ROA will looks like a new one for the PP and RP. Then the CA revokes= the old one. And accordingly the RP needs to synchronize the data. (Maybe= the description in the draft is not accurate enough. It's appeciate if yo= u can suggest the descriptions.)
2. While, re-lo= ad will not cause any change of the ROA file because the software will com= pare the data in the csv file.

ps. Here I am not saying DRL-CA has shortcoming.
BR,
=0A
=
=0A
=0A
YAN Zhiwei
=
 
Date: = 2021-10-28 15:20
CC: sidrops
Subject: Re: [Sidrops] New Ver= sion Notification for draft-ietf-sidrops-roa-considerations-01.txt
Hi Randy,
=0A
 
=0A
> On 28 = Oct 2021, at 04:12, Randy Bush <randy@psg.com> wrote:
=0A
&= gt;
=0A
>> Because I would consider it a bug if a single p= refix being removed
=0A
>> caused all VRPs on the ROA to be= withdrawn and then announced again
=0A
>> over RTR.
= =0A
>
=0A
> as it is within the specs, it depends on t= he implementation of the CA,
=0A
> the PP, and the RP.  h= ave fun setting up the NxMxL experiment :)
=0A
 
=0AIndeed, the number of permutations is not pretty. Since you need a consi= stent
=0A
set of objects for the RP to accept the content of a PP= , I would focus on the CA
=0A
and RTR implementation when setting= up the experiment.
=0A
 
=0A
>
=0A
&g= t;>  * (initial situation): A CA with one ROA with many prefixes f= or a specific AS
=0A
>>    on an internal te= st environment for RIPE NCC RPKI dashboard.
=0A
>> &nb= sp;  * The CA has roa for that AS with many prefixes in it.
=0A<= div>>>  * (user): Deletes one prefix for that AS from the CA.=0A
>>  * (system): re-creates the ROA (file), new ROA = replaces old one
=0A
>
=0A
> does the publication= protocol have a Replace operation?  i do not
=0A
> remem= ber it.  if not, it's either a create and a delete or a delete and=0A
> a create.  my memory is that ordering is not discusse= d.
=0A
>
=0A
> and things go wobbly from there.=0A
 
=0A
"publish with a hash", mismatching hash re= sults in an error (rfc8181 2.2). In
=0A
practice, an implementati= on needs to abort the whole operation if an error
=0A
occurs (iir= c [1] does). Otherwise, updating a single object for a CA would
=0Aalmost always [2] result in a consistency problem.
=0A
 <= /div>=0A
I agree that ordering is under-specified in 8181.
=0A>
=0A
>> In my opinion, if a RP or CA causes all <= AS, ip_prefix> pairs to be
=0A
>> withdrawn temporarily,= it is a bug in the software stack.
=0A
>
=0A
> b= ug in what sense?  protocol/rfc violation or just the normal ill=0A
> advised coding?
=0A
 
=0A
That depend= s on where it happens - and I had to look it up. If this happens in
= =0A
an RTR pdu, I think this is a protocol violation since this is not= the minimal
=0A
set of changes (rfc8210 5.3).
=0A
 = ;
=0A
>> A CA can (and should) publish this change without = an intermediate
=0A
>> state in which <AS, ip_prefix>= pairs disappear.
=0A
>
=0A
> but it might not.&n= bsp; luckily we have not seen questionalble programming
=0A
> = practice in rpki implementations </dripping sarcasm>
=0A
&n= bsp;
=0A
It might not. But in that case, it would publish an inte= rmediate state that does
=0A
not reflect the intent of the human = operating the CA. Again, bug.
=0A
 
=0A
>
= =0A
>> p.s. The software I used was: Routinator 0.10.1, RIPE NCC= CA software
=0A
>> cb9e889f4, rpki-rtr-client, wireshark=0A
>
=0A
> thanks for actually describing your ex= perimental setup.  i wish we all
=0A
> were good about th= is.
=0A
>
=0A
> for me, the goal here is simplici= ty.  to quote a friend with whom i
=0A
> agree
=0A>
=0A
>    I seem to remember you (Randy= ) jumping up and down about how
=0A
>    operat= ors don't give a rat's <bleep> about the AS number per se,
=0A<= div>>    it's just a tool: operators think about this in= terms of prefixes,
=0A
>    and what operators= care about are the prefixes, so arbitrarily
=0A
>  =   stuffing a bunch of prefixes into a single object is premature=0A
>    optimization at the expense of simplicity = and fate sharing.
=0A
>
=0A
>    I= think the original motivation was just trying to squeeze out as
=0A<= div>>    many bits as possible, on the theory that ROAs = might end up being
=0A
>    flooded inline via = BGP, in much the same spirit as the bizarre
=0A
>  &= nbsp; encoding of prefixes as bit strings in RFC 3779.  Once inline B= GP
=0A
>    flooding was off the table, size be= came relatively unimportant (RPKI
=0A
>    obje= cts are tiny compared to the average kitten video), so
=0A
>&n= bsp;   operational fate sharing and user interface simplicity se= emed like
=0A
>    more pressing issues.
= =0A
>
=0A
>    Of course, no bad idea e= ver dies, so there are people whining about
=0A
>  &= nbsp; wanting to stuff RPKI into inline BGP again....
=0A
> =0A
> as to that latter, have we learned nothing about overly t= ight coupling
=0A
> and interdependence from facebook?  t= he lesson there is nothing new,
=0A
> just shoved in the world= 's face.  privacy and security are not the same
=0A
> sin= ce snowden.  wrapping things in a tightly over-bound harball should=0A
> not be the same since facebook.  but i digress.=0A
 
=0A
As a CA operator, "one prefix per ROA" is not= simpler (and would cause ~5x more
=0A
objects to sign, transfer,= and serve). I don't think this should be blanket
=0A
advice; it = is a trade-off between failure modes (e.g. fate-sharing vs ROAs
=0Aexpiring at a different time). The elephant in the room is fate-sharing= at the
=0A
CA level and the brittleness that fate sharing by man= ifest lifetime introduces.
=0A
 
=0A
If routers fre= quently encounter the mass withdrawal + publication described, a
=0A<= div>single prefix per roa may be a good workaround for that bug, and I wou= ld support
=0A
that if needed. Clarification from the authors on = the situation where this
=0A
behaviour was encountered would help= .
=0A
 
=0A
Kind regards,
=0A
Ties
= =0A
 
=0A
[1] https://github.com/RIPE-NCC/rpki-publicati= on-server
=0A
[2] the exception that I can think of is the CA cer= tificate signed by a TAL's public key
=0A
>
=0A
>= randy
=0A
>
=0A
> ______________________________= _________________
=0A
> Sidrops mailing list
=0A
>= Sidrops@ietf.org
=0A
> https://www.ietf.org/mailman/listinfo/= sidrops
=0A
 
=0A
 
=0A
=0A ------=_001_NextPart262603782625_=------ From nobody Fri Oct 29 00:14:34 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144A93A0C79; Fri, 29 Oct 2021 00:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 OsfPjhG6D-dh; Fri, 29 Oct 2021 00:14:26 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 293273A0C92; Fri, 29 Oct 2021 00:14:26 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id u9so16404826uac.8; Fri, 29 Oct 2021 00:14:26 -0700 (PDT) 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=c1tUAGc3bIa0/goPk/KciwOmSCdP5IMnuIREp7I+IyI=; b=dhvyZkoTaZzxVwHhvQ7l3ixITiqBcDKIO+N/ohrMYYlXEFFsy+v16+Jy2Mbh05hOwZ NVpvJ38YiOUZYcoa7igJ6T13LAj1TgmPsLjcGjz1It+vavUDYI2xwmCY78WBwIVQoAEZ dr6ijdajik3tR2fRFejPKcHytFaZG5KHdy738H4qdf+jz9mjNViIp2HBZ+uz3Jx3+fAz lQmmBBXRxgb/BVUavNViCIrmTNkAzVWEs7q6YV6P4IblvxtWb5fnyvEJ5Lw/RJ/RVS3V nRc+to/dqUZH/tzhCrgIswXQJLZMw7hYPnoiP3hW887oc9E05DcGpECqJvRiDHGhvaHl 3E2Q== 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=c1tUAGc3bIa0/goPk/KciwOmSCdP5IMnuIREp7I+IyI=; b=qrMHdRQ03H9A7Y3UKrmCvXBTXttnX6LtZu9f/Kped9HvnssjLZ3Vf8tZjn3ZP7bKA1 LtTravNhXxyOamzWucin+pAYwVE6J/K5ux3HZb3zAFQdp4Ax/si8UuvFNKVjIuA5p4/M pRNJ0anf5WhSPylS8jkvT/KjOT/O3pEIEzZw2MDpsVj2zhQJgyMhFOvquUMuWotFtkQP 5hlkO9a3mkvMq2r1NGYetwXsqzkVcxKJzcvm3tPirihWNCEDkiUqE4EZB3CxNQqnHDdi yjsfxjxUJ95/DKaZA1npKmMKP2P/Zn5Kyj+vtN20n9H9xtvtSJO/PIh0vzoWRtKj24nY Ukeg== X-Gm-Message-State: AOAM530a6qye0gdtAHq36ImheKgd/aMYHDwvP0VBOxXo4yBYUXWBuYcY iZYZGxaSdyMSuOv7MnsNMCUK6upzO5gniNqgfLAJabel X-Google-Smtp-Source: ABdhPJy48YWxQX25wZkQEKQzt5uN3QMZrskg48xTbkc8oUwycoiqExd2tPa4/njXeCpkl6E+MdO5qngVS7lMNkZxEjo= X-Received: by 2002:a67:f4c9:: with SMTP id s9mr10008654vsn.35.1635491663297; Fri, 29 Oct 2021 00:14:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amreesh Phokeer Date: Fri, 29 Oct 2021 11:13:47 +0400 Message-ID: To: SIDROps Chairs Cc: "sidrops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009fbfc005cf78931b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 07:14:32 -0000 --0000000000009fbfc005cf78931b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Chairs, Apologies for my late comments. I have read the document and I believe it highlights an important loophole which operators need to know about. I would like the authors to address the following comments: ##Editorial [Section 3] at the time writing --> at the time of writing [Section 5.1] s/considerabley/considerably [Section 5.1(2)] the set IP prefixes --> the set of IP prefixes ##Substantial 1. The document does not provide any guidance on how to deal with currently existing ROAs with maxLength. 2. The "security considerations" section is missing, all major concerns mentioned in the draft should move this section. e.g. Though minimal ROAs provides certain level of protection but can not completely eradicate the impact of forged-origin subprefix hijack even the subprefix is already originated. 3. Another point that can go into the "Security considerations" section: The creation of specific ROAs (minimal ROA) for DDoS mitigation has a trade-off, it is revealing important information on which prefixes are protected against DDoS and which ones are not. While this information can potentially be obtained from Internet Routing Registries (IRRs), having them in RPKI provides a more precise source of information, which inherently introduces a new attack vector. Regards, Amreesh Phokeer On Tue, Oct 12, 2021 at 3:19 AM Keyur Patel wrote: > 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. > 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 > --=20 Amreesh Phokeer --0000000000009fbfc005cf78931b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Chairs,

Apologies for my late comments. = I have read the document and I believe=C2=A0
it highlights an imp= ortant loophole which operators need to know about.

I would like the authors to address the following comments:
##Editorial

[Section 3]
at the time writing --> at the = time of writing
[Section 5.1]
s/considerabley/considerably
[Sectio= n 5.1(2)]
the set IP prefixes --> the set of IP prefixes

##Sub= stantial
1. The document does not provide any guidance on how to deal wi= th currently existing ROAs
with maxLength.

2. The "sec= urity considerations" section is missing, all major concerns mentioned= in the draft=C2=A0
should move this section. e.g. Though minimal ROAs = provides certain level of protection but=C2=A0
can not completely= eradicate the impact of forged-origin subprefix hijack even the subprefix= =C2=A0
is already originated.

3. Another point= that can go into the "Security considerations" section:

T= he creation of specific ROAs (minimal ROA) for DDoS mitigation has a trade-= off,=C2=A0
it is revealing important information on which prefixe= s are protected against DDoS and=C2=A0
which ones are not. While = this information can potentially be obtained from=C2=A0
Internet = Routing Registries (IRRs), having them in RPKI provides a more precise=C2= =A0
source of information, which inherently introduces a new atta= ck vector.

Regards,
Amreesh Phokeer
=


On Tue, Oct 12, 2021 at 3:19 AM Keyur Patel <keyur@arrcus.com> wro= te:

Hi Folks:<= /span>

=C2=A0

A working group last call has been requested fo= r 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=C2=A0WGLC=C2=A0will end on October 25th, 2021.

=C2=A0

The draft can be found at:=C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-sidrops= -rpkimaxlen-08. Authors, please reply indicating whether you're aware of any relevant IPR that = hasn't been disclosed.

=C2=A0

Regards,

Nathalie, Chris & Keyur

=C2=A0

=C2=A0<= /span>

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


--
Amreesh Phokeer
--0000000000009fbfc005cf78931b-- From nobody Fri Oct 29 02:27:08 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0D93A0E89 for ; Fri, 29 Oct 2021 02:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 Xw5bwpBSgCQp for ; Fri, 29 Oct 2021 02:27:01 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE40F3A0E84 for ; Fri, 29 Oct 2021 02:26:59 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19T9QtNt041469 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2021 10:26:55 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Randy Bush Cc: SIDR Operations WG , "North American Network Operators' Group" References: From: Nick Hilliard Message-ID: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> Date: Fri, 29 Oct 2021 10:26:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.51 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 09:27:07 -0000 Randy Bush wrote on 29/10/2021 02:03: > received this vuln notice four days before these children intend to > disclose. so you can guess how inclined to embargo. The position doesn't seem to be compatible with e.g. > https://www.first.org/global/sigs/vulnerability-coordination/multiparty/FIRST-Multiparty-Vulnerability-Coordination.pdf At the top of the FIRST list: > 1. Establish a strong foundation of processes and relationships > > 2. Maintain clear and consistent communications > 2.1. All parties should clearly and securely communicate and negotiate expectations and timelines. Because this didn't happen, we now get to look forward to a weekend of elevated risk, followed by people upending their calendars to handle un-coordinated upgrades on monday morning. Vulnerability researchers perform a valuable service, but enthusiasm needs to be tempered with an understanding that there are real life consequences to not handling this sort of thing in a well-structured way. It doesn't need to be said that: "1. we screwed up with your email address, and 2. we're disclosing in 4 days and aren't telling you what the problem is unless you agree to our terms" is not an appropriate way of handling anything, whatever about claiming to speak on behalf of an NCSC. This won't be the last time a screw-up of this form happens, so maybe NCSC-NL's takeaway should be to ensure that co-ordinated vuln management and disclosure happens in a reasonable way when engaging with all parties? As a separate thing, software authors also need to have clearly defined security notification points and vulnerability management policies. Most have in this situation, but not all. Nick > randy > > > From: Koen van Hove > 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 Fri Oct 29 05:02:12 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DAB3A1158 for ; Fri, 29 Oct 2021 05:02:10 -0700 (PDT) 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 GSfFE4yFQTnf for ; Fri, 29 Oct 2021 05:02:04 -0700 (PDT) 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 B31933A1151 for ; Fri, 29 Oct 2021 05:02:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mgQa8-0005FV-14; Fri, 29 Oct 2021 12:02:00 +0000 Date: Fri, 29 Oct 2021 05:01:59 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: SIDR Operations WG , "North American Network Operators' Group" In-Reply-To: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> References: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 12:02:10 -0000 i would not be surprised if email to my previous addresses ...!uunet!m2xenix!randy ...!uunet!oresoft!randy bounced, making it difficult for these kiddies to reach me. https://en.wikipedia.org/wiki/Responsible_disclosure randy From nobody Fri Oct 29 05:37:05 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E193A118E for ; Fri, 29 Oct 2021 05:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 u6R-0XuLKIgz for ; Fri, 29 Oct 2021 05:37:02 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01993A1188 for ; Fri, 29 Oct 2021 05:37:00 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19TCatBH065471 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2021 13:36:55 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Barry Greene Cc: cert@ncsc.nl, Randy Bush , SIDR Operations WG , "North American Network Operators' Group" References: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> From: Nick Hilliard Message-ID: <7ebda77d-b41c-19d6-cb3a-e464539fdd8b@foobar.org> Date: Fri, 29 Oct 2021 13:36:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.51 MIME-Version: 1.0 In-Reply-To: <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 12:37:05 -0000 Barry Greene wrote on 29/10/2021 13:15: > That only happens if the team has the time to get the fix into the code, > tested, validated, regressed, and deployed. I would say this is a > classic example of “ego” to publish overruling established principles. > > The University of Twente should explore requiring classes for > responsible disclosure. > > NCSC, it seems you threw out your own policy: > > "The NCSC will try to resolve the security problem that you have > reported in a system within 60 days. Once the problem has been resolved, > we will decide in consultation whether and how details will be published.” > > I would have expected you to council the researchers on responsible > disclosure principles. Indeed + also manage the vendor disclosure process in a more comprehensive / structured way. An interesting and worthwhile outcome here would be a presentation on how the set of inputs into the sausage factory produced the mess that's going to be served for lunch on monday. I.e. let's use this as an opportunity to learn from the mistakes that were made here. Nick From nobody Fri Oct 29 08:21:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B33A1182 for ; Fri, 29 Oct 2021 05:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 WXm50QCM2vFV for ; Fri, 29 Oct 2021 05:15:50 -0700 (PDT) Received: from smtp68.iad3b.emailsrvr.com (smtp68.iad3b.emailsrvr.com [146.20.161.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874A13A1160 for ; Fri, 29 Oct 2021 05:15:50 -0700 (PDT) X-Auth-ID: bgreene@senki.org Received: by smtp17.relay.iad3b.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 043A3A008A; Fri, 29 Oct 2021 08:15:46 -0400 (EDT) From: Barry Greene Message-Id: <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E7D33530-EA56-4859-987A-C00DB13E2C11"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 29 Oct 2021 20:15:43 +0800 In-Reply-To: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> Cc: Randy Bush , Nick Hilliard , SIDR Operations WG , North American Network Operators' Group To: cert@ncsc.nl References: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Classification-ID: 5fc31aa4-ce37-445a-bd99-13740eb49748-1-1 Archived-At: X-Mailman-Approved-At: Fri, 29 Oct 2021 08:21:20 -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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 12:15:55 -0000 --Apple-Mail=_E7D33530-EA56-4859-987A-C00DB13E2C11 Content-Type: multipart/alternative; boundary="Apple-Mail=_E35744A6-1EC7-4CA8-817A-D198211FC428" --Apple-Mail=_E35744A6-1EC7-4CA8-817A-D198211FC428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 29, 2021, at 5:26 PM, Nick Hilliard wrote: >=20 > Because this didn't happen, we now get to look forward to a weekend of = elevated risk, followed by people upending their calendars to handle = un-coordinated upgrades on monday morning. That only happens if the team has the time to get the fix into the code, = tested, validated, regressed, and deployed. I would say this is a = classic example of =E2=80=9Cego=E2=80=9D to publish overruling = established principles. The University of Twente should explore requiring classes for = responsible disclosure. NCSC, it seems you threw out your own policy: "The NCSC will try to resolve the security problem that you have = reported in a system within 60 days. Once the problem has been resolved, = we will decide in consultation whether and how details will be = published.=E2=80=9D I would have expected you to council the researchers on responsible = disclosure principles. --Apple-Mail=_E35744A6-1EC7-4CA8-817A-D198211FC428 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 29, 2021, at 5:26 PM, Nick Hilliard <nick@foobar.org> = wrote:

Because this = didn't happen, we now get to look forward to a weekend of elevated risk, = followed by people upending their calendars to handle un-coordinated = upgrades on monday morning.

That only happens if the = team has the time to get the fix into the code, tested, validated, = regressed, and deployed. I would say this is a classic example of = =E2=80=9Cego=E2=80=9D to publish overruling established = principles. 

The University of Twente should explore requiring classes for = responsible disclosure. 

NCSC, it seems you threw out your own = policy: 

"The NCSC will try to resolve the security problem that you = have reported in a system within 60 days. Once the problem has been = resolved, we will decide in consultation whether and how = details will be published.=E2=80=9D

I would have expected you to council = the researchers on responsible disclosure = principles. 
= --Apple-Mail=_E35744A6-1EC7-4CA8-817A-D198211FC428-- --Apple-Mail=_E7D33530-EA56-4859-987A-C00DB13E2C11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQVKvL3V0R4ztROshhbbsAQf/4hxwUCYXvl7wAKCRBbbsAQf/4h xw/DAKDsbsgNw1wN3Iuz5cW/gd3h7yayZQCgmtQ7Wce5U25FxpCFVBIM2TaQq0E= =NZIX -----END PGP SIGNATURE----- --Apple-Mail=_E7D33530-EA56-4859-987A-C00DB13E2C11-- From nobody Fri Oct 29 08:34:52 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1D23A1319 for ; Fri, 29 Oct 2021 08:34:51 -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 NKPC-dWlL8Xc for ; Fri, 29 Oct 2021 08:34:49 -0700 (PDT) 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 758733A1318 for ; Fri, 29 Oct 2021 08:34:49 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id f8so18429266edy.4 for ; Fri, 29 Oct 2021 08:34:49 -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=LOnK27TOMh+1eOd8ph5Bjp54pg7qEoznUncWsBzHKFc=; b=OcpTRSZEQUHQqnLDCRAEF5I0GMl6H1rdD8/rueUpgKwKXd+ebTu2xauHOt2ez334M8 p5fQXCjoxQfTLPgjWMvZTA1y1ZQvrr/htmTN7ELKa5cZnuD2R11JU4JdQlYGVYzpL1Wd vnEbu4aqie3gsLCb3TEb8R0qZXh0G696vvKc3L2d7u1ZI0d9KgRifc9k6oElmxkvXIIf cG2RrxD7eof5J2FJYSxZSLy1FpJaZb+bYG+XbTMHBrihi7oMdP0I7RRNTD2Uo31MqJEh Q5IbX5pQXf8II4plnxis42JBayCe7EoVwrb+I7eR316UPqhUi5GdvHhgN00zf9QpUeZ+ i9kg== 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=LOnK27TOMh+1eOd8ph5Bjp54pg7qEoznUncWsBzHKFc=; b=ny38/9s4Or19RfKCF1GANR0WGvOrvVnv6wBr0fgFs3JXeobE1JsEk3oe7soOGJtd1B I82SU611c1RdDfpPnsJ59HURLsWqISj/81xSavX63Xj5dME+n23x3MUMVqHRCgt3UUTd 2nnmtu5x9R7MpGomHvBCbxgxZ3D6xjak1lcEsVdB719iv5O5Llk2FHtJtE60dwBTCuFE hPwyCEg0yIim200JKw24rsVe8+aXsznjIgU7V/cChx6wJb7emmeDntj35z7j3u7EF0p0 Kq2DnuIvqDkZ6S+S3kfwzIDcK8yiB4xboPdGEOlZ0StINhehP0UWvSiNsr9DeNVpGjVS WE2g== X-Gm-Message-State: AOAM532sdeYZJyW1pRhoJK/KqAVV7Ux2qZBbFEDzWsZ/oklxXumXn5yt nD1gP9GBX+BhddeGuGQt9aicKqnCtgjQTClOhfla5HxPblc= X-Google-Smtp-Source: ABdhPJx5lNUVrG0MDNsmpt0cpD91JxNC8EC9dyv8LOBDtFKt8SZ7tX4JURAFjg/wBMHJ4i/ZJsr4ted070Ah+V9Rbws= X-Received: by 2002:a17:907:1c81:: with SMTP id nb1mr15291107ejc.153.1635521682709; Fri, 29 Oct 2021 08:34:42 -0700 (PDT) MIME-Version: 1.0 From: Amir Herzberg Date: Fri, 29 Oct 2021 11:34:31 -0400 Message-ID: To: sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000eba10805cf7f9073" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 15:34:51 -0000 --000000000000eba10805cf7f9073 Content-Type: text/plain; charset="UTF-8" Hello Chairs, Apologies for my late comments. I have read the document, and I think it is addressing an important problem and provides a useful contribution to reduce vulnerability; I recommend its adoption. That being said, let me mention that, with some colleagues, we are working on a possible future enhancements to ROAs. In particular, these enhancements involve an improvement to the maxlength mechanism, which may provide an efficient way allowing operators to announce sub-prefixes if/when the need arises (e.g., to foil hijack and esp. DDoS attacks). I'm also having sidebar discussions about this with the authors of this draft. But I think (and I think all of us do) that this idea, even if it turns out useful, should not delay the publication of the current proposal. Obviously, any such change will require considerable discussion, evaluation, refinement and adoption period. Best, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook --000000000000eba10805cf7f9073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Chairs, =C2=A0

Apologies for my l= ate comments.=C2=A0

I have read the document, and = I think it is addressing an important problem and provides a useful contrib= ution to reduce vulnerability; I recommend its adoption.=C2=A0

That being said, let me mention that, with some colleagues= , we are working on a possible future enhancements to ROAs. In particular, = these enhancements involve an improvement to the maxlength mechanism, which= may provide an efficient way allowing operators to announce sub-prefixes i= f/when the need arises (e.g., to foil hijack and esp. DDoS attacks). I'= m also having sidebar discussions about this with the authors of this draft= . But I think (and I think=C2=A0all of us do) that this idea, even if it tu= rns out useful, should not delay the publication of the current proposal. O= bviously, any such change will require considerable discussion, evaluation,= refinement and adoption period.=C2=A0

Best, Amir<= /div>
--
Amir Herzbe= rg

Comcast professor of Security Innovations, = Computer Science and Engineering, University of Connecticut
= `Applied Introduction to Cryptography' textbook and lectures:=C2=A0https://sites.google.com/site/amirherzberg/applied-crypto= -textbook


--000000000000eba10805cf7f9073-- From nobody Fri Oct 29 09:28:48 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD83A141E for ; Fri, 29 Oct 2021 09:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 4GpNP1EW1GDC for ; Fri, 29 Oct 2021 09:28:43 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562393A141B for ; Fri, 29 Oct 2021 09:28:41 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19TGSXHO093464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Oct 2021 17:28:34 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Barry Greene Cc: Randy Bush , SIDR Operations WG , "North American Network Operators' Group" References: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> From: Nick Hilliard Message-ID: <73c542ba-87b5-b880-f0ef-b330d3fe65e4@foobar.org> Date: Fri, 29 Oct 2021 17:28:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.51 MIME-Version: 1.0 In-Reply-To: <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 16:28:48 -0000 Barry Greene wrote on 29/10/2021 13:15: > "The NCSC will try to resolve the security problem that you have > reported in a system within 60 days. Once the problem has been resolved, > we will decide in consultation whether and how details will be published.” > > I would have expected you to council the researchers on responsible > disclosure principles. there's a public statement about this from NCSC-NL: > https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki "In dit proces is een afweging gemaakt om de ontwikkelaar van RPKI-client pas later te informeren. Deze afweging is gemaakt op basis van het publieke standpunt van deze ontwikkelaars, namelijk steun voor ‘full disclosure’. De ontwikkelaars van RPKI-client hebben het NCSC laten weten dat zij niet akkoord gaan met betrokkenheid onder embargo." "During this process, a decision was made to inform the developer of RPKI-client at a later stage. This decision was made on the basis of the public standpoint of these developers, namely support for 'full disclosure. The developers of RPKI-client have let the NCSC know that they do not agree with involvement under embargo." Looks like the NCSC got confused about OpenBSD's internal security vuln management process, which involves full disclosure on their terms, and the way they operate with disclosures from third parties / multiparty engagement, which involves co-operation with the disclosing party / CERT about mutually acceptable terms, including co-ordinated disclosure, i.e. standard industry practice. Some public clarity from the openbsd people would help here. + there was a screwup with the rcynic developers. It's a bit much to claim that the openbsd (+ rcynic) people didn't agree with involvement under embargo when the terms were apparently: we're releasing details in 4 days and will only tell you what the problem is if you agree to this. Regardless of how this misunderstanding came about, this style of approach doesn't form part of an acceptable vulnerability management process. Nick From nobody Fri Oct 29 09:38:23 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1C3A1437 for ; Fri, 29 Oct 2021 09:38:20 -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 sNaPlNXFuZE5 for ; Fri, 29 Oct 2021 09:38:15 -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 984D53A11D5 for ; Fri, 29 Oct 2021 09:38:15 -0700 (PDT) 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 78DC595; Fri, 29 Oct 2021 16:38:10 +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=1635525489; bh=O4gi+Kdz7ysElDlp81X53wK4wpX1aVDM4HAj+h4itGM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=oLQgFO/cmNsqHu6tnD4IUDuSDRQPntYKhSyLS+LhgV7EzRv7nJHwrxLDF2EI/9/cr skUpCcOH0SjgoOpbwabjjDLaY/0Oe5mVRDKI7GvFqdgphhl15w4gsQ2yb60wh/1uel HrLC2HhFQPHNki1HBg7/rd8xLId6kr9rOBR1PlDsB2IBmwvn1LBnF7O3k3YDoHFznb ky/VNteFRbzGkchP3vag0zLq49RaCgqYDjHZjSKgiQkGH7WCG5X6PTj2XOqkuyCvvG 5T1mzyqV5+ucvVaF5e8P6wChwixim7YfAiLlpQpkJ3hRMoRLsKBBuReLWUY7nRplym Odl0zbdAfG3nA== 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 In-Reply-To: <20211026091006.rbdm5jwq2w2leul5@benm-laptop> Date: Fri, 29 Oct 2021 18:38:04 +0200 Cc: Alexander Azimov , Job Snijders , SIDR Operations WG , Claudio Jeker Content-Transfer-Encoding: quoted-printable Message-Id: <40B84E6D-2323-45C5-8231-16B404CAF784@nlnetlabs.nl> References: <37F1DB3D-04DD-47B7-9227-2CDDDE9F67FD@nlnetlabs.nl> <2DD2C079-8116-4CB8-88B7-09B840EC9887@nlnetlabs.nl> <5781BD96-BF1A-4A69-AEF6-DD3444C8BB4D@nlnetlabs.nl> <20211025134501.xlbbr35qxdsif7so@benm-laptop> <311C5F80-5BF8-41B0-92C5-C34DFE7B8731@nlnetlabs.nl> <20211026091006.rbdm5jwq2w2leul5@benm-laptop> To: Ben Maddison Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 16:38:21 -0000 Hi Ben > On 26 Oct 2021, at 11:10, Ben Maddison wrote: >=20 >>>=20 >>> On the other hand it would no longer be possible to express = 'transit-free' >>> in IPv6, but not in IPv4, or vice versa. >=20 > I don't follow. Surely { (65000, ipv4), (65001, ipv4) } means transit > free in ipv6 but not in ipv4? Yes, that makes sense. This implies an empty sequence wrt v6. Tim From nobody Fri Oct 29 10:10:37 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721033A1489 for ; Fri, 29 Oct 2021 10:10:35 -0700 (PDT) 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 kouR_FrvI5Ky for ; Fri, 29 Oct 2021 10:10:30 -0700 (PDT) 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 C73993A1487 for ; Fri, 29 Oct 2021 10:10:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mgVOd-0005ob-EO; Fri, 29 Oct 2021 17:10:27 +0000 Date: Fri, 29 Oct 2021 10:10:26 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: SIDR Operations WG , "North American Network Operators' Group" In-Reply-To: <73c542ba-87b5-b880-f0ef-b330d3fe65e4@foobar.org> References: <994c6cef-c596-8420-c00c-59c972fcaaa0@foobar.org> <5DE0B4FB-8E3B-437A-B43C-58653AC3919D@senki.org> <73c542ba-87b5-b880-f0ef-b330d3fe65e4@foobar.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 17:10:36 -0000 > there's a public statement about this from NCSC-NL: >> https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendmaking-cvd-procedure-rpki blah blah blah bottom line. they gave first notice to devs 4 days before threatened disclosure. that they then asked to embargo was just adding insult to injury. https://en.wikipedia.org/wiki/Responsible_disclosure we will remember their names. like the herzberg incident, "the internet has two weeks to upgrade all microtiks globally before we intentionally break it again." would they do the same to the electric grid or other scada network? the internet's openness and kindness has led them to think we can be abused willy nilly. we will remember their names. randy From nobody Fri Oct 29 12:03:33 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE5F3A0BF1 for ; Fri, 29 Oct 2021 12:03:31 -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_PASS=-0.001, UNPARSEABLE_RELAY=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=ncsc.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 8lcAQlqPW1aQ for ; Fri, 29 Oct 2021 12:03:26 -0700 (PDT) Received: from min1.ncsc.nl (min1.ncsc.nl [147.181.97.77]) (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 C1B2C3A0C6D for ; Fri, 29 Oct 2021 12:03:20 -0700 (PDT) Received: from mailer DKIM-Filter: OpenDKIM Filter v2.11.0 min1.ncsc.nl 4F005E0003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.nl; s=ncsc201806; t=1635534198; bh=73C2+I621jpPiW1KanWyik6tNl5HOpqwQTFd8t83170=; h=From:To:Subject:Date:From; b=WDDb2O/xYyrVlsqtH6dZMccK01Nzj84a3lkBohFTY5ahvGenTBTQjsYNKG82da35u ng0hSJnLnA8xAn+vjRj7FjSl8cL8TBnT+ZamTUoSWCvLJ531AbcVdH+mlseQckwjwn 5HV3eJNku1q/UKniGzPN3KNONaB3yB0oynoCMeUCXSSVvMhMEnyWqq+txPFfM5487s ukenUBkgyrbCSQfPQGJdX0OHp15Q+2Dy9Kg5tKTZ65R285sQnl5fWDtoKkgkc9bh+7 kYdUhzfDPacNOQwA0+tdSrwqlUzeL28lCQ7wNIOSe72ml4Z76pz+fFkZ5xZRbYOsGT Bsxf3GPMrFfSA== Received: from mailer Received: from mailer From: "Jeroen van der Ham (NCSC-NL)" To: "sidrops@ietf.org" Date: Fri, 29 Oct 2021 19:03:17 +0000 Message-Id: Accept-Language: nl-NL, en-US Content-Language: en-US x-tmase-matchedrid: 6U5+IFFVdB8MPDZrnvcM98CxC+PryYbTgdkHykGcMpnjk/hobulc2OHM Zn+b5ItK4PkIhwvBc3rsfV2UNVDv3pFN+B8oJZ5afa90YmMUpz1y4VFP6muDhirDA1gYfyhv0K/ W5f+6CgkGa8DsJoEQRLF/kSFzUBGjeNbTbNb6myqrm7DrUlmNkF+24nCsUSFNZiFQvkZhFu1q8/ xv2Um1avoLR4+zsDTttrrTuahHzlFujzRsAB3dmkqwv6c/wRPuc6+CHBHonnz86PueyrmIP6VkI kFfggr4I2nLI89rmcGNn1qtIMAqNP1wHlLQTGzx7Vew9JLQXUk1nv6xeee13ynUf1OLUa/w2Er5 7KI2kAgQpVBFLdTlCGA7bUFBqh2V x-tmase-result: 10--1.069800-8.000000 x-tmase-version: SMEX-14.0.0.3031-8.6.1018-26498.002 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 19:03:31 -0000 Hi, I've joined this list to post the announcement of NCSC-NL regarding the con= cerns around the RPKI CVD process. Please find our statement here: https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-o= f-rpki-cvd-procedure I will try as best as I can to answer any questions you may have. Regards, Jeroen. From nobody Fri Oct 29 12:16:25 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB853A15EF for ; Fri, 29 Oct 2021 12:16:24 -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 Wv8p16Rq7g_4 for ; Fri, 29 Oct 2021 12:16:22 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 B52E43A15E8 for ; Fri, 29 Oct 2021 12:16:21 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id w1so22925368edd.0 for ; Fri, 29 Oct 2021 12:16:21 -0700 (PDT) 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; bh=dSvfPjm6YICr36Ak59QPl92RxqtsSXY0j5VpjJ6YmtY=; b=YYKtDmOAaQxW48bFOrPAh/xSfpGDuVbdp45dYx5YRbxwnHpGgf4yWzl9JOdY0Xiu2T opuez9f7BucCAcXGoSCYn2ghA84v65xCDfD68w7zguMKQ7ZMMkC+09nJHXXTFFxtH4jV HVIYxUr7BKQBqzPsCCrOXquklHhPRzjMU+6g00B7bLYC2mu3z1PUrwigj2wl1HHs21Y7 Qz1p+Q/Xmdgfj+BOQi0yTkSyI7rX0PLzwy1jSHidwHQOoUhEvgkSYTzZauB76VOHFgaA FuFmIqex9/q2Wt4wy60u/yMWU3rX0PSaKU3se1fx0ApvPv6DDi9qaxD0wmmbtpqjgfnW nY6g== 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; bh=dSvfPjm6YICr36Ak59QPl92RxqtsSXY0j5VpjJ6YmtY=; b=oTN+btZ4wzpvL2Z5k4QMEVL1Gde25QTu8W8hliO6VAdZTnR/nPD0Vl0VxMXmWVZxlL KV7NuzbZFl8DyvuzankPyPBhagzk+8nehgN9/7EQixlcsI9PfeFZTKXbVVcNwRyEd6vS xk6ZKM1XtTDRMHmDVEoBVqRte5PxGoTd9dJOYAf43qTrfEKxiJf3mqI3CKoJML7zhVB7 3HuNgxr/gXmrbIwNkcFoQl+iyWh+ypmZpBppJTcxPxuyFMNDKixEm6cCcm1I4XQMMiTc vOQUR4pbSu6Qc+lTIP01kXfrJ2HBARqSDMBKRxJ9delBk8FrLOSXDW6w5onNmOiePYzw 9iqw== X-Gm-Message-State: AOAM530IxdpPRPCfELhyRUQKKanjTP2ryWA942T3mJbqU1SYGxTmBRdk mYIDcaK9k2ItG3hzZmZoHOg6bcF53ogAIZ+GrDXsitYxbsw= X-Google-Smtp-Source: ABdhPJycKzRG/2uxL6cmh+jdR8OMthL9mFBBzogjFw+x0xb08xFb0pIQwJMlNssrJGN/eLv/E/tlgA0VxbPPFinJjyc= X-Received: by 2002:a17:907:9688:: with SMTP id hd8mr15410494ejc.535.1635534976165; Fri, 29 Oct 2021 12:16:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amir Herzberg Date: Fri, 29 Oct 2021 15:16:04 -0400 Message-ID: To: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000045add505cf82a99b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 19:16:24 -0000 --00000000000045add505cf82a99b Content-Type: text/plain; charset="UTF-8" Small correction: I have read the document, and I think it is addressing an important problem and provides a useful contribution to reduce vulnerability; I support its publication as a BCP. (earlier I wrote by mistake `recommend its adoption') Sorry for the mistake (and resulting spamming) - Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook On Fri, Oct 29, 2021 at 11:34 AM Amir Herzberg wrote: > Hello Chairs, > > Apologies for my late comments. > > I have read the document, and I think it is addressing an important > problem and provides a useful contribution to reduce vulnerability; I > recommend its adoption. > > That being said, let me mention that, with some colleagues, we are working > on a possible future enhancements to ROAs. In particular, these > enhancements involve an improvement to the maxlength mechanism, which may > provide an efficient way allowing operators to announce sub-prefixes > if/when the need arises (e.g., to foil hijack and esp. DDoS attacks). I'm > also having sidebar discussions about this with the authors of this draft. > But I think (and I think all of us do) that this idea, even if it turns out > useful, should not delay the publication of the current proposal. > Obviously, any such change will require considerable discussion, > evaluation, refinement and adoption period. > > Best, Amir > -- > Amir Herzberg > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > Homepage: https://sites.google.com/site/amirherzberg/home > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/applied-crypto-textbook > > > > --00000000000045add505cf82a99b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Small correction:=C2=A0

I have read the document, and I think it is= addressing an important problem and provides a useful contribution to redu= ce vulnerability; I support its publication as a BCP.=C2=A0

(earlier I wrote by mistake `recommend = its adoption')

Sorry f= or the mistake (and resulting spamming) - Amir
--
Amir Herzberg

=
Comcast professor of Security Innovations, Computer Science and = Engineering, University of Connecticut
`Applied Introduction= to Cryptography' textbook and lectures:=C2=A0htt= ps://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Fri, Oct 29, 2021 at 11:34 = AM Amir Herzberg <amir.lists@gma= il.com> wrote:
Hello Chairs, =C2=A0

Apologies fo= r my late comments.=C2=A0

I have read the document= , and I think it is addressing an important problem and provides a useful c= ontribution to reduce vulnerability; I recommend its adoption.=C2=A0

That being said, let me mention that, with some coll= eagues, we are working on a possible future enhancements to ROAs. In partic= ular, these enhancements involve an improvement to the maxlength mechanism,= which may provide an efficient way allowing operators to announce sub-pref= ixes if/when the need arises (e.g., to foil hijack and esp. DDoS attacks). = I'm also having sidebar discussions about this with the authors of this= draft. But I think (and I think=C2=A0all of us do) that this idea, even if= it turns out useful, should not delay the publication of the current propo= sal. Obviously, any such change will require considerable discussion, evalu= ation, refinement and adoption period.=C2=A0

Best,= Amir
-- =
Amir Herzberg

Comcast professor of Se= curity Innovations, Computer Science and Engineering, University of Connect= icut
`Applied Introduction to Cryptography' textbook and= lectures:=C2=A0https://sites.google.com/site/amirher= zberg/applied-crypto-textbook


--00000000000045add505cf82a99b-- From nobody Sat Oct 30 03:22:27 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40C33A041C for ; Sat, 30 Oct 2021 03:22:26 -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, 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 4E9Rgvjq4l1E for ; Sat, 30 Oct 2021 03:22:21 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.69]) (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 14B563A04BB for ; Sat, 30 Oct 2021 03:22:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T5d5/1jtqbhf5Pa5dJY+NfI0VXVIT1RJcF5MlTb7gB2PJnQU8ulh7WWvpSRc52lL55eDCV1zyfcP4VkI3eOkPaAme/kwdhAHLIuOQSJ/wFTHmcTJc4aABa4x62TIXmgDI8nT68r5tDqu5TaSZSzc/skxFUA4Xc2WFjejqumSj3f9swjgYeoot4kfvqERiuzqqjrW3MY9NJ01z1xTAmf7R+7dcU6q4kvFY0MrxV4jCnns4eSsT+J3Tq7MK8uDD9+u5bOqMwcMqNBH2uNGL+Jo61UHCZmIwCm+noDE41TCQ5w7Dr1ulDKn1wmZVq53/5H4BFmz/YgRmjaYqIfzqOv8QA== 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=JBcvvKXLqhtGmiucQ4bEEX9ClQ3jwj/ckhT1iuqQRqM=; b=N4enMo1ORvkKqYldKxt+S/V2sGon1Ofg/9GLBAFQD90liRQZbA7tdjAfjR4ZoooyvRuSgn0Qu/dLfErsY+lbaFvWZe/DK1lTynOKYw+F2oEmRrNYXR0TLZEf0RLrHZkhA8f/hU+qfEWKX3tzV1WDHtuFg32D4Pkv4HdVGpfw6/WqNlgPZdYHamjMG2nkC0rV4HYZePYC5ExhMlpGnithD8q5JURf+ZwCT0eHEqGHpUELzf8namQKDqXUhza/lc7h/QzjX3mn3w5G6Iyx5TkJ/hb5KzhdhJR60mWKPvYXVb+ZrWgwyq3y0/a0tM/rKFSY7/0JAW1oK+pyH6pcMbKPWA== 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=JBcvvKXLqhtGmiucQ4bEEX9ClQ3jwj/ckhT1iuqQRqM=; b=cvSZzm7pMKsoPuDGFyeA62mk4xrvUfDOL//l4JERE7tftkEsMOYWsAQ/v3BsC6bo6V0wm8TI74vEy4hFoifrA4cbfuLrEqMPwd0fymBTJa59Skf6iu217fevBzB14KZB+7bhPrHEdvYXXWe0Vv86tgDbCINSToYHDlm8X5aZZfw= 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 AM5P190MB0467.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.15; Sat, 30 Oct 2021 10:22:15 +0000 Received: from AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006]) by AS8P190MB1078.EURP190.PROD.OUTLOOK.COM ([fe80::15f5:8c34:b1be:6006%7]) with mapi id 15.20.4649.017; Sat, 30 Oct 2021 10:22:15 +0000 Date: Sat, 30 Oct 2021 12:22:07 +0200 From: Ben Maddison To: Jeroen van der Ham Cc: SIDR Operations WG Message-ID: <20211030102207.t2dokied3azflzg6@benm-laptop> References: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="slpdbuklq53f2ew4" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CT2P275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::26) To AS8P190MB1078.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:2e7::13) MIME-Version: 1.0 Received: from localhost (105.233.97.54) by CT2P275CA0038.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14 via Frontend Transport; Sat, 30 Oct 2021 10:22:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9177874f-b3f7-4ae9-5b35-08d99b8f250f X-MS-TrafficTypeDiagnostic: AM5P190MB0467: X-Microsoft-Antispam-PRVS: 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: uc/9qHhrDpLbV4IoDNsK2b33+OS6PMIt+xTJ+MIPBZkSw/zOz/8z3poeJym/TfJQgLfHlu6AJLyM2UjEvFS4MNLpoclWdq0Rx2icmwoPScI+zOAAdxA7UnKQnukERwd6aqkRqoc9ldo8/4kosZJiCoepXxFZNj03HV6EFKPNRASIzlMy0ag2ouKpo0mv8xkBTTwT5xR9P7RB91gTIAqQM6R67EEYInF9p55qs+J07k+15wmHLRYVYDPbrR6X1EkKg612TcASHyaesV3//5u2hIc9mI9e+Ia4ig360AwkPYhgFI+8Tf6luwvYsxChJsijyDwhuA3OYQxOfshTjdPwkRmLiJhoT0MH4mP8Fj4qssM7tTZ9BHqgctUc+wcBLLWuNHssZvXResM5WTuN349jCBPfRvd/lULSKJuwqocNeaBAL0dsEeBuOfCzKCodfog5M8dEz1xP0wOT/Vp4HrT909yoos0VU+NA/xkC1DQMyiTeMDYFV5ytQJPHC0HHTWk1CBh/wF88jFdAFg9R4X5DgZBssZLLydmmapbGmwxM/Hah2i5Y73xwNdiJ5qXJIbrPaWNla1lJThheIT4OCqL1ur8qfvqX+NPJPtlJZqC9WQCHKV8u5+4xhUawy9v02yR13w5U34szhRm7WOFKlzinSsipwjUQUwHqIBU8UCc2ccPjrkq4ciAqRScQmNLJFPRbo3FkbV0SPZ/PQTnoJT/hYr8vzWdwJc5MR/B9l1FEOvsaVDAxShCmjIYrTOKqDIw6mk//5fMOTT/Zk/wPvNl/uaKGTfHUY2V8x5rV/yuynmSI+lERnQ/apqP+NkRBoW6T/UbWqMKD4iEvIkcI+18kohDI+U8PHnWoni0dEPTwy50= 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)(366004)(376002)(396003)(39830400003)(86362001)(6496006)(33716001)(6486002)(66574015)(1076003)(966005)(83380400001)(66556008)(9686003)(66946007)(66476007)(4326008)(5660300002)(21480400003)(8676002)(44144004)(8936002)(508600001)(52116002)(316002)(38100700002)(26005)(6666004)(38350700002)(956004)(2906002)(186003)(46492013)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ilYvIZ6lNtKUGnSjBxUqAx21tU0Rh96AkOU0GFZ0MjvbIcVDzf12Pow/9pIT?= =?us-ascii?Q?MuFpa3YFp6RMQDU717eLeRyNT865zcwc9pUaGxtENRP5Fjr2DByyZhARD1+e?= =?us-ascii?Q?DEEb4oOpkOevaz6FeZxkHZWYw6cvc0pzi1dhpC0VaODL206lwVbXik6va2x3?= =?us-ascii?Q?f5AcLFru2vG5ZK8jqUrHCalMIBUhxrvAmBXWdLuPYmM/x1efWZD+1+zjm3r/?= =?us-ascii?Q?MkXVRz18OeiQyGw1ed/Rz+RKwdF30S48c9+LARGUpFDgxX+73zwhXpTSeIpN?= =?us-ascii?Q?sKWPF5CDZd6QHwwSz4l63u+WFyY69QGphpmzMtpOlYmnEErYAx0I7yC5tPLU?= =?us-ascii?Q?EaJ2dGZ1e38o34gPVnq4irmNpWO3ZMg+7f/R+zLhArK8oXw4jA6xsqKzbIsn?= =?us-ascii?Q?C8wEeJfTllMgpHncNFfcEBUhaavfAdd/h9caMFfmeP9gSeNIJh67kSECVKhb?= =?us-ascii?Q?OtjNaVE3W+QGP05+qiPa/9rVKWRuH/pKtXlXbkR3We3L5xKifwNaB5Vxr2iL?= =?us-ascii?Q?Fw4eL1XQN/226e6MpPqWMDYWvAhmsiMzwOOUayHOmSGQtmNuhYpJxVI3SDOJ?= =?us-ascii?Q?44cV342XKNz95RfPVk92Dqe3iebR3weLUplDrUOfxBFVuO5KIzWhuVFgFMT/?= =?us-ascii?Q?1CgvwLCCZ7mbTNfbjC9NgeogrJv2hE0RVN8OaxQ/q27E4ebaioaLZaEzCBx6?= =?us-ascii?Q?O/UViMRMAdxHxmsIutz1uJhbCba4KrW/5Z1AzBsMf2LaJFGMh9MA7SGgc1LM?= =?us-ascii?Q?ekH9yrWGn42XmYMSc8CqZE2c5T0i8bbgxrL7KU2XhZBHqoQ6pY8WdrdnH7uC?= =?us-ascii?Q?xXH6hhKHgwH/qmwjY57pJM5VulZ72/QeNLqa1bMIafb5D86v47p22GhFsEpW?= =?us-ascii?Q?abyQukXx4J1mkIUowr1z0FMRgYHkMu1gtPH77+cfLV+j4jcRReBiOEuQfb90?= =?us-ascii?Q?F8+0mHvV6kk1qpRAWkyp0EnWnUUiwwHC8RWjDYkwzuPzbCU+S93tX0jEBZbi?= =?us-ascii?Q?9KM7W/RnjOGKd0Iar1+wknrsXj9OcXukCltaHmmTOkslPdiG8PSmmmLvN7SB?= =?us-ascii?Q?g8HsnJSBqC0hA4j4b8xenqj0eRPxj0kPqWNulpMp6HX7beShCYq8qLesGxXI?= =?us-ascii?Q?orxiNhAI02EMbdKlLprONAXT8xjjEgTXxu/zbtuyIKdc8Na+n1cxqjBiZK2q?= =?us-ascii?Q?SVYMM8q4IyfWbPgNkxfNYBz+Fs5W35K0+4s3C8vhN2rN30TWdx3x24xvR668?= =?us-ascii?Q?Nck5jeYIXFxgfteJbCPxip2AtJZ1PUIe4amdRW2SroCDx/RmHRUvZPn+gkAh?= =?us-ascii?Q?xi0/H37RpRBz5FLjexw2ywYTiv6c7KvZfVJ2gTLzl/PGDemNAwEu8IKbDbO0?= =?us-ascii?Q?zN4jkHn6tvijD2WvnVmSiZE17Svr4/na9DQmRDBPmKAwAiVMdugIt4uM81Xs?= =?us-ascii?Q?fLqppes1yipXE/BGoVlzlvYQQyvYAuaxMs5LJpiTx1a8M8hlkHxyPuS5xwOC?= =?us-ascii?Q?NohvgOtzzyyHo0OE1YWMc3RlB4axzNWt8ff3Re9abdYk1ELtr2Rwi7Ufvu4B?= =?us-ascii?Q?ifpTP3uA0cvR2tLOiQpEd8jok55J2XY/7s+Q5ypCEPKC1yGI07elSEE6o6cV?= =?us-ascii?Q?12nBNfADm2qaVuo2K2AQSA8=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 9177874f-b3f7-4ae9-5b35-08d99b8f250f X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1078.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2021 10:22:15.7562 (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: xLQcKwiYgdGL9i+SdV8GXh8tQtIYwWNM7bE9f28iLXxPHMFbEiNgHeAVD8RIloHjP5VvkIJC64gIkZaoblwQgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0467 Archived-At: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 10:22:27 -0000 --slpdbuklq53f2ew4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jeroen, On 10/29, Jeroen van der Ham (NCSC-NL) wrote: > Hi, >=20 > I've joined this list to post the announcement of NCSC-NL regarding the c= oncerns around the RPKI CVD process. >=20 Welcome. > Please find our statement here: > https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement= -of-rpki-cvd-procedure >=20 > I will try as best as I can to answer any questions you may have. >=20 Excellent. I have several: - My understanding of the openbsd disclosure policy referenced in the above link is that it relates to vulnerabilities specific to openbsd, and discovered by openbsd developers. I do not read it as saying: "if you attempt to inform us of something in good faith, and request that it be kept confidential in the legitimate interests of the Internet community, we will ignore you and post it on twitter". You appear to have arrived at the later interpretation. Did you or your colleagues have any actual conversations with anyone involved in rpki-client development that lead you to this conclusion? If so, on what dates did those conversations take place? - When you did not hear back from Rob and Randy after your initial attempt to make contact, what further steps were taken to contact them, and on what dates? I occasionally find myself making email contact with Randy even when I do not intend to, so I have a hard time accepting that this posed such a difficulty. - When you publish the details of the vulnerability, do you also plan to disclose the fact that you intentionally withheld details necessary to mitigate it from many of the very people that were in a position to do so? I hope that when operators find their infrastructure exposed on Monday afternoon, they will be able to make an informed decision about who to blame. - The fact that you appear to have chosen only RP developers in your disclosure strategy suggests that you are of the opinion that the issue is not capable of mitigation without code changes. Presumably, you arrived at this conclusion through consultation with industry experts with meaningful experience operating RPKI infrastructure. Please confirm whether this was the case, and that you will be providing the details of those engagements along with your disclosure? - Please would you elaborate on how you perceive the interests of the "cyber security of vital sectors" to be at odds with the developers of software designed to ensure said security? - Please would you explain how your stated preference for "disclosure at a time when the solution is widely available" is consistent with your decision to selectively withhold information necessary to make such a solution widely available? - Have you used ssh recently? Regards, Ben --slpdbuklq53f2ew4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAmF9HM4ACgkQOkYk/rSL aGC+cQ//TeU968X/CSVQqZqGfKMhCNmPerAVtWy0P0g2KAb+e0Ae+LLtOc/CF1EG EDOxtsZ2DEXUQP4AodhhcceuJY1uhcD/uM4PblFwuIMdWV3nJ/dhKdjHbzFtOHV4 npaEHrx997MGaQNBVAe34DVRFiYjWkyFf476+3C8luF9IkRJAob90vmAmNDEPnnn 5Ti6W0k4AysWNLDKoWxoyFGxwMAwkgkX9dB7sn+iRlaE06VTlamavD5pRSLaECQ7 EizAOMhlBwdtx49EH+4+8ssNvmPl3iHlF4x/+o9yXaD+mVtta7FUZfTsXjyv6XJl 9yrvrhb4gtfAMGNn6JJHPLA6wI9AARrlhKg3Nsei1WacLSWv1EWBS9P2lU0xwXi7 VYJhnR6lgGcEhG3ubRA3QU9JIzP4p008iIo1Q5DeC/QAYnQCTJcXmjToYGLaWUF3 XjPLN20tq4NmoTPk6DLBLoEmCJuLq/X810phcIR4V0l820ocgUpXKi26b84MV389 eazGimCg+Ig/NH4rrXepGYTE+agKiGbV48Upoqykbsd6L8q8wjiR36OSGZjr/8vi M7e8UEeQ7ypW3JBlagkwM39jQENlpe3ZTSQcchtM06gyrWtIFh5/k5eruoeQSnLo 5lp9xWQPgVQD7CUbkoV/FqbcBHxo7YNkOEI7imYqfPaRyJ+reWI= =Hd++ -----END PGP SIGNATURE----- --slpdbuklq53f2ew4-- From nobody Sat Oct 30 07:38:05 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB53A0E7A; Sat, 30 Oct 2021 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, 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 oVS6OkRi9K_7; Sat, 30 Oct 2021 07:37:58 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6359F3A0E73; Sat, 30 Oct 2021 07:37:56 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19UEbksu056863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Oct 2021 15:37:47 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: "Jeroen van der Ham (NCSC-NL)" Cc: "sidrops@ietf.org" References: From: Nick Hilliard Message-ID: <11fbd75c-c32c-215e-db35-adbf318c4c35@foobar.org> Date: Sat, 30 Oct 2021 15:37:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.51 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 14:38:03 -0000 Hi Jeroen, thanks for dropping in. Not sure that sidrops is the best forum for opsec discussion, but hopefully the chairs turn a blind eye. The current situation seems to be that vulnerabilities will be announced on monday which allegedly affect both rcynic and rpki-client. I don't have much visibility of where and how many sites rpki-client is used, but rcynic is used in production by both afrinic and jpnic. If the set of vulnerabilities affects rpki integrity and the vulnerability details are released on monday without engagement with the authors of rcynic, then NCSC-NL is putting a very large amount of public infrastructure at risk. It's a matter of public record that there was an attempt last wednesday to contact the rcynic authors. Randy Bush's reply suggested that this was the first they had heard from you. The terms that were dictated were unilateral and unacceptable from a vulnerability management point of view. Specifically, they flouted well-established industry principles regarding vulnerability management, namely engagement and negotiation with stakeholders, and ensuring that software authors are happy that fixes can be done and tested well in advance of the planned disclosure date. The best outcome here would be for all affected software to be patched and tested to the satisfaction of the authors well in advance of disclosure. Can you describe how NCSC-NL will work to achieve this goal with the authors of rcynic and rpki-client? thanks, Nick Jeroen van der Ham (NCSC-NL) wrote on 29/10/2021 20:03: > Hi, > > I've joined this list to post the announcement of NCSC-NL regarding the concerns around the RPKI CVD process. > > Please find our statement here: > https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of-rpki-cvd-procedure > > I will try as best as I can to answer any questions you may have. > > Regards, > Jeroen. > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Sat Oct 30 12:25:41 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AE33A11A7 for ; Sat, 30 Oct 2021 12:25:39 -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 (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 gaBaXgWFXnfc for ; Sat, 30 Oct 2021 12:25:36 -0700 (PDT) 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 1C6A43A1250 for ; Sat, 30 Oct 2021 12:25:36 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id z20so50400452edc.13 for ; Sat, 30 Oct 2021 12:25:35 -0700 (PDT) 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=di0HMheul+dhI7kwCL4x5Xt95s7hlTCQ43EJr6z0Iu8=; b=K0CTNfGETzdwcyp4C3XlRKAsqlalaPvVFQspNRrxfLqbUVeKDoB6c6G0QElc9qMqdd un1E2Stq4SCqfy4rmObILBVVIvXgpE5bSNRxmsOvO71aste0BHB0QR/trc7U1dRtunkM GnRl2xqteuBidoclePgmE/msjtcgmod+ucTg0= 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=di0HMheul+dhI7kwCL4x5Xt95s7hlTCQ43EJr6z0Iu8=; b=Nb6XQKgqi53WnauceCqOycmcG8My9iUjhUMrUjFCBIVaChVBi/XSz5iBIpptkEgOQF oINoLo4Rk86Pp8aSbkvga6GYGpKD6UvpQttUx3Tf3ZJYmZXWOV03RFzawPsweWJ2U58s mzj693qGsnNmKz6gz9cMcifmgOsAoNkwEruTc52fFCfNTILry3zk2VucyElOZrCN8zD5 mKdivxi/ZuzJ1Be4pHS/Zs5SLnjwtNt5ju7r8xWetZl1vw9EuWUATvEiN+RxajA51qRV TptQ0wMXFdxC9dTBkBSdEEBsy1R2vkqTPRWm6K5O9W5CsalXHyby8k5CuHo1cyHXxrhO 7NzA== X-Gm-Message-State: AOAM533QHwkceOHwDPOb1cGlplv1Iq/2cNzL9+OJ/7X7WJ+wCDt3Ipxq wyu/OSFVEOzq648AZVb1uBorrsMTUdbII7FZLHciZqDeuf5pJKhUjYNd8J77Qz5tXsRpoq2x13l sWem1BbRWJL/TIzwDkvDGm4Y1/vrVwUCG3xuMvrXc+EbDvLYH+acWx+4= X-Google-Smtp-Source: ABdhPJyu/UXs2O2KFOCKvQE3yl1ps68zZpptrcs+euaTAMQVA83No4yvyu97vWFpJXArxb1Czf2u/w== X-Received: by 2002:a17:907:7da0:: with SMTP id oz32mr23241005ejc.2.1635621931581; Sat, 30 Oct 2021 12:25:31 -0700 (PDT) Received: from snel ([2a10:3781:276:1:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id b9sm5984247edk.62.2021.10.30.12.25.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Oct 2021 12:25:31 -0700 (PDT) Date: Sat, 30 Oct 2021 21:25:29 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] rpki-client 7.4: limits on objects and RRDP constraint X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 19:25:39 -0000 Hi everyone, The rpki-client team decided to add a few arbitrary limits and impose a constraint on RRDP in version 7.4 >From our testing and guesswork these limits do not pose an issue for any current CA or RIR Repository, and also allow for sufficient growth for the forseeable future. RRDP specification deviation: RRDP Snapshot and Delta files MUST be hosted on the same host as the notification file. The consequence is that Repository operators no longer are permitted to host the Notification XML on a different host than the deltas/snapshots it references. All current CAs appear to abide to this constraint. Simple numerical limits: * Manifests referencing more than 100,000 FileAndHash are invalid * rsync won't download any files larger than 2 megabyte * Signed Objects larger than 2 megabytes are considered invalid * RRDP snapshot files larger than 2 gigabyte are discarded * RRDP delta files larger than 2 gigabyte are discarded * RRDP notification files larger than 2 gigabyte are discarded * Subject Information Access URIs cannot be longer than 2048 bytes * RFC 3779 extension containing more than 200,000 IP entries are invalid * RFC 3779 extension containing more than 200,000 AS entries are invalid Full release notes here: https://marc.info/?l=openbsd-announce&m=163561569932494&w=2 We welcome feedback from the broader community. Thanks to all of the contributors who helped make this release possible. Kind regards, Job From nobody Sat Oct 30 14:32:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE993A1386 for ; Sat, 30 Oct 2021 14:32:38 -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, 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 rjd2kEfPxPoF for ; Sat, 30 Oct 2021 14:32:34 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 18C243A1357 for ; Sat, 30 Oct 2021 14:32:34 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id a129so1185958vkb.8 for ; Sat, 30 Oct 2021 14:32:34 -0700 (PDT) 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; bh=4Bxb3MAicCBKUKVeqeUqUG8i2wcUzQWo0Ab0+LN+sos=; b=Imdtjq27DpbdGzUie6TWzktQmsbY2jbNrowDN1lActfuei1a7dCuA5ipzhfooi9X53 6s69AOlOdMkkxXZiYx9KMaS4pSeXNQABdCGEcFpK7HVB/T+MdkzIKroVkCgrN/Uv70f2 JX3mmhdouj/PxHo0kyoyVC553T1s98QdNwbmZpGMr1DIPy2G1PEom3kXV9PGV45oYwnH 23ot/MEnfBskMGXqUmHMVnG5y8j9FbZlTtCMFUiyXZzqknuuYLaPNzzVELWNVYF7eRar gBs+VxwdYNR7dtxVuCQ91gX/gKb0Ry90irIz4XGDIx+/sc0XX6DbNEtMmQ8cOkdapP1h NvQw== 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; bh=4Bxb3MAicCBKUKVeqeUqUG8i2wcUzQWo0Ab0+LN+sos=; b=UXwakOcVKyDiv0GL+PgNa0iE7ZzaYRtHAjO10uq3lGU0Ex9DP+oirNgVxWQRvxgMfe Dnt8LGNbcddSrNZ8O6HD/yxcThWxK4txdBjG2+2ixTgmPkZfMn2Wd6dmdm+KPWFfK+Tu 4ocvEWzCEqBHfJffgBLrnSERe3VDWCzZiwQ960yHrjXdLNWfaKkSJSf4i6AnwSAFoVe3 rIG/Rr/wS+qiY1TIrex7Vzk1t8hpXT4ksYmaWNh2eMvQ5czouOYJTgs+QZAzSmFrXS5+ glPipZOkUos+vh8tkffcO0+B9WgungIoxFt70tP83vTx4IK0sJkmbg5JxexPIY+Lymgx i5FA== X-Gm-Message-State: AOAM532qBI5wopgQsnUcNgJZXYtrx4qx21urfDDlRfuH3jgTKeVGgjP1 kYbcJosfXq27Q0rRsqzlkuILT7wTdI5DxQVKgt0KsZZx6haHNg== X-Google-Smtp-Source: ABdhPJwQyczNKkvEcLikwilYwSg9kpmoYmccSxg5KwCgOX/5VNY5+rwK7c9mtaqCPHY7S06eXLClUkyXuMaxZUIDRb4= X-Received: by 2002:a05:6122:884:: with SMTP id 4mr21113561vkf.6.1635629551458; Sat, 30 Oct 2021 14:32:31 -0700 (PDT) MIME-Version: 1.0 References: <163465367954.6522.14340577438091121445@ietfa.amsl.com> In-Reply-To: <163465367954.6522.14340577438091121445@ietfa.amsl.com> From: Warren Kumari Date: Sat, 30 Oct 2021 17:31:55 -0400 Message-ID: To: SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000662ee605cf98ae86" Archived-At: Subject: [Sidrops] Fwd: NomCom 2021-2022 Call for Community Feedback X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 21:32:45 -0000 --000000000000662ee605cf98ae86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please provide feedback to the NomCom -- the IESG you get is the one that *you* help select. Even a few sentences help... W ---------- Forwarded message --------- From: NomCom Chair 2021 Date: Tue, Oct 19, 2021 at 10:28 AM Subject: NomCom 2021-2022 Call for Community Feedback To: IETF Announcement List Hi IETF, The deadline for nominee acceptance and questionnaire submission was yesterday, Oct 18. As of today, Oct 19, NomCom is accepting feedback on nominees for IAB, IESG Area Directors, IETF Trust and LLC Board. NomCom is also accepting feedback on other topics (more on this below). You can see the list of nominees for the 2021 nomination cycle at https://datatracker.ietf.org/nomcom/2021/feedback/ [If you are a nominee and submitted a questionnaire your name should appear on that page, otherwise, please let me know.] You may provide feedback using the web form. Any submitted feedback is encrypted with a key I created and gave only to NomCom members. Without this key, your feedback cannot be seen by the secretariat, the tools people, or any of the management. Your feedback through the web form is not anonymous when shown to NomCom members as you need an IETF login to provide it. You may also send feedback directly to the NomCom via nomcom-2021 at ietf.org If you want to give more anonymous feedback, please contact one of the NomCom members that you trust directly, and ask that person to relay the feedback anonymously to the NomCom. You can also submit feedback via email to nomcom-chair-2021 at ietf.org and I will enter it in the datatracker (one email per candidate, please). Please indicate if I should share your identity with the full NomCom. The positions to be filled and the desired expertise are listed at: https://datatracker.ietf.org/nomcom/2021/ Some of you may be aware of the "360-degree reviews" of the current IESG ADs: https://mailarchive.ietf.org/arch/msg/ietf-announce/DecFofU9c-svf_yiCPQDi6n= LOQg/ I encourage you to provide that feedback as well. I wish to clarify that personnel feedback to NomCom should be limited to nominees (some of which may also be IESG incumbents). This should clarify the difference of NomCom feedback with the "360-degree reviews". NomCom also welcomes feedback on topics related to the nomination process. Please submit via email as suggested above, although some topics may start showing up in the above feedback web form at https://datatracker.ietf.org/nomcom/2021/feedback/. Thanks in advance for your feedback - we really value it and appreciate your time taken to submit it. Gabriel Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --000000000000662ee605cf98ae86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please provide feedback to the NomCom -- the IESG you get = is the one that *you* help select.=C2=A0

Even a few sent= ences help...
W

---------- Forwarded message ---------
From: NomCom Chair 2021 <nomcom-c= hair-2021@ietf.org>
Date: Tue, Oct 19, 2021 at 10:28 AMSubject: NomCom 2021-2022 Call for Community Feedback
To: IETF Announce= ment List <ietf-announce@ietf.= org>


Hi IETF,

The deadline for nominee acceptance and questionnaire submission was yester= day,
Oct 18.

As of today, Oct 19, NomCom is accepting feedback on nominees for
IAB, IESG Area Directors, IETF Trust and LLC Board. NomCom is also acceptin= g
feedback on other topics (more on this below).

You can see the list of nominees for the 2021 nomination cycle at
https://datatracker.ietf.org/nomcom/2021/feedback/=
[If you are a nominee and submitted a questionnaire your name should appear= on that page,
otherwise, please let me know.]

You may provide feedback using the web form. Any submitted feedback is
encrypted with a key I created and gave only to NomCom members.=C2=A0
Without this key, your feedback cannot be seen by the secretariat, the
tools people, or any of the management.

Your feedback through the web form is not anonymous when shown to
NomCom members as you need an IETF login to provide it.

You may also send feedback directly to the NomCom via nomcom-2021 at ietf.org

If you want to give more anonymous feedback, please contact one
of the NomCom members that you trust directly, and ask that person to
relay the feedback anonymously to the NomCom.

You can also submit feedback via email to nomcom-chair-2021 at
ietf.org and I will enter it in the datatracker (one email per
candidate, please). Please indicate if I should share your identity
with the full NomCom.

The positions to be filled and the desired expertise are listed at:
https://datatracker.ietf.org/nomcom/2021/

Some of you may be aware of the "360-degree reviews" of the curre= nt IESG ADs:
https://mailarchive.= ietf.org/arch/msg/ietf-announce/DecFofU9c-svf_yiCPQDi6nLOQg/

I encourage you to provide that feedback as well. I wish to clarify that pe= rsonnel feedback to
NomCom should be limited to nominees (some of which may also be IESG incumb= ents).
This should clarify the difference of NomCom feedback with the "360-de= gree reviews".

NomCom also welcomes feedback on topics related to the nomination process.<= br> Please submit via email as suggested above, although some topics may start =
showing up in the above feedback web form at
https://datatracker.ietf.org/nomcom/2021/feedback/= .


Thanks in advance for your feedback - we really value it and
appreciate your time taken to submit it.

Gabriel

Gabriel Montenegro
IETF NomCom Chair 2021-22
nomcom-chair-2021 at ietf dot org

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
The compu= ting scientist=E2=80=99s main challenge is not to get confused by the
co= mplexities of his own making.
=C2=A0 -- E. W. Dijkstra
--000000000000662ee605cf98ae86-- From nobody Sun Oct 31 07:32:27 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11C83A08D9 for ; Sun, 31 Oct 2021 07:32:25 -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_PASS=-0.001, UNPARSEABLE_RELAY=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=ncsc.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 D3lS2vUOYtLe for ; Sun, 31 Oct 2021 07:32:21 -0700 (PDT) Received: from min1.ncsc.nl (min1.ncsc.nl [147.181.97.77]) (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 0EC5F3A08E2 for ; Sun, 31 Oct 2021 07:32:20 -0700 (PDT) Received: from mailer DKIM-Filter: OpenDKIM Filter v2.11.0 min1.ncsc.nl 67613E0003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.nl; s=ncsc201806; t=1635690738; bh=Q9vY37jj8/efv8MixsQ1v3Zq3zmgPS3rrNXuJ2u6bEE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=eblZ+93zNPswKf9rlnvrqQvWFyafWqTM8Z0RH3w38LOxkrUa4rQkjNSL2VD7Mlzot PfbENrXsEqjgJ6AROuH0GpNiRquspOracBDX0ksdwTWVq1CwXaEUebHuLSo4D9LwKv K0VyeaYSh0ldf40IxtBM3Y//w1GyoNNZwj7lJxhcy9PYN8UUwcwFrAjhcs2jBWCZAT n3VXRDfWn+9jBig594X0SEClXdIzuGSpH+WIzRskvueVFmkkDNLMvxcNjPL8oIJyIh d7OsZLAdg5wLKZVw7MhIsUwe9joo0JgP7SaukprA05yYD4AE7llhZpK0TlgQ0eAc1H uBRwp0lfeeCCQ== Received: from mailer Received: from mailer From: "Jeroen van der Ham (NCSC-NL)" To: "sidrops@ietf.org" Date: Sun, 31 Oct 2021 14:31:53 +0000 Message-Id: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US x-tmase-matchedrid: VfovoVrt/obuo96mfIBuogrcxrzwsv5u3dCmvEa6IiGoLZarzrrPmTn3 zGQhjJHefRQeSD4IX2ewVhQ1GtAqYFvQ2lxoUSXgaPXXRVSBBoup8u/TGEilnNURh96ntLOmGdK UpyZuAVQkD9S2pgqzeySc4ah4hDOW1xQ2OgXti5XrsVSfbsvAHwABHzrfA5PbtXl9IxEPXOrFTl NxrS5r3+4ntHg8jXuSNWri8ZQHmUBA+Fh9U0Q4eijtvm0vFhmtxMZq+YajS9YQ40mF962JIJ4CI KY/Hg3AWQy9YC5qGvy2s0ar5ZAS9Ku6xVHLhqfxwrbXMGDYqV9fbzE2lTRTcyTnDaRB0PhPPY6t nOcSmM/Ud7aKRJlE3OC1hXjiHV4k x-tmase-result: 10--14.414700-8.000000 x-tmase-version: SMEX-14.0.0.3031-8.6.1018-26502.000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 14:32:26 -0000 Hi everyone, We have updated our statement: https://english.ncsc.nl/latest/news/2021/oct= ober/29/upcoming-announcement-of-rpki-cvd-procedure Most importantly: talks with OpenBSD have resumed, and we have postponed th= e disclosure. Jeroen. > -----Original Message----- > From: Jeroen van der Ham (NCSC-NL) > > Sent: vrijdag 29 oktober 2021 21:03 > To: sidrops@ietf.org > Subject: [Sidrops] Statement of NCSC-NL on RPKI CVD process >=20 > Hi, >=20 > I've joined this list to post the announcement of NCSC-NL regarding the > concerns around the RPKI CVD process. >=20 > Please find our statement here: > https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement= -of- > rpki-cvd-procedure >=20 > I will try as best as I can to answer any questions you may have. >=20 > Regards, > Jeroen. >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sun Oct 31 15:45:29 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F39503A0C60; Sun, 31 Oct 2021 15:45:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org Message-ID: <163572032798.22416.6572022077230469828@ietfa.amsl.com> Date: Sun, 31 Oct 2021 15:45:27 -0700 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-6486bis-07 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 22:45:28 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-6486bis-07 as Proposed Standard on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ From nobody Sun Oct 31 15:45:58 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5B13A0C61; Sun, 31 Oct 2021 15:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 5Uk0cFuwq7jb; Sun, 31 Oct 2021 15:45:52 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 7EC183A0C60; Sun, 31 Oct 2021 15:45:52 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id v17so14378379qtp.1; Sun, 31 Oct 2021 15:45:52 -0700 (PDT) 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; bh=32+Dxbs1vRYAcrWvinNO6ccUVUSAF/n0OVyNSyQzRM4=; b=R6NHtklSksJQbn7pCiz7pusw+FBL27bT0ZvFXKAjmf+Io+9VX4NK6TxuyZYse2fyTM 2E+y4MvJXUL5ve50slaX117mU1XGOGSVKpA9GNvtmq4J8KF2GzLPKaabf30RmMpC5j5p 7V4JVjcgfPS5sBWGXk0dfdFPrK/ZA/DqdQYFNjnDXGrF1+56SZg1uiCFobjUN2TACi4C ApvbKYvWUCRkRK1JS/96iwbl/e+5+2uMC/TtjN6W4sP2XLwpmEuU8EzULrg/AUDLuPfP EKVT5UGm4GQS7507bC5M325uJKZOlp5juSDEyaP53M0orJX3325X8bZtajf+qd2IzaoR rxmQ== 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; bh=32+Dxbs1vRYAcrWvinNO6ccUVUSAF/n0OVyNSyQzRM4=; b=p3HntcaddFPmtT7KpTu1CbTKd/lTCgpW6x+vUpY1Ix7k3QsQ3GRAmd0D4vRac2Y9H2 1+S91CKR4r1i4nRsMN8YdFWXV3MXvkZWAFO6pgHEx8tH3kINimA4ESHRolCesBbQitEc dxoRTWijXxgKzYXbjaoxGCsJVlFw2PK2FryR9JUTsZorYayE8pkqZ6nD51TtvOPePKhJ ORQS7InJ4wK1girE5oYqabAuyHr27GsP1E8d047OK1XIJlgH6K0bzkFZjxiJe6ZOozbc DgQStYF3U0KVV3KzfOdKSosOHZKSbx6rY/uBxycElDV3CUUw4PA5iitlwVwCcDZTyZBj mZbQ== X-Gm-Message-State: AOAM531QHqw7mei4RZ+Ns0A8pb5rl9c25OlNCVBVRDdDu/TgUis7L5Wb DBgKwjhr8X1zLKo3tcGlViBdMb3JqyBcQQ9R0QmursT2fQY= X-Google-Smtp-Source: ABdhPJwRXCZpKZPhDsDEeVoF0FITfU5wWtmBdkz7cAt8UFyvaYXzLIXkVf4yM0OLm+MGrIENhW2TcQm92Zb6P31pt44= X-Received: by 2002:ac8:5c48:: with SMTP id j8mr19332905qtj.317.1635720349886; Sun, 31 Oct 2021 15:45:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sun, 31 Oct 2021 18:45:39 -0400 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="000000000000682d8205cfadd242" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 22:45:57 -0000 --000000000000682d8205cfadd242 Content-Type: text/plain; charset="UTF-8" this finally got done. On Thu, Oct 14, 2021 at 1:22 PM Christopher Morrow < christopher.morrow@gmail.com> wrote: > > Backing up to the top of the thread.... > > I think there was some good conversation, small changes (acceptable to all > parties) and consensus to move forward! So, > please consider this a closing comment on the WGLC, I'll kick out a > shepherds doc and push forward into the waiting arms of the > (loving?) IESG. > > thanks! > -chris > co-chair-persona > > On Fri, Sep 24, 2021 at 1:58 PM Christopher Morrow < > christopher.morrow@gmail.com> wrote: > >> WG Folks: >> Please take this as a WGLC start for: >> draft-ietf-sidrops-6486bis >> >> The abstract of such is: >> "This document defines a "manifest" for use in the Resource Public Key >> Infrastructure (RPKI). A manifest is a signed object (file) that >> contains a listing of all the signed objects (files) in the >> repository publication point (directory) associated with an authority >> responsible for publishing in the repository. For each certificate, >> Certificate Revocation List (CRL), or other type of signed objects >> issued by the authority that are published at this repository >> publication point, the manifest contains both the name of the file >> containing the object and a hash of the file content. Manifests are >> intended to enable a relying party (RP) to detect certain forms of >> attacks against a repository. Specifically, if an RP checks a >> manifest's contents against the signed objects retrieved from a >> repository publication point, then the RP can detect "stale" (valid) >> data and deletion of signed objects." >> >> The WGLC should finish on/about 10/11/2021 - Oct 11, 2021... There's >> already one question/comment on-list for this WGLC a pointer to which is: >> >> https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc >> >> Please give the -06 version of the document a read/comment and if you >> have opinions(about this document!) please express them on-list before Oct >> 11, 2021 (10/11/2021) >> >> -chris >> co-chair-persona >> > --000000000000682d8205cfadd242 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this finally got done.

On Thu, Oct 14, 2021 at 1:22 PM Chri= stopher Morrow <christop= her.morrow@gmail.com> wrote:

Backing up to the top=C2=A0 o= f the thread....

I think there was some good conversation, sm= all changes (acceptable to all parties) and consensus=C2=A0to move forward!= So,
please consider this a closing comment on the WGLC, I'll= kick out a shepherds=C2=A0doc and push forward=C2=A0into the waiting arms = of the=C2=A0
(loving?) IESG.

thanks!
-chris
co-chair-persona

On Fri, Sep 24, 2021 at 1:58 = PM Christopher Morrow <christopher.morrow@gmail.com> wrote:
WG Folks:Please take this as a WGLC start for:
=C2=A0=C2=A0draft-ietf-sidrops-64= 86bis

The abstract of such is:
=C2=A0 "Thi= s document defines a "manifest" for use in the Resource Public Ke= y
=C2=A0 =C2=A0Infrastructure (RPKI).=C2=A0 A manifest is a signed obj= ect (file) that
=C2=A0 =C2=A0contains a listing of all the signed object= s (files) in the
=C2=A0 =C2=A0repository publication point (directory) a= ssociated with an authority
=C2=A0 =C2=A0responsible for publishing in t= he repository.=C2=A0 For each certificate,
=C2=A0 =C2=A0Certificate Revo= cation List (CRL), or other type of signed objects
=C2=A0 =C2=A0issued b= y the authority that are published at this repository
=C2=A0 =C2=A0publi= cation point, the manifest contains both the name of the file
=C2=A0 =C2= =A0containing the object and a hash of the file content.=C2=A0 Manifests ar= e
=C2=A0 =C2=A0intended to enable a relying party (RP) to detect certain= forms of
=C2=A0 =C2=A0attacks against a repository.=C2=A0 Specifically,= if an RP checks a
=C2=A0 =C2=A0manifest's contents against the sign= ed objects retrieved from a
=C2=A0 =C2=A0repository publication point, t= hen the RP can detect "stale" (valid)
=C2=A0 =C2=A0data and de= letion of signed objects."

The WGLC should finish o= n/about 10/11/2021 - Oct 11, 2021... There's already one question/comme= nt on-list for this WGLC a pointer to which is:
=C2=A0=C2=A0https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2= dbXr516Kdg35Amc

Please give the -06 version of= the document a read/comment and if you have opinions(about this document!)= please express them on-list before Oct 11, 2021 (10/11/2021)
-chris
co-chair-persona
--000000000000682d8205cfadd242-- From nobody Sun Oct 31 17:23:09 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2683A0778 for ; Sun, 31 Oct 2021 17:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 BrWDILUMSQro for ; Sun, 31 Oct 2021 17:23:03 -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 B1AFC3A0774 for ; Sun, 31 Oct 2021 17:23:03 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id h4so13893657qth.5 for ; Sun, 31 Oct 2021 17:23:03 -0700 (PDT) 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=VatneNDocUHXKppxu3deR4ItrONGiy8Vr1mgOzLMbyc=; b=S121gnduAhwFs08KZMfg8mxmHB/9gjuLuGxDw4YLzff8+IgP92Emlg3XjoT/RLITjC nX4Ef9ACT5m0liIV+HqmIHigDk+AfFDtSbCF3vubF945kPDLCOqcbZ+QOsBhVs9mlXuL 1FlxSlNuGDkczVkOrNczFLyZMETSuqKleM4mvCiWwnSaGQ2ngRmkz04KiFCnCz55T7bS lwe2RUe9ho9t/2Me2WhfOhNtlHgvD+DK2beNFxPHhGkNnZZjafhLtA15TkFR7msqvabo 7a2XDAQBp66J1febXpLn7C9PQ/NGYhd1cipkO97OxHNzrq7igGnqNu7pcQCe9eGK9K1v PDzg== 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=VatneNDocUHXKppxu3deR4ItrONGiy8Vr1mgOzLMbyc=; b=niGqD7ckcvYe0856RmajU0+3Q1IGiW7xCUD+77nMP19XC4A/GjdYsNPMMTB0aw27wn kzpSDdk6cgJzIh8xrmuW0fVU0mkmVL1dkzUXlEmPeU+lqPVV1BlGw7BaibUDGsyLbvBF Y3GQ/Z+e5rk9guTxUC8Aybolzy59YPYK7zSWsVwTh7ZS61U+Jkr9BkBO7LgBMyruncZe mpSmbm/2vwurmkOBg9EogSrlxq6cha8RhVHXiSDOL5+C0AM/KKIq2E7abkq8TZm4tT4N HClAO+oaxfoWnjFzjdtUITjQfqYHzFNJ2TDXEHTCimjwVxqMAyz6j+c/9v9QgiDn7m2P B6Wg== X-Gm-Message-State: AOAM530fkhI8UuxThuFYG5ohAiG+lpfkGaW4TbjmSNtXdq/FpI73T1qT KewJSfGWLvB9BGvMlbwnD6tGFZiB+AA+SV4Q/8A= X-Google-Smtp-Source: ABdhPJyyMCW0844fLQHStzH2Y5F3gQR1uvV93FQA5KlPD61rGbdLAKc17c9vXe4QVtIxIxD8J4zipB/FQOYkh1ZPuhY= X-Received: by 2002:ac8:5c48:: with SMTP id j8mr19705150qtj.317.1635726182147; Sun, 31 Oct 2021 17:23:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sun, 31 Oct 2021 20:22:51 -0400 Message-ID: To: "Jeroen van der Ham (NCSC-NL)" Cc: SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000009689405cfaf2e4c" Archived-At: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 00:23:08 -0000 --00000000000009689405cfaf2e4c Content-Type: text/plain; charset="UTF-8" Thank you for the update, and the delay in announcing. It would be great if the fixed software were available with enough time to test and validate prior to the announcement. The global bgp infrastructure is operated by many entities, some of which depend on working rpki validator software for safe operations of their (and the wider) networks. Pushing everyone into an uncomfortable corner was very... Unhelpful; ( Thanks! -Chris On Sun, Oct 31, 2021, 10:32 Jeroen van der Ham (NCSC-NL) wrote: > Hi everyone, > > We have updated our statement: > https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of-rpki-cvd-procedure > > Most importantly: talks with OpenBSD have resumed, and we have postponed > the disclosure. > > Jeroen. > > > -----Original Message----- > > From: Jeroen van der Ham (NCSC-NL) > > > > Sent: vrijdag 29 oktober 2021 21:03 > > To: sidrops@ietf.org > > Subject: [Sidrops] Statement of NCSC-NL on RPKI CVD process > > > > Hi, > > > > I've joined this list to post the announcement of NCSC-NL regarding the > > concerns around the RPKI CVD process. > > > > Please find our statement here: > > > https://english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of- > > rpki-cvd-procedure > > > > I will try as best as I can to answer any questions you may have. > > > > Regards, > > Jeroen. > > > > _______________________________________________ > > 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 > --00000000000009689405cfaf2e4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the update, and the delay in announcing. It= would be great if the fixed software were available with enough time to te= st and validate prior to the announcement.=C2=A0

The global bgp infrastructure is operated by many entiti= es, some of which depend on working rpki validator software for safe operat= ions of their (and the wider) networks. Pushing everyone into an uncomforta= ble corner was very... Unhelpful; (

Thanks!
-Chris

On Sun, Oct 31, 2021= , 10:32 Jeroen van der Ham (NCSC-NL) <Jeroen.vanderHam=3D40ncsc.nl@dmarc.ietf.org> wrote:
Hi everyone,

We have updated our statement: https://english.ncsc.nl/latest/news/20= 21/october/29/upcoming-announcement-of-rpki-cvd-procedure

Most importantly: talks with OpenBSD have resumed, and we have postponed th= e disclosure.

Jeroen.

> -----Original Message-----
> From: Jeroen van der Ham (NCSC-NL)
> <Jeroen.vanderHam=3D40ncsc.nl@dmarc.ietf.org>
> Sent: vrijdag 29 oktober 2021 21:03
> To: sidrops@ietf.org
> Subject: [Sidrops] Statement of NCSC-NL on RPKI CVD process
>
> Hi,
>
> I've joined this list to post the announcement of NCSC-NL regardin= g the
> concerns around the RPKI CVD process.
>
> Please find our statement here:
> https:/= /english.ncsc.nl/latest/news/2021/october/29/upcoming-announcement-of-<= br> > rpki-cvd-procedure
>
> I will try as best as I can to answer any questions you may have.
>
> Regards,
> Jeroen.
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/s= idrops

_______________________________________________
Sidrops mailing list
Si= drops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrop= s
--00000000000009689405cfaf2e4c-- From nobody Sun Oct 31 18:00:47 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113053A08A9; Sun, 31 Oct 2021 18:00:45 -0700 (PDT) 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 M8CKpRBOG4mF; Sun, 31 Oct 2021 18:00:40 -0700 (PDT) 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 743E13A089B; Sun, 31 Oct 2021 18:00:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mhLgj-0004W7-BJ; Mon, 01 Nov 2021 01:00:37 +0000 Date: Sun, 31 Oct 2021 18:00:36 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: "Jeroen van der Ham (NCSC-NL)" , SIDR Operations WG In-Reply-To: References: 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: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 01:00:45 -0000 > Thank you for the update, and the delay in announcing. It would be great if > the fixed software were available with enough time to test and validate > prior to the announcement. they did not even contact rtrlib folk; and rtrlib is incorporated into vendor products. this means a two stage fix and distribution. here, for example, are grownups, with a three month disclosure window https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities/ randy From nobody Sun Oct 31 20:29:42 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42D23A0D69 for ; Sun, 31 Oct 2021 20:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 upX2gcE958OE for ; Sun, 31 Oct 2021 20:29:36 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 8D2323A0D64 for ; Sun, 31 Oct 2021 20:29:36 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id g25so9438160qvf.13 for ; Sun, 31 Oct 2021 20:29:36 -0700 (PDT) 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=EdmMNK6lDR57+302MBHuka+f8NFdHjVFmjFjbEfrsi0=; b=VpYgSXm4efLQCDI1OqHuDTUf5ZDpaju2L+P0DM6oL0jcyclrJhDOqVUCnNUAhA/PV3 6AZh5aIgiWXdC64ek3eEhxtZRpCS0bhX7wnEf4u5UdmrQUIdSknDfbqJrKsJnP7ywS7X wK9YWdoabtUPMWJ8j4IOyYuzf9eTIR6JWZm3Vy34Ss6RuQDiy/qxhGFZ3tDun1YEY1bh 6mxGfKWNgBM5oFfGTLKkQDEoVBxnvsaj7ZZ3cts486fxrhaiuSAhxZ00ElXMjc2E7VFW Ykyg8uuy8V9q+PySH6bsa2joYANIatWwejKp8deE9aHEy1QTNXJU7s4mBKCMoRMMZ1KK tzVA== 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=EdmMNK6lDR57+302MBHuka+f8NFdHjVFmjFjbEfrsi0=; b=3FYuOeiFJtDMbmRj1ZgVj/hxBNPE/O3Y/yT3RUbY5QIpuPOZnA7Zy5rGcuLgrxRp09 Tlzti5Khf6Pc+rrilA13SMVkc8Yi/0dfV+kngcQyc3QC9Obrxdu22twvRfrVZuUONo3+ EkhwAM4KeV+yOEJHtRX3em2NJ5tZ7zSJY8z4HIpvcZ+15UrjdcFv4LsLmwWbzaDmr7wi KwXnTs7A7GU9DBCySOOgpBprCz3z7dBHpg2zUnYO6lgJVx5cZlshRtwRBWfq0fzDt6rg lYDDMBcmRZhm/FzTqP0bWmwkd3elIWQ4nEZzNYBWcBl9NosVTBhgFeePhJDq88Cu1bLm fOhw== X-Gm-Message-State: AOAM530rWQ6nSGc1me/LVzcRo4/qT3d0e1+0wX+jZgqhCeIPx4wF71Km mvJ1EiZ7+m0dKXud3Gxup/Ln8aMYvpx8Oitr8I4= X-Google-Smtp-Source: ABdhPJx8CG4WaDztl3kRJ9lp1mPDx8q5pu26gPng9f9cgp6ZWa9fnw0LJYp34NfIROD92ye0vaHgfv2jr0aX4AK1R/Y= X-Received: by 2002:a05:6214:23cd:: with SMTP id hr13mr25738580qvb.20.1635737373777; Sun, 31 Oct 2021 20:29:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sun, 31 Oct 2021 23:29:23 -0400 Message-ID: To: Randy Bush Cc: "Jeroen van der Ham (NCSC-NL)" , SIDR Operations WG Content-Type: multipart/alternative; boundary="0000000000001c238905cfb1c942" Archived-At: Subject: Re: [Sidrops] Statement of NCSC-NL on RPKI CVD process X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 03:29:41 -0000 --0000000000001c238905cfb1c942 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 31, 2021 at 9:00 PM Randy Bush wrote: > > Thank you for the update, and the delay in announcing. It would be great > if > > the fixed software were available with enough time to test and validate > > prior to the announcement. > > they did not even contact rtrlib folk; and rtrlib is incorporated into > vendor products. this means a two stage fix and distribution. > IDEALLY that also happens with this longer timeline. IDEALLY that code is not vulnerable.. but .. who knows because no details? As a network operator, for a reasonably sized network, I'm more than a tad distressed about how this process has been handled ;( I plan to see if there are folk in my ${CORPO} who interact with the NCSC-NL and .. perhaps bend their ear about how this process went down :( I also plan to find utwente related folk at ${CORPO} and see if they can bend ears in that forum. > > here, for example, are grownups, with a three month disclosure window > > https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities/ > > randy > --0000000000001c238905cfb1c942 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 31, 2021 at 9:00 PM Randy= Bush <randy@psg.com> wrote:
=
> Thank you for = the update, and the delay in announcing. It would be great if
> the fixed software were available with enough time to test and validat= e
> prior to the announcement.

they did not even contact rtrlib folk; and rtrlib is incorporated into
vendor products.=C2=A0 this means a two stage fix and distribution.

IDEALLY that also happens with this longer tim= eline.
IDEALLY that code is not vulnerable.. but .. who knows bec= ause no details?

As a network=C2=A0operator, for a= reasonably sized network, I'm more=C2=A0than a tad distressed about
how this process has been handled ;( I plan to see if there are fol= k in my ${CORPO} who interact
with the NCSC-NL and .. perhaps ben= d their ear about how this process went down :(

I also plan t= o find utwente related folk at ${CORPO} and see if they can bend ears in th= at forum.
=C2=A0

here, for example, are grownups, with a three month disclosure window
https://www.l= ightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities/<= /a>

randy
--0000000000001c238905cfb1c942--