From nobody Wed Dec 2 16:26:38 2020 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 71F053A00C4 for ; Wed, 2 Dec 2020 16:26:36 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hxr-us.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_gtfw_SXMfR for ; Wed, 2 Dec 2020 16:26:34 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741A13A00D8 for ; Wed, 2 Dec 2020 16:26:34 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id s27so156543lfp.5 for ; Wed, 02 Dec 2020 16:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+C7rk+YtSvjUPG254fZJBe8OuUzBYeCk8x9EKJcGkyM=; b=NLTonj0wk/BP7fuWvvgZvSBBd6zmZIuLU83Bz0SiyWl9vNmJ62WMhLjOdxEPNJeJPD JNebLGtM3MU3v9ERl7ckmbShaa2CJQq28EEvvEINA5EPNbjtpOfFldytO9uyBTebXbX8 OC7PZJf17h1OqlLxoG5A6ilsqItW4q+oZmRcuPSmkVuL4hH1lIy5B9i2DnFFDc+OMMSn I5Fz4pkaarv7+oo6QfFDoDXUfz09si6eA3fGtNbBOAOxcLqvbRuwJEVSjxwMqGIVQlo5 YB92cs9q7sD3iG9naE/ZuKl+InhDaJ9XEGGR88MIsOlFCUTnK6kx230/tYaD2xLQUgD1 EWSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+C7rk+YtSvjUPG254fZJBe8OuUzBYeCk8x9EKJcGkyM=; b=nKc5BXUcVx6zD3sz5UmZ7PUhaWMDr7d9NROend7R5KF2vp7OJQn9ExlkABbVWSxxJ5 Uv/BxkOPv/lMt2JVGjBeP/8/tGHFHcDn7dPgi3kWfQh2StfjvOM5bKgWvUTE2/t2mlkE bBL2HQ0RR2zu7K0W06e8uUc2asgF8FbqL4Mp0z5BU+90Rjpk2To/flOxj/ndywgliQZH ujIAEKWOnP1lI140e6LDA8wGqAlnvCSJZKzvYiFOUnO6efitkzIhYAzOynluMOpQhc42 uElvPp03Cx/dbAhnKCTb64i5EfGmWMOxP8iKNc6LNOMCqtRubeahJHaVm+HMc7bwYyAy bgXw== X-Gm-Message-State: AOAM533L6DJDBAeNC1zd/UDzc+k5ubj3Sws+ooVIOo3XP/4InbWF38oW 3XS4iprL53qwLEegDZ5mkHwWEFXHbbiAO9WVYQY/Ww== X-Google-Smtp-Source: ABdhPJyJg+k1tUPOYyy0B3p9tUA4F5OgkX1qawnBcPxkgypN3sYZIzMm97PflKHhLHLfRo+J6ob5WCVVB6o1rmQf4Yk= X-Received: by 2002:a05:6512:3384:: with SMTP id h4mr241188lfg.554.1606955192316; Wed, 02 Dec 2020 16:26:32 -0800 (PST) MIME-Version: 1.0 References: <20201120091030.ffpkqhfhmf53wnm2@benm-laptop> In-Reply-To: <20201120091030.ffpkqhfhmf53wnm2@benm-laptop> From: Andrew Newton Date: Wed, 2 Dec 2020 19:26:21 -0500 Message-ID: To: Ben Maddison Cc: Christopher Morrow , SIDROps Chairs , SIDR Operations WG , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) 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, 03 Dec 2020 00:26:36 -0000 On Fri, Nov 20, 2020 at 4:11 AM Ben Maddison wrote: > > We have at least two immediate use cases for this: > - Ability for customers (and maybe peers more generally) to prove > ownership of their ASN > - Ability for customers-of-customers to signal to us which TE/Anti-DDoS > actions we should honor via communities for their address space I see several use cases for this work as well, and I support it's adoption. -andy From nobody Thu Dec 3 14:42:34 2020 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 1D0B23A0E57 for ; Thu, 3 Dec 2020 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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=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 IuouGwz7G8uk for ; Thu, 3 Dec 2020 14:42:24 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2051.outbound.protection.outlook.com [40.107.22.51]) (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 3E2843A0DF9 for ; Thu, 3 Dec 2020 14:42:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JZkTMwex2IbXKWxq0LvyVeA2Wz7JnvaReOtQlw5bwYfq882SDAMJUKDtl0bmoRE9xZlupiyrhT8i+LQHwsU009n85tKJd9A/nql6syveEaYBh4oj5z5A6pYbhqby20pDvhWax1iyOVQOXtfBf4B3jwXAUZDuxiwwfyvlwKv/EgHxdPK029loT88P6tJeRLY5NcVl0ZbBJwJvuOP04Bs/4uMOHuoRP1GzWauvEd1pfUd1TlVeUB/vtLpTaZwm8Lr4nkK/ENSAbp4RkIVRSez8w9kshlMhNKWWc/UkHSDyRiQIsphcqoef7uzh3HIqz+7QV55ZbHfXXGFJ7Udhs+r28A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AC2f0Sfq4R6mvAUHi6xqLeMd/O58voAMT9p7qMjI6nU=; b=ghML4KQMMaG+l2pAiag9W4zttyYmpXKerRYY92JSZuL1F5gHGEsJBsNjRHYB/MdQdeNedSDkcjoWPxD+PTYAkXJI1/eYKI4cwUfAxQyke9uzlgkBlGQx8uglEHeXNdo1Rl0fYuFAquzjcD8nYYVb2QE98wV6CwcFBHUjY5qRGUzD7hlKDR4WmhXg8a6bKfJ3RLRSWo6aooW0yF8D0EphqKE9YKU4hVCDiPOfP7JQ6HcMSpHxGskba5tnuuKZTtRpFEJqWyTDNzIALCaSZJxf4qJDfJ5kI+Jq3WhdLv1zY/Wb++Md+objNqUrs99xhVQZqf24BKYarVGn8rmFRgP8SQ== 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=AC2f0Sfq4R6mvAUHi6xqLeMd/O58voAMT9p7qMjI6nU=; b=hosKwPKbV6hHlxzqYZh8D95C1uW5uQILuPNrtxbaN7eJ1cv/hWm0PhOErvq0MoH/8XL7yxa3RCOS4QpXgMxZkfEJNPIHDG0AYzQ+8z1HHXh8Nnvoc8293Lxfo/rjn6MOVOItBFSQqbndg0rwhRXo4TLAI1ql5IgeVDU7QN6z9Fg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB6P190MB0549.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:3b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.31; Thu, 3 Dec 2020 22:42:20 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda%3]) with mapi id 15.20.3632.017; Thu, 3 Dec 2020 22:42:20 +0000 Date: Fri, 4 Dec 2020 00:42:13 +0200 From: Ben Maddison To: sidrops@ietf.org Message-ID: <20201203224213.gnb2nawujxm7a32q@benm-laptop> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ngqh4sdjdhb2t6jz" Content-Disposition: inline X-Originating-IP: [160.119.236.50] X-ClientProxiedBy: JN2P275CA0005.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:3::17) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (160.119.236.50) by JN2P275CA0005.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Thu, 3 Dec 2020 22:42:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0772fcc4-3186-4b5c-4fb7-08d897dcb186 X-MS-TrafficTypeDiagnostic: DB6P190MB0549: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 02dlD2k2JsCHoPu1bWSxcBduLtlltB6qNxULAWNZoyF5+wbfsuRcNWpaEmn3FWqNCTHM1+xoHjCiCRPSv7pr5EMgrncZrHcp4WPdr617CMZOsKXHuPP8Um7oaN07Zty/B6ImfjloVtm475/lH8luHNy612BEYigGtRIINlAPDlw5Z8p4PS2/kHc1uoAJkmqWN/K7aEfogem2dtEa+6XQ34Suy+bxXr4CBskxWPgZVXH5Kj4VwI3wx3/F+qIINicDWpWoB1xo+J+KMdk9eo7Hws3hYtf/8hF7iGxinCXKy2OJMrXARdd9dmaV1Dsy7CuJr6b2Hw99a9K4iFR5/UIDUJt7Lb23tPejOQKHb8VlTgwLINxGP1CEy7ro+JA/Kz+vmtp9mY3IMTnWEopMPwsbU3grSiu+e993AuvwQ0oP6uD9duYg9qxJXgh03bUL2g1/u6Gl8YhWO6aFp4/vjl3Jj5tIUpOP8npHdwpAj/YeFLarZ1h26DpS+tbOkI8m13PghdE8/P0EjdkRXTWwT44NLA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(346002)(396003)(376002)(136003)(39830400003)(366004)(6486002)(956004)(86362001)(8676002)(8936002)(83080400002)(44144004)(66476007)(186003)(66946007)(16526019)(66556008)(5660300002)(966005)(83380400001)(26005)(6496006)(478600001)(21480400003)(52116002)(316002)(2906002)(33716001)(6916009)(1076003)(6666004)(9686003)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?bld1yEiObN69o3/yxbEWt8UmuUMk0jmMqfVz16lJ/JAo0ScSrsQopqEPSW4S?= =?us-ascii?Q?TK07tyecR5BdokyG3anVEOuuTFcggfhzZh1OlaqzqKd99ytNERUp7M/CdWUz?= =?us-ascii?Q?pZjlZtQ5t+y0QXGWquVJO3VbO13ftWy+4J4iSdcz8cMH/F/ZORdlh0qSHqik?= =?us-ascii?Q?0H4MmM01Pa1+hZqJ6r6pY6I1Dbqz+q54i4FJCF/GG5A1xActS9QyuVBi2FMe?= =?us-ascii?Q?my6icQk8mz0GFUB2h7wIOGAHqmM55HgAGTfuwlGcpa1GKjRUC2R8wIZz9g79?= =?us-ascii?Q?2Z/scLb/4oRfYh/GcG/x+w3qfN1uZ/GUsp2GPpjOHwDDACVtuhy2UO1XlfPr?= =?us-ascii?Q?LA5dv6Klj9M29dPIujot+q45Rc4LyRjnIPwagGCdvk2l2zekqcLsTfLgxd2N?= =?us-ascii?Q?nzydL+lr7jtehnn2XDCCFK2sG3IlY+dZWTS6D1224sc3oqVwbTCkeZAGituJ?= =?us-ascii?Q?t55xpHeHPIslaP3b/ZsnuK3+9jrAf/uUDujvbONLDLInyQLwqMNyvRSp2PEt?= =?us-ascii?Q?+SbLEw4L4z9IAD28jQ6P3UxlKUe60eu32l2ASZb1QoePpUhAZ/WQtKRCH6nf?= =?us-ascii?Q?p8Nnp9eaZmBVDLnscWMekaP/alJaWNFaDxs+/zJzwnTu2sOKG9/QidT3EBG2?= =?us-ascii?Q?hO4Qo3IKBc0/Sp45sRYRGuQxJjjGkwPl2Ox4MJ2ItXzf21M7xnyqOiLJCGSi?= =?us-ascii?Q?kRUl7z94xIJWvvaWUcByDyAl1G7Ao9Pef3BuyQL7w3u1cRjF5jQ4dhW83Jbz?= =?us-ascii?Q?ikEylafdiO9yBJ3NJOgkI6NWGeEuBG79QMmzJyv3rTNKzorjghQMyjRLUVsq?= =?us-ascii?Q?jNP7NqKwT/54sDV1Eum2ZMa6X6uSML32ASSS835OP7Mwbu9mjMKQ95BMS1U1?= =?us-ascii?Q?0NjHhmoxZrrP5Px1d7SA/mc/Kx/ebVSMCCEep0bi4FcARN2V3bavoc8ZFb96?= =?us-ascii?Q?QgNxX9S5bmmorMXPcEdVSB5ZR0ymjkX4YH0X3K03U8AgX/baRMu9TTlCJmC0?= =?us-ascii?Q?/DAY?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-Network-Message-Id: 0772fcc4-3186-4b5c-4fb7-08d897dcb186 X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2020 22:42:20.3856 (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: 7ubzgI4ew6tEr+0tgRO7fzKo/bsAJqcS7i1rNkpFlkmsZQpAeBLVkOcNsrDEBPY0N5YzR3/8iBYqSFlgYWjdLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0549 Archived-At: Subject: [Sidrops] 6486bis: referenced object validation 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, 03 Dec 2020 22:42:34 -0000 --ngqh4sdjdhb2t6jz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, As a result of the incident last night that caused the number of VRPs output by some RPs (certainly routinator, possibly others too) to drop dramatically, a couple of us have been going over the observed behaviour in comparison with the current text of 6486-bis. It appears from Job's analysis [1] that the incident was triggered when several resource certs that were listed on an APNIC issued manifest became invalid due to their 'notAfter' time expiring, which in turn caused the affected RPs to consider the manifest invalid and fail the fetch. It should be perfectly legitimate for a manifest to list objects which will become invalid during the lifetime of the manifest, or which are not yet valid when the manifest is generated (for pre-staging). The presence of such objects should not invalidate the manifest. I think there are at least two places that need an update in light of this: Section 6.4 states: """ If there are files listed in the manifest that cannot be retrieved from the publication point, or if they fail the validity tests specified in [RFC6488], the fetch has failed and the RP MUST proceed to Section 6.7 """ The reference should probably be to both RFC6487 and RFC6488, as the former provides the validation details for .cer and .crl objects, which are presumably intended to be included in this step. Additionally, due to the values in the 'notBefore' and 'notAfter' in a Resource of EE cert, an object that was legitimately included in a manifest may become invalid when processed later in the manifests lifetime by an RP. I would therefore suggest the following revision: """ ... if they fail the validity tests specified in [RFC6487] and [RFC6488= ], with the exception of the checks against certificate Validity From and To values described in Section 7.2 of [RFC6487], the fetch has failed ... """ Although not directly related to the current problem, the list of objects in section 6.4 for which the ability to process is mandatory=20 should perhaps be reduced to those in general circulation today, and not include BGPsec certs or ghostbuster records, since those add approximately zero utility to an operator who wishes to run an RP today, and are therefore unlikely to be priorities for implementation. Next, section 6.6 states: """ If a current manifest contains entries for objects that are not within the scope of the manifest (Section 6.2), the fetch has failed and the RP SHOULD proceed to Section 6.7 """ I believe that the reference to 6.2 is a typo, and should point to section 2: """ A manifest associated with a CA's repository publication point contains a list of: o the set of (non-expired, non-revoked) certificates issued and published by this CA, o the most recent CRL issued by this CA, and o all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA. """ The term "non-expired" begs the question of whether a certificate should be non-expired at the time of manifest generation or RP processing to be in scope. On the one hand, insisting that a listed certificate be valid throughout th= e manifest lifetime is what gave rise to the failure described above, and is clearly, IMO, the wrong choice. On the other, insisting that a certificate be valid at the time of manifest generation precludes certificates which have not yet reached their notBefore time. Validating as if "at manifest generation" also appears to contravene the guidance in section 4.6.1 of RFC6487: """ Relying Parties SHOULD NOT attempt to infer from this time information that a certificate was valid at a time in the past, or that it will be valid at a time in the future, as the scope of an RP's test of validity of a certificate refers specifically to validity at the current time. """ As above, therefore, I would suggest that rather than choosing either of the above options, the question of temporal expiry should be left=20 out of manifest validation altogether. Thus point one of section 2 becomes: """ A manifest associated with a CA's repository publication point contains a list of: o the set of non-revoked certificates issued and published by this CA, o the most recent CRL issued by this CA, and o all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA. The list MUST include any objects that have a validity period that overlaps the period between the thisUpdate and nextUpdate times of the manifest. ... """ There may be other parts of the text that are similarly in need of update or clarification on this point: I'll update if I find any. Hopefully the above makes sense. Please let me know if anything is unclear. Cheers, Ben [1]: https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html --ngqh4sdjdhb2t6jz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/JacUACgkQOkYk/rSL aGC4pw/8CGs0PG/4ETypkCQNTgdjABfoL/5YV0sL1WDGsjAVEgUvlC+Qu0PQ0noD h1iMsp9dDmXPMLfJKqEIF6Ed7UH0dNFHElZCHKh8378vVWtRcEi79aV7uizg3dYc wXaDQs7YoZL1YJVR+PvZ+EPJ/HILtic5GeSyoH9HwX+8k6cSutElXCVBME+EbCaU gR5k2uuRjHxRTMNgWHLB4M9PQNWclp68kE2CrmfVzyqZedhIyjED5+JTEdnZLzzv 0zPGx3b+LNeJ9HL/jKvJDdHQ1Rm6XIFJFWJAVhGW+ZiZuOHvkUJGU3V4OW4suzle nc/tcjhPe//KSiT/pC0iHCwqvzodLUQjyOytWDHbCxkR7QpHxxUo26DsK3JmJUJK EooBOxuDF+pC0Mf5nv06bz2IoDyf2fb5d0xhscWk23tG9g5jcA+2p9j53h2CONEZ nBZairssxo6AzYsltj8jJtyBUH4wAPFF0wAo/KseD3Zi7+LpG+BGiPniswNEIhI2 aBSSgpYpDF+BDGoP+6GqyEb9pGnaxEAgrqOHl/tMkCVaGdoSIiJD8KEuUi1mEPvQ kL2fgNbB73ZIqOWgfI07gAvDMKT7zBg5rj+DD8dUh00SGxhvvksbPnHD6/Pz+XNn Q2eZs0f4q2vFqNcUpYvyCyBsbwfcCr+eR3OD2CiZ2xSJ/TRHvbw= =hBAc -----END PGP SIGNATURE----- --ngqh4sdjdhb2t6jz-- From nobody Thu Dec 3 17:33:55 2020 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 B41503A11F8 for ; Thu, 3 Dec 2020 17:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikj4oubB4AQ8 for ; Thu, 3 Dec 2020 17:33:51 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0583A11F5 for ; Thu, 3 Dec 2020 17:33:50 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id u18so5510611lfd.9 for ; Thu, 03 Dec 2020 17:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=byvP8QiFDft+5Rg7Sz+TOaPfB+IdafMQqMSFr3dGTNw=; b=oybmnmGWJ+NlrhvUL+rziGNoOSqFAcNBKblCjseagJM5nJ4pLA33e+0HwVfyk1gtnb FuM5coBWGQrrLB1SlPwEwb3MO/xtc51/Jw68Q3cFL9YOG3RHR09qQYtjmhDNo3jOA1zB OQj09IAutYQR08Q3Ggr8tmOJWM80DiKPXw689RBD1sFEvKUPYl0XtFTy/+VGf2aUmMCz skWfkI9Bv7jyd3IziNDK4ZrW//BVGgmd3smdRKfyf0phr5MtPLxpnYmKini73BGyGbCv 1cGnOA1ykSxC7P4Zn5e4oyQhcyxhFdtNdZYdxb4/tq8vXrkUMF6qvBuMVTz7iI+HeWpG yqhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=byvP8QiFDft+5Rg7Sz+TOaPfB+IdafMQqMSFr3dGTNw=; b=OJ5Z1Hc5KWmaL8nT7gpppfd0/FJNIyuMGexXFwTxV+I1327Stx5voqAFbUClXxKKvT k2s6Cl7tPTo4iEri2jB2ViaUlZcF7ovAuAEvppYL35nQoCIHTEf8/5vqNF56eWDVMYaf Iwsqk8HGo/i3cPTxrYpeWTCtfbiLKNmWAkFoEJmiuU9/T9pCEae/av5mey0WkgbZ9yKe WeU+5TCLkrsWJggq0ffHalFTRkI7j4Ga5oVaBnemRpkVmHypRn4JltuAUCvRNxLHJDWs CT9K8+sNi7XJaLq5oPsfUjWARDL6xwz8lfKppz4qt48pB/hmLXruideKqCb15FN2UoJr 8zNw== X-Gm-Message-State: AOAM532LPfXzQvsNCe4OqqfdZYZv+AtsrQxpLTSNN/tFj5rdhwOuvB9a 5i3Rq6bsS9Gecid5a5V1p6hcItg1mkY9veybLM86q8XB6F4= X-Google-Smtp-Source: ABdhPJxtLAIRg0SPzg/fM6tFOkzoHVX/FzVprcVPhTbO4au4BmheiMPaFWY6I6B4BAPYh2HMzgzDp5wNLOGJPqOdHOg= X-Received: by 2002:ac2:4834:: with SMTP id 20mr2340735lft.598.1607045628046; Thu, 03 Dec 2020 17:33:48 -0800 (PST) MIME-Version: 1.0 References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> In-Reply-To: <20201203224213.gnb2nawujxm7a32q@benm-laptop> From: George Michaelson Date: Fri, 4 Dec 2020 11:33:37 +1000 Message-ID: To: Ben Maddison Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 01:33:54 -0000 I support this kind of change to the wording. I believe this language addresses my concern with rejection of a Manifest which was legal before an expiry timer, and becomes illegal purely because of the expiry of a descendent child CA. The signing chain over the Manifest itself, its EE, and the CA chain over that EE still need to be valid, unexpired, unrevoked. Validation of objects on the Manifest, validity of the manifest given other errors, are not altered in this change. cheers -G On Fri, Dec 4, 2020 at 8:42 AM Ben Maddison wrote: > > Hi all, > > As a result of the incident last night that caused the number of VRPs > output by some RPs (certainly routinator, possibly others too) to drop > dramatically, a couple of us have been going over the observed behaviour > in comparison with the current text of 6486-bis. > > It appears from Job's analysis [1] that the incident was triggered when > several resource certs that were listed on an APNIC issued manifest > became invalid due to their 'notAfter' time expiring, which in turn > caused the affected RPs to consider the manifest invalid and fail the > fetch. > > It should be perfectly legitimate for a manifest to list objects which > will become invalid during the lifetime of the manifest, or which are > not yet valid when the manifest is generated (for pre-staging). > The presence of such objects should not invalidate the manifest. > > I think there are at least two places that need an update in light of > this: > > Section 6.4 states: > """ > If there are files listed in > the manifest that cannot be retrieved from the publication point, or > if they fail the validity tests specified in [RFC6488], the fetch has > failed and the RP MUST proceed to Section 6.7 > """ > > The reference should probably be to both RFC6487 and RFC6488, as the > former provides the validation details for .cer and .crl objects, which > are presumably intended to be included in this step. > > Additionally, due to the values in the 'notBefore' and 'notAfter' in a > Resource of EE cert, an object that was legitimately included in a > manifest may become invalid when processed later in the manifests > lifetime by an RP. > > I would therefore suggest the following revision: > """ > ... if they fail the validity tests specified in [RFC6487] and [RFC6488], > with the exception of the checks against certificate Validity From > and To values described in Section 7.2 of [RFC6487], the fetch has > failed ... > """ > > Although not directly related to the current problem, the list of > objects in section 6.4 for which the ability to process is mandatory > should perhaps be reduced to those in general circulation today, and not > include BGPsec certs or ghostbuster records, since those add > approximately zero utility to an operator who wishes to run an RP today, > and are therefore unlikely to be priorities for implementation. > > Next, section 6.6 states: > """ > If a current manifest contains entries for objects that are not > within the scope of the manifest (Section 6.2), the fetch has failed > and the RP SHOULD proceed to Section 6.7 > """ > I believe that the reference to 6.2 is a typo, and should point to > section 2: > """ > A manifest associated with a CA's repository publication point > contains a list of: > o the set of (non-expired, non-revoked) certificates issued and > published by this CA, > o the most recent CRL issued by this CA, and > o all published signed objects that are verifiable using EE > certificates [RFC6487] issued by this CA. > """ > > The term "non-expired" begs the question of whether a certificate should > be non-expired at the time of manifest generation or RP processing to be > in scope. > > On the one hand, insisting that a listed certificate be valid throughout the manifest > lifetime is what gave rise to the failure described above, and is > clearly, IMO, the wrong choice. > > On the other, insisting that a certificate be valid at the time of > manifest generation precludes certificates which have not yet reached > their notBefore time. Validating as if "at manifest generation" also > appears to contravene the guidance in section 4.6.1 of RFC6487: > """ > Relying Parties SHOULD NOT attempt to infer from this > time information that a certificate was valid at a time in the past, > or that it will be valid at a time in the future, as the scope of an > RP's test of validity of a certificate refers specifically to > validity at the current time. > """ > > As above, therefore, I would suggest that rather than choosing either > of the above options, the question of temporal expiry should be left > out of manifest validation altogether. > Thus point one of section 2 becomes: > """ > A manifest associated with a CA's repository publication point > contains a list of: > o the set of non-revoked certificates issued and published by > this CA, > o the most recent CRL issued by this CA, and > o all published signed objects that are verifiable using EE > certificates [RFC6487] issued by this CA. > > The list MUST include any objects that have a validity period that > overlaps the period between the thisUpdate and nextUpdate times of > the manifest. > > ... > """ > > There may be other parts of the text that are similarly in need of > update or clarification on this point: I'll update if I find any. > > Hopefully the above makes sense. Please let me know if anything is > unclear. > > Cheers, > > Ben > > [1]: https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 4 02:17:03 2020 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 4F1EA3A03F2 for ; Fri, 4 Dec 2020 02:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PliJAgZFIvxh for ; Fri, 4 Dec 2020 02:16:58 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 107513A03EF for ; Fri, 4 Dec 2020 02:16:57 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DB2F860577; Fri, 4 Dec 2020 10:16:54 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net Date: Fri, 4 Dec 2020 11:16:51 +0100 From: Martin Hoffmann To: Ben Maddison Cc: sidrops@ietf.org Message-ID: <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> In-Reply-To: <20201203224213.gnb2nawujxm7a32q@benm-laptop> References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> Organization: NLnet Labs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 10:17:01 -0000 Ben Maddison wrote: >=20 > As a result of the incident last night that caused the number of VRPs > output by some RPs (certainly routinator, possibly others too) to drop > dramatically, a couple of us have been going over the observed > behaviour in comparison with the current text of 6486-bis. >=20 > It appears from Job's analysis [1] that the incident was triggered > when several resource certs that were listed on an APNIC issued > manifest became invalid due to their 'notAfter' time expiring, which > in turn caused the affected RPs to consider the manifest invalid and > fail the fetch. >=20 > It should be perfectly legitimate for a manifest to list objects which > will become invalid during the lifetime of the manifest, or which are > not yet valid when the manifest is generated (for pre-staging). > The presence of such objects should not invalidate the manifest. I think the incident shows a general flaw in the approach that anything being wrong with any of the objects published by the CA should lead to all the CA=E2=80=99s objects being invalidated: It prohibits= a CA from publishing invalid objects on purpose. The validity time is only one such case. Another one that we already know about is changing resource entitlements in the CA certificate. This case is actually worse since the CA itself has no influence on this happening and, as the protocols are now, there is no automated way of agreeing on a timeline for the process. It is not entirely unlikely that we will encounter more such issues in the future. So perhaps instead of trying to work around each of these issues as they arise, we should go back and look at what started this revision in the first place. That was an observation that by manipulating a publication point=E2=80=99s objects, an attacker can force a route announce= ment to become RPKI invalid. The current approach does solve this problem but it also attempts to solve a different problem: to protect a CA from accidentally publishing invalid data. But as we found out, that requires anticipating the intentions of a CA. Perhaps it is better to trust a CA and accept that if it fails there will be problems for its resources. Under this approach, the manifest expresses which objects the CA intended to publish. If all the objects listed on the manifest are present with a matching hash, the publication point reflects the intent of the CA and can be processed. If it contains invalid objects, these can be discarded individually. This approach will be simpler and easier to implement. It will avoid the invalidation of the entire CA because of expired or not yet valid CA certificates or changing resource entitlements. It may, however, lead to a partial set of objects applying to a particular resource. That may be intentional or by accident. Whether it is better to reject the partial set accepting that an intentionally partial set is rejected or to accept an accidental partial set to be included depends on the particular application of RPKI. For ROV, rejecting the set may be better (although there are consequences of that, too) whereas for router keys or Ghostbuster records including it would seem to be fine. In other words, the proposal is to simplify the text for section 6.4 to say: The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point the fetch has failed and the RP MUST proceed to Section 6.7; otherwise, proceed to Section 6.5. In addition, section 6.6 can be repurposed to specify the behaviour in case of invalid objects. As a proposal: 6.6. Invalid Files If files listed in on the manifest fail the validity tests specified in [RFC6487] and [RFC6488], the fetch has not necessarily failed. However, applications of the RPKI may define specific consequences if one or more files are invalid. Alternatively, this section can provide the rules for existing applications of the RPKI, i.e., ROV, BGPsec, and GBR as well as delegation to child CAs. I understand that this proposal is a departure from our current approach, but I would like to ask the working group to consider it nonetheless as it keeps validation relatively simple and, by separating out the individual steps of the overall process, should limit the number of unforeseen consequences. Kind regards, Martin From nobody Fri Dec 4 02:40:14 2020 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 15CF93A08C5 for ; Fri, 4 Dec 2020 02:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 82YxUBKTXW2N for ; Fri, 4 Dec 2020 02:40:11 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005A53A08BB for ; Fri, 4 Dec 2020 02:40:10 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 24A57220133; Fri, 4 Dec 2020 10:40:07 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id d46fdc76; Fri, 4 Dec 2020 10:40:06 +0000 (UTC) Date: Fri, 4 Dec 2020 10:40:06 +0000 From: Job Snijders To: Martin Hoffmann Cc: Ben Maddison , sidrops@ietf.org Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 10:40:13 -0000 On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: > Under this approach, the manifest expresses which objects the CA > intended to publish. If all the objects listed on the manifest are > present with a matching hash, the publication point reflects the > intent of the CA and can be processed. If it contains invalid objects, > these can be discarded individually. Indeed, I believe you've now captured the essence of why manifests exists at all. This is what rpki-client & FORT seem to have implemented. Other than the hashes matching & files being present, additional conditions apply: the manifest & EE certificate need to be valid, current, latest, correctly encoded, part of the cert chain, CRL present, etc. Kind regards, Job From nobody Fri Dec 4 02:44:27 2020 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 BDADA3A08E5 for ; Fri, 4 Dec 2020 02:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Y3lIFFiwlp for ; Fri, 4 Dec 2020 02:44:23 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 90A913A08DA for ; Fri, 4 Dec 2020 02:44:23 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 14216600F1; Fri, 4 Dec 2020 10:44: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=1607078661; bh=OQDEgNGeQkbS9gccBsGBrfSMTJXHVrfLmtLfnp4W7tE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=xgH2rESL8BfAHAtnV4XP1srs4+MnBnuSbEeWIT5ZebAohsmrPwBiqS5zA6TDAdyzw eZftmGTrjJQ78VJk7bRvXt5HvX6Gn5NqCnJZs+RyaZ70mScvGZYibKQj3zfmP1FVOA NFWoAtmCgnz+BblqZa2sb2c6OgpO0a4fxHXs60xUcV90tCw9FynAVLpESTLZQP9bAL TvKYlOz/8mbs1rj2SlvswX6EYm78oBUnrrR8Rujf7GW6q3sgscDqvm9E53AkJKdChD FuLnMeSHAuBmeUOnzd8dl+tM2QymbZVtylYKr/LT9sTv8OyPZEQQj+K4nQyTjbopLc f27DWjopmUQ7w== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 4 Dec 2020 11:44:17 +0100 Cc: Martin Hoffmann , SIDR Operations WG , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 10:44:26 -0000 Hi Job, > On 4 Dec 2020, at 11:40, Job Snijders wrote: >=20 > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: >> Under this approach, the manifest expresses which objects the CA >> intended to publish. If all the objects listed on the manifest are >> present with a matching hash, the publication point reflects the >> intent of the CA and can be processed. If it contains invalid = objects, >> these can be discarded individually. >=20 > Indeed, I believe you've now captured the essence of why manifests > exists at all. This is what rpki-client & FORT seem to have = implemented. I suggested this in August: = https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk/= I think a lot of this could have been avoided if we had this discussion = then, but I welcome this now.. > Other than the hashes matching & files being present, additional > conditions apply: the manifest & EE certificate need to be valid, > current, latest, correctly encoded, part of the cert chain, CRL = present, > etc. Indeed >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 4 02:47:22 2020 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 438753A0911; Fri, 4 Dec 2020 02:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UvVY1q2etF1; Fri, 4 Dec 2020 02:47:19 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079383A08FA; Fri, 4 Dec 2020 02:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=wtRSbpxaebblc5CwFzscFa7RL7FO2wGeCQJB+FRCyD8=; b=U58Pwu/ywzHJ w/NxUK/5/CnPKJeqQwDL7dXVn8a73M7nkgrXeME2GCFboJ+ZCjeUWimXj9CM5jJgRG5Tn3rq4Lzxg Qe8UAwnQjN1WXkZq/M0rgsAIvnEiQm7/3gG+p4oq8Xji7fWARGCw1ywcjXpmUy2xvNFDxFwabUXek NExnkNwx7HqyTuf0Iqd1dJkZNXRk84HZKIhg0mvfg6QYC5cdCLSNifikDH7au4zW9/F/1Ix3vXOzc hxseuRm8+X51XKMCP4l5Mv2alrUANQYh+8Zh9nXUj2e+sbQ/1vgOk+Fb05bwItYK4OIfKXHo0nOvT r+K9y5+6yEeZ4bN3fW9cEg==; Received: from allealle.ripe.net ([193.0.23.12]:58218) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kl8cP-0009FY-Go; Fri, 04 Dec 2020 11:47:17 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::91f]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kl8cP-0000MS-E3; Fri, 04 Dec 2020 11:47:17 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Ties de Kock In-Reply-To: Date: Fri, 4 Dec 2020 11:47:17 +0100 Cc: Martin Hoffmann , sidrops@ietf.org, Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1d842a1bb5c12b25172660e6b3d16d876 Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 10:47:20 -0000 > On 4 Dec 2020, at 11:40, Job Snijders wrote: >=20 > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: >> Under this approach, the manifest expresses which objects the CA >> intended to publish. If all the objects listed on the manifest are >> present with a matching hash, the publication point reflects the >> intent of the CA and can be processed. If it contains invalid = objects, >> these can be discarded individually. >=20 > Indeed, I believe you've now captured the essence of why manifests > exists at all. This is what rpki-client & FORT seem to have = implemented. >=20 > Other than the hashes matching & files being present, additional > conditions apply: the manifest & EE certificate need to be valid, > current, latest, correctly encoded, part of the cert chain, CRL = present, > etc. However, validating these requirements for just CMS objects (as per -03, = instead of for CAs as well as per -00) leaves open the situation where only part = of the objects for a CA apply. When the ROAs are correct, but the sub-CA is = not, this can cause outages. I don't have a preference on which way to go, but I would propose that = we treat invalidation (time, c.f. because of semantic errors) for both CA = certificates and other objects similarly. Ties= From nobody Fri Dec 4 02:51:32 2020 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 BC9BA3A0936 for ; Fri, 4 Dec 2020 02:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RSr9ujJGMr-E for ; Fri, 4 Dec 2020 02:51:30 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A283A091C for ; Fri, 4 Dec 2020 02:51:30 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 16545EE007C; Fri, 4 Dec 2020 10:51:28 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 7edfc160; Fri, 4 Dec 2020 10:51:27 +0000 (UTC) Date: Fri, 4 Dec 2020 10:51:27 +0000 From: Job Snijders To: Ties de Kock Cc: sidrops@ietf.org, Martin Hoffmann , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.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] 6486bis: referenced object validation 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, 04 Dec 2020 10:51:32 -0000 On Fri, Dec 04, 2020 at 11:47:17AM +0100, Ties de Kock wrote: > > On 4 Dec 2020, at 11:40, Job Snijders wrote: > > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: > >> Under this approach, the manifest expresses which objects the CA > >> intended to publish. If all the objects listed on the manifest are > >> present with a matching hash, the publication point reflects the > >> intent of the CA and can be processed. If it contains invalid objects, > >> these can be discarded individually. > > > > Indeed, I believe you've now captured the essence of why manifests > > exists at all. This is what rpki-client & FORT seem to have implemented. > > > > Other than the hashes matching & files being present, additional > > conditions apply: the manifest & EE certificate need to be valid, > > current, latest, correctly encoded, part of the cert chain, CRL present, > > etc. > > However, validating these requirements for just CMS objects (as per > -03, instead of for CAs as well as per -00) leaves open the situation > where only part of the objects for a CA apply. When the ROAs are > correct, but the sub-CA is not, this can cause outages. > > I don't have a preference on which way to go, but I would propose that > we treat invalidation (time, c.f. because of semantic errors) for both > CA certificates and other objects similarly. I am not sure I follow, can you construct an example data set where the 'situation left open' you describe appears? Kind regards, Job From nobody Fri Dec 4 02:57:39 2020 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 8419F3A0949; Fri, 4 Dec 2020 02:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgNSXS7Ty_zw; Fri, 4 Dec 2020 02:57:35 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631273A0940; Fri, 4 Dec 2020 02:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id: From; bh=QHDSHNk3RxnKtg4weDNLPUGJtEJoC7ZkfGeOcy0pExc=; b=fGcuhA3UDNHZKVbmXrax A/eTl/nvt7W7PUr/4or8sa2lwmLHvhicPbkZ2MY/LcYZUgBp8eRFKwcfiGrje0MjnHoJNmHLVdn0I los3Cnkoep13uy14+eRbcx2vX0TccJM5/dxMlDLMfzlGRkFYg0p6JVrvCiLyapH9CyZRNWap3b+bJ Yey2cN/hawo2cthnQ0MAaaXguwrhupo6B7Ng/kMfs7BFRBMhe5bhwkQ/SalLsdHwdDSuzZ7+umD8i vdo8UTAN8hBDHcaauDny3FoTNri66HG6pdsvM06n+3K39LIczMKHPFt0iWb4mVF83oeuk/iUksY7J Sq9fostd5Mcc0Q==; Received: from allealle.ripe.net ([193.0.23.12]:36434) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kl8mL-000CIs-Rh; Fri, 04 Dec 2020 11:57:33 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::91f]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kl8mL-0000zE-Ok; Fri, 04 Dec 2020 11:57:33 +0100 From: Ties de Kock Message-Id: <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_DEBF7422-0E3D-4D82-8B3F-FC886F95BB8C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 4 Dec 2020 11:57:33 +0100 In-Reply-To: Cc: sidrops@ietf.org, Martin Hoffmann , Ben Maddison To: Job Snijders References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e19f65609ae4fd83633b92f7f7626a4298 Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 10:57:38 -0000 --Apple-Mail=_DEBF7422-0E3D-4D82-8B3F-FC886F95BB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Dec 2020, at 11:51, Job Snijders wrote: >=20 > On Fri, Dec 04, 2020 at 11:47:17AM +0100, Ties de Kock wrote: >>> On 4 Dec 2020, at 11:40, Job Snijders wrote: >>> On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: >>>> Under this approach, the manifest expresses which objects the CA >>>> intended to publish. If all the objects listed on the manifest are >>>> present with a matching hash, the publication point reflects the >>>> intent of the CA and can be processed. If it contains invalid = objects, >>>> these can be discarded individually. >>>=20 >>> Indeed, I believe you've now captured the essence of why manifests >>> exists at all. This is what rpki-client & FORT seem to have = implemented. >>>=20 >>> Other than the hashes matching & files being present, additional >>> conditions apply: the manifest & EE certificate need to be valid, >>> current, latest, correctly encoded, part of the cert chain, CRL = present, >>> etc. >>=20 >> However, validating these requirements for just CMS objects (as per >> -03, instead of for CAs as well as per -00) leaves open the situation >> where only part of the objects for a CA apply. When the ROAs are >> correct, but the sub-CA is not, this can cause outages. >>=20 >> I don't have a preference on which way to go, but I would propose = that >> we treat invalidation (time, c.f. because of semantic errors) for = both >> CA certificates and other objects similarly. >=20 > I am not sure I follow, can you construct an example data set where = the > 'situation left open' you describe appears? >=20 Thanks for asking for clarification. I'll try to explain the scenario: CA certificate with * Manifest, containing * ROA: AS0, 192.0.2.0/24 * sub-CA, resources: * Manifest, containing: * ROA: We have "all or nothing" for ROAs. I argue that a similar situation is = present for sub-CAs if the sub-CA expires. Kind regards, Ties= --Apple-Mail=_DEBF7422-0E3D-4D82-8B3F-FC886F95BB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 4 Dec 2020, at 11:51, Job Snijders <job@ntt.net> wrote:

On Fri, Dec 04, 2020 at = 11:47:17AM +0100, Ties de Kock wrote:
On= 4 Dec 2020, at 11:40, Job Snijders <job@ntt.net> wrote:
On Fri, Dec 04, 2020 = at 11:16:51AM +0100, Martin Hoffmann wrote:
Under this approach, the manifest expresses = which objects the CA
intended to publish. If all the = objects listed on the manifest are
present with a matching = hash, the publication point reflects the
intent of the CA = and can be processed. If it contains invalid objects,
these = can be discarded individually.

Indeed, I believe you've now captured the essence of why = manifests
exists at all. This is what rpki-client & = FORT seem to have implemented.

Other than = the hashes matching & files being present, additional
conditions apply: the manifest & EE certificate need to = be valid,
current, latest, correctly encoded, part of the = cert chain, CRL present,
etc.
However, validating these requirements for just CMS objects = (as per
-03, instead of for CAs as well as per -00) leaves = open the situation
where only part of the objects for a CA = apply. When the ROAs are
correct, but the sub-CA is not, = this can cause outages.

I don't have a = preference on which way to go, but I would propose that
we = treat invalidation (time, c.f. because of semantic errors) for both
CA certificates and other objects similarly.

I am not sure I follow, can you construct an example data set = where the
'situation = left open' you describe appears?


Thanks for asking for clarification. I'll try to = explain the scenario:

CA certificate = with <AS64496, 192.0.2.0/24>
  * Manifest, = containing
 * ROA: AS0, = 192.0.2.0/24
 * sub-CA, resources: = <AS64496, 192.0.2.0/24>
  * = Manifest, containing:
 * ROA: = <AS64496, 192.0.2.0/24>

We = have "all or nothing" for ROAs. I argue that a similar situation is = present
for sub-CAs if the sub-CA expires.

Kind regards,
Ties
= --Apple-Mail=_DEBF7422-0E3D-4D82-8B3F-FC886F95BB8C-- From nobody Fri Dec 4 03:06:50 2020 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 CE5E53A09C3 for ; Fri, 4 Dec 2020 03:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc_oG24Jyqnk for ; Fri, 4 Dec 2020 03:06:48 -0800 (PST) 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 D18E03A09C4 for ; Fri, 4 Dec 2020 03:06:47 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 86FDE60294; Fri, 4 Dec 2020 11:06:45 +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=1607080004; bh=paHluVr/ZYRbKLVJcUCUB7xmBluKMGrzC+oihk3Vd2E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=WxV7uoG7fFIyc9WLZ5STyWD9MWIqbcUyEqaiBC0YMJjPzXT82qFzF2aDMaIWD+6Pi X2MP57IMD7vMDQjlSnJGYt9DPZk8ZV+lLqFMDrp78fpOg6Q540zIox4wHxF6u1AU6/ jm28zLYrgP6zci5xwjA3TrPQex0OLEE+8VWtHfs7aPkoShydsikQEdUTrp6NoAcdWP zKACpoitSdna1/yqW3PLos3ThEP52OxcJDdwHqwYcv2CPltxgur3vIz5pk7NDyI1Xi /T6xhRZrbLFBamM1TNyoUvDbsVFefLI0tao3ugYJIWa/+1N7FTNc5F0ZFPuSlOMWti 4mduQk0E2v75Q== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> Date: Fri, 4 Dec 2020 12:06:40 +0100 Cc: Job Snijders , SIDR Operations WG , Martin Hoffmann , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: <35CF44B7-5C04-460F-9E67-03F6E659A093@nlnetlabs.nl> References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> To: Ties de Kock Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 11:06:50 -0000 Hi, > On 4 Dec 2020, at 11:57, Ties de Kock wrote: >=20 >=20 >> On 4 Dec 2020, at 11:51, Job Snijders wrote: >>=20 >> On Fri, Dec 04, 2020 at 11:47:17AM +0100, Ties de Kock wrote: >>>> On 4 Dec 2020, at 11:40, Job Snijders wrote: >>>> On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: >>>>> Under this approach, the manifest expresses which objects the CA >>>>> intended to publish. If all the objects listed on the manifest are >>>>> present with a matching hash, the publication point reflects the >>>>> intent of the CA and can be processed. If it contains invalid = objects, >>>>> these can be discarded individually. >>>>=20 >>>> Indeed, I believe you've now captured the essence of why manifests >>>> exists at all. This is what rpki-client & FORT seem to have = implemented. >>>>=20 >>>> Other than the hashes matching & files being present, additional >>>> conditions apply: the manifest & EE certificate need to be valid, >>>> current, latest, correctly encoded, part of the cert chain, CRL = present, >>>> etc. >>>=20 >>> However, validating these requirements for just CMS objects (as per >>> -03, instead of for CAs as well as per -00) leaves open the = situation >>> where only part of the objects for a CA apply. When the ROAs are >>> correct, but the sub-CA is not, this can cause outages. >>>=20 >>> I don't have a preference on which way to go, but I would propose = that >>> we treat invalidation (time, c.f. because of semantic errors) for = both >>> CA certificates and other objects similarly. >>=20 >> I am not sure I follow, can you construct an example data set where = the >> 'situation left open' you describe appears? >>=20 >=20 > Thanks for asking for clarification. I'll try to explain the scenario: >=20 > CA certificate with > * Manifest, containing > * ROA: AS0, 192.0.2.0/24 > * sub-CA, resources: > * Manifest, containing: > * ROA: >=20 > We have "all or nothing" for ROAs. I argue that a similar situation is = present > for sub-CAs if the sub-CA expires. Indeed there are many such corner cases. Imho this discussion is complicated because we are conflating object = validation and the impact of encountering invalid objects on the = resulting VRP set and ultimately routing decisions. I think it could help to separate these issues. Keep RPKI object tree = validation itself simple, but track invalid / rejected objects and = discuss how to deal with the VRP set as a separate issue. E.g. we could = track all resources that are under some dispute (intersection of what is = issued to a CA and issues with objects by the CA) and filter VRPs based = on that. Tim >=20 > Kind regards, > Ties > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 4 03:17:08 2020 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 39E643A00D3 for ; Fri, 4 Dec 2020 03:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jtrOuA4Ks3Ct for ; Fri, 4 Dec 2020 03:17:04 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [128.241.192.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC393A09C5 for ; Fri, 4 Dec 2020 03:17:04 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 42617EE007B; Fri, 4 Dec 2020 11:17:03 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id cf4860e9; Fri, 4 Dec 2020 11:17:01 +0000 (UTC) Date: Fri, 4 Dec 2020 11:17:01 +0000 From: Job Snijders To: Ties de Kock Cc: sidrops@ietf.org, Martin Hoffmann , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 11:17:07 -0000 On Fri, Dec 04, 2020 at 11:57:33AM +0100, Ties de Kock wrote: > >> However, validating these requirements for just CMS objects (as per > >> -03, instead of for CAs as well as per -00) leaves open the situation > >> where only part of the objects for a CA apply. When the ROAs are > >> correct, but the sub-CA is not, this can cause outages. > >> > >> I don't have a preference on which way to go, but I would propose that > >> we treat invalidation (time, c.f. because of semantic errors) for both > >> CA certificates and other objects similarly. > > > > I am not sure I follow, can you construct an example data set where the > > 'situation left open' you describe appears? > > > > Thanks for asking for clarification. I'll try to explain the scenario: > > CA certificate with > * Manifest, containing > * ROA: AS0, 192.0.2.0/24 > * sub-CA, resources: > * Manifest, containing: > * ROA: > > We have "all or nothing" for ROAs. I argue that a similar situation is present > for sub-CAs if the sub-CA expires. You list two manifests, which means that software should: round 1: process Manifest 1 containing AS0.roa + sub-CA.cer + crl check if as0.roa and sub-CA.cer + crl are present and if the hashes match round 2: process Manifest 2 containing AS64496.roa + crl check if AS64496.roa + crl are present and if the hashes match Now let's image sub-CA.cer is present and the hash match, but turns out to be expired, it just invalidates sub-CA.cer and thus the software would never even open manifest 2, because sub-CA.cer is expired. If sub-CA.cer is expired the ROA for AS64496 indeed will 'disappear' (as if never existed), leaving just the AS0 ROA. This is as the CA intended. Kind regards, Job From nobody Fri Dec 4 04:13:42 2020 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 B96593A0C01 for ; Fri, 4 Dec 2020 04:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Vv5B-5y8lTKB for ; Fri, 4 Dec 2020 04:13:36 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7C63A0BF8 for ; Fri, 4 Dec 2020 04:13:36 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 6AA9722014A; Fri, 4 Dec 2020 12:13:34 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id a9c4da58; Fri, 4 Dec 2020 12:13:32 +0000 (UTC) Date: Fri, 4 Dec 2020 12:13:32 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: Martin Hoffmann , SIDR Operations WG , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 12:13:41 -0000 On Fri, Dec 04, 2020 at 11:44:17AM +0100, Tim Bruijnzeels wrote: > > On 4 Dec 2020, at 11:40, Job Snijders wrote: > > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote: > >> Under this approach, the manifest expresses which objects the CA > >> intended to publish. If all the objects listed on the manifest are > >> present with a matching hash, the publication point reflects the > >> intent of the CA and can be processed. If it contains invalid objects, > >> these can be discarded individually. > > > > Indeed, I believe you've now captured the essence of why manifests > > exists at all. This is what rpki-client & FORT seem to have implemented. > > I suggested this in August: > https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk/ > > I think a lot of this could have been avoided if we had this > discussion then, but I welcome this now.. Looking back I'm at a loss how "a lot of this" really could've been avoided. What additional steps or process should I have followed for NLNetLabs/RIPE/Cloudflare to sooner understand the problem with their implementation choices and encourage those organisations to provide a solution to their users? As you know, I reported 'this' as a problem in February 2020 to sidrops@ OpenBSD rpki-client implemented the 'this' solution already in March 2020 https://github.com/openbsd/src/commit/8e07ef58f8a3812e87e1b5cf4d956ba264438cd5 FORT implemented also implemented the 'this' solution already back in March 2020 https://github.com/NICMx/FORT-validator/commit/0ad2c3da34827b68c4f524c0c50f223746af91a5 To protect its business, NTT deployed 'this' in their transit-free network in April 2020, further proving the viability of the approach on global scale. I reported 'this' again as a problem & mentioned the solution in April 2020: https://github.com/NLnetLabs/routinator/issues/319 We had *multiple* virtual SIDROPS meetings where I and others kept repeating the issue and the solution, in simple english: ignore the manifest when files are missing or corrupted. Additionally, ignore objects that are expired or otherwise invalid. Two RP implementers told me they *first* wanted to see a nearly finished or even published RFC, before making any changes to their code. I think RFC-first-code-later is an entirely unworkable model for cryptographic software actively used in the field. It seems weird to me to set the bar so high before addressing simple software defects. Conversely, IDR requires 2 implementations *before* RFC publication (which helps avoid lots of problems in RFC texts^W^W^W^W^W^W^Wimprove quality of RFCs), a ritual which I think should be followed by SIDROPS as well. RFC compliance (or a perception thereof) is very important for system interopability, but not the end goal in and of itself. The real goal is to keep the network running, where in this context our role is to create software for network operators for them to securely validate the wishes of the Internet number resource holders. We have to keep the Internet running *while* we discuss things in IETF. Drafts/RFCs are the byproduct, they come after the coding effort and deploying the code. Kind regards, Job From nobody Fri Dec 4 05:13:46 2020 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 0C1CA3A07F0; Fri, 4 Dec 2020 05:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R4kZaEBSmvM; Fri, 4 Dec 2020 05:13:43 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE633A07DB; Fri, 4 Dec 2020 05:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=4rcmWWdDJLzLdOuJ8w9tu2GLXirPGxZEBGaxOTiiPWo=; b=UqEaxiECl1/z 4Yn/D6lIeNHvVe4xX+qJWNq0i/tLMvdUkhTbtsvP2P9p6OHBb8zqqh+8mbYNHKZyjFQcNaiy0T0Z/ BTQNMLpY9klApUNroI6BkUoPjOVyWN88ORhBD9ST3OL/Vj+EpywnMTZlzRzczkpRWnANGnIniF0CC 51+KbAU370bgw9oj0+PmdOcLCJrgHrlkAohwZfmyJ4idpt2j5cRRl1bNhUGDFS3L4c6iO/58y3qNE fXA702DZmivnokSJCYukSpX6XEQdlhyaw3VR+EzWW92s3E+chy4Lv7oeeUEq+mlJpsLrofbs1ihgF c2jl9YdoF1DGhQg/uG7V3Q==; Received: from bufobufo.ripe.net ([193.0.23.13]:54084) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1klAu6-0009tP-8t; Fri, 04 Dec 2020 14:13:42 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::99d]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1klAu6-0003eb-5y; Fri, 04 Dec 2020 14:13:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Ties de Kock In-Reply-To: Date: Fri, 4 Dec 2020 14:13:41 +0100 Cc: sidrops@ietf.org, Martin Hoffmann , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1a48c643071497d76528df08a5a10a45c Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 13:13:45 -0000 On 4 Dec 2020, at 12:17, Job Snijders wrote: >=20 > On Fri, Dec 04, 2020 at 11:57:33AM +0100, Ties de Kock wrote: >>>> However, validating these requirements for just CMS objects (as per >>>> -03, instead of for CAs as well as per -00) leaves open the = situation >>>> where only part of the objects for a CA apply. When the ROAs are >>>> correct, but the sub-CA is not, this can cause outages. >>>>=20 >>>> I don't have a preference on which way to go, but I would propose = that >>>> we treat invalidation (time, c.f. because of semantic errors) for = both >>>> CA certificates and other objects similarly. >>>=20 >>> I am not sure I follow, can you construct an example data set where = the >>> 'situation left open' you describe appears? >>>=20 >>=20 >> Thanks for asking for clarification. I'll try to explain the = scenario: >>=20 >> CA certificate with >> * Manifest, containing >> * ROA: AS0, 192.0.2.0/24 >> * sub-CA, resources: >> * Manifest, containing: >> * ROA: >>=20 >> We have "all or nothing" for ROAs. I argue that a similar situation = is present >> for sub-CAs if the sub-CA expires. >=20 > You list two manifests, which means that software should: >=20 > round 1: process Manifest 1 containing AS0.roa + sub-CA.cer + crl > check if as0.roa and sub-CA.cer + crl are present and if the hashes > match >=20 > round 2: process Manifest 2 containing AS64496.roa + crl > check if AS64496.roa + crl are present and if the hashes match >=20 > Now let's image sub-CA.cer is present and the hash match, but turns = out > to be expired, it just invalidates sub-CA.cer and thus the software > would never even open manifest 2, because sub-CA.cer is expired. >=20 > If sub-CA.cer is expired the ROA for AS64496 indeed will 'disappear' = (as > if never existed), leaving just the AS0 ROA. This is as the CA = intended. Compare that to: Valid CA certificate with * Manifest, with valid EE certificate, containing * valid CRL * ROA: AS0, 192.0.2.0/24, EE cert with 2020-12-01 expiration * ROA: AS64496, 192.0.2.0/25, EE cert with 2021-01-01 expiration This results in a failed fetch when validated today. Under our interpretation of -00, this manifest would be rejected, since = all objects on a manifest need to be valid (present, hash match, correct, = non-expired) for a fetch to succeed. I would argue that to be consistent, this should not result in failed = fetch, the expired ROA should not apply, because this is what the CA intended. What do you think the outcome should be? Kind regards, Ties= From nobody Fri Dec 4 05:13:56 2020 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 C34BC3A0CDB for ; Fri, 4 Dec 2020 05:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9RHZ6pLpb0Q for ; Fri, 4 Dec 2020 05:13:46 -0800 (PST) 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 83BF23A07DB for ; Fri, 4 Dec 2020 05:13:46 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 49CD2602D8; Fri, 4 Dec 2020 13:13: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=1607087623; bh=Ho91Wx4jst+MDdq+O2o3k/jadwFI9iUN7MZDOiHjeP8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=C7Tex+HKf+KvdbrlTVPhGN2orrk863oBKpGIPbDDgsQNCzvQaE3431I7riJg1XeOa WHzSdu5h8XLA/ezL5kW89w9/sxVxD1mU9IUkpuJ6LRI33FrZMDBB953AtquoT9RTAu WnjtTDLUMgE0fSg3tv8zZPHc5HRmJpnFgdPwKPBbzeebsxUGHWjYx65s11SSMTWxgz WlqnrX0zid3LoCacuk9umx+i187dJeRpzl/Rfby50TKcZIceEv3fb3lN9c5TCWEeAp ntsZDJhmV2DSm/i5+6U+JjEf1COh3TQplOdzdZcGbY8i/C0c8JVxYSPOVqwOhMvAdG AbpdGgO+/A81w== To: Job Snijders , Tim Bruijnzeels Cc: SIDR Operations WG , Martin Hoffmann , Ben Maddison References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> From: Benno Overeinder Message-ID: Date: Fri, 4 Dec 2020 14:13:40 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 13:13:54 -0000 Hi Job, WG, On 04/12/2020 13:13, Job Snijders wrote: > On Fri, Dec 04, 2020 at 11:44:17AM +0100, Tim Bruijnzeels wrote: >>> Indeed, I believe you've now captured the essence of why manifests >>> exists at all. This is what rpki-client & FORT seem to have implemented. >> >> I suggested this in August: >> https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk/ >> >> I think a lot of this could have been avoided if we had this >> discussion then, but I welcome this now.. > > Looking back I'm at a loss how "a lot of this" really could've been > avoided. What additional steps or process should I have followed for > NLNetLabs/RIPE/Cloudflare to sooner understand the problem with their > implementation choices and encourage those organisations to provide a > solution to their users? > > As you know, I reported 'this' as a problem in February 2020 to sidrops@ timeline for brevity. Your timeline is correct, as far as I have followed the discussions. The remark from Tim is meant to be constructive, not defensive. Not looking back, but looking ahead, I want to focus on how we solve issues and discuss them in sidrops. And indeed, if there is an impasse, organise a virtual meeting and discuss the matter to make progress. > The real goal is to keep the network running, where in this context our > role is to create software for network operators for them to securely > validate the wishes of the Internet number resource holders. Agree to that! Let's keep the good spirit of collaboration and learning together. Best regards, -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From nobody Fri Dec 4 06:37:29 2020 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 6B6C53A0BE7 for ; Fri, 4 Dec 2020 06:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h48JNLRGGNEq for ; Fri, 4 Dec 2020 06:37:27 -0800 (PST) Received: from mail4.dllstx09.us.to.gin.ntt.net (mail4.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB533A0BD4 for ; Fri, 4 Dec 2020 06:37:26 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 9EF91EE007D; Fri, 4 Dec 2020 14:37:24 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 455543c1; Fri, 4 Dec 2020 14:37:21 +0000 (UTC) Date: Fri, 4 Dec 2020 14:37:21 +0000 From: Job Snijders To: Benno Overeinder Cc: Tim Bruijnzeels , SIDR Operations WG , Martin Hoffmann , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@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] 6486bis: referenced object validation 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, 04 Dec 2020 14:37:28 -0000 On Fri, Dec 04, 2020 at 02:13:40PM +0100, Benno Overeinder wrote: > Not looking back, but looking ahead, I want to focus on how we solve > issues and discuss them in sidrops. And indeed, if there is an > impasse, organise a virtual meeting and discuss the matter to make > progress. Yes, I took it as a sign of convergent thinking. Progress indeed. However, my question remains, looking forward, what can be done differently in the future? Some suggestions from my side: - SIDROPS must require multiple implementations before sending an Internet-Draft towards the IESG. To meet this requirement, Implementers should write an implementation report and share it with the group, at least detailing the behavior for each normative term. - Please listen to operators who report (hard to troubleshoot, hard to explain) network outages which resulted from RPKI processing. RPKI ROV is supposed to be an incrementally deployable 'fail open' mechanism. - Implementers should more often share/construct the actual X.509 files rather than attempting to document the hypothetical states of the RPKI in natural language (avoid English or Dutch). We can all load X.509 files into our implementations, set currenttime to the test case at hand, and discuss results. - Implementers should feel empowered to make improvements to their software (for the benefit of their users), especially if there is perceived ambiguity in RFC texts. An implementer doesn't need the blessing of the whole IETF before making a change. - Sometimes RFCs are wrong, or worse: the then-WG kicked the ball down the road and state 'up to the implementer' (aka 'local policy'); in which case the implementer will have to weigh the advantages of perceived 'RFC compliance' vs the effects of the behavior in the BGP Default-Free Zone. See the previous point. - The RPKI is a system that has been deployed on the Internet, this sometimes means operators need to quickly deploy fixes to address ongoing issues. Time is of the essence when it comes to security or reliability issues. So 'code first, RFC later', which goes well with point 1: 'implementations first, then publish RFC'. You mentioned some kind of testbed, indeed it would be wonderful if we can easily reproduce states of the RPKI and allow implementers to provide annotations on why software (versions) behaves in a certain way. The December 1st, 2020 case is definitely one I'd add to the testbed archive. > > The real goal is to keep the network running, where in this context > > our role is to create software for network operators for them to > > securely validate the wishes of the Internet number resource > > holders. > > Agree to that! > > Let's keep the good spirit of collaboration and learning together. For sure! Kind regards, Job From nobody Fri Dec 4 07:07:19 2020 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 82E293A0D86 for ; Fri, 4 Dec 2020 07:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YhMhvoSglQBc for ; Fri, 4 Dec 2020 07:07:16 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109BF3A0D7D for ; Fri, 4 Dec 2020 07:07:15 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 7EA0222014A; Fri, 4 Dec 2020 15:07:14 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id cdec34c8; Fri, 4 Dec 2020 15:07:12 +0000 (UTC) Date: Fri, 4 Dec 2020 15:07:12 +0000 From: Job Snijders To: Ties de Kock Cc: sidrops@ietf.org, Martin Hoffmann , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> 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] 6486bis: referenced object validation 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, 04 Dec 2020 15:07:18 -0000 On Fri, Dec 04, 2020 at 02:13:41PM +0100, Ties de Kock wrote: > > You list two manifests, which means that software should: > > > > round 1: process Manifest 1 containing AS0.roa + sub-CA.cer + crl > > check if as0.roa and sub-CA.cer + crl are present and if the hashes > > match > > > > round 2: process Manifest 2 containing AS64496.roa + crl > > check if AS64496.roa + crl are present and if the hashes match > > > > Now let's image sub-CA.cer is present and the hash match, but turns out > > to be expired, it just invalidates sub-CA.cer and thus the software > > would never even open manifest 2, because sub-CA.cer is expired. > > > > If sub-CA.cer is expired the ROA for AS64496 indeed will 'disappear' (as > > if never existed), leaving just the AS0 ROA. This is as the CA intended. > > Compare that to: > > Valid CA certificate with > * Manifest, with valid EE certificate, containing > * valid CRL > * ROA: AS0, 192.0.2.0/24, EE cert with 2020-12-01 expiration > * ROA: AS64496, 192.0.2.0/25, EE cert with 2021-01-01 expiration > > This results in a failed fetch when validated today. > > Under our interpretation of -00, this manifest would be rejected, > since all objects on a manifest need to be valid (present, hash match, > correct, non-expired) for a fetch to succeed. The objects ON the manifest must be present and matching hashes, and the manifest's EE certificate being correct, non-expired. I think this is what is meant with the manifest must be 'valid', and 'current' > I would argue that to be consistent, this should not result in failed > fetch, the expired ROA should not apply, because this is what the CA > intended. > > What do you think the outcome should be? Current versions of rpki-client and FORT consider the fetch successful, but the 'AS0 ROA' in your example is expired, so that ROA will not be emitted as VRP, as the ROA did not pass validation. Imagine this scenario: I am an IP prefix broker, and I have a /16. For this /16 I create a AS0 ROA because I don't want anyone to use the /16 unless I've given explicit permission through the creation of a ROA. In december customer A leases a /24 for 3 months. In January customer B leases a different /24 for 5 months, starting at February 2020. Current time: 4 december 2020, 15:03 UTC Valid CA <10.0.0.0/16> * Manifest, with valid EE certificate, containing * valid current CRL * ROA: AS0 10.0.0.0/16 (start date 1 july 2020, end date 1 july 2030) * ROA: AS1, 10.0.0.0/24 (start date 1 december 2020, end march 2021) * ROA: AS2, 10.0.1.0/24 (start date 1 february 2021, end juli 2021) I believe the above to be real-world examples of how people perceive the functionality of the RPKI, and this is confirmed by APNIC indicating that the expiration dates on CA .cer files can match the expiration of APNIC membership status. The beauty here is that a CA (an internet number resource holder) can pre-provision the routing authorisations ahead of time. Each ROA on this manifest represents a cryptographic 'product' (think something tangible you can buy and hold), in this case authorizations to originate IP space. The CA can also pre-provision the decommissioning of the product, this is done by aligning the ROA expiration dates to the business contract. This is an important cryptographic feature to be able to pre-provision contract terminations. Different expiration dates (and also start dates) for different objects on the same manifest is an expected state of the RPKI. I believe the CA's wishes are honored by checking that all files are present & hashes matched, and that then in a second step each individual object is validated (both signatures and validity time) Kind regards, Job From nobody Fri Dec 4 07:58:14 2020 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 8907C3A0DBB for ; Fri, 4 Dec 2020 07:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llzLQOgKjbYH for ; Fri, 4 Dec 2020 07:58:10 -0800 (PST) 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 BE4F33A0DB4 for ; Fri, 4 Dec 2020 07:58:09 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id E477C60600; Fri, 4 Dec 2020 15:58:07 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1607097486; bh=FkcWajNe1HSJWZ1imlJJcTNocmv7qa++2WtfugTUqrk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=BQCVPRgAZZZGNXlY0Upcg8MJF9ojL1pCj2fZwD3OS6oLtlcIA8ZwpNV17kan52UwX YEeyiDsRimgF9EbD0IKlrlmE/l98KiILw+yhU0F3cH3SEyDOLMuLoEByl5Lq4+M8DX JdfBjHHxtnSQ7QLGuIiszh0TfO8IMrmmjHdVuNISy2F68JndH3LJ8ZhyFZU4m3ZGmx qWTLDOFXd24QmsKPj09sbcq2wDQJrKuE6FTVEAsJ/jI8tfX0N6KU33Iyw5/MzQevvE /sct4qAcbPgh7x/6YdrYg8ORMXCXmkdzodB4Circ+BPAbI6Aq/jSTSLJW4hWno9c3O cKC3IpV+7asJw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 4 Dec 2020 16:58:02 +0100 Cc: Benno Overeinder , SIDR Operations WG , Martin Hoffmann , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 15:58:13 -0000 Hi Job, all, > On 4 Dec 2020, at 15:37, Job Snijders wrote: >=20 > On Fri, Dec 04, 2020 at 02:13:40PM +0100, Benno Overeinder wrote: >> Not looking back, but looking ahead, I want to focus on how we solve >> issues and discuss them in sidrops. And indeed, if there is an >> impasse, organise a virtual meeting and discuss the matter to make >> progress. >=20 > Yes, I took it as a sign of convergent thinking. Progress indeed. >=20 > However, my question remains, looking forward, what can be done > differently in the future? >=20 > Some suggestions from my side: Thank you for taking the time to suggest ways to improve! We can continue this discussion here, or perhaps even have a separate = thread on this. I don't really mind either way. I am just happy with = this effort. > - SIDROPS must require multiple implementations before sending an > Internet-Draft towards the IESG. To meet this requirement, > Implementers should write an implementation report and share it > with the group, at least detailing the behavior for each = normative > term. works for me > - Please listen to operators who report (hard to troubleshoot, hard > to explain) network outages which resulted from RPKI processing. > RPKI ROV is supposed to be an incrementally deployable 'fail = open' > mechanism. Yes, of course. Also listen to software implementers, and RPKI infrastructure (CA/repo) = operators, or anyone who speaks up here. People who do, do so because = they all believe strongly in making things better. So, respect each = other and trust people's motives. When there is pushback perceived, then = this is most likely because the other party is trying to make a point, = and not necessarily because they don't acknowledge your issue. And before I offend anyone with this.. we all suffer from cognitive bias = in how we read what the other people wrote, and might have thought, or = not said, etc. So, really I mean this as a constructive thought. 1-on-1 = emails may also help to get some clarity - now that we do not get to = meet anyone in person, before mis communications get out of hand. > - Implementers should more often share/construct the actual X.509 > files rather than attempting to document the hypothetical states > of the RPKI in natural language (avoid English or Dutch). We can > all load X.509 files into our implementations, set currenttime to > the test case at hand, and discuss results. There has been talk of an effort in the dark past, which was abandoned. = But in short, yes, I think it would be great if we had a way to achieve = this. > - Implementers should feel empowered to make improvements to their > software (for the benefit of their users), especially if there is > perceived ambiguity in RFC texts. An implementer doesn't need the > blessing of the whole IETF before making a change. >=20 > - Sometimes RFCs are wrong, or worse: the then-WG kicked the ball > down the road and state 'up to the implementer' (aka 'local > policy'); in which case the implementer will have to weigh the > advantages of perceived 'RFC compliance' vs the effects of the > behavior in the BGP Default-Free Zone. See the previous point. >=20 > - The RPKI is a system that has been deployed on the Internet, this > sometimes means operators need to quickly deploy fixes to address > ongoing issues. Time is of the essence when it comes to security > or reliability issues. So 'code first, RFC later', which goes = well > with point 1: 'implementations first, then publish RFC'. On the above three points. Generally speaking plausible, and agreed. = However, it's not always easy to achieve. On 6486 in particular there was a strong desire communicated by = operators that RPs behave the *same* way. Which is why we were hesitant = to implement the changes suggested by you in the GH issue. In fact we = even agree with the approach in the issue. But it's different from where = the -bis text is headed until now. We felt that the desire for universal = behaviour (-bis) outweighed the rush to make a quick change here. You = are welcome to disagree with that assessment, but understand that there = was well intended reasoning behind it. > You mentioned some kind of testbed, indeed it would be wonderful if we > can easily reproduce states of the RPKI and allow implementers to > provide annotations on why software (versions) behaves in a certain > way. The December 1st, 2020 case is definitely one I'd add to the > testbed archive. It would be. I think this is an effort in itself. Do you have a proposal = in mind? >=20 >>> The real goal is to keep the network running, where in this context >>> our role is to create software for network operators for them to >>> securely validate the wishes of the Internet number resource >>> holders. >>=20 >> Agree to that! >>=20 >> Let's keep the good spirit of collaboration and learning together. >=20 > For sure! For sure! Tim >=20 > Kind regards, >=20 > Job From nobody Fri Dec 4 12:46:22 2020 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 05BC33A0ECB for ; Fri, 4 Dec 2020 12:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ltri.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqS0sHyxGhly for ; Fri, 4 Dec 2020 12:46:19 -0800 (PST) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601B53A0C37 for ; Fri, 4 Dec 2020 12:46:19 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Cnl9P5C48zQlLR for ; Fri, 4 Dec 2020 21:46:17 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltri.eu; s=MBO0001; t=1607114775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KZC7KCXfWe9DKxUsg0vDfaB7U94jt8JmSfN5cL6jqIs=; b=hoSmqH8eoTCZLEdaleRvcPkcmbZUlO3clPSGV29jn86llfhurLVunfPmOka259NWhTOgpQ It27fhepJshoQYCAROveBnZBnU/FQ87E7tn75lQb2yTcWjGz/M1PIZdLSI+pVy45BHDQiX 3XJ9OvzVAfTZRxvoFENasvNb7BnkvaVgfGeIOzXRwhEvMBShZzPs1U/P0qQJBAY/MILY5V CyC1/7GE1vnWHQLPiE0HY3XcEpk+08iGQBe5nrwiRMlcYn5C+CdH8CTIRr+VdffEf6VQTR 3926EYdor3Fpg1LL7FZVQl6vchezSo8xM8LW0zqjblDCM9Fr3wmHMqVM8g90gA== Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id iq1LxPk1m6zN for ; Fri, 4 Dec 2020 21:46:13 +0100 (CET) Received: by mail-io1-f51.google.com with SMTP id r9so7119784ioo.7 for ; Fri, 04 Dec 2020 12:46:13 -0800 (PST) X-Gm-Message-State: AOAM531vU/mQ5hQb4o8BERbmh1kbcFm+plNRphMwc8ICyv99kspg+zQO qPwDXSGW6v3eQ+NlJlymFDt60kMhqdADHNnHJf0= X-Google-Smtp-Source: ABdhPJyHGJqDxE+u4g6/Wali/KNQfhrcd5BkwDZ+YPWFVQZs49oxD4hOvkbb2UZFf359nGC/N0JaaxGh5tDgrog9u5Y= X-Received: by 2002:a02:a419:: with SMTP id c25mr8611864jal.91.1607114772063; Fri, 04 Dec 2020 12:46:12 -0800 (PST) MIME-Version: 1.0 References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> In-Reply-To: <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> From: Lukas Tribus Date: Fri, 4 Dec 2020 21:46:00 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Tim Bruijnzeels Cc: Job Snijders , Benno Overeinder , SIDR Operations WG , Martin Hoffmann , Ben Maddison Content-Type: text/plain; charset="UTF-8" X-MBO-SPAM-Probability: X-Rspamd-Score: -7.47 / 15.00 / 15.00 X-Rspamd-Queue-Id: 71C4B17B3 X-Rspamd-UID: e2ff66 Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 20:46:21 -0000 Hello! On Fri, 4 Dec 2020 at 16:58, Tim Bruijnzeels wrote: > On 6486 in particular there was a strong desire communicated by operators > that RPs behave the *same* way. If I recall correctly, I expressed this desire, yes. This was based on my gross underestimation of the complexities of the RPKI repository system and also a lack of understanding of how routers will handle multiple RTR servers at the time. As a network operator, I like the fact that BGP implementations across vendors, given the same/similar parameters, select the same best path. This means I can replace vendor X with vendor Y in location Z and keep the rest of the network as is, without routing loops. However different VRP outputs from RP's do not cause routing loops in networks (when deployed correctly). Apart from routing loops in the BGP analogy, same exact VRP output means that I don't have to think about what happens if different RP software disagrees, which I can appreciate. However the RPKI repository system is just too complex and has too many variables. In the WebPKI world, although TLS is standardized, TLS clients will behave differently. Firefox is actively querying OCSP servers, Chrome will never do that and will wait for Google to push CRL-sets to the browser. Implementation choices vary widely. If the TLS RFC's would go into such details like specifying whether Firefox or Chrome is "right" (should a browser actively query OSCP server and what about walled gardens [...]), that would probably make RFC ratifications take a *very long* time (too long to keep up, while the real world moves on) and defeat it's entire purpose. And how would this impact something like 1/n-1 record splitting (the workaround for the BEAST vulnerability, which all browsers implemented after Chrome made the first step forward [1])? While the same exact VRP output from different RP's would be *nice to have* for us network operators, I fail to see how this is actually necessary. It certainly is more convenient to not have to think about those mismatches, that's the reason why I advocated for this, but that is not a luxury we can afford. This is why I now believe expecting the same VRP output from different RP's is an unrealistic goal and actually harmful. A software implementer must feel free to implement fixes for important operational issues as they see fit. Best regards, lukas [1] https://www.imperialviolet.org/2012/01/15/beastfollowup.html Which is why we were hesitant to implement the changes suggested by you in the GH issue. In fact we even agree with the approach in the issue. But it's different from where the -bis text is headed until now. We felt that the desire for universal behaviour (-bis) outweighed the rush to make a quick change here. You are welcome to disagree with that assessment, but understand that there was well intended reasoning behind it. > > > You mentioned some kind of testbed, indeed it would be wonderful if we > > can easily reproduce states of the RPKI and allow implementers to > > provide annotations on why software (versions) behaves in a certain > > way. The December 1st, 2020 case is definitely one I'd add to the > > testbed archive. > > It would be. I think this is an effort in itself. Do you have a proposal in mind? > > > > >>> The real goal is to keep the network running, where in this context > >>> our role is to create software for network operators for them to > >>> securely validate the wishes of the Internet number resource > >>> holders. > >> > >> Agree to that! > >> > >> Let's keep the good spirit of collaboration and learning together. > > > > For sure! > > > For sure! > > Tim > > > > > Kind regards, > > > > Job > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 4 13:23:29 2020 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 B08173A100A for ; Fri, 4 Dec 2020 13:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SiRI0r3NjQaS for ; Fri, 4 Dec 2020 13:23:18 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FB13A102B for ; Fri, 4 Dec 2020 13:23:18 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 576E5220133; Fri, 4 Dec 2020 21:23:17 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 05f0a090; Fri, 4 Dec 2020 21:23:14 +0000 (UTC) Date: Fri, 4 Dec 2020 21:23:14 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: Benno Overeinder , SIDR Operations WG , Martin Hoffmann , Ben Maddison Message-ID: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 04 Dec 2020 21:23:28 -0000 Dear group, On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote: > On 6486 in particular there was a strong desire communicated by > operators that RPs behave the *same* way. > Which is why we were hesitant to implement the changes suggested by > you in the GH issue. I have a celebratory moment to share with all of you, below is a terminal transcript and some hashes which will allow you to confirm my findings. The below was executed on a modern POSIX.1 implementation with default settings. I used routinator's '-n' option and a symlink to ensure the input to both routinator and rpki-client is the same, up and including to all filesystem metadata. We have some tals: # ls /etc/rpki afrinic.tal apnic.tal arin.tal disabled lacnic.tal ripe.tal Execute rpki-client, which will fork rsync and gather all data from the Internet. The system is located in Amsterdam. I've also included the size of the cache and a hash of all the object filenames that were in the cache at that moment. # rpki-client -jc > /dev/zero 2>&1 && date Fri Dec 4 20:33:14 UTC 2020 # cd /var/cache/rpki-client && du -s 839028 . # find . | sha256 a8c03e2ef66de2532a119f56cdeba0e52acbeb23b8ac3e645d6fa7442c8fed8e rpki-client VRP set: # sort /var/db/rpki-client/csv | sha256 e0e8de429465def598b18a399d6695968cb7f28db2c2093c95bdc4563240fa4b routinator 0.8.2-rc1 VRP set: # ls -lahtr .rpki-cache/repository/rsync lrwxr-xr-x 1 job job 23B Dec 4 20:09 .rpki-cache/repository/rsync -> /var/cache/rpki-client/ # ./target/debug/routinator -v -t /etc/rpki vrps -n 2>/dev/zero | sort | sha256 e0e8de429465def598b18a399d6695968cb7f28db2c2093c95bdc4563240fa4b >From the above we learn it truly is possible for multiple entirely different implementations written by different people to arrive at the **exact** same results, based on data derived from a complex distributed PKI system with 5 Trust Anchors and 22,084 manifests from tens of thousands of CAs resulting in the exact same 205,768 unique VRPs. I *also* went back to December 1st, 2020 at 00:00:13 UTC and fed that data from the tarball linked at https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html into both routinator and rpki-client, and the resulting VRP lists from both rpki-client and routinator resulted in the same hash: be9e7fd656c3d143f2eb5cbb0b13d299a3534c6043f49a3330f5ac14854e621f However rocky the road was to get to this point, this really is a marvelous achievement at scale for the internet engineering community. Congratulations NLNetLabs. I hope other implementations will soon arrive at the be9e7fd656c3d143f2eb5cbb0b13d299a3534c6043f49a3330f5ac14854e621f checksum when mimicking that december 1st moment with that x509 data set. Kind regards, Job ps. Please note the above two data points are only single snapshots in time, but encouraging ones. At present I am aware of implementation differences between RP implementations related to ASN/BER/DER handling, and possibly other differences, which will probaably manifest themselves (pun intended) at one point or another in the future, or already have in the past. From nobody Mon Dec 7 05:49:41 2020 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 129723A13D0 for ; Mon, 7 Dec 2020 05:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hLFkYTQAWEVW for ; Mon, 7 Dec 2020 05:49:38 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61E03A13CB for ; Mon, 7 Dec 2020 05:49:38 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 72D92220378; Mon, 7 Dec 2020 13:49:37 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id dab96585; Mon, 7 Dec 2020 13:49:32 +0000 (UTC) Date: Mon, 7 Dec 2020 13:49:32 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: SIDR Operations WG Message-ID: References: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Example BGPSec Router certificate, and GBR for testing? 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, 07 Dec 2020 13:49:40 -0000 Hi Tim, On Fri, Oct 02, 2020 at 11:24:03AM +0200, Tim Bruijnzeels wrote: > Does anyone have a real world BGPSec router certificate and > Ghostbuster object they could share for testing validation software? > > The same applies to Ghostbuster records. If there is an example that > could be shared, then this could help us and other RP implementers to > deal with these objects securely as well. I published a Ghostbusters record which you can find by via the RIPE NCC Trust Anchor: rsync://chloe.sobornost.net/rpki/Sobornost/m4SxTZayQtEojVOp4jrY0LmhDyw.gbr Kind regards, Job From nobody Mon Dec 7 06:07:25 2020 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 9C4373A13A5 for ; Mon, 7 Dec 2020 06:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7c4QGPl6GPV for ; Mon, 7 Dec 2020 06:07:22 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 83D123A0D78 for ; Mon, 7 Dec 2020 06:07:22 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 9644260057; Mon, 7 Dec 2020 14:07:20 +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=1607350039; bh=SZXAfO7BwLkPhpPMx26+ehc2yzwigIL4L4VlBbQLMWY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=TN27nkpvckK7aMgX11CErvXicDqJ7+vYHsnfHKV7hQ0qhjKjM+GIJe9BJWBdswy1b ye6w7sVg73SLaOzrk8j8IwcHUSoSmTJR+5bsmVFF4GPttqbhOBB4+IKHmWChKBZhuU gTXbpbHl2BvRMe/Jr9dYKKkSUw2INg8hlyOXVPhwLkmV+CezaPK+frlaFRmHwD8RyA r4mJsICmCD0FV7C4UDg2fCknVKtpk6OGGfitdnyFnYzzkvLA9FOQLEjKewxSVUD8dJ Hl/YqeeQKGcdhs62Rd4Qim6p8CYitg3UbyLLROuJYv9S1gXErYSEYOg9JeT6qAhJrR tNT8umD/t9nFw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Mon, 7 Dec 2020 15:06:47 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <39C631B2-0BEA-4833-96B3-83F1186DC4B6@nlnetlabs.nl> References: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [Sidrops] Example BGPSec Router certificate, and GBR for testing? 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, 07 Dec 2020 14:07:25 -0000 Hi Job, > On 7 Dec 2020, at 14:49, Job Snijders wrote: >=20 > Hi Tim, >=20 > On Fri, Oct 02, 2020 at 11:24:03AM +0200, Tim Bruijnzeels wrote: >> Does anyone have a real world BGPSec router certificate and >> Ghostbuster object they could share for testing validation software? >>=20 >> The same applies to Ghostbuster records. If there is an example that >> could be shared, then this could help us and other RP implementers to >> deal with these objects securely as well. >=20 > I published a Ghostbusters record which you can find by via the RIPE = NCC > Trust Anchor: >=20 > = rsync://chloe.sobornost.net/rpki/Sobornost/m4SxTZayQtEojVOp4jrY0LmhDyw.gbr= Thanks! We noticed. When we looked earlier it had the wrong vCard version, but it's useful = to have this also in that state. My colleagues are already analysing it. = We can report on it later. Tim >=20 > Kind regards, >=20 > Job From nobody Mon Dec 7 09:51:14 2020 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 63F833A1632 for ; Mon, 7 Dec 2020 09:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ADgJkz9o1Xws for ; Mon, 7 Dec 2020 09:51:11 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95FB3A162E for ; Mon, 7 Dec 2020 09:51:11 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id EA415220376; Mon, 7 Dec 2020 17:51:09 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 20e41c72; Mon, 7 Dec 2020 17:51:05 +0000 (UTC) Date: Mon, 7 Dec 2020 17:51:05 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <7058F38E-AB83-4209-823D-6A3B860711B6@nlnetlabs.nl> <39C631B2-0BEA-4833-96B3-83F1186DC4B6@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39C631B2-0BEA-4833-96B3-83F1186DC4B6@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Example BGPSec Router certificate, and GBR for testing? 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, 07 Dec 2020 17:51:13 -0000 On Mon, Dec 07, 2020 at 03:06:47PM +0100, Someone wrote: > Thanks! We noticed. > > When we looked earlier it had the wrong vCard version, but it's useful > to have this also in that state. My colleagues are already analysing > it. We can report on it later. Ah, good catch. Now fixed: $ rsync rsync://chloe.sobornost.net/rpki/Sobornost/LMrbiOIR4bDInnBEXLsY5MZ1q1U.gbr . $ openssl cms -verify -noverify -in LMrbiOIR4bDInnBEXLsY5MZ1q1U.gbr -inform der BEGIN:VCARD VERSION:4.0 ADR:;;;Amsterdam;;;The Netherlands EMAIL:job@sobornost.net FN:Job Snijders N:;;;; ORG:Sobornost TEL:+31654942365 END:VCARD Verification successful Without pointing fingers to anyone... It appears not yet all validators are able to handle the presence of this valid, correct, signed data gracefully... In some networks my Very Important route is now marked as 'not-found' in BGP routers instead of 'valid'. Any CA could at any moment start publishing .gbr files, and it seems some validators consider all objects on the manifest to be invalid merely because they don't (yet?) support Ghostbuster Records. While would be beneficial if all validators implement decoding RFC 6493 objects... something worse than 'lack of support' is going on: I currently see some RPs 'choke' on the ghostbuster record and as a result ignore adjacent .roa files (which I consider critical for Internet routing). The existence of validators which don't *at least ignore* object types that are unknown is potentially is somewhat detrimental to the deployment of new applications based on PKIX-RPKI. To validate the *manifest*, at a high level a validator should perform these steps: 1) check if the manifest's EE certificate is valid, current, not-revoked 2) check if each file listed on the manifest is present 3) check if the hash of each file matches the hash on the manifest 4) process each object according to the rules for that object (if the object type is supported, if the object type is not supported ignore the object) So in the subsequent 'per object' validation (that follows after manifest validation), an object like this Ghostbuster Record can of course be ignored if the implementation does not support GBR files. In summary: I posit that lack of support for a given object type is not a great reason to 'throw out' all objects on a valid manifest. Kind regards, Job From nobody Mon Dec 7 10:58:23 2020 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 BE16B3A0365 for ; Mon, 7 Dec 2020 10:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2efzlWGuOU-R for ; Mon, 7 Dec 2020 10:58:19 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2066.outbound.protection.outlook.com [40.107.94.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 E96123A02DC for ; Mon, 7 Dec 2020 10:58:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bcAHUCaKY4JpGnn3dexUQoXjSFjgXjcbSx94N4oglUm6BFe5BYEf0QW3v07me7xULJ+BnfrAjZyqmOdOOftI5MjbwqrE9E71yH+kZ31vfEEBilexZuJA19xLvP1q1GNCyYt9qQXwZKwxELn+KmKN3paQErbIsNUmIhS+1G0QUuUIBUU4g9PXO9Ae7XmZ1mOSFVrjhWyloZFOMoMSJW2byz3RIkIj3xpVrJMyu+J4aNJgpuXx9R3GZPiT68FAQBYJTe1oQxSP3METvoTjlpRdgI4LQl5KcHDGYyNhjn0dF+iu33XyKflUTf8HUsQeLAja0+dxiyCPnXIqa9sgzyEiWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yYIbUtqg0bc/nCmyLs3vVqtxlBn4uykl6LcsKeuc1MM=; b=WM2EuZFhCmqnsX8onOZ6ImeXtrGblaypO2PPenNOAYzioTzO8iZ+4wmAPAfZMf+6exfWmPwe6G8hh+Y+9IqlOdCfP5SpeQMuuteqbngkoDhzBpUAIsmb7qcBSnK0Ef9j3HfGGD0gH4eFya8KoUgAcv4aMcVksYgAZzjh0m21ySGxzkiJdR80Ha/erU4EJSLasiXMqegbpcSpScSnbGSxoe1dTdRQKCjJhpJX7PChhJSQUPTmhHC6/DLOsMxLJgmcsjj4LpLb4B725276gS0VKAY3Uei1GkmjwOmg6OvRQuHNh6xclCYtFp0Tq4sZePbuF/UEW8PLV9jaXh845AXyXA== 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=yYIbUtqg0bc/nCmyLs3vVqtxlBn4uykl6LcsKeuc1MM=; b=durFwQD8GlMTpP64qXChqLBnngMHxhJ01FZDsJLNcUNBJWyYUsLBO3vRFqzHoY5kWdVKYkJmni+C8nddM4H2JRbK+9sdgFET3m0fA+UH+jNAZHUj4zbwXoKswyXNR2g+2OxWw3mKPWHi/UrUD2JLaJcRHwb20ja2T98q0uT9G7Y= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2632.namprd18.prod.outlook.com (2603:10b6:a03:13c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Mon, 7 Dec 2020 18:58:16 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4%4]) with mapi id 15.20.3632.023; Mon, 7 Dec 2020 18:58:16 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05 Thread-Index: AQHWzMrrGv2wDjNKKEmky0li8kGWWg== Date: Mon, 7 Dec 2020 18:58:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27379f70-b30c-4363-c59e-08d89ae20e6b x-ms-traffictypediagnostic: BYAPR18MB2632: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5M98unFoCVgCEbARtHq6ZgXyf5hML1uzxghVz/ahjW1ho8tuTlhfsS8fJ61ontwqyRcOijpoX1mU1SwgAErUVZouPrTCQ2ipq1/XvmsmaWxTQeZIGpecU8wARymYPeAXyvr/O7VepqCYh+HuAZw7/i6pQKIwhwVZ06ZyCWBOyRh2Ius3uKeBkAtSNLdu9pOGsoeax+F4nAt5o0VJcVzGoWuB2DeANEoiQsgKmVyoz0kc73C/uU4GDoksLyPMaR4AnkESvLmfNFMjSfGO4EhLk1gcQ7X8Uzl0SFCMF5hCW8l7wTUPT/EQ6XumzASJRfluiU/sg47MrrKhqoox8YM/2UiheCYAHf2330PNDsGFBlpsnkoc71TxTpvmnwSh6zeaJoqgQYrItZIkxJdCVwnNhioV733hUlN5DEoBHofI3HlYv2cY3a9u/lGuCz6buCvcA9deXx1n5mUik9yfprfXAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(376002)(346002)(39830400003)(86362001)(66446008)(2616005)(2906002)(8676002)(316002)(33656002)(76116006)(83380400001)(186003)(5660300002)(66556008)(6506007)(6916009)(6486002)(66476007)(36756003)(6512007)(166002)(8936002)(966005)(26005)(478600001)(64756008)(66946007)(53546011)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dW1rWG03ZnpRSURrUTd0OVZHRWFEQ0NMRk1jdml4Wk1aV3JuSDU3RkUzUVBp?= =?utf-8?B?ajMzL0xLQkpXaWxySUZSdDVvM29RUkhZelhvQmQxRlRLVUduT3dybUFwNzZB?= =?utf-8?B?Q2p2ZEhoZk1SajlidGlYaTV4bHJsZHRBbkRhc3l2dXMzVlZWZ3QyNjEzOWxo?= =?utf-8?B?anFYL2g1VWROcENrRkprUFZlRjdpV3RoMGR2Vk9xeWVEY3cxODgrTHduOWxV?= =?utf-8?B?dEVSRXpLclFmSm9Oa0F3Mks5aEVNN3ZEaUMzM3pZUDVvL3RpK294dUZEMXlL?= =?utf-8?B?bzhLSnNjWUVlTC9CcGhkWGpadlFUTzBmSGMvQ0FiVXZQWFRCc2UzYU0wR3lX?= =?utf-8?B?Q3RkLzNTL2dpbXBHU0xaNi9hMWRDY3lXa0pnMXVnREQ0OWUwdHZDNlBPbE9l?= =?utf-8?B?SzU4Ny9BSGM5S21xbTc5RkN2QzJYWXRueHVVMDFqRHJZdGVNeXp3ajlNLy9r?= =?utf-8?B?RXlTSmpaaHJETTlXTUVWd2NIdXAyUUtMTmFuc3dSK1dKRW9sMUUyWlE5SzVR?= =?utf-8?B?dVA4OWFoQk41K0haV3N1NkpEeWF1VXdvMkFEV1NNTXBQVDZlR2lyTnowbzEv?= =?utf-8?B?N2ppWjZzSjNHZTZrYnlQdGhzVGlMN20zMUpsMXlObTdWcWgxNzBraSt4bnhv?= =?utf-8?B?MnEraWlTQ3lRUmF2SXJJc0tBN1FMaVFQb1U4VE9jK1J0cjNma0NpZzhyYS9K?= =?utf-8?B?aVdmMlpiNy9wK2hqVzk2UFVtejUrbUtkLzZabk82RXJ4MTZFRVo1a3kvWjdZ?= =?utf-8?B?S3gyeDZOazdRNlppYlBKWXNWY1NhM2IrSEpEbldLeTJBSVlLTXIrVlFEUHZ0?= =?utf-8?B?R25Seml0V29BSHlNK3dpcGYyeDJvNHJ1NW1nN1U5KzRoc0cvd0ZFYVhaQ3Zk?= =?utf-8?B?V2dWcWVsWnJtSC8wRy9EVERxLzl3MlpFZkhCVE0rcFF2TTkxYjk2aDV5NHk1?= =?utf-8?B?SHJ4K0FWZVhrR1BMdjhENjcwOHVGZWV5MDBGUVhCSXVHcVpYa3ArdGZ0ekl0?= =?utf-8?B?L290bXlTMURka0Q0cThDVHJyaW83RnNXNW5tOG0yYnk0dVlvK2JScTlYK3pP?= =?utf-8?B?VktMWWR5RXdIVlpack12TVRUcS9Za2tzbkNleWpGRk9JYmhrSGNRaGR0MGkv?= =?utf-8?B?N3FYTFlsMVV2S3Y4R2N0MW9KNGkrWm1KbzNrdUc4R0hZek11am9sazlhMk1x?= =?utf-8?B?N2ZDbzkrbnluTjFYVmxwM3VZNWt4SUhvMUJleWczUWxlSmQ3SHVQNFd2MDd6?= =?utf-8?B?S29oY2tRYVVHMWJvK0NURWxPQ0x0R2VRK1VDbkl0Q3NCbE5UVlZLYUdYQytV?= =?utf-8?Q?Ad0AGZ6eVBzH7v/xjAapNVfl62eNIFIDza?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CB44F63069CB4F07840B6B4482C27632arrcuscom_" 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: 27379f70-b30c-4363-c59e-08d89ae20e6b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 18:58:16.6736 (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: kyp7MjMn85LBFa30YGT+opdTunJ5gGtdk5NIm3DLQMr5LSTQ+akQztGoi3gonIGRrIkeuIN9nD6jBkGhWlbmmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2632 Archived-At: Subject: [Sidrops] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05 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, 07 Dec 2020 18:58:21 -0000 --_000_CB44F63069CB4F07840B6B4482C27632arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgY2xvc2VkLiBBdXRob3Jz IGhhdmUgYWxyZWFkeSBpbmNvcnBvcmF0ZWQgcmVsZXZhbnQgZmVlZGJhY2sgcmVjZWl2ZWQgZHVy aW5nIHRoZSBsYXN0IGNhbGwgYW5kIGF0IHRoaXMgcG9pbnQgdGhlIGRyYWZ0IGlzIHJlYWR5IHRv IHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdlIHdpbGwgcHJlcGFyZSBhIHJlcG9ydCBh bmQgZm9yd2FyZCBpdCB0byBJRVNHLg0KDQpSZWdhcmRzLA0KS2V5dXINCg0KRnJvbTogS2V5dXIg UGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRlOiBXZWRuZXNkYXksIFNlcHRlbWJlciAzMCwg MjAyMCBhdCA3OjM1IEFNDQpUbzogInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtTaWRyb3BzXSBbV0dMQ10gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFs aWRhdGlvbi1zaWduYWxpbmctMDUgLSBlbmRzIDcvT2N0b2Jlci8yMDIwDQoNCkhpIEZvbGtzLA0K DQpUaGUgdXBkYXRlIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGluY29ycG9yYXRpbmcgYWxsIHRoZSBw cmV2aW91cyBjb21tZW50cyB3YXMgcHVibGlzaGVkIHRvZGF5IGFuZCBjYW4gYmUgZm91bmQgYXQ6 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0 aW9uLXNpZ25hbGluZy0wNS4gVGhlIHdnIGNoYWlycyBleHRlbmRlZCB0aGUgY2FsbCBmb3IgYSB3 ZWVrLiBUaGUgV0dMQyB3aWxsIG5vdyBlbmQgb24gT2N0b2JlciA3LCAyMDIwLg0KDQpCZXN0IFJl Z2FyZHMsDQpLZXl1cg0KDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkRhdGU6IFRodXJz ZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjAgYXQgMTA6MjcgQU0NClRvOiAic2lkcm9wc0BpZXRmLm9y ZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIFtXR0xDXSBkcmFm dC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyAtIGVuZHMgMTcvU2VwdGVt YmVyLzIwMjANCg0KSGkgRm9sa3MsDQoNClRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQgdGhlIGNhbGwg Zm9yIGEgd2VlayBpbiBob3BlcyB0aGF0IHdlIHdvdWxkIGhhdmUgYSBjb25zZW5zdXMuIFNlZW1z IGxpa2UgbW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZCBhbmQgc28gd2UgcGxhbiBleHRlbmQgdGhl IGNhbGwgZm9yIDEgbW9yZSB3ZWVrLiBUaGUgV0dMQyB3aWxsIG5vdyBlbmQgb24gU2VwdGVtYmVy IDE3LCAyMDIwDQoNCkJlc3QgUmVnYXJkcywNCktleXVyDQoNCkZyb206IEtleXVyIFBhdGVsIDxr ZXl1ckBhcnJjdXMuY29tPg0KRGF0ZTogVHVlc2RheSwgQXVndXN0IDExLCAyMDIwIGF0IDExOjQ1 IEFNDQpUbzogInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPg0KU3ViamVjdDog W1dHTENdIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIC0gZW5k cyAyNS9BdWd1c3QvMjAyMA0KDQpIaSBGb2xrczoNCg0KQSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24t c2lnbmFsaW5nLTAzLCDigJxCR1BzZWMgVmFsaWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBs ZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwg ZW5kIG9uIEF1Z3VzdCAyNSwgMjAyMC4NCg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDogIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9u LXNpZ25hbGluZy0wMy4gIEF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIg eW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9z ZWQuDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQo= --_000_CB44F63069CB4F07840B6B4482C27632arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <87FBA8DA8676634C81B0D90E7F972C3C@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oi13ZWJraXQt c3RhbmRhcmQ7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Rm9sa3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgaXMgY2xvc2VkLiBBdXRob3JzIGhhdmUgYWxyZWFkeSBpbmNvcnBvcmF0ZWQgcmVsZXZh bnQgZmVlZGJhY2sgcmVjZWl2ZWQgZHVyaW5nIHRoZSBsYXN0IGNhbGwgYW5kIGF0IHRoaXMgcG9p bnQgdGhlIGRyYWZ0IGlzIHJlYWR5IHRvIHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdl IHdpbGwgcHJlcGFyZSBhIHJlcG9ydCBhbmQgZm9yd2FyZCBpdCB0byBJRVNHLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+S2V5dXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPktleXVy IFBhdGVsICZsdDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIFNlcHRlbWJlciAzMCwgMjAyMCBhdCA3OjM1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtz aWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW1NpZHJvcHNdIFtXR0xDXSBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxp ZGF0aW9uLXNpZ25hbGluZy0wNSAtIGVuZHMgNy9PY3RvYmVyLzIwMjA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRm9sa3MsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSB1cGRhdGUgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaW5jb3Jwb3Jh dGluZyBhbGwgdGhlIHByZXZpb3VzIGNvbW1lbnRzIHdhcyBwdWJsaXNoZWQgdG9kYXkgYW5kIGNh biBiZSBmb3VuZCBhdDoNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wNSIgdGl0bGU9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25h bGluZy0wNSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7LXdlYmtpdC1zdGFuZGFy ZCZxdW90OyxzZXJpZjtjb2xvcjpibHVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDU8L3NwYW4+PC9hPi48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj5UaGUgd2cgY2hhaXJzIGV4dGVuZGVk IHRoZSBjYWxsIGZvciBhIHdlZWsuDQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpbGwgbm93IGVuZCBvbiBP Y3RvYmVyIDcsIDIwMjAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXl1cjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+U2lkcm9wcyAmbHQ7c2lkcm9wcy1ib3Vu Y2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgS2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1 cy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMjAg YXQgMTA6MjcgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsg Jmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbU2lkcm9w c10gW1dHTENdIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIC0g ZW5kcyAxNy9TZXB0ZW1iZXIvMjAyMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRm9sa3MsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSB3ZyBjaGFpcnMgZXh0ZW5kZWQgdGhlIGNhbGwgZm9yIGEgd2VlayBpbiBob3BlcyB0 aGF0IHdlIHdvdWxkIGhhdmUgYSBjb25zZW5zdXMuIFNlZW1zIGxpa2UgbW9yZSBkaXNjdXNzaW9u IGlzIG5lZWRlZCBhbmQgc28gd2UgcGxhbiBleHRlbmQgdGhlIGNhbGwgZm9yIDEgbW9yZSB3ZWVr Lg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V0dMQzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj53aWxsIG5vdyBlbmQgb24gU2VwdGVtYmVyIDE3LCAyMDIwPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXl1cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXl1ciBQYXRlbCAmbHQ7a2V5 dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgQXVndXN0IDExLCAy MDIwIGF0IDExOjQ1IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtzaWRyb3BzQGlldGYub3JnJnF1 b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bV0dMQ10g ZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMgLSBlbmRzIDI1L0F1 Z3VzdC8yMDIwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24t c2lnbmFsaW5nLTAzLCDigJxCR1BzZWMgVmFsaWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBs ZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpbGwNCiBlbmQgb24gQXVndXN0IDI1 LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo ZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyIgdGl0bGU9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9u LXNpZ25hbGluZy0wMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMt Ymdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzPC9hPjwvc3Bhbj4uPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkF1dGhv cnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSBy ZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+S2V5dXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CB44F63069CB4F07840B6B4482C27632arrcuscom_-- From nobody Mon Dec 7 12:54:09 2020 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 195C73A0A0B for ; Mon, 7 Dec 2020 12:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Yo9rYNJQKLph for ; Mon, 7 Dec 2020 12:54:07 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539733A09D6 for ; Mon, 7 Dec 2020 12:54:07 -0800 (PST) Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 59A96220375; Mon, 7 Dec 2020 20:54:05 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 147ae914; Mon, 7 Dec 2020 20:54:03 +0000 (UTC) Date: Mon, 7 Dec 2020 20:54:03 +0000 From: Job Snijders To: Keyur Patel Cc: "sidrops@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] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05 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, 07 Dec 2020 20:54:09 -0000 Dear Keyur, On Mon, Dec 07, 2020 at 06:58:16PM +0000, Keyur Patel wrote: > This working group last call is closed. Authors have already > incorporated relevant feedback received during the last call and at > this point the draft is ready to progress further. Accordingly we will > prepare a report and forward it to IESG. I really think this is a draft where it will proof to be useful to ask for an implementation report from *at least two* implementations, demonstrating interopability between the two implementations. In this (lengthy, sorry!) email https://mailarchive.ietf.org/arch/msg/sidrops/5-sFl3RCzn7xQ0YFOD31C56Ko4o/ I tried to outline various problems I perceive with the draft in its current form, Oliver replied to all text, but zero changes were made to the document as he disagreed on all points of substance. Oliver claims to have an open source implementation, (which I am happy to believe!), and perhaps there is another implementation written by someone else? Has it been tested how they interact with each other in various configurations? If there is a second implementation, the working group can confirm whether the proposed Internet-Draft text, Oliver's implementation, and the second different implementation are aligned with each other and behave in exactly the way outlined in the document. An implementation report can be as simple as listing all IETF normative terms contained in draft, the line number, and a short comment whether the implementation is compliant (MUST), or an implementation specific choice was made (MAY), or anything else of note. Specifically in this draft, I really see potential for a repeat of the 'IOS XE / origin validated extended communities'-problem that many operators suffered from when they tried to deploy RPKI Origin Validation in the BGP default-free zone, and I do not wish a similar repeat of events upon the BGPSec technology stack! Here is one of many references to the 'standardized' extended rpki origin validation communities causing issues in networks build using multiple BGP implementations, here is one mail thread. This was/is a multi-year problem because of the slow upgrade cycle of field-deployed routers: https://www.mail-archive.com/cisco-nsp@puck.nether.net/msg67710.html I think there is some kind of technology stack layering problem when the state of a route can be manipulated through multiple channels. In this case (1) signaled via BGP community and (2) via signalled via RPKI-To-Router protocol, it can lead to problems for resource holders who are trying to use BGPSec, because there can be situations where their wishes are not expressed in the state of the network because of interference of an unauthenticated BGP communitiy. So far I think some of us (perhaps myself included) have been too focussed mostly on the security aspect (and of course everyone knowns extended BGP communities are not authenticated), but perhaps the *security* aspect of it is not the real problem, the real problem might be how an accidental misimplementation of draft-sidrops-bgpsec-validation-signaling-05 can lead to operators having to turn the feature off in the entire fleet of devices, or roll back the software (be forced to keep running some unwanted version). If you ask anyone in the field about RFC 8097, virtually no operator will tell you that RFC 8097 in any way helped them deploy RPKI Origin Validation at scale (where scale is 100s of routers, multi-country network, multiple vendors). What you *will* hear is that there were interopability issues caused by the very existence of the RFC that caused many people extra work. It also means that everybody now has to test each and every new BGP software version they receive from their vendor on what exactly the behavior is of the proposed bgpsec origin validation signaling draft communities. If this draft is published as RFC, IANA will assign 3 codepoints to be used in some fashion in a generally unauthenticated protocol (BGP), and from that moment all operators doing QA will need to blackbox test the behavior of every BGP implementation they consider, to see if the implementation does not accidentally cause deviation from 'local policy' in any way under any circumstances. Standardizing codepoints to signal cryptographic validation states through unauthenticated channels really causes Internet operators down the road deployment problems, for multiple reasons. Kind regards, Job ps. I once was young and wet behind the ears and endlessly argued how great RFC 7999 was a *great* idea. At the time it really did seem great because DDoS attacks were a big problem, also lots of network operators with a 32-bit had difficulty picking suitable inter-domain BGP values. But in retrospect what I should have advocated for is a 'BLACKHOLE' PKIX-RPKI profile, now realizing that the RPKI via RRDP/RSYNC/RRDPv2 might make for global near real-time public 'routing intention' distribution, really rivaling with the speed at which BGP updates propagate through the Default-Free zone. From nobody Tue Dec 8 06:28:06 2020 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 A00A63A0EF8 for ; Tue, 8 Dec 2020 06:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yjhdjFjj0Tob for ; Tue, 8 Dec 2020 06:28:02 -0800 (PST) Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5973A0EF6 for ; Tue, 8 Dec 2020 06:28:00 -0800 (PST) Received: from bench.sobornost.net (236-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.236]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 00F20220371; Tue, 8 Dec 2020 14:27:58 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id a50b588d; Tue, 8 Dec 2020 14:27:57 +0000 (UTC) Date: Tue, 8 Dec 2020 14:27:57 +0000 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] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 08 Dec 2020 14:28:05 -0000 Dear all, I propose some following text detailing a requirement for multiple implementations to exist prior to RFC publication will be beneficial to the working group. Our neighbors at the IDR working group are known to have a similar requirement, which has dramatically improved the quality of that working group's specifications and subsequently the deployability of IDR technologies. I hope the same can be achieved in SIDROPS. IDR participants track implementation reports & interopability testing through internet-drafts or their Wiki https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports Here are some examples of what reports can look like: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations Proposed text to add to the SIDROPS charter: """ Specifications produced by the SIDROPS working group are intended to address a practical need where a standard specification can assist both vendors and consumers of cryptographic PKIX products to be assured that a standards conformant implementation will undertake certain functions in a known manner, and that, as appropriate, implementations of the standard specification from different vendors will indeed interoperate in intended ways. The SIDROPS working group requires interopability reports from at least two different implementations of a proposed specification, prior to publication as RFC. """ Kind regards, Job From nobody Tue Dec 8 06:49:11 2020 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 8B24B3A0F3A for ; Tue, 8 Dec 2020 06:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y-PTBed0BEqY for ; Tue, 8 Dec 2020 06:49:07 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 1C72C3A0F39 for ; Tue, 8 Dec 2020 06:49:06 -0800 (PST) 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.16.1/8.16.1) with ESMTPSA id 0B8En3Bb044799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2020 14:49:03 GMT (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: sidrops@ietf.org References: From: Nick Hilliard Message-ID: Date: Tue, 8 Dec 2020 14:49:02 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.40 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] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 08 Dec 2020 14:49:10 -0000 Job Snijders wrote on 08/12/2020 14:27: > will indeed interoperate in intended ways. The SIDROPS working group > requires interopability reports from at least two different > implementations of a proposed specification, prior to publication as > RFC. given the difficulties that have been seen in the RPKI recently, all of which related to subtle spec interpretations, this does not seem to be a completely dumb idea. Nick From nobody Tue Dec 8 10:17:10 2020 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 511153A1080 for ; Tue, 8 Dec 2020 10:17:08 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VfdUrTpc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e+wc/b56 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA33d-OjMT_Q for ; Tue, 8 Dec 2020 10:17:05 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9343A0100 for ; Tue, 8 Dec 2020 10:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1607451425; x=1608661025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jkSnRVAkEoxHneMcCfxjFl/pnjeZu4kQIgjJlCKzE7s=; b=VfdUrTpc4hFJfjJsFt2UkNjl1LBWpbrRdweth4UEM7KjjkWBKNGwF8r5 TrQAyVH73DYPeBTF0Ci7ObUVXLsokH/t71qHxMWtTCpB6k+nhL6+YJcE9 GJnqieSwN6owjLNhuAFHehkOjGDSAW/nEjiH3LQsY9SomJOBiRvv8UoF5 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AV9fAvhKwI/vOmoBve9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/gljOV4zBrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtbH8H0bkeUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjCgApws9f/4oNJK1iHgEBCxIMQIM?= =?us-ascii?q?hUQd1Wy8uiAYDjWCZCYJTA1QLAQEBDQEBGAsKAgQBAYQGRAKBfgIlOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRxhWEMhXIBAQEBAwEBECgGAQEsCwELBAIBCBEEAQEfBQs?= =?us-ascii?q?nCx0IAgQBDQUIGoMFglUDLgEOoXgCgTyIaXSBNIMEAQEFhTMYghADBoE4gnS?= =?us-ascii?q?GOoQVG4FBP4ERQ4InLj6CXQEBgWGDSIIsg35aIBxrpxWRMwqCdJtigyOfEZN?= =?us-ascii?q?6ggKfIAIEAgQFAg4BAQWBbSOBV3AVO4JpUBcCDY4hN4M6hRSFRHQ3AgYKAQE?= =?us-ascii?q?DCXyMDQEB?= X-IronPort-AV: E=Sophos;i="5.78,403,1599523200"; d="scan'208";a="567753641" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Dec 2020 18:17:04 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B8IH3Ba008434 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Dec 2020 18:17:03 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 8 Dec 2020 12:17:03 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 8 Dec 2020 12:17:02 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 8 Dec 2020 12:17:02 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V/UeP4XcKs5dGpVcBHY9DH+lVr8q2b7DBCFalvbAHJLKmyW0hR5sqKyn6RabCbipZxz9DTg4YofuKY5UtjSFvIfeoKSJW8A5HV5BEmUNElQ0c3xFM29R7WyK9Q66Ru32K5S8i6vcVa9s/Pa8hPGzU17UU4OSkAUNubUA1pwLYg4W9lTfINCsgHTgW6ttdG4jDxeTsqAjf5e4tVCMZw/yrQixktuQfOiBK1raBTXTBkblKOSBkXxRobKdXPbU6mJzIXzj+stXvpXH6vOybHDI3qa68Xgx+19ScY5qJO2yxGDG7uYJ1xeJCHD2eTm0ZwbBMvOz/ZrnRRynHv4hNBXSeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R+emD2aZd8TU5nxUeTqNgjxWrzzf3W6/igxRZzffGJ4=; b=lsi/JzfEB3qXtjbwplZYzfBqfN7SSjxc6uY/by649rvvjrbb3OmFZ+obDk8D0oiJEw/w7Vdccd3JMUMHou0oW9gcri2lraXrYDSaUyK8MAKcajX9yfcKt3icv93RJJ/qeRYwJuzvygW2vBM0jDnt4WHETQadOR+ymcEZSDT8H0Y7JlFS3cqYB9j3VntQfNfrGLNlCztH1wvUOHGpU2YjsmZva/l6gXgna8xPMvagehlEMZxY8zOUNDkTy4FX/VjRButnn1ViaYZapQGcpSIoSREXGu3PykWTMk8csCv3JaV66WCJgacxKZEWgwGHSiBNq7deKyznss9qjgb8qkwllw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R+emD2aZd8TU5nxUeTqNgjxWrzzf3W6/igxRZzffGJ4=; b=e+wc/b569ItjjCFQwVKbQDLX1qlznBV1qODRfEKj9aTqVcPHWxMEt6GGuc3vkhoXnW/rn6xAlX6IokrrxRoWzEHg7HQ/wtk0CXyuX+Igy1nXkMmtK4DaMPANMG/DXWvJq/ZViUt+tY/ekBkvpE95LzKN3Q60MHbE2e8K9jgfycc= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB4055.namprd11.prod.outlook.com (2603:10b6:a03:18b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.22; Tue, 8 Dec 2020 18:17:01 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3632.023; Tue, 8 Dec 2020 18:17:01 +0000 From: "Jakob Heitz (jheitz)" To: Nick Hilliard , Job Snijders CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) Thread-Index: AQHWzW5iCwQHeg9JqEajYhVaM/1WY6ntR6wAgAA5/lA= Date: Tue, 8 Dec 2020 18:17:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:8574:3aac:ddb5:b980] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7c1f74a-8d10-44f9-7daa-08d89ba575a9 x-ms-traffictypediagnostic: BY5PR11MB4055: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MqPJJWdU2IR6E4kK3xu9SI1agB4vIBO64JpNdRwDTv/0Gs3Gl/ZT3VsDsem4YEG6ubKM760182J96NcghFHbpQL92COK+IoLI+vOHE8MVp4L5fez+3D4LP9/dPfw/S1p6HTW5TJ670NpsWFfp8v3jM51NHav7GlyHotqDek51yYIXbhoWo3N6E3yS7NmjLCEQ482UunCgNxjq+X+LbRi+XmWzRRC7s6LNP3C67im42LXkwWS3LQQRpBDhnZCl1ISDWgfKXNpBeuvVxUDKlk0Uyl0H/RXxmbSSu0rWRm21pvuJjxFjTNTALtTQC+qAcyQBWIB8aDxqajnHczDH1t4fW3PssvVG1Q3OqCFo6Qt3LfAiQfpCQEH9ukbUQxMK8DbNhh77atzaGl+ClmUwlovyw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(346002)(366004)(66946007)(7696005)(110136005)(76116006)(4744005)(186003)(66556008)(4326008)(6506007)(64756008)(52536014)(66446008)(33656002)(83380400001)(55016002)(8676002)(71200400001)(66476007)(9686003)(86362001)(53546011)(5660300002)(15650500001)(8936002)(2906002)(508600001)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?NH+elUu3MsMaPPBp5313lsp8R80SH2VmvkkD2ih31lN+5H/Trfm/Mk3PTXKF?= =?us-ascii?Q?iFjKNxmemUEvS4dE0OIaLuOXR/fpzA40iN/HHo8ETBtKi/tJmST2DYcErpHO?= =?us-ascii?Q?0KlGmmUQk1vks4/SXa15u8AHRqmG2kxkaeTs9g3wLQEoc1rTE4V/W6a5kKwa?= =?us-ascii?Q?iNPR4+CDBZ+y0EKNZK1oxWCh1OwPJsuzxkIkT0zezh3gz9H9s5sTgO2J0md4?= =?us-ascii?Q?Q8F5Fdkq6wmiJ1ehEMekgUO1WHG9v31I4GqnxNd4IvAKx4uNBoXvCUDoSHCU?= =?us-ascii?Q?S8iQ0UoGajjmoLkpM8n2FWyl5D3NgCPKUzrHFtBBYcu1tkOg7dnVkRNAuQC3?= =?us-ascii?Q?ZoghK3oi6lgeQyBLnc7VF7gc2Vhc+eL2enyeVgpYSlwS1M9HO4REqyhQcyGJ?= =?us-ascii?Q?w+QWm4J7OnWug4r65dmIxAnmbDw6/6sniRVYm7JReKzIHMptBpiCRjHaMigj?= =?us-ascii?Q?skIAvRN2Kz1pBx4YtZgAGUyqsFU9hntlGbgTnVsyPmCEZUP9866wKP7ksYpU?= =?us-ascii?Q?X45/rJ9kw0o9nY+SxsH3W6e9wSG3gi4QvASyALkZvKfX4AjgXDt2EW9ZgesD?= =?us-ascii?Q?4rv1hS+e/vOidGKyCMuy/ajzsdnY8xfQLQ9+2fEH4BHBNkbbkyi3SYEIvS34?= =?us-ascii?Q?aZcFa133yz9y1BiFmMCDFg3qzphm0yL9TpdIQBw9eurisUE3KEvPNPF5mCSh?= =?us-ascii?Q?DII5FgW5Id02e3bhnPnzUCOzWiWkymucJV3QTN/KJknZd5Gi9B5Bv04hK2Aq?= =?us-ascii?Q?QWJlADrCVUcS/FxEZpSQtLvDcf1gt+XfZucHbn36cDWs2yIJcRayLuOO7FwU?= =?us-ascii?Q?hHdNZArI81iSEaMRGQuz2JuiRLHNHwsW2JRHLaA2BQATDvNLQdnWYfBG4w0g?= =?us-ascii?Q?W39IGII7cpSiXbkfVzkU/JeclfxI7n3Yt6VK3r+kaokGg71cbVLVjjXqYW0k?= =?us-ascii?Q?7IwXugmIx0MBOTWw0adVhsCGzNLQ/qLafv/7rH0CRLZYOj07NgUAbVqnrQ16?= =?us-ascii?Q?GeKEdAcCz5eIjF5Jsl2nsz5Fx3qZTLWMyMamXszkTYY8dNo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7c1f74a-8d10-44f9-7daa-08d89ba575a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 18:17:01.7207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9BCLVjqpPAJdZdmpuCPxJB3JUuj/cSaXMs5+mdQidqBTt0crCKXhYasc/UDpD8fH8xMogRCcNBxYpb+MWVluVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4055 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 08 Dec 2020 18:17:08 -0000 I support. Regards, Jakob. -----Original Message----- From: Sidrops On Behalf Of Nick Hilliard Sent: Tuesday, December 8, 2020 6:49 AM To: Job Snijders Cc: sidrops@ietf.org Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for = multiple implementations before IESG/RFC publication) Job Snijders wrote on 08/12/2020 14:27: > will indeed interoperate in intended ways. The SIDROPS working group > requires interopability reports from at least two different > implementations of a proposed specification, prior to publication as > RFC. given the difficulties that have been seen in the RPKI recently, all of=20 which related to subtle spec interpretations, this does not seem to be a=20 completely dumb idea. Nick _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 8 10:32:39 2020 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 46B2D3A1015 for ; Tue, 8 Dec 2020 10:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ltri.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 329AJSJpGHm2 for ; Tue, 8 Dec 2020 10:32:35 -0800 (PST) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBFB3A0045 for ; Tue, 8 Dec 2020 10:32:35 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Cr81F6Bs1zQjTy for ; Tue, 8 Dec 2020 19:32:33 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltri.eu; s=MBO0001; t=1607452351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vif1686GnytiX5AyJ+vJcDIRTOOnB4Tyo5RoHPkwQAk=; b=jxWowlS6XnbV4dxhI/lnCdZZs/FtYx6+lqPJ3646YP2WFTkD3/QaLml+THx6X+GUKpRywH hJ+BYCCJ4nqyxtK/TgVnwRufLTpQftn/X0e3q0Qo7QOy6r5S/Fexyqrj6H9u6JYAdwobUP o5+Pyky7uRAQorRfN6diZwYi74q/nekwB7NLqSLAKUdp6gLivpZMzhcLxXf9cbT8t5PRT5 PC7X1v3Uy9vDgtc1w/caLv/gXXyEdR5Ky3s00vS+oABWhmUJEFmzOGSRRa/TWLHHOAAGPv DTno87eqnI+6YhPRYyfjX/Ng7Mqz86L+rezy7OeeeWLm0la+01sMUx+UTCuenw== Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id 2mMbdtFW0YFU for ; Tue, 8 Dec 2020 19:32:30 +0100 (CET) Received: by mail-il1-f174.google.com with SMTP id k8so16376010ilr.4 for ; Tue, 08 Dec 2020 10:32:30 -0800 (PST) X-Gm-Message-State: AOAM531HjUwvx1I+/IzCen2bBO/016/XkL3KrbIrX7H1Wko9ey/hIpmg o9QB4FRm27B7qxJpoR9muxbLNfiCpqYQWJ8wp2k= X-Google-Smtp-Source: ABdhPJzFI72BiC3k63wpe5HTbCBekwjGOtoN/itL9sVlUyKJyAuKAknd2v8aKVSTbgtTFrhd5DaIPlTWfuzon2oUCpo= X-Received: by 2002:a92:5:: with SMTP id 5mr28724029ila.150.1607452348622; Tue, 08 Dec 2020 10:32:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lukas Tribus Date: Tue, 8 Dec 2020 19:32:16 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Job Snijders Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" X-MBO-SPAM-Probability: X-Rspamd-Score: -3.95 / 15.00 / 15.00 X-Rspamd-Queue-Id: A35941850 X-Rspamd-UID: 5c314d Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 08 Dec 2020 18:32:37 -0000 Hello, On Tue, 8 Dec 2020 at 15:27, Job Snijders wrote: > > Dear all, > > I propose some following text detailing a requirement for multiple > implementations to exist prior to RFC publication will be beneficial to > the working group. > > Our neighbors at the IDR working group are known to have a similar > requirement, which has dramatically improved the quality of that working > group's specifications and subsequently the deployability of IDR > technologies. I hope the same can be achieved in SIDROPS. > > IDR participants track implementation reports & interopability testing > through internet-drafts or their Wiki > https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports > > Here are some examples of what reports can look like: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis > https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations > > Proposed text to add to the SIDROPS charter: > > """ > Specifications produced by the SIDROPS working group are intended to > address a practical need where a standard specification can assist > both vendors and consumers of cryptographic PKIX products to be > assured that a standards conformant implementation will undertake > certain functions in a known manner, and that, as appropriate, > implementations of the standard specification from different vendors > will indeed interoperate in intended ways. The SIDROPS working group > requires interopability reports from at least two different > implementations of a proposed specification, prior to publication as > RFC. > """ I support this proposal. Thanks, Lukas From nobody Tue Dec 8 20:06:58 2020 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 8483C3A0AB4 for ; Tue, 8 Dec 2020 20:06:56 -0800 (PST) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 p-CSAt_jELcs for ; Tue, 8 Dec 2020 20:06:54 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 885413A0962 for ; Tue, 8 Dec 2020 20:06:54 -0800 (PST) Received: from jmbp.local ([73.63.242.69]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id 0B946rNc087500; Wed, 9 Dec 2020 04:06:53 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [73.63.242.69] claimed to be jmbp.local To: Job Snijders , sidrops@ietf.org References: From: Joel Jaeggli Message-ID: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> Date: Tue, 8 Dec 2020 20:06:47 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C90C1512F36451871DFEDC4F" Content-Language: en-US Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 09 Dec 2020 04:06:57 -0000 This is a multi-part message in MIME format. --------------C90C1512F36451871DFEDC4F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/8/20 06:27, Job Snijders wrote: > Dear all, > > I propose some following text detailing a requirement for multiple > implementations to exist prior to RFC publication will be beneficial to > the working group. > > Our neighbors at the IDR working group are known to have a similar > requirement, which has dramatically improved the quality of that working > group's specifications and subsequently the deployability of IDR > technologies. I hope the same can be achieved in SIDROPS. So, back when we proposed that the sidr work was mature enough to spin up this working group to focus more on deploying it and less on what should go into the base specification. we figured this would be an involved and somewhat perilous transformation. This deployment must be properly handled to avoid the division of the Internet into separate networks. Sidrops is responsible for encouraging deployment of theSIDR technologies while ensuring as secure of a global routing system, as possible, during the transition. To my mind this includes addressing the question of how we collectively use it and consensus on how the moving parts are expected  to work. If we don't have a consensus reality, then how am I to expect that my network and yours will operate on the same information in similar ways. Inter-domain routing really is one of those places where the consensus reality had better be the market dominate one. > IDR participants track implementation reports & interopability testing > through internet-drafts or their Wiki > https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports > > Here are some examples of what reports can look like: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis > https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations > > Proposed text to add to the SIDROPS charter: > > """ > Specifications produced by the SIDROPS working group are intended to > address a practical need where a standard specification can assist > both vendors and consumers of cryptographic PKIX products to be > assured that a standards conformant implementation will undertake > certain functions in a known manner, and that, as appropriate, > implementations of the standard specification from different vendors > will indeed interoperate in intended ways. The SIDROPS working group > requires interopability reports from at least two different > implementations of a proposed specification, prior to publication as > RFC. > """ In the current charter sidrops does not intend to produce standards track documents, with IETF and working group consensus being output as BCPs when the weight of demonstrating consensus is required.  That is a challenge in the case of for example https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ And one that should probably be more explicitly included if we are amending the charter. If we take on the protocol specification maintenance here there absolutely we should require interoperable implementation for standards advancement. requirements text around interoperability testing is good, but it needs be expanded a little to let us do the protocol maintenance, which we generally would have ascribed to IDR under the original charter. I hope the current AD will revist this. joel > > Kind regards, > > Job > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --------------C90C1512F36451871DFEDC4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/8/20 06:27, Job Snijders wrote:
Dear all,

I propose some following text detailing a requirement for multiple
implementations to exist prior to RFC publication will be beneficial to
the working group.

Our neighbors at the IDR working group are known to have a similar
requirement, which has dramatically improved the quality of that working
group's specifications and subsequently the deployability of IDR
technologies. I hope the same can be achieved in SIDROPS.

So, back when we proposed that the sidr work was mature enough to spin up this working group to focus more on deploying it and less on what should go into the base specification. we figured this would be an involved and somewhat perilous transformation.

This deployment must be properly handled to avoid the division of
the Internet into separate networks. Sidrops is responsible for
encouraging deployment of theSIDR technologies while ensuring as secure
of a global routing system, as possible, during the transition.

To my mind this includes addressing the question of how we collectively use it and consensus on how the moving parts are expected  to work. If we don't have a consensus reality, then how am I to expect that my network and yours will operate on the same information in similar ways. Inter-domain routing really is one of those places where the consensus reality had better be the market dominate one.

IDR participants track implementation reports & interopability testing
through internet-drafts or their Wiki
https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Here are some examples of what reports can look like:

    https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis
    https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations
    https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations

Proposed text to add to the SIDROPS charter:

"""
    Specifications produced by the SIDROPS working group are intended to
    address a practical need where a standard specification can assist
    both vendors and consumers of cryptographic PKIX products to be
    assured that a standards conformant implementation will undertake
    certain functions in a known manner, and that, as appropriate,
    implementations of the standard specification from different vendors
    will indeed interoperate in intended ways. The SIDROPS working group
    requires interopability reports from at least two different
    implementations of a proposed specification, prior to publication as
    RFC.
"""

In the current charter sidrops does not intend to produce standards track documents, with IETF and working group consensus being output as BCPs when the weight of demonstrating consensus is required.

 That is a challenge in the case of for example

https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/

And one that should probably be more explicitly included if we are amending the charter. If we take on the protocol specification maintenance here there absolutely we should require interoperable implementation for standards advancement.

requirements text around interoperability testing is good, but it needs be expanded a little to let us do the protocol maintenance, which we generally would have ascribed to IDR under the original charter.

I hope the current AD will revist this.


joel


Kind regards,

Job

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--------------C90C1512F36451871DFEDC4F-- From nobody Wed Dec 9 05:24:23 2020 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 F35FA3A1659 for ; Wed, 9 Dec 2020 05:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QbOAX5bTcGy for ; Wed, 9 Dec 2020 05:24:18 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 683433A1658 for ; Wed, 9 Dec 2020 05:24:18 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id F3FC2600E6; Wed, 9 Dec 2020 13:24:15 +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=1607520255; bh=TVtZfcLAkI9nX2E5VxGRAtWQBsL2pXHIFVNV37TzLdc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=X8pbFUiNXIq7yk7+yVbsQyOb54U09SGVji1uEcCUr45sV9sB+xEkaXzMwNvZKEWc9 WzmGG23pGBTW5HZ1kkiezisogEe1KTg5ym/mybSKyzPwZR6hd6iLhDqCjXEchJw4Wn d/SP38e6V2+43JgDrwsDj0mMdGfVThHM/DLTNUWHdGSGr7ZSDRAvdGhEXKxkdF2nUv BrhSI7Y1e6VXbw8mIKmzqj8kTwEwoHX8o5wNrzMR/tPOUQgdwVzPOSeiLXi40jgWz8 dT5ljGUi6xhvlaUYdBtCLAAIbEE+gGtyAtzv4e3nKmz+ebyvztE47igWKWzHUGw109 k6axYPs065PGA== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> Date: Wed, 9 Dec 2020 14:24:12 +0100 Cc: Job Snijders , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl> References: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> To: Joel Jaeggli Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 09 Dec 2020 13:24:22 -0000 Hi, > On 9 Dec 2020, at 05:06, Joel Jaeggli wrote: >=20 >=20 > On 12/8/20 06:27, Job Snijders wrote: >> Dear all, >>=20 >> I propose some following text detailing a requirement for multiple >> implementations to exist prior to RFC publication will be beneficial = to >> the working group. >>=20 >> Our neighbors at the IDR working group are known to have a similar >> requirement, which has dramatically improved the quality of that = working >> group's specifications and subsequently the deployability of IDR >> technologies. I hope the same can be achieved in SIDROPS. >>=20 > So, back when we proposed that the sidr work was mature enough to spin = up this working group to focus more on deploying it and less on what = should go into the base specification. we figured this would be an = involved and somewhat perilous transformation. >=20 > This deployment must be properly handled to avoid the division of > the Internet into separate networks. Sidrops is responsible for > encouraging deployment of theSIDR technologies while ensuring as = secure > of a global routing system, as possible, during the transition. >=20 > To my mind this includes addressing the question of how we = collectively use it and consensus on how the moving parts are expected = to work. If we don't have a consensus reality, then how am I to expect = that my network and yours will operate on the same information in = similar ways. Inter-domain routing really is one of those places where = the consensus reality had better be the market dominate one. >=20 >> IDR participants track implementation reports & interopability = testing >> through internet-drafts or their Wiki >>=20 >> = https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports >>=20 >>=20 >> Here are some examples of what reports can look like: >>=20 >> =20 >> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis >>=20 >> =20 >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementation= s >>=20 >> =20 >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20imple= mentations >>=20 >>=20 >> Proposed text to add to the SIDROPS charter: >>=20 >> """ >> Specifications produced by the SIDROPS working group are intended = to >> address a practical need where a standard specification can = assist >> both vendors and consumers of cryptographic PKIX products to be >> assured that a standards conformant implementation will undertake >> certain functions in a known manner, and that, as appropriate, >> implementations of the standard specification from different = vendors >> will indeed interoperate in intended ways. The SIDROPS working = group >> requires interopability reports from at least two different >> implementations of a proposed specification, prior to publication = as >> RFC. >> """ >>=20 > In the current charter sidrops does not intend to produce standards = track documents, with IETF and working group consensus being output as = BCPs when the weight of demonstrating consensus is required.=20 >=20 > That is a challenge in the case of for example >=20 > https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ >=20 > And one that should probably be more explicitly included if we are = amending the charter. If we take on the protocol specification = maintenance here there absolutely we should require interoperable = implementation for standards advancement. >=20 > requirements text around interoperability testing is good, but it = needs be expanded a little to let us do the protocol maintenance, which = we generally would have ascribed to IDR under the original charter. >=20 > I hope the current AD will revist this. I believe that it would be good to extend the sidrops charter to allow = it to produce standard tracks documents *and* require two = implementations for that track. While in case of ASPA one could still argue that this could also be = discussed in IDR (or perhaps just be discussed there as well), I think = there is other work here that is not suitable for IDR. It may not be = routing related (see the RTA document for which adoption was requested), = or talk about the RPKI infrastructure itself (mft-bis / deprecate-rsync = / ..future work). Tim >=20 >=20 >=20 > joel >=20 >> Kind regards, >>=20 >> Job >>=20 >> _______________________________________________ >> Sidrops mailing list >>=20 >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >>=20 >>=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Dec 9 15:12:01 2020 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 0E5D73A0045 for ; Wed, 9 Dec 2020 15:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 KQMRhNqKQHeO for ; Wed, 9 Dec 2020 15:11:58 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 4F2513A003E for ; Wed, 9 Dec 2020 15:11:58 -0800 (PST) Received: from jmbp.local ([73.63.242.69]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id 0B9NBu7q096582; Wed, 9 Dec 2020 23:11:56 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [73.63.242.69] claimed to be jmbp.local To: Tim Bruijnzeels Cc: Job Snijders , sidrops@ietf.org References: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl> From: Joel Jaeggli Message-ID: <430ac11d-c2ce-0035-34f1-7a3a951f0ae6@bogus.com> Date: Wed, 9 Dec 2020 15:11:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 09 Dec 2020 23:12:00 -0000 On 12/9/20 05:24, Tim Bruijnzeels wrote: ... >> In the current charter sidrops does not intend to produce standards track documents, with IETF and working group consensus being output as BCPs when the weight of demonstrating consensus is required. >> >> That is a challenge in the case of for example >> >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ >> >> And one that should probably be more explicitly included if we are amending the charter. If we take on the protocol specification maintenance here there absolutely we should require interoperable implementation for standards advancement. >> >> requirements text around interoperability testing is good, but it needs be expanded a little to let us do the protocol maintenance, which we generally would have ascribed to IDR under the original charter. >> >> I hope the current AD will revist this. > > I believe that it would be good to extend the sidrops charter to allow it to produce standard tracks documents *and* require two implementations for that track. > > While in case of ASPA one could still argue that this could also be discussed in IDR (or perhaps just be discussed there as well), I think there is other work here that is not suitable for IDR. It may not be routing related (see the RTA document for which adoption was requested), or talk about the RPKI infrastructure itself (mft-bis / deprecate-rsync / ..future work). I tend to agree, charters are meant to be amended when taking on new work. > > Tim > From nobody Wed Dec 9 15:22:58 2020 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 8387C3A0127 for ; Wed, 9 Dec 2020 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43gxbs8SCG1O for ; Wed, 9 Dec 2020 15:22:53 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 B89B93A00D9 for ; Wed, 9 Dec 2020 15:22:51 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id s11so4518256ljp.4 for ; Wed, 09 Dec 2020 15:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zGqOLCdndYxjC34PqVNqfvIQhJiFXZrFYHWhatl0oKI=; b=NqbxCkGziGTvXzx7IVKcOz4KPJAKra8l90BCGYgPQvv6HkgVPpWHXW0djwFhdrZrDV 0Yfg5ZqQ29rzqyd1Lw/vi2dz/vU7lN7IJJ2JcTrOoU97ZZftet9BtGAeqToL18DFVyJW tQOI8T2j456N3fVkArEQdkd3SVAVmQvbx84BxXsMRT/+1IvJarn4OP9HvR4CFSYD2T+g f3dcBGgC28crtEatb5nsjoowMZr50dmzFojSnIys4KQCfqRbYsfPTsBaluETn66YUue2 klw82Sc9rvhhZVE+U1tiMOxVbV+fDJs98konHQy9QA25Rb6UPa6P4ApYikbDaLyBLJLe g7hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zGqOLCdndYxjC34PqVNqfvIQhJiFXZrFYHWhatl0oKI=; b=KBSANAoE6QO57uUibtQ/LiwjltviE4XEWfCGOWlq+tjS6LMrAAPuBrfVPCFHC1X441 pC5tLX+SVsX5AD9/np24iQ32IBS6v/Ox+DU0xI+5wF958HwgqAoTDd+oiWoLl15TrG6m 6X25uX66VB8ottiiAuGO4ngcMWFhtHCNdgS0l4upIDLiT8IResU0JrZAzysdIn93J+G0 Mshj/KOojiZ39/G7QGSXi13degDyTsNjT99OWeoKyKu8NIfok8X4MzDWZxN5jcpxyB5m A7jb+hzPWlou6YTMARe03EB3lIdBkIS6F/v/6bj+i5pocbkBZpsTmu+sh9fPyHjzr+JE VC5g== X-Gm-Message-State: AOAM530ziptbxbB9nwGxqeJoVd+titpIyD/Oxwq0D561+UPdC7ES3LF/ vUp++f/HftgQV54TGWMUTOS78TTAkVIRCnTTNr0pKQ== X-Google-Smtp-Source: ABdhPJwNaRbd4hFltbREIGUtfFFCsW30tDarzW6DvftzeEl5foRxEI3X3nYdRsCJvXIxYnHkCa5NFaiEvuYC8OuokbY= X-Received: by 2002:a2e:154c:: with SMTP id 12mr1958919ljv.210.1607556169801; Wed, 09 Dec 2020 15:22:49 -0800 (PST) MIME-Version: 1.0 References: <0aa464e4-2411-dbf1-ad44-d3c1d62a1046@bogus.com> <01A452C5-DDC8-4554-BA33-8A577E9B2566@nlnetlabs.nl> <430ac11d-c2ce-0035-34f1-7a3a951f0ae6@bogus.com> In-Reply-To: <430ac11d-c2ce-0035-34f1-7a3a951f0ae6@bogus.com> From: George Michaelson Date: Thu, 10 Dec 2020 09:22:38 +1000 Message-ID: To: Joel Jaeggli Cc: Tim Bruijnzeels , SIDR Operations WG , Job Snijders Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 09 Dec 2020 23:22:57 -0000 I truly think RTA has a case to be here. It's aiming to provide B2B pre-provisioning assurance, and other services to Operators who have delegated Internet Number Resources. That is why I asked for adoption here. If there is a better fit in an OPS WG, I'm happy to take it there if the AD or WG chairs prefer, but I think SIDROPS makes sense, not the least because "here" is where it was previously discussed and presented. Given that we're heading to a registry for .3letter code assignments for file types in Manifest and Repo, there is a meta-question lurking here: What process do people want to adjudicate additional types into the declared registry? Personally, I think where they don't go to routing, It is low pain to just admit an OID. If it has consequence in routing by intent, or would alter validation models, VRP and ROV Then it demands more discussion since it heads towards flag day consequences. If we made that a conditional bar, then we could defer a process to IANA as "if the submitter says its not routing, but is RPKI signed, then it should be ok" and have an evil-bit model. (I know, but.. ) I also truly believe RTA doesn't do this (alter routing directly). We did not expect it to alter validation outcomes for the issuing CA, we intended the objects to lie outside of RPKI Repo space except for the CA certificate chain issuing the RTA detached signature object. But, it MAY appear in a repo., so it SHOULD be understood to have no consequence for being unable to be parsed: it wasn't meant to alter validation in routing like that. cheers -G (sorry if this is deemed to be thread-hijacking) On Thu, Dec 10, 2020 at 9:12 AM Joel Jaeggli wrote: > > > On 12/9/20 05:24, Tim Bruijnzeels wrote: > > > > > ... > > >> In the current charter sidrops does not intend to produce standards tr= ack documents, with IETF and working group consensus being output as BCPs w= hen the weight of demonstrating consensus is required. > >> > >> That is a challenge in the case of for example > >> > >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/ > >> > >> And one that should probably be more explicitly included if we are ame= nding the charter. If we take on the protocol specification maintenance her= e there absolutely we should require interoperable implementation for stand= ards advancement. > >> > >> requirements text around interoperability testing is good, but it need= s be expanded a little to let us do the protocol maintenance, which we gene= rally would have ascribed to IDR under the original charter. > >> > >> I hope the current AD will revist this. > > > > I believe that it would be good to extend the sidrops charter to allow = it to produce standard tracks documents *and* require two implementations f= or that track. > > > > While in case of ASPA one could still argue that this could also be dis= cussed in IDR (or perhaps just be discussed there as well), I think there i= s other work here that is not suitable for IDR. It may not be routing relat= ed (see the RTA document for which adoption was requested), or talk about t= he RPKI infrastructure itself (mft-bis / deprecate-rsync / ..future work). > > I tend to agree, charters are meant to be amended when taking on new work= . > > > > > Tim > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Dec 10 15:30:57 2020 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 61F173A1341 for ; Thu, 10 Dec 2020 15:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=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 0PBTul8pwMa1 for ; Thu, 10 Dec 2020 15:30:54 -0800 (PST) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6671D3A133F for ; Thu, 10 Dec 2020 15:30:54 -0800 (PST) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id D22DA497EB; Thu, 10 Dec 2020 23:30:53 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id A56FC5640A60; Thu, 10 Dec 2020 18:30:53 -0500 (EST) X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24530.44968.720604.842924@oz.mt.att.com> Date: Thu, 10 Dec 2020 18:30:48 -0500 From: Jay Borkenhagen To: Job Snijders Cc: sidrops@ietf.org In-Reply-To: References: Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 10 Dec 2020 23:30:56 -0000 Job Snijders writes: > Dear all, > > I propose some following text detailing a requirement for multiple > implementations to exist prior to RFC publication will be beneficial to > the working group. > I support. I believe this change will help improve the quality of RFCs produced here by requiring thorough and detailed understanding by implementers before the drafts become RFCs. Thanks. Jay B. From nobody Fri Dec 11 12:09:08 2020 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 756E13A0EA6 for ; Fri, 11 Dec 2020 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 0C4TVZG8QF1P for ; Fri, 11 Dec 2020 12:09:05 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760080.outbound.protection.outlook.com [40.107.76.80]) (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 AFB303A0EAA for ; Fri, 11 Dec 2020 12:09:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ow5ffkvWNilu9HIE8fqs6mTMusW3OCbsdxMMNUs8SrfD06EuCnfghpexCDkzKI6fjBSYM8XhspUsA0jdZDS8xfx5n83Awcy583TuDi5YJVXXhlSKdqmqiu8IJVH7pOTRWeIwqFwb+iFoJ3UXvSi43svXyVjLAjrbWt7yHgJEG2K2g65hn3b6wXj0M8nGXtPKkqVLp18IuTkMc5x2l9YMfLBNvvLQxVvKRzx/Qw4L0jQdIajad+eg/VpUca9wGniPLg2CwtUhvDtAXBeFpt2xCkt1LCV/4HBwoy4KLsfDhTaDXWlwwolo4jfsopOE+Vmlx/WkK4lw1cInJsAQ0QCVhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=azZPU/fIozeA2LwwRego9sv2piWkSuhL6X0gwc0wizA=; b=C1s6Xr5vpL9WnZfETSeS0xT8RMluGVyI4yaPsOsMqGru8sOGvfik9yQCrFzfszb5U2arCv9zgM50n7Y7ZN+R4TG7iB3uP+AJwjMKTbyNUEOqNmkXEWHjopscqnzwLnyu3lGY5qqnN4zR6Sk7LVfKmmMWvErqGPpf/AmLYSZhVZIE3cK5XNeIeA/hQo4BvtsAiMs4NLGrnVhK4vpkqHPyYOSbGndB7yYtQ2x63ln4lKmw/URunltZaO1CbjZk47mGn+DJg/p+CdcI2vnuhncwkqCms83y0aT26I6Brt8rzTdWTYyYfrZQJSsQeJtJFxgq0eQ4EIA6vcfqFYLW/v10xg== 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=azZPU/fIozeA2LwwRego9sv2piWkSuhL6X0gwc0wizA=; b=rWQ9IAADOHXKsVk8RB0Aqq+2fZyk9En4BZGCKDfvVhkrNA7MSbrFRFNOaF3astD5GgkhL1pAsHyXlR8uZgTRC/6tXA6xeSYxtX1oN50auS0PE/OvzLWskCqAmVcwYWujVMb5RmardrOy7lMGtj7zqGktqrZoPl66WxLjedTE2rs= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by SJ0PR18MB4059.namprd18.prod.outlook.com (2603:10b6:a03:2ed::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.23; Fri, 11 Dec 2020 20:09:04 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4%4]) with mapi id 15.20.3654.015; Fri, 11 Dec 2020 20:09:04 +0000 From: Keyur Patel To: Job Snijders CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05 Thread-Index: AQHWzMrrGv2wDjNKKEmky0li8kGWWqnsHJqAgAW2pIA= Date: Fri, 11 Dec 2020 20:09:04 +0000 Message-ID: <2E4CC932-4C4C-4BCE-B25D-BB8001E3F583@arrcus.com> 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.43.20110804 authentication-results: ntt.net; dkim=none (message not signed) header.d=none;ntt.net; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed5db366-2116-4420-1333-08d89e109bdb x-ms-traffictypediagnostic: SJ0PR18MB4059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F++70aQL/hndP6TEUG3YD7wbQpGfboV8wQRx0S/j6uN4DUtaUoyX73ZSzbwjX1+R3AMxFH+8r8Ng2fJVP4S1ukbK8RpmJfveC+J9ZOkIUvEOT/0uqNO2B/9c3SYEjctjis/SCrivyYAG1YuN2gAA3wPJM0mi2XWjF8Zt2kCl/87JwNCAO7OsRVRZzNJZ2sRMqYp9VECrUw5MGzt4ln2lyr9ffkn0L837kjsx3lQ4Mft6fgjyD3Klq2lrQEfaPHt7IAuAz4j4VNFAfbaEET8IG5OmrAyQBZQFczyRahIvA9bJpHSZH2GPZuxPA/E6d/H0nEJMAg0MmprSmO5KPo4O1M4b8Qs99T5atgVO8ygZEvue9Y12+DjEVW5C2rX5FJiZOaF6FcldhbulY2bP3UHnkaBgUgiu0zMKC8Fba3ARGoyVB9kXLE9St+PKkS3yrhrjLKVPH12At085LaPMgDCtAw== 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:(376002)(136003)(39830400003)(366004)(346002)(396003)(66556008)(66574015)(71200400001)(966005)(86362001)(64756008)(478600001)(8676002)(8936002)(83380400001)(5660300002)(2616005)(4326008)(6916009)(6512007)(66946007)(66446008)(26005)(6506007)(33656002)(36756003)(6486002)(76116006)(66476007)(186003)(2906002)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WXpGTzRROVhyMWdnRXJRMzBlN1Nmc01UbmpGYlFTMmp2VUUycE1zOUJwVXZO?= =?utf-8?B?b0dSdU9JWnk4N0J3ZHZEeitKbmpCVTM2UERyNU5CRzZGQURVUzM1YXN2OEhu?= =?utf-8?B?QlYwb1FHK29iUEVuNzlwOCtLOWxWUTRWMElXS1lRTmVSNjZLL1l1ekR2Rk1Q?= =?utf-8?B?ZWxZakJMVGprQTBXOFc0RTY5U0ZZLysrMVl1S1krRUgySHpzLzFFOFFiWDZt?= =?utf-8?B?cVdVbk5aZG5lbm1BR3BoaXNWWnZuTW5vdGJseE5yVEd2enR2SkgxaEtkbjll?= =?utf-8?B?NFVGS2x2N3FYRUxkMjlPdTFzZzJrZFkwb0k4TlU1RnpqQW44Q3p4TjgzaENu?= =?utf-8?B?YmRmYkt5WU1zWUY4dlRxaTVDQUw0T1c3YzBFcWNmY1Z1aTg2b0tJTkxnK2o4?= =?utf-8?B?Q2htQk1BVHVLQndzVVhOUEhpbDN3ZmR4TTF2MXBpdkRiQkF0UDVhYkFxQU5S?= =?utf-8?B?S1VRKzVxOFpLbW1ONmVEcmdIRStXb0diVFphZzh2VnZhcnlDbjJXZ1ZteGNP?= =?utf-8?B?K3A3aGV5bEJLaDVjcVMya3FHM2RrbjVicVM1ODlwMld2bzhiQWR1OEIzYzlG?= =?utf-8?B?eHhEQWZtYUZTOE9CUFRCaHdlcysveElyT3dZa3A1VnJ4d3d6NmJRSUcrcDJW?= =?utf-8?B?dlcyditYU0QwN0ZYRktoQnI4bkUzUVFxWFhka1h3ek1QSFQwb2tVTEN5MU9m?= =?utf-8?B?Rkk2R0ZNTnpHUENsQjNiSEpzYmZGay9RQjVtSi9NZDVHamU5ekM0TVEvb2RW?= =?utf-8?B?cmxwd1lrYVJ1aTgrR2ZNMXVieHFuSDJoZEoxTWJLSE5jb2hMa3JiNmNpYVps?= =?utf-8?B?eG9nZURlU01qTUpicUlMM1JZK1MyT0wxTjhyNkRFYTN4ekxVc21oZ0dNcElr?= =?utf-8?B?dmt1UmpUeWhST3FIclhJdkVXQzF1NWYyTkljaEVUNytjMXZaZUpVc0I2Y2V5?= =?utf-8?B?SkU0LzdvajI2L3l6TzlZdnhkeWV2amMzZlBVVklVRFNzMVRweE9lSk1JNmRh?= =?utf-8?B?NGxDcW93MUZrOFdQenduTWhpYnUxcWNEdDhZWThCN0JMWTAzYVRMSTVrYWlT?= =?utf-8?B?dW5yelpRYUZsQldiS0RwT1Z4aHVDU3hud0UyMmNHRVVoSTdDaGN6WTZ4SnB6?= =?utf-8?B?dGpiS20raVFVWVZXQ091aVFVd2UwRzBjS1ExK0JCRk9adjZiYkFoZFVkUy9z?= =?utf-8?B?eldVdTNwa0tuTjNGY09sa0JQaGQvamxoSUN5UmkySGFmZVpvRWQwekdFaEhv?= =?utf-8?B?UDM2YTZ0RitYSTBDZUNZWnZkRk45YUVFN2p3UjVVYXoxQXdSRCs2YS9uY1Fo?= =?utf-8?Q?akD2tWwPBOwgZAbdD0+cml4ViYZy4a9q60?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 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: ed5db366-2116-4420-1333-08d89e109bdb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 20:09:04.3057 (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: T0cLYmNml7vNDneYIE8L6wi3KUS3qj5XlA4DfH8JAFyPQ69QORNVAcUoxDT6tlG0TvEdhYBMB4YcptCh9UHF8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB4059 Archived-At: Subject: Re: [Sidrops] Closed -- [WGLC] draft-sidrops-bgpsec-validation-signaling-05 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, 11 Dec 2020 20:09:08 -0000 RGVhciBKb2IsDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIGFuZCB0aGUgZGV0YWlsIHJldmll dyBvZiB0aGUgZHJhZnQuIENvdXBsZSBwb2ludHMgdG8gbm90ZToNCg0KLSBUaGUgd29ya2luZyBn cm91cCBjaGFydGVyIGRvZXMgbm90IHJlcXVpcmUgdXMgdG8gaGF2ZSBtdWx0aXBsZSBpbXBsZW1l bnRhdGlvbnMgYXMgb2Ygbm93LiBJIGRvIHNlZSB5b3VyIGVtYWlsIHN1Z2dlc3RpbmcgdG8gaW1w cm92ZS9tb2RpZnkgY2hhcnRlciBvbiB0aGlzIHRvcGljLg0KDQotIFRoZSBjaGFpcnMgY2xvc2Vk IHRoZSBXR0xDIGZvciB0aGUgZHJhZnQgb24gRGVjZW1iZXIgN3RoIDIwMjAuIFRoaXMgV0dMQyB3 YXMgc3VwcG9zZWQgdG8gYmUgY2xvc2VkIG9uIE9jdG9iZXIgN3RoLiBUaGUgYXV0aG9ycyBvZiB0 aGUgZHJhZnQgYmVsaWV2ZXMgeW91ciBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZC4gWW91ciBlbWFp bCBzdWdnZXN0cyBvdGhlcndpc2UuICBUaGUgY2hhaXJzIGhhZCBhIHF1aWNrIGNoYXQgYW5kIHdl IGJlbGlldmUgd2UgY2FuIHJlLW9wZW4gdGhlIGxhc3QgY2FsbCB3aXRoIGhvcGVzIHRoYXQgeW91 IGFuZCBvdGhlciB3b3JraW5nIGdyb3VwIG1lbWJlcnMgY2FuIGhhdmUgdGhlaXIgY29tbWVudHMv Y29uY2VybnMgYWRkcmVzc2VkLg0KDQpCZXN0IFJlZ2FyZHMsDQpLZXl1cg0KDQrvu79PbiAxMi83 LzIwLCAxMjo1NCBQTSwgIkpvYiBTbmlqZGVycyIgPGpvYkBudHQubmV0PiB3cm90ZToNCg0KICAg IERlYXIgS2V5dXIsDQoNCiAgICBPbiBNb24sIERlYyAwNywgMjAyMCBhdCAwNjo1ODoxNlBNICsw MDAwLCBLZXl1ciBQYXRlbCB3cm90ZToNCiAgICA+IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNh bGwgaXMgY2xvc2VkLiBBdXRob3JzIGhhdmUgYWxyZWFkeQ0KICAgID4gaW5jb3Jwb3JhdGVkIHJl bGV2YW50IGZlZWRiYWNrIHJlY2VpdmVkIGR1cmluZyB0aGUgbGFzdCBjYWxsIGFuZCBhdA0KICAg ID4gdGhpcyBwb2ludCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MgZnVydGhlci4gQWNj b3JkaW5nbHkgd2Ugd2lsbA0KICAgID4gcHJlcGFyZSBhIHJlcG9ydCBhbmQgZm9yd2FyZCBpdCB0 byBJRVNHLg0KDQogICAgSSByZWFsbHkgdGhpbmsgdGhpcyBpcyBhIGRyYWZ0IHdoZXJlIGl0IHdp bGwgcHJvb2YgdG8gYmUgdXNlZnVsIHRvIGFzaw0KICAgIGZvciBhbiBpbXBsZW1lbnRhdGlvbiBy ZXBvcnQgZnJvbSAqYXQgbGVhc3QgdHdvKiBpbXBsZW1lbnRhdGlvbnMsDQogICAgZGVtb25zdHJh dGluZyBpbnRlcm9wYWJpbGl0eSBiZXR3ZWVuIHRoZSB0d28gaW1wbGVtZW50YXRpb25zLg0KICAg IEluIHRoaXMgKGxlbmd0aHksIHNvcnJ5ISkgZW1haWwgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9zaWRyb3BzLzUtc0ZsM1JDem43eFEwWUZPRDMxQzU2S280by8NCiAgICBJ IHRyaWVkIHRvIG91dGxpbmUgdmFyaW91cyBwcm9ibGVtcyBJIHBlcmNlaXZlIHdpdGggdGhlIGRy YWZ0IGluIGl0cw0KICAgIGN1cnJlbnQgZm9ybSwgT2xpdmVyIHJlcGxpZWQgdG8gYWxsIHRleHQs IGJ1dCB6ZXJvIGNoYW5nZXMgd2VyZSBtYWRlIHRvDQogICAgdGhlIGRvY3VtZW50IGFzIGhlIGRp c2FncmVlZCBvbiBhbGwgcG9pbnRzIG9mIHN1YnN0YW5jZS4NCg0KICAgIE9saXZlciBjbGFpbXMg dG8gaGF2ZSBhbiBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiwgKHdoaWNoIEkgYW0gaGFwcHkN CiAgICB0byBiZWxpZXZlISksIGFuZCBwZXJoYXBzIHRoZXJlIGlzIGFub3RoZXIgaW1wbGVtZW50 YXRpb24gd3JpdHRlbiBieQ0KICAgIHNvbWVvbmUgZWxzZT8gSGFzIGl0IGJlZW4gdGVzdGVkIGhv dyB0aGV5IGludGVyYWN0IHdpdGggZWFjaCBvdGhlciBpbg0KICAgIHZhcmlvdXMgY29uZmlndXJh dGlvbnM/DQoNCiAgICBJZiB0aGVyZSBpcyBhIHNlY29uZCBpbXBsZW1lbnRhdGlvbiwgdGhlIHdv cmtpbmcgZ3JvdXAgY2FuIGNvbmZpcm0NCiAgICB3aGV0aGVyIHRoZSBwcm9wb3NlZCBJbnRlcm5l dC1EcmFmdCB0ZXh0LCBPbGl2ZXIncyBpbXBsZW1lbnRhdGlvbiwgYW5kDQogICAgdGhlIHNlY29u ZCBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gYXJlIGFsaWduZWQgd2l0aCBlYWNoIG90aGVyIGFu ZA0KICAgIGJlaGF2ZSBpbiBleGFjdGx5IHRoZSB3YXkgb3V0bGluZWQgaW4gdGhlIGRvY3VtZW50 LiBBbiBpbXBsZW1lbnRhdGlvbg0KICAgIHJlcG9ydCBjYW4gYmUgYXMgc2ltcGxlIGFzIGxpc3Rp bmcgYWxsIElFVEYgbm9ybWF0aXZlIHRlcm1zIGNvbnRhaW5lZA0KICAgIGluIGRyYWZ0LCB0aGUg bGluZSBudW1iZXIsIGFuZCBhIHNob3J0IGNvbW1lbnQgd2hldGhlciB0aGUNCiAgICBpbXBsZW1l bnRhdGlvbiBpcyBjb21wbGlhbnQgKE1VU1QpLCBvciBhbiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp YyBjaG9pY2UNCiAgICB3YXMgbWFkZSAoTUFZKSwgb3IgYW55dGhpbmcgZWxzZSBvZiBub3RlLg0K DQogICAgU3BlY2lmaWNhbGx5IGluIHRoaXMgZHJhZnQsIEkgcmVhbGx5IHNlZSBwb3RlbnRpYWwg Zm9yIGEgcmVwZWF0IG9mIHRoZQ0KICAgICdJT1MgWEUgLyBvcmlnaW4gdmFsaWRhdGVkIGV4dGVu ZGVkIGNvbW11bml0aWVzJy1wcm9ibGVtIHRoYXQgbWFueQ0KICAgIG9wZXJhdG9ycyBzdWZmZXJl ZCBmcm9tIHdoZW4gdGhleSB0cmllZCB0byBkZXBsb3kgUlBLSSBPcmlnaW4gVmFsaWRhdGlvbg0K ICAgIGluIHRoZSBCR1AgZGVmYXVsdC1mcmVlIHpvbmUsIGFuZCBJIGRvIG5vdCB3aXNoIGEgc2lt aWxhciByZXBlYXQgb2YNCiAgICBldmVudHMgdXBvbiB0aGUgQkdQU2VjIHRlY2hub2xvZ3kgc3Rh Y2shDQoNCiAgICBIZXJlIGlzIG9uZSBvZiBtYW55IHJlZmVyZW5jZXMgdG8gdGhlICdzdGFuZGFy ZGl6ZWQnIGV4dGVuZGVkIHJwa2kNCiAgICBvcmlnaW4gdmFsaWRhdGlvbiBjb21tdW5pdGllcyBj YXVzaW5nIGlzc3VlcyBpbiBuZXR3b3JrcyBidWlsZCB1c2luZw0KICAgIG11bHRpcGxlIEJHUCBp bXBsZW1lbnRhdGlvbnMsIGhlcmUgaXMgb25lIG1haWwgdGhyZWFkLiBUaGlzIHdhcy9pcyBhDQog ICAgbXVsdGkteWVhciBwcm9ibGVtIGJlY2F1c2Ugb2YgdGhlIHNsb3cgdXBncmFkZSBjeWNsZSBv ZiBmaWVsZC1kZXBsb3llZA0KICAgIHJvdXRlcnM6IGh0dHBzOi8vd3d3Lm1haWwtYXJjaGl2ZS5j b20vY2lzY28tbnNwQHB1Y2submV0aGVyLm5ldC9tc2c2NzcxMC5odG1sDQoNCiAgICBJIHRoaW5r IHRoZXJlIGlzIHNvbWUga2luZCBvZiB0ZWNobm9sb2d5IHN0YWNrIGxheWVyaW5nIHByb2JsZW0g d2hlbiB0aGUNCiAgICBzdGF0ZSBvZiBhIHJvdXRlIGNhbiBiZSBtYW5pcHVsYXRlZCB0aHJvdWdo IG11bHRpcGxlIGNoYW5uZWxzLiBJbiB0aGlzDQogICAgY2FzZSAoMSkgc2lnbmFsZWQgdmlhIEJH UCBjb21tdW5pdHkgYW5kICgyKSB2aWEgc2lnbmFsbGVkIHZpYQ0KICAgIFJQS0ktVG8tUm91dGVy IHByb3RvY29sLCBpdCBjYW4gbGVhZCB0byBwcm9ibGVtcyBmb3IgcmVzb3VyY2UgaG9sZGVycw0K ICAgIHdobyBhcmUgdHJ5aW5nIHRvIHVzZSBCR1BTZWMsIGJlY2F1c2UgdGhlcmUgY2FuIGJlIHNp dHVhdGlvbnMgd2hlcmUNCiAgICB0aGVpciB3aXNoZXMgYXJlIG5vdCBleHByZXNzZWQgaW4gdGhl IHN0YXRlIG9mIHRoZSBuZXR3b3JrIGJlY2F1c2Ugb2YNCiAgICBpbnRlcmZlcmVuY2Ugb2YgYW4g dW5hdXRoZW50aWNhdGVkIEJHUCBjb21tdW5pdGl5LiANCg0KICAgIFNvIGZhciBJIHRoaW5rIHNv bWUgb2YgdXMgKHBlcmhhcHMgbXlzZWxmIGluY2x1ZGVkKSBoYXZlIGJlZW4gdG9vDQogICAgZm9j dXNzZWQgbW9zdGx5IG9uIHRoZSBzZWN1cml0eSBhc3BlY3QgKGFuZCBvZiBjb3Vyc2UgZXZlcnlv bmUga25vd25zIA0KICAgIGV4dGVuZGVkIEJHUCBjb21tdW5pdGllcyBhcmUgbm90IGF1dGhlbnRp Y2F0ZWQpLCBidXQgcGVyaGFwcyB0aGUNCiAgICAqc2VjdXJpdHkqIGFzcGVjdCBvZiBpdCBpcyBu b3QgdGhlIHJlYWwgcHJvYmxlbSwgdGhlIHJlYWwgcHJvYmxlbSBtaWdodA0KICAgIGJlIGhvdyBh biBhY2NpZGVudGFsIG1pc2ltcGxlbWVudGF0aW9uIG9mIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZh bGlkYXRpb24tc2lnbmFsaW5nLTA1DQogICAgY2FuIGxlYWQgdG8gb3BlcmF0b3JzIGhhdmluZyB0 byB0dXJuIHRoZSBmZWF0dXJlIG9mZiBpbiB0aGUgZW50aXJlIGZsZWV0DQogICAgb2YgZGV2aWNl cywgb3Igcm9sbCBiYWNrIHRoZSBzb2Z0d2FyZSAoYmUgZm9yY2VkIHRvIGtlZXAgcnVubmluZyBz b21lDQogICAgdW53YW50ZWQgdmVyc2lvbikuDQoNCiAgICBJZiB5b3UgYXNrIGFueW9uZSBpbiB0 aGUgZmllbGQgYWJvdXQgUkZDIDgwOTcsIHZpcnR1YWxseSBubyBvcGVyYXRvcg0KICAgIHdpbGwg dGVsbCB5b3UgdGhhdCBSRkMgODA5NyBpbiBhbnkgd2F5IGhlbHBlZCB0aGVtIGRlcGxveSBSUEtJ IE9yaWdpbg0KICAgIFZhbGlkYXRpb24gYXQgc2NhbGUgKHdoZXJlIHNjYWxlIGlzIDEwMHMgb2Yg cm91dGVycywgbXVsdGktY291bnRyeQ0KICAgIG5ldHdvcmssIG11bHRpcGxlIHZlbmRvcnMpLiBX aGF0IHlvdSAqd2lsbCogaGVhciBpcyB0aGF0IHRoZXJlIHdlcmUNCiAgICBpbnRlcm9wYWJpbGl0 eSBpc3N1ZXMgY2F1c2VkIGJ5IHRoZSB2ZXJ5IGV4aXN0ZW5jZSBvZiB0aGUgUkZDIHRoYXQNCiAg ICBjYXVzZWQgbWFueSBwZW9wbGUgZXh0cmEgd29yay4gSXQgYWxzbyBtZWFucyB0aGF0IGV2ZXJ5 Ym9keSBub3cgaGFzIHRvDQogICAgdGVzdCBlYWNoIGFuZCBldmVyeSBuZXcgQkdQIHNvZnR3YXJl IHZlcnNpb24gdGhleSByZWNlaXZlIGZyb20gdGhlaXINCiAgICB2ZW5kb3Igb24gd2hhdCBleGFj dGx5IHRoZSBiZWhhdmlvciBpcyBvZiB0aGUgcHJvcG9zZWQgYmdwc2VjIG9yaWdpbg0KICAgIHZh bGlkYXRpb24gc2lnbmFsaW5nIGRyYWZ0IGNvbW11bml0aWVzLg0KDQogICAgSWYgdGhpcyBkcmFm dCBpcyBwdWJsaXNoZWQgYXMgUkZDLCBJQU5BIHdpbGwgYXNzaWduIDMgY29kZXBvaW50cyB0byBi ZQ0KICAgIHVzZWQgaW4gc29tZSBmYXNoaW9uIGluIGEgZ2VuZXJhbGx5IHVuYXV0aGVudGljYXRl ZCBwcm90b2NvbCAoQkdQKSwgYW5kDQogICAgZnJvbSB0aGF0IG1vbWVudCBhbGwgb3BlcmF0b3Jz IGRvaW5nIFFBIHdpbGwgbmVlZCB0byBibGFja2JveCB0ZXN0IHRoZQ0KICAgIGJlaGF2aW9yIG9m IGV2ZXJ5IEJHUCBpbXBsZW1lbnRhdGlvbiB0aGV5IGNvbnNpZGVyLCB0byBzZWUgaWYgdGhlDQog ICAgaW1wbGVtZW50YXRpb24gZG9lcyBub3QgYWNjaWRlbnRhbGx5IGNhdXNlIGRldmlhdGlvbiBm cm9tICdsb2NhbCBwb2xpY3knDQogICAgaW4gYW55IHdheSB1bmRlciBhbnkgY2lyY3Vtc3RhbmNl cy4NCg0KICAgIFN0YW5kYXJkaXppbmcgY29kZXBvaW50cyB0byBzaWduYWwgY3J5cHRvZ3JhcGhp YyB2YWxpZGF0aW9uIHN0YXRlcw0KICAgIHRocm91Z2ggdW5hdXRoZW50aWNhdGVkIGNoYW5uZWxz IHJlYWxseSBjYXVzZXMgSW50ZXJuZXQgb3BlcmF0b3JzIGRvd24NCiAgICB0aGUgcm9hZCBkZXBs b3ltZW50IHByb2JsZW1zLCBmb3IgbXVsdGlwbGUgcmVhc29ucy4NCg0KICAgIEtpbmQgcmVnYXJk cywNCg0KICAgIEpvYg0KDQogICAgcHMuIEkgb25jZSB3YXMgeW91bmcgYW5kIHdldCBiZWhpbmQg dGhlIGVhcnMgYW5kIGVuZGxlc3NseSBhcmd1ZWQgaG93DQogICAgZ3JlYXQgUkZDIDc5OTkgd2Fz IGEgKmdyZWF0KiBpZGVhLiBBdCB0aGUgdGltZSBpdCByZWFsbHkgZGlkIHNlZW0gZ3JlYXQNCiAg ICBiZWNhdXNlIEREb1MgYXR0YWNrcyB3ZXJlIGEgYmlnIHByb2JsZW0sIGFsc28gbG90cyBvZiBu ZXR3b3JrIG9wZXJhdG9ycw0KICAgIHdpdGggYSAzMi1iaXQgaGFkIGRpZmZpY3VsdHkgcGlja2lu ZyBzdWl0YWJsZSBpbnRlci1kb21haW4gQkdQIHZhbHVlcy4NCg0KICAgIEJ1dCBpbiByZXRyb3Nw ZWN0IHdoYXQgSSBzaG91bGQgaGF2ZSBhZHZvY2F0ZWQgZm9yIGlzIGEgJ0JMQUNLSE9MRScNCiAg ICBQS0lYLVJQS0kgcHJvZmlsZSwgbm93IHJlYWxpemluZyB0aGF0IHRoZSBSUEtJIHZpYSBSUkRQ L1JTWU5DL1JSRFB2Mg0KICAgIG1pZ2h0IG1ha2UgZm9yIGdsb2JhbCBuZWFyIHJlYWwtdGltZSBw dWJsaWMgJ3JvdXRpbmcgaW50ZW50aW9uJw0KICAgIGRpc3RyaWJ1dGlvbiwgcmVhbGx5IHJpdmFs aW5nIHdpdGggdGhlIHNwZWVkIGF0IHdoaWNoIEJHUCB1cGRhdGVzDQogICAgcHJvcGFnYXRlIHRo cm91Z2ggdGhlIERlZmF1bHQtRnJlZSB6b25lLg0KDQo= From nobody Fri Dec 11 12:38:10 2020 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 E2C993A0EBF for ; Fri, 11 Dec 2020 12:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZX63xARvF9K for ; Fri, 11 Dec 2020 12:38:06 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700055.outbound.protection.outlook.com [40.107.70.55]) (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 73F5C3A0EC0 for ; Fri, 11 Dec 2020 12:38:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Upnevu3xIptBIABeqjCqHaRYvExXqYAthxgxU0/I2f9WpGS5iZCHhSvykh3b1mjtKzDhKD2Y1pETs7c6NdVS+LL0y4faztPOd/hLftKeYOS0VqwzLSNV8wK9lkyos6VDRA0kutDsr3HV0gQy6kv5maFV5+kb7iBEewOMi0l5xOlsBMkHv4KkPkJafRdhvFoMDbLMmrNyEi1yZKFPtCuKOh/OVnulOJQ8rkEtuI7ojH9IZ5EIWq9mcWtPwDVnIKT8gfC9rAkF+w2SYEa9EIgsD/yoQ3P7ys0L2halyyGdo1hFWbk4z4WVFHRPnZfGHuflR/U0Jtlpzh/AJycXkHZVKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GgyFBhnBY8kfxA/pzVLWrhh30BCxB4hQ2tZQiLSigsE=; b=Y5ggu0UUti4nekgsbXgVnLKMMpjPsOU6YNdsBKJg9OukBb7wd+9EKjMpFcivoMd7DQ+Set109TwdygetcJ01gFZNOPLLTWTNFbl62iJwDuO2Ei3xpHJv9RIxUoK2MLL305paXU9iht4PbaXFx4Y4iSqxJJH5+S/J+d8jJcuqF6Id+CEhfsEVbkChIndoOQxrDiLk59cgwqyuscsrip/8aElvzqIe51b9l4Kjv3Y9ZMSa+Ned1n9Xa10C/gm2lL2i8RrpX+GSeJPr75K3eu0OrnJjotbPimI11/OcV4xlv9a8UMRa4f+XK7Qp6TXOA/WoYelRiGZIEEVxgDWyZB6QFA== 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=GgyFBhnBY8kfxA/pzVLWrhh30BCxB4hQ2tZQiLSigsE=; b=bibOq4SgA9sHLgfqP04BDbU8m6UTm7ib6NGe+jbHz8j7N+Z4WaF+eHTy3JpQlUbvTPuQsmCxd1ib/sI83lY0DYLUy7EhmZLw9bU3SxXPVINyVtOHA5wIbAZ8HMTYCD/tVTprw4WzItqHXeqp2aNE/nZXbjrPQ39tWQgXXK64kmA= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by SJ0PR18MB3899.namprd18.prod.outlook.com (2603:10b6:a03:2ec::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.15; Fri, 11 Dec 2020 20:38:05 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4%4]) with mapi id 15.20.3654.015; Fri, 11 Dec 2020 20:38:05 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020 Thread-Index: AQHWz/2G0uiuHC7tYUqy/kTJhhgF2g== Date: Fri, 11 Dec 2020 20:38:04 +0000 Message-ID: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f41adce3-c2ad-4225-5eba-08d89e14a95f x-ms-traffictypediagnostic: SJ0PR18MB3899: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ey+it0U9VGzFZhGUHbnlX7aBI1yUksfBCwFep/lZ27nc2kGeauu9tLMvf7pJRsbq4YDJ+tNW/bfznPQvRA1pjWmB1kvWSsPE/D/iplPOyVZfR17OKfTRWVrG5bnnCuNkzQnqhAN6C7N/12mpQww/9MtZvrhIOgAPWEfa8GLTcSedQ3EXOrkMWoSleNL5EmiGUBFVICjQ578+wjmkI+DK1qwR15eqpSpqT1mQsKB0iRfC1HADRj7IbNElNuZ+FGE/sJKlLNLYfG0jRYmWIoMKI5Xcoo34MNL3NmiYxu/da4+HDIpwdhyEoCW7sodPVD5Dzy8OrxL4PcKQlmHowAR4eAXoVd+u/QIdn1yrKjhAdN0V8u111EBDpJnoBlRey5ABVyfIlYETDE6ePhV3NEiMviLZM3tLB4u3iGHi/WE9kOcJTIYrcskDy6YhdODpgzlCqoObZYNZCCYQufLhuokrgQ== 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:(366004)(376002)(136003)(39830400003)(346002)(396003)(33656002)(71200400001)(2906002)(6506007)(6486002)(4744005)(66446008)(86362001)(76116006)(8936002)(316002)(8676002)(166002)(2616005)(66946007)(26005)(36756003)(186003)(6512007)(66476007)(64756008)(6916009)(5660300002)(508600001)(66556008)(966005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SVhKSUVuN1dma29GM3FoWUlMRW1IUEVpMHl1ZEhZUzZJNXF6QW1zQTBCSkN0?= =?utf-8?B?Z2FCb3I2cGI2VGd0aHhPREZsTWZQTnBjdExvdDJZZDU0bEtjZWNZZnhjaWVT?= =?utf-8?B?aEplS015Mk1xdE43TkNPRUZncmp0eHJ2a1JLcC9TazdlMzhQV0VCUWJqak1Z?= =?utf-8?B?T3dYQkY4TVZYTTh3Ynd0Qjc2MzNFbjFQbzZ5ZFZYMEpyQVh0OW9rVEtDYjV0?= =?utf-8?B?S2dDRnU4T0ZQSFA0L2I4aVNKRGlzOEQ4eGZ3WDhuenB2SkNuSzhZQ25FaS9Q?= =?utf-8?B?UldkMDk4L0JHKy9ITm8wVis0VEh0MHMxVWJLMXBkSTNiV1JOeFpITjZJNmp0?= =?utf-8?B?NWdnUUNtVUg1a24vRjBOOU9vdUFUVGFFRzFkSHJaU0g5Z2c0VVVZeUZ5SWdB?= =?utf-8?B?WitjeEdqMncwV0hJY3cyQzQxNnhIdHdud0RLNjNnZm9tM21SNW5xMEVCaTRV?= =?utf-8?B?REZaK0lyRVhoZHRyQ0NiMU1FeUZBMXNQY2cwVVJQU3djdmo2ZHI2ZmRjRmk0?= =?utf-8?B?N1BPU2lxbUFTZVJlWVd3ejFBNmQrajZObU94c2QxRE9tdStqemJISDFhTm5F?= =?utf-8?B?MWVTYzV6RmZQelM1Y2hWSmJaazFLbzBINFlaRTFBbzFnV0lkcUo5b2JkakZP?= =?utf-8?B?b2RCZVkyRGhjVlVYRXYvTi90LzIzMFNqdkVCeDNCQVl6M0dvTG53VUVOZWsw?= =?utf-8?B?QTlGVDJRdWVSajZBbnlmVFQydVkyemFYNXkzdHYzUDNhVG9HVFV6Nml5QTdQ?= =?utf-8?B?cTVuaTRQUnRyTVpTdVU5MmtDUFdrTlA4QWp3VVF4Z1dyQWtoUFpQbGJMeWMr?= =?utf-8?B?Q25peDRteFdJbXBMcUZPMSsrTnQ4NzBMK3pBZGtGbUUrTXNpTjFSMThEaGxP?= =?utf-8?B?SW9FSWlvR01GcWYvQVdLQjA4YlFOOFdyY2VpWENYb2VHRTZwYUNQejhjS0F3?= =?utf-8?B?ckk1Ni9wYU1oNVcxN1dsMGxCcUNBTXFBMERHVjBEMXVWZ0g5aTEzN3dNOVY5?= =?utf-8?B?c2g3T1FHT0FlNng4T1U4aFQ3NTZnYVpMKzJrR2tvMmF6SkFYcnBMK2V4ZEk1?= =?utf-8?B?WDE5RldGc3NmWDJhTTkveno1OEVpbTdoVUZkL2h0QnUvc1VvSTRWZTRoWVV4?= =?utf-8?B?cDUwdHJnQ250OTBDd2s1SlpMZU5PQldBTmtLQjVFQUMrVDBKUXlUV0pObGky?= =?utf-8?B?bXdsV2hvaUtlaGgzOFZKTFVnK21tdCtMc1NpTktzaG9QaEVaVmNUODFqNmtR?= =?utf-8?B?ZzBkYllKNUtwVUszRk5vR2lnN3o1cmJLNVFBN3hiUnJpQm9ybksyeXRwT1hM?= =?utf-8?Q?kDkTTk9EyWD8zdUQjLEHCgWVNAIv5N9w2E?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_33FBAE0F1D614EC382D011807AC24687arrcuscom_" 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: f41adce3-c2ad-4225-5eba-08d89e14a95f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 20:38:05.0089 (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: a5R8/xOMjGJnw/DE7DNrLo6o5uuM9bRqYZmJPgGCqzO0MbC5LP5Z/CHJBqbp1cCNHy6nV/HYDwGIMMXKUxIqhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB3899 Archived-At: Subject: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020 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, 11 Dec 2020 20:38:08 -0000 --_000_33FBAE0F1D614EC382D011807AC24687arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmUtb3BlbmVk IGZvciBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wNSwg4oCcQkdQ c2VjIFZhbGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxp c3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBEZWNlbWJlciAyOCwg MjAyMC4NCg0KVGhlIGxhdGVzdCBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6ICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmct MDUuDQoNClJlZ2FyZHMsDQpDaHJpcywgTmF0aGFsaWUgJiBLZXl1cg0KDQoNCg== --_000_33FBAE0F1D614EC382D011807AC24687arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F6E769FDE680F498FEDD9D20DB27DB9@namprd18.prod.outlook.com> 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+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZS1vcGVuZWQgZm9yIGRyYWZ0 LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1LCDigJxCR1BzZWMgVmFsaWRh dGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlv dXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPndpbGwNCiBlbmQgb24gRGVjZW1iZXIgMjgsIDIwMjAuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgbGF0ZXN0IGRyYWZ0 IGNhbiBiZSBmb3VuZCBhdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTA1Ij5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDU8 L2E+LiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNocmlzLCBOYXRoYWxp ZSAmYW1wOyBLZXl1cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_33FBAE0F1D614EC382D011807AC24687arrcuscom_-- From nobody Mon Dec 14 22:45:50 2020 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 16D713A0AFA for ; Mon, 14 Dec 2020 22:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mFbayc9b; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vvwXmxcF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3gH9n8ccXoX for ; Mon, 14 Dec 2020 22:45:47 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7CD3A0AF3 for ; Mon, 14 Dec 2020 22:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26703; q=dns/txt; s=iport; t=1608014746; x=1609224346; h=from:to:subject:date:message-id:mime-version; bh=sORvTqp0j0p5qfZtTJ7mROVIhzsCxFhRP87bJxU7z6o=; b=mFbayc9bgcE9EFOV4r01IX2xsSuCNy/p/BcyuXzPkrWEgLAwEhzR4yFg LQ5k6RIqD3gn2MhaWxO83Jx/eTG5mg8APl1Jh4hdFR2c58CjyeGqoJA7S vtSQCIDE/WtHX34YdW5wXhTqtUtxkLupXCg/eH2Y6CBNx40n9p8UGMHoW w=; X-Files: image001.jpg : 11173 X-IPAS-Result: =?us-ascii?q?A0AoBQDrWdhfkIMNJK1igQmCci8jBih8Wy8uiAcDjVaUH?= =?us-ascii?q?IRxglMDVAQHAQEBCgECAQEjCgIEAQGESgKCAQIlOBMCAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBBQBAQEBAQGGOAELhXQBCQEMEwgBEgEBJQsIEQElAQEBCh4FEAEMA?= =?us-ascii?q?gwmAQQSAQYCBhSCOUsBglUDLgEOoT8CgTyIaXSBNIMEAQEFgTMBAwIGAYNbG?= =?us-ascii?q?IIJBwMGgTiCdYUyhSAbgUE/gRFDgxOCXQEBAgEWgUgrgx2CLIISAm8oHTQCF?= =?us-ascii?q?jmBB3CPX4pNgVKKWoNRhGIDXogiCoJ0h0QCgV1KkX6NY5RZAZIWgW6JGYF0l?= =?us-ascii?q?hoCBAIEBQIOAQEFgS4/IYFZcBWDJFAXAg2Je4QyDgmDToUUhUR0NwIGCgEBA?= =?us-ascii?q?wl8hxgsgT5cAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AriVAHhz3fUJ0ipvXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,420,1599523200"; d="jpg'145?scan'145,208,217,145";a="634170176" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 06:45:45 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BF6jjgm008496 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Dec 2020 06:45:45 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 00:45:45 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 00:45:44 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 01:45:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GZst7OplACjAuimSpVyZKB2Wd5ZljsQfE1iBgloj8Yv2xkH+hXUEMGdOzC3ZMPJrWjBBm4SMy+Y0R/AUyBOLCwc/lbG1sZOCuvP4rtpORYy7wcxglH7E//CQe5HwYJqbvnES1j/0ec7N2vtE9X5DIqgWNj93NaGG4OI9+8b4uios/pkjCr5OL5wAbuEm15Nuv6RnzQjBbnLYWT8Sn+Z2v4CtDYmPohOI/qGodeQ/VbV81Mimb7U4vOSboU09guj/O6gbxZvBbCtps+lwfOrEBkShTomnUCwHriJZtX3DsQK5L5/SJ8obh8RV1D8T3s2aPsqoKFCp99YAXLr2QfqEuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10BDRT0qd/UkvPccvokthOXJJbdOVSZ4dD01GJr5CYQ=; b=YNDjSBkddy13/Z1mYuhs55Y2SahO7HyzV12XO7dhAJW5Lt0gNg/rHW/vWgZ2Y9A7yBQEtxV5XOZjJMiDOwuVdFBT5pveEwlDYrRt2dWOTFgTlWh5vdUkOu56KlbBjEObfkfcL/ACHPL0E3ZqKITFgzzkGVZfPZpiZS3Mb008BiPEmG220xl/tPciqifRtv90xb+H1VlOqz5VEngWN0o6eQKLwDwRQFMSabg3BagPj4VNunrqabii5kD1ADwiyCPanETveJfYAVyNzqWPJLNVIjVL3UZ4hkpiIhc35WChQTQwME2UwWF3B3aT8etoRXgj+bnS1/aAkJlWaqwBoIWFBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10BDRT0qd/UkvPccvokthOXJJbdOVSZ4dD01GJr5CYQ=; b=vvwXmxcFUNrveSj9jtTg2OZuh8yyrVpoQJCDiq6mCX2fPx1fB+Y1NfjA1DU41A3B3RRY4BR8ogxCVCxCb8kFV9nj4krSdJp8yekR2ly9qZrtYoN0aiCiR/fWcOaRVY46xNVheT7SMYxQblm7FwOIzHdmnOA8WvIwnPfh6QIo0P8= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by SJ0PR11MB5135.namprd11.prod.outlook.com (2603:10b6:a03:2db::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Tue, 15 Dec 2020 06:45:43 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 06:45:43 +0000 From: "Jakob Heitz (jheitz)" To: "sidrops@ietf.org" Thread-Topic: ASPA: Is this really a leak? Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354w== Date: Tue, 15 Dec 2020 06:45:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:45ca:9d3c:5636:a4db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90019e4d-4171-4f6e-ce27-08d8a0c50b80 x-ms-traffictypediagnostic: SJ0PR11MB5135: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +JSDTdNudJi0BRKc6Qw5Z/AJ2ETWajmFx7mDskl9zzwOb1jibGln+9AB4pZCNgsYt5yZDpfjQb5pVxVbOOmO37LVID1UvqBaynrBYgwsq42JhYv4FQr0fWJEsJJOSTrUkLLuD0LZRMKzEihYtQKnt8kw4tg+6RAUzn1DxVa4yFEoq3qAm7zQPH9NtOwUK2jsZvMwyoVnoFJNtG1wWLKNDMIsE2Wux5auFL8V+JVm16WiTFczD+p/CNEc+spSUh6ksSQQHQrg7MfW0JnPhQjDon354nfxer1qloHsbCotBwL2jmeikbmt5QwdEl1Ce8ERrDyko7FHYx1KNf25xpKsAcOa4dNHfX819OdxWpLpxnK4Qnbb4X8kBviZp9n1ZDXuJoq5HiwdzZjuSyIkmMXFNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(39860400002)(366004)(346002)(136003)(83380400001)(66574015)(478600001)(52536014)(71200400001)(99936003)(7696005)(66446008)(86362001)(316002)(9686003)(76116006)(186003)(66556008)(66616009)(64756008)(6916009)(6506007)(166002)(55016002)(2906002)(5660300002)(966005)(33656002)(8676002)(66476007)(8936002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?oFAo3Z5PbAexrX0977mkN+KbLilnB6I9GaujFLlIHWi2h83Hwho2loW4Z8YB?= =?us-ascii?Q?MiESG+JQX9oapoN2O11WFDEKCBMiqzfVpU/PnEFVSRKfV1+NEhY8sznaYtki?= =?us-ascii?Q?XIkyLol16Ud9/LGoNvrqIRcaei1Zx7r12KUZuM+ugdqqdjC2dTovIlnRUnDF?= =?us-ascii?Q?o//6IjDDLJRwR8HH2EzzZ8nZ5sC75v1gtKyaulBSSfYQrVbCL3eBFYyGI6/H?= =?us-ascii?Q?ktj8PSSCwJH53Fa/xvxcLo3SnU6S+9tXk0XenTawB9H5MTQYfpJ8jWzieHve?= =?us-ascii?Q?zzRRapbWVJBvuccISRI/5fZi9OqCQEiPljM+juGzOuPjVSM71jl2Lm75tpUY?= =?us-ascii?Q?GD5amTbbX9BOhcbOFsI4hQ6y6v6qtkBYgaZllNWldxRmFCgsDaMorryfFKEs?= =?us-ascii?Q?yWpro0pHim3dBaaGyr0mwkQc+2UIPNqbXYBwZW58/cno2d+ZDtDMDMfF3S/T?= =?us-ascii?Q?P92enN22cXIUih014ZLdR5y3htZuXBp9SqonfvhA5WHMHmUZpWwSaB9vslJD?= =?us-ascii?Q?uI4n4CV/wRQXG6SkRwkuS7C/qY3HbDZ8xL4R8U0BxFZ+XvIL58If338fV/WW?= =?us-ascii?Q?R6n85Qp6ogbD3tVBDFYHhao/iYZM+gwGl3YDlFn8m8RteH4kwKbikcxxysR5?= =?us-ascii?Q?HxT6wQ2z3NXy3cLETDG6/VDYFBxu4UukMT/OpRwm6NL4zkIQbEQv7sr3pCuz?= =?us-ascii?Q?kWLtiFP19lMSnf/i3xvrlUAgtvkD/eeY/AS6zYWhEciS4z4GSHrswgs2JyZb?= =?us-ascii?Q?URN5KTE/afCO61ZqRWnq9biTQi+VRhcRmz7Wxtm8pOiNpYfNzptq/5siTV/O?= =?us-ascii?Q?RXzg+zj9DoAOxwka0iPMvR5MA/RPS6a75/V6qsB86zkcH2NWeh3+5M38nIY7?= =?us-ascii?Q?3CFkMfbHQ2rymVyXYPH9W3tfNCmOPpqN1jvmeI+l5NxXSzbWL7JYWd2kG3TU?= =?us-ascii?Q?NdF1y/ID7nQ6yPySaNJpRg+ZpofH3beqmvkFVGBvThKxCLO5M5BZ6VRLOOao?= =?us-ascii?Q?n8AqGqL1fROxdZAgZQ98VzS/JZ5ceKwWmouk9vBFLeKWBGE=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90019e4d-4171-4f6e-ce27-08d8a0c50b80 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 06:45:43.3997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b53pQM6IG1Djn9aKm1oUQ5AnEjR7MLsH50xOOjxJ+tajQZ340B9ccQ+Va5QweqxhESKbyHVu5PAblfbNt1oYGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5135 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [Sidrops] ASPA: Is this really a leak? 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, 15 Dec 2020 06:45:49 -0000 --_004_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_ Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_" --_000_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 finds suspected leaky AS paths. However, not all routes with suspected leaky AS-PATHs should be automatical= ly dropped, because some of them may not be unequivocal leaks. A BGP monitoring service should provide alerts to all suspected leaks. However, a router should automatically drop only unequivocal leaks. https://bgpstream.com/event/258771 is listed as a leak. [cid:image001.jpg@01D6D269.84D10C20] The as-path is the red line. The black line is a customer-provider relationship that exists between 37545 and 33765 as can be seen at https://asrank.caida.org/asns?asn=3D33765= . Therefore, 33756 is an authorized carrier of traffic for 37545 and ought to not be called out as a leaker. The route may not have taken the black line because of a temporary failure of that link. An apparently leaky detour should be allowed for a temporary failure as long as all the ASes involved are in the provider cone of either the source AS or the destination AS. All ASes in the provider cone of an AS are either directly or indirectly authorized to carry traffic for that AS. This is just one example. It's easy to find more. ASPA should add a section that defines an unequivocal leak, such that a BGP router can optionally drop only unequivocal leaks. The definition of an unequivocal leak is based on the provider cone. The provider cone of an AS consists of all the providers of that AS and all the providers of those providers and so on. All providers in the provider cone of either the originator or the receiver of the route are permitted (contracted, actually) to carry the traffic for = the route between these two ASes. Therefore, the AS-path is only invalid if it contains any ASes not within these provider cones. If valleys exist in the AS-path, but these valleys are entirely within these provider cones, then all the ASes in the AS-path are still permitted to carry the traffic and th= e route should be declared valid. Regards, Jakob. --_000_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06

finds= suspected leaky AS paths.

Howev= er, not all routes with suspected leaky AS-PATHs should be automatically dr= opped,

becau= se some of them may not be unequivocal leaks.

A BGP= monitoring service should provide alerts to all suspected leaks.

Howev= er, a router should automatically drop only unequivocal leaks.

=  

https://bgpstream.com/event/25877= 1 is listed as a leak.

<= /span>

The a= s-path is the red line.

The b= lack line is a customer-provider relationship that exists between

37545= and 33765 as can be seen at https://asrank.caida.= org/asns?asn=3D33765.

There= fore, 33756 is an authorized carrier of traffic for 37545 and

ought= to not be called out as a leaker.

The r= oute may not have taken the black line because of a temporary

failu= re of that link. An apparently leaky detour should be allowed

for a= temporary failure as long as all the ASes involved are in the

provi= der cone of either the source AS or the destination AS.

All A= Ses in the provider cone of an AS are either directly or indirectly

autho= rized to carry traffic for that AS.

=  

This = is just one example. It's easy to find more.

=  

ASPA = should add a section that defines an unequivocal leak, such that=

a BGP= router can optionally drop only unequivocal leaks.

=  

The d= efinition of an unequivocal leak is based on the provider cone.<= /span>

The p= rovider cone of an AS consists of all the providers of that AS and

all t= he providers of those providers and so on.

=  

All p= roviders in the provider cone of either the originator or the receiver=

of th= e route are permitted (contracted, actually) to carry the traffic for the

route= between these two ASes. Therefore, the AS-path is only invalid if it<= /o:p>

conta= ins any ASes not within these provider cones. If valleys exist in the<= /o:p>

AS-pa= th, but these valleys are entirely within these provider cones, then

all t= he ASes in the AS-path are still permitted to carry the traffic and the

route= should be declared valid.

=  

=  

Regar= ds,

Jakob= .

 

--_000_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_-- --_004_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=11173; creation-date="Tue, 15 Dec 2020 06:45:42 GMT"; modification-date="Tue, 15 Dec 2020 06:45:42 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAEEAawDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKz7zW7SzuDbEyzXIXd5MEbSOB74HH44pN2KhCU3aKuaFFYltcX+ t72SX+z7eORo2VMPMWU4IJOVX8M/WpzoFvLxd3F5dr/dmnO3/vlcA/jSvfY0dKMHactfLX/gfiaI ljZyqupYdQDzT6yTomhzFoEs7MSR4JEShZE9DleRTbWe40u+SwvpWmgmJFrcv94nGfLc/wB7AJB7 gHuOS/cbpRa9x69mvyNiiiiqMAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsbw +Fjk1OJ/+PoXjvKCOSG+4fptwB9D6Vs1n6jpjXMiXdnIIL+IYjk7MP7jjup/MdRSfc2pSVnBu1/6 +4z9OF09rerZkI02ozAykA+WobBYDucjA9zVrSPOZb+IXEssUcxjhklO5shRu57gNn8qh8PmR/Dp t4ZBFfRl0m3rny5iSWyO4ycj1BFXNJ0aHR4fLgluHBHzebKWBbOS2DwCSecVMVsb1pRXPF7300/H /L5mFp9veWelao8cEAvbRTBE0S7nY7FZ2J/iLE5wfpU+jpHrek39o1xdSCO5IiuJSdynAZGUnB44 PIHOe1bdhZtaNdM7BjPO0ox2BAAH6VXsEGlafNPqEkcTySvNK7P8oyeBn2XaPwpKNi54jmUrb3Vv 6/rcl0i9kvLQi4UJdQOYZ1HTeO49iCCPY1erL0TMxvb0qyrdz749w2koFVVODyM4J/EVqVcdjkrJ KbS/ry+QUUUUzIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiis3WbiQRR2Nq226vCUR h/yzX+N/wHT3IpN2LhBzkoozDpr67fz6la3ctiEYRQyQHHn7Dyzj+Jc5AHoDzzV8HX4uNum3AH8W 54ifww3860reCO1t44IVCxRKEVR2A4FSUlE2niG9LJpbX/z3Mgx69cnDTWFmvrGrTN+u0foaoXNl JpuoR3+qltStUUZmkxm2bP3hGBt24xlvvD6V01IyhlKsAQRgg96HEI4hxeyt5afjuAIYAqQQeQRS 1i2kh0O6TT7g/wChStizlJ4Q/wDPJj/6D6jjqOdqmncyqQ5H5PYKKKKZmFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUVDc3dvZx+ZdTxQp/ekcKPzNA0m3ZE1FZ0fiHR5W2x6pZM3oJ1/xrQVg6hlIKno R3pJpjlCUPiVhk88dtBJNM4SKNSzsegA6ms/SIZJ3k1S6QrPcgCNG6xRD7q/U9T7nHaopj/bmpG2 Xmws5AZz2mlHIT6LwT74HY1s0t2ay/dw5er39O3z3+7zCiiiqMAooooAiurWG9tpLe5jWSGQYZGH BrO0uaa0vJdKu5GlaNfMt5X+9JFnGCe7KeCe4IPetasnX1NvDBqcYJewfzHA7xHiQflz9VFS9NTe i+b92+u3r0/yZrUUisHUMpBUjII70MwRSzEBR1JNUYC0VUj1Swml8qK9tnk6bFlUn8s1bouOUXHd BRRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAqO4uIrWB5riRY4kGWZjgCpKyIYxqurzTzfNbWUnlwRnoZAPmc+pGcD0 wTSbNKcFK7lsiuNem1kmHw9HvUcSXk6MsUf+6Dgu3t09TU9t4dsbdjc33+m3WMtc3WGI+g6KPYAV nzSX+n3pF3M0CNI226bLQBSflXYuApweS3cdTmrI1FrhIIr2WHy/tboZgNiSLGM55J/iAHXsahPu dsoSirUtI+W7+fX009DWk06zmXbLaW7r6NGpH8qyZ/D01iGl8OXC2UjdbeTLW7e+3+E/7uPerkOo zXlnf3FqsbpGXS32nJkZRyfTluB9Pes0RPB4fl1SDVbq6uRblvNeTKA45Plj5RjnjHGOabszOkqk XZy6pWeqv5rb+tCTRr1dK8rTdQtJLO4lYkTM4eO4kPJIcfxE5OCB7V0NYw8L6a9rMrq88s8ZRria QySHPcE9OcEYx0qzod1JeaNbSz8zBSkh9XUlWP5g0RutGRiOSd6kO+v/AANWaFFFFWcoUUUUAFIy hlKsAVIwQe9LVXULhre1Pl486RhHED/ePA/Lr9BQOKcmkjmm1U6DqraZYFJbeVCYVnm2pbMDhsse fL9B6qQPa3Z2+napdKNQvf7TuSCyoykQDGM7F+6cZHJJNT6R4eghs431C2SS880yl3wxU5wuD7AD 9fWpNMb7Ve3kk5eK+5QRsuPJiyQu3PBzjJI78dqySfU9KpUhaXs73W77vv6d9r9dye9sdIitCLy1 s1g6YeNQPoPf6VTtlurGBLjSZG1DTnGRbyPiRB/sM3Uf7Lfn2qa/to7OENDulv52EMMsp3MpbqR6 ADJ4x0q4oXT1s7aJR5J/cj1GFJB/8dNVbU51K0N736Pb+vO/crReI9PZxHcStZzH/lndoYj+Z4P4 E1pxyJKgeN1dT0KnIqK6eHYY5kEu5Swi27i2OvH4ispdG0ie1F7Hb/Ydy7jJA5hK+5KkD+lPUjlp yV7Nfj/l+puUVzmnav8AZ79LU3rX1nKQkc7rh43OdoJwA6tg4YdxjnNdHTTuRVpSpOzCiiimZBRR RQAUUUUAFVb/AFK202JXuXwXO1EUFnkb0VRyTUtzI0NtJJGgdlUkKWwD9T2rn9GgW1gOv61deZdX KDaTnbEjcqiL6nj3NS30N6VJSTlL7lu2Xhc63d/PBaWtnGen2py7n6qvA/76NO8nXj/y96cPb7M/ /wAXU9pqi3VyIGt7mB2QyIJkC71BAJHJ6ZHBweaueYnmeXuXeRu255x64oSv1HKcou3Kl8r/AJ3M vGvoeH0yUehWRP6mg32sRf6zSYpR3MF0D+jBf51rUUW8yfap7xT+9fk0ZB8R28P/AB/W95ZD+9PC dn/fS5X9a04Z4rmJZYJEljblXRgQfxFSVh3drHo2p2t5ZKIormdYLmFOEfdwr46Bgcc9wTmjVFKN OppFWf3r/gfiblFFFUc4UUUUAFFFMkmihGZZEQf7TAUAlcfRUE17a26hp7mGMEZy7gfzqi3ifR1b H9oQt7oSw/McUm0jSNKpP4Yt/I1aKqWmqWN//wAel5BMfRJAT+VW6d7kSi4u0lYKKKKBBRRRQAUU UUAFFFFABWRpsosdRutPuPleWZ7i3Y9JVY5YD3Uk5Hpg1r1WvrCDUbfybhCVBDKwOGRh0ZSOQR60 mjSnJK8ZbMpaxdZb7H5ogiMZluZj/wAs4umB7t09hn2pNCsUGjJFNbgW/mM1vDKuTHHuJQEHvj8q rTaRqC3EUrCx1Ew8RvdKY5AO2SuVJ99op66zqrXklqujo0saK7kXg2gHOOduc8HtUX1uzr5W6fJT a7vVL87Pr/XV2gafFazXjJG0UiXEsbheFkBberEdMgMBn8Kt6bbSL9sluIVi+0zF/KJDYXaF5xxk 4yfrUBvtbHP9jQH2W9Gf1SmNca7djyo7K3sM9Z5JhKVHsoHJ+pxTVkTNVJttta/3l/n+hT0/UZBY /wBm6awkm8x0t5DyscAbAkb2HQf3semTW9Y2cen2UVrDnZEu0E9T6k+5PNR6dpsOmQFIdzu53SSu cvI3qT/kDtVynFW3Mq9WMm1Da9/UKKKKo5wooooAKo6osgSC4ijaU20okMajJZcFTgeoDZ/Cr1FD 1KhLldyh/bNpJbNLav8AaXX/AJYxcyZ9Np5H44x3osLWYTS3l7t+0zALsQ5WJB0UHv1JJ7n6Cpbr TLK+Obq1hlb+8yAkfj1qodHltfm0y+mgx0imJmiPtgnI/Aip1Nk6bi4xdm+/+a/yLkloJdQhuXbI hRlRMdC2Mtn6DH4mpZIEllikbOYmLLz3II/kTWcNVu7b5dQ02cEf8tbUech98D5h+IpTr0R/1Vnq Mp/2bRx+rAUXQvZVXa34EuoRXDzxG2Xlo3j35H7vcV+b8gfxxTNXs4W0Ga3KsYkiwFDEZwOAfUe1 RSanqMi5t9L8hTx5l5OqAfgu4/ypH0rULyJ1vdVZVkBDRW0KKuD1GWDH9aT1NIpw5eaSVvn+V/0M /USLyd0j5kubiG3twOoWJ97v9Adwz7D1rqKz9O0W201zJGZJZioTzZm3MFHRR2A9gBWhTirbkV6k ZWjHZf1+iCiiiqOcKKKKACiiigCG8iM9lPEvV42UfiMVnaXbJe22l3rMGWG2AWMjIVyAC31GCPxN a9ZLRXOkXEstrC1xZSsXeBPvxMepQHqD1K9c5IznFS+5vSk3FxTs/wCkyvc3M2marPeXVo8ySMkM DxuvyocfKFJBLFsk47AelRLqkFtZ/b5rmJbm+kTYNwJSLd8qgey5J9yauaZ5Oo3LX73S3EsZKJGq lRbg9tp5DEdSfwwKmn02FLm0ktrWJCs++QogU42MMn8SKmz3R0c8E+Sa1W/y6a/Ig1eO6v0tfssL TWr5aWPzTCW6bQxIyF65HXp703w3HPCl9FK6GOO42RpHuKx/KuQCecZJ/XgVtVn6KhWwLspVpZpZ CCMHl2I/TFVbW5iqv7lwtp/T/wCAPkupDrMFrGRs8l5ZePcBf1z+VVtfO5dPhHLSX0OAOvynef0U 1YghkGt3kzodjQxIjeuC5I/UVj3lnP4n1AzWl9NZ29ixjimhAJkfpIRnsB8oPrupNuxdGMedNuyS 383/AMF/gdNVW61OysR/pd3BD7SSAH8qz4vC1lsxdzXl62fvXNy7foCB+lXbXR9OsiDa2NvEw/iW MA/n1p6mTVFdW/lb9f0Kv/CR2sv/AB5297ee8Nu23/vpsD9aim8TCyliGoaddWsUhwJGKNt5xlgr EgZI5963KQgHqM0WfcFOkn8Gnrr/AJfgY+o+ILaOFYrK5ilupjtQJ8+z1Ygc4H6nA71jTM1woTRh siZWe51i5jJJA67T1z154A7VvqVh8SyeaBunt1ELH/ZLb1Hv8yn/APVUfiXA0oM7R+SkqPLE7hBK gOSgJ454474x3qWm1c6aM4wlGEVv/XbW3npfcj0PSbFtKtbiTTLaOeSMO2U3Nk+7ZP5mtiJo2jUw lTH2KdKx7+f+2bWytraWWCK/Uu0gXa4jAyRg9CcgfTNGmo9trMlpb3c9xbRQ/vRLtIjfI2qpAGOM 5Hbj1pp20RlUhKonOT11dtdr/wCehNqcOjSyBNQgt5Zj28vc4HrwMge9Qf2ZbQXa2tnq13azshdY BOJPlHfa+7iqOuWcC+J7KWDKXE7ItxIucxqG+RsjuxBTnqD7VPaSW8KXWuzRmS5luHihC/eZdwjR B9SoP4k0r6myi1Ti1J6rbz6abdy55Gu2/wDq7yzux6TQmNv++lJH6Uf21PZuo1exNrGxCi4SQSRA npuOAVz6kY96NOeefUL65vAoeDbAqIxKr8oduuMk7gM4/hq1ayJqelRfaljb7TAGki7FWHTHpzim vIxlZfHFPbbTfXS2n4F2isjQpJIPP0u4ZnlsiAjt1kiP3G+vBU+6+9a9UndHPUhyScQooopkBRRR QAUUUUAISACScAd6zNABmtJb9wd17KZhnqE6IP8AvkD86XX5GXSngiOJbplt0PoXOCfwGT+FaEUa QxJFGAqIoVQOwHSl1Nvhper/AAX9fgPooopmIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBU1S0N/p lxbqdruh2E9m6g/ninadeC/sIbgLtLr8y/3WHDL+BBH4VZrJVv7K1dkbi0vn3IeyTdx/wLGR759R SejubQ9+Dh1Wq/X+vI1qKKKZiFFFFABRRRQAUUUUAFFFFAFC/wBLt7lvtJdra5jHFzEdrKPc9CPY 5FZmmatq8tp9qks0vLRmPlSRHy5XQdH2Nxz1HI47c1PqBOt3zaVET9kiIN84/i7iIe56t7cd62lU KoVQAAMADtUWu9Dqc+SmozV2+/Rfnr/W5nw6/pswIa7jhkX70U58t1PurYNMfxHpavsjuluH/u26 mU/+Og1fmtoLjHnQxyY6b1Bx+dPSNIlCxqqqOyjAqtTO9Hs/vX+Rjyy6hrI8mGCbT7Rv9ZPLhZWX 0RRnbn+8eR2FattbxWltHb28axxRqFRF6ACpaKEiZ1OZcqVkFFFFMzCiiigCtf2Md/b+W7MjKweO RDho2HRh/nnpWdJdy2hQa1ZpKkRyl5FHuUe7LyUPuMj3raopNGsKtlytXX9bf1YqSwWWr20bNsni zuR0f9QwNS21rDZwiG2iSKMdFUY/GqNzo/lStdaXItpcnl1x+6m/31/9mHP16VUtPE8s8s0Umk3Z eHbuaDEinOeRkg4xyMjvSuk9TT2cpx/du6XTt/XkTPpFxJqskryRfZnnSdiAfMJQDanptBGc+/41 Su9Eg/t6zthc3cVu4muFiWcqokBH3e4++x4NaQ1qU/d0jUj9UjH83prajeSFWTQ7oleVMkkS4/8A HjUtRZrCdaL3W1t0ulht1oR8iY2d3dxzOmMeeQHYDAZjgnOAMkdcVa0vSLXSbdY7eNQ4QK8h5Z8D uev4VB9v1dvu6Og/37tR/IGkb+3bgbQLGzU9XDNMw+gwoz9aem6REvauPLKSt6r9LiQ/v/F11JHy tvaJDIf9osWA/AYP/Aq16q6fp8Wm23kxF3LMXkkc5aRj1Yn1q1VJGNWSlL3dloFFFQXd7BYxCS5k CKTtUdSx9AByT7CmZpNuyJ6K52fxnbRTyQpZX7tEcSYhOF74Pvgjg1ZXxXpq4+1NPZ5GVN1A8Yce oJGKnnj3N3hK6V+VmzRWN/wlFm/Nvb39yn9+GzkK/njmk/4SqwT/AF8d9APWWzlA/PbRzR7i+rVv 5X9xLcf6X4jtYRylnE1w/pvbKJ+m+tWuf8N6nZXf2mX7Zbve3MzO8ayAsFB2oMdcbQPzNdBRF3Vw xEXCSg1tp/n+IUUUVRgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFQ3VrFe20lvcJvikGGH+eh96m ooGm07ozdMuZUlk0+8cvcwAMsh/5bRno317H3+orSrL1r/Rhb6ko5tHzJjvE3D/lw3/Aa0wQQCDk HvSXY0qJNKa6/n/WotFFFMyCiiigAooooAKzdWv5YjHZWO039xnZkZESjrI3sPTucCp9Rv0060Mz qzuSEjiX70jnoo9z/wDXqLStPe2Elzdssl9c4aZx0X0Rf9kfrye9S9dEbU4qK9pL5Lu/8l1+4n0+ wi02zS3hyQMlnY5Z2PJZj3JPNWaKKoylJyd3uFFFFAgooooAKKKKACiiigAooooAKydAb7St9fD7 l1cs0Z9UUBAfx25/Gn+IbmS20aYQHFxNiCH/AH3O0H8M5/CrtpbR2VpDbQjEcKBFHsBip3ZsvdpN 93b5LV/oTUUUVRiFFFFABRRRQAnSsrSo/wC0Jjq04yZAVtVP/LOL1+rdT7YHatR1DoynowwazdCd n0KGHIWa3U27Z52sny/0z+NS9zaGlOTXkvlqJPrUEV3LaWFvJeXin97HAAAhx/GxwBx+PtV77Tss TcXUZgCoXkViDswMnkcVz8VjfeF9Na5F5FOocSXEfk7fNLEBmDZJ3HPfI7YFafiTLaHPCp+a4KQD /gbBf5E0k3Z3Np0oOUYw1Tdr638/6/Et214stpbTTAQNcBSqM3OSM7fc4qp/wkNnJd/ZrYT3Ugfy 2MELMqHODl/ujHfmmatbzLeW13FbvcxQxyRtFEwV03Y+dc4BIAI6554qJ5LR/B12ml5SKK1kjVMF WQhTwQeQ315obYo0qbSlbf7lr16/lcv3uk6fqceLy0gnB6MyjI9weo/Cs5bHVNKydKuhfWynH2W7 f5l9ll6/g2frWrp+waba+UAI/KXaF6AYGK5WyeeO80vR7uK8tnaSaa4ZAQs753Ah16rlsnp0ANKV i6CnJSje6XR66Wd3+HTvudFp2sx38zW0kE1peIu5oJ1wcdMqRwwz3BrRrH1sCO90i5UfvEuxHn/Z dWBH8j+ArYq12Zz1YxspRVkwooopmIUUUUAFFFFABRRRQAUUUUAFFFFABVW/1K00uDzr64SFCcDc eWPoB1J+lWqy9RUX9/Dp+P3YXzrg/wCznCr/AMCOc+ykd6TehpSipS97bqVk1PU9Wh3afpkcdrIv yy30m3ep7+WATg+5FUoNN12zMNnLfymzACJJZxR5j9m35OAOhGenNbt3qcNpMtusc085XcIYE3EL 0yewH1IpbHUVvXmjMMsE0JAeOUDIyMg5BI/WpsnuzpVWUItxglHz1+ev/DFP+y9WhP8Ao+tu4/u3 Nuj/AKrtNH2bXzwdRsAPUWjZ/wDQ62KKfKjH6xLsvuX+Rj/Y9dTldVtJD/dezIH6PR53iCH79pp9 wP8ApnO8Z/Iqf51sUUcoe3v8UU/lb8rGQNR1luBoig+rXi4/QE/pQZPEEn3YNMhH+1K7n9FFa9FF vMXtY9IL8f1Zzco1Oy1JdS1W3iu4Yk2obTdm3B+8+w/ezxkg5AHA610FvcRXVuk9vIskUg3K6nII pVmjeR0R1Z4yA6g5K5GRn04rJsUGm+IbiyiGLa5i+1Rp2Rw2HA9jlT9SfWjYuT9tHVWaXyt/Wv8A wTZoooqjmCiiigAooooAKKKKACiiigAooooAx77/AEzxJp9r1S2R7uQe/wBxP5sfwrYrH0X/AEq/ 1PUOqyTeRGf9iPjj/gRetipj3N6+jUOy/wCC/wAXYKKKKowCiiigAooooAKybqG406+e+somnhmx 9pt1+8SBgOnvjAI7gDuOdaik1cuE+RmDDJba1fgPqfmRRuJFsWQRsrDkbwfmIB5AwPxrZuLaK5EY mXcI3Ei89GHINRXmm2eoqFvLaKYDoXUEj6HtVP8A4Ry0UYhnv4R2Ed5IAPw3UrNGznCVtWreS/S3 5GnKHaJxEwRyDtYjIB9cd6rWOnR2dk1uzGYyFmmdxzIzfeJ/w7DAqp/YU0fNtrGoxt28x1lX8QwP 86QT67ajbJaWl8B0eGUxMfqrAj9aL90JQuuWE1+X5/5mrDClvBHDEoWONQqqOwHAFZ9/bSNrWm3Q AENus3muWACgqMfyqP8AtDWW5XRUA9HvFB/RT/OmDSLnU3WTXJY3iBytlDnygf8AbJ5c/XA9qTd9 EVCDptynJdeqb1Vuj/MFl/t2/tpYF/4l9rJ5omP/AC3fBA2/7IyTnucYrapAAoAUAAcAClqkrGNS fNZJWSCiiimZhRRRQAUUUUAFFFFABRRRQAUUUUAFZmj/AL83d6cE3E7BT/sJ8g/kT+NaVZ3h0Y8P WPvCrH6nk0nuax0pyfovzf6In1K8GnWE115Lysi8RxrlnPQAY9zVDw/NGRMkxl/tCU+fOJYmjJzw NoP8IwAPpzyauX2rQWTCJQ092/8Aq7eLl2/wHucCmadZTrPJe37q13KoXYn3IUzkKPX3Pf2pdTSK UaL5la+3n/wP66GXp9kzeJpHhurmZbUt9omklJEjtysQX7oCggnA649609SuNQM8dppsIV3Xc91K uY4l9h/E3t+JqjcJNoeow/Y7gSR39181m6AnLcu6sOQAMk5yO3GRW+SAMngClFaWLrT96M91bT+v X5dOhzV7bXtlfWEMOsXs95cTAsjhBH5a8uSoXgY469SK3b++i060a4m3EAhVVRlnYnAVR3JNZuhA 6hcXGtSA/wCk/u7YH+GBTwf+BHLfl6VW1C8mvfE8NtYwJdf2ehmlR5diiRuF5wckDd+YpJ2V+5co e0moS+ytdl8vyXqaiXstnpsl5rBigx8xRMt5Y7Ln+Jvp1JwKha2utSRLq3u73TmkXDQuqNxk4O05 2n6fjShYfEukRO3nW+JQ6lGG5XRuoPIIyOD0NZuqW02mCFbPVtQl1CaQLBDJIrq/I3Fl2/dAySeK bf3E04Jy5VpK/a6/X5tm7p+nQaZb+TbhvmYu7udzyMerMe5NU7n/AJGqw/69Z/8A0KOtasa3lXUv ErTwENb2ULQmQdGkYgsAe+0KM+7e1N9jKk5SlKcuzv8ANWNmiiiqOcKKKKACiiigAooooAKKKKAC qOs3x07Sbm5QZkVMRr/ec8KPxJFXqxrz/iZeIrWzHMNkPtU3pvORGv8A6E34ClJ6GtGKc7y2Wr/r z2L2lWI03S7a0ByYowrN/ebufxOTVuiimtCJScm5PdhRRRQSFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWXoJ8qxezb/WWkrRMD6Zyp/FSDWpVC80zz 7gXVtO9rdBdhkQAh19GU8HHbuPWk+5rBqzhLS5bS3hilkljijWST77qoBb6nvRcNKtvIbdFeUKdi u20E9snBxVDytaQYW6sJPdrd1P6PR52tRD57Wyn/AOuc7IfyKn+dK4/Z3d+ZP5/52F03S2t5nvL2 UXF/KMNJjCov9xB2X9T1NT6pbS3ul3NtbyCKSaMorn+HIxmqx1ieHH2vSr2Md2jCygf98kn9KtWW p2eohvslwkhX7yg4Zfqp5H40K2xU1VUvaNbfNfhoTQQpbW8cES7Y41CKPQAYFUrrQrC7kDvEyN82 4xSMm8MckNgjIJ9a0ar3t9bafbtPdzLFEONzHqfQDufYU2lbUzhKpze43d9iWKJIYkjiRUjQBVVR gADsBVe20y1tLiW4ij/fy/fldizEemT0HsOKoJd6zqP7yztoLK3P3WvFZpH99gI2j6nPsKcdM1W6 +W71fy4z1W0gEZP/AAIliPwxSvfoa+zcbqU0r77v8iO4u3129m07T59ltbtsvLiNvm3f88lPY46n tnjnpr29vDaW8cFvGscUY2oijAArgdf8LnwXL/wk3hOKRGhO7ULEOWS5h/iOD0Ydc/U/Xt9K1S11 rS7fULCUSW1wgdGH8j6EdCKaXUynUulFbL+rlyiiimZhRRRQAUUUUAFFFFABRRRQBDdXMVlaS3M7 bYoULufQAZNUPD9tLHYtdXS7bu9c3EoPVc/dX/gKgD8DUWsf8THUrTSV5jJ+03X/AFzU/Kp/3mx+ Cmtqp3Zu/cpJdZa/Lp9+/wBwUUUVRgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVO90mz1Aq1xADKv3ZVJWRfow5FXKKGrlRlKL vF2MkabqUHy22sOUHQXMCyEfiCp/PNPtNESO6F5fTPe3g+7JIAFj/wBxRwv16+9adFLlRo687W/J JfkFFFFMxEIyMHpXncm/4YeIHlCsfCmpS5cDkWEx74/uH9Pw59FqG8s7fULSW1u4Umt5lKSRuMhg e1AEkciSxrJGyujAMrKcgg9CDTq85invfhbdi3ujNeeEpn/cz8vJp5J+63qn+evB9BtrmG8to7i2 lSaGVQySIcqwPcGgCWiiigAooooAKKKKACmu6xozuwVVGST0Ap1Y3iJmuYrfSoyQ+oSeW5HVYhzI fy+X/gQpN2RpShzzUf6t1F8Oo1xDPqsykS6g/mKD1WIcRj8ufqxrYpFVUUKoAVRgAdhS0JWQVZ88 3L+rdAooopmYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEc0MdxC8M8aSRSKVdHGQwPUEVwE2g634Au JLvwqjahojtvm0hyd8XqYj/T+fb0OigDD8M+MNK8V2zPp0xE8f8ArraUbZYj/tL/AFHFblcb4y8G veyDXfDxFn4htfnjkj4FwB1Rx0ORxk/Q8Vq+D/FEPivQkvETyblCYrq3PWGQdQf5igDdooooAKKK KACsXTP+Jhrl9qJ5jh/0OD/gJzIfxbj/AIBVnW9QexsglsA17ct5Nsh7ue59gMk+wqfTbFNM06C0 jJZYlxuPVj3J9ycn8andm8fcpuXWWi9Ov+X3lqiiiqMAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAK4LxDoWp+G/EEninwrb/aDMMalpynH2gf31/wBsf5zkg97RQBy+h/Ebw7rpSKO+W1u2 O02t1+6kVv7vPBP0JrqK5/xRoHhzVLNjr9rbbX+QXDKFdT2w45H8qzPCOo22h+H4dOm1iXWriIkK 9vC8h254UEA9B6mk5JbmkKNSavGLa9Ds6Kx/+Egccto+qhfXyVP6Bs1Hc+KrO2tZZJ4b+DahI8y0 kXnHrjFLmRaw1Vuyjf01HaYv9o61e6jJylu5tLYH+ED/AFjD3LcfRa2q5/wxqOnRaLZ2q39q1wsY 81RKNxc8tkHnOSa6CiOw8Smqji1otF6L+rhRRRVHOFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQBirCdfurg3DN/Z0EhhWAHAmZeGZ/VQeAvTgk54q3e3sOkwRRQwF5ZDsgtoQAWP8gB 3PQVW0p/sWpXunTfKzytdQHs6Mctj3Vic/UetS6vpRvo5Jbe4a2u/JaJJgThVJBORn269RUdLrc6 5cvtFGXw9P8AP/PqQ2OvNLprXV3auNtw8P8AoytMDgkbhgZxkEZxT7bxDaT293LcpJZxWziNzcgL kkA46n1HHXmneHZvO0aLbbxwxRkxxCIko6DgMuecH3+tYb27R6empMYFFvfXF35dySgcbmAPQnIG COD2pXdkaqlTlOUWra2Wvrp+FjcuH0u9tLee9tUeO5dY4xcQfMS3A4IyKiPhuG3+bS7m509xyFif dH+KNkflis/xNPfTaFZajb2zRtFmeSN2AaEmNgCf90tk/Stuyt3ttGSCbyo3SIqxVi6j3y3J989a ejZL5qdNSjLdtWvfby/4BmWHiNl1L+z7/wAuVt4jW8tgfJZz0Rs/dfjpk/0roa5CyW3tfCmpadeG Oe3sB8s1v8vmZUSKRycNuYdO+K6fT1uF0+3F4wa5Ea+aw6Fsc/rRBvqTi6cIvmgrdPXS9/LzXQsU UUVZxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBS1PTU1KFRvaGeJt8M6feib1HqOxHQ isd5ILq5S18QSSWtxgI0YkK292B0IPfryuQexyK6Wo5oIrmJop4kljbqjqGB/A1Ljc3pV3FWf/BX p/X3DlVVQKgAUDAA6AVDc2FtePC9zAkrQP5kZYZ2t6iqH/COW0Jzp891YHriCX5P++Gyv6UfZ9dh GI7+yuB6z25VvzVsfpRfuhqMb3hO3rdP8L/maksSTRPFKoeN1Ksp6EHqKjVYLGyVCwjt4UC5kfgK PUn+tZ/k6/MNr3en24/vRQM7fhlgP0pY/Dts8qy6hLNqEqnINy2VU+yDCj8qLvohckYq0p6dlr/k inY20OrSx/ZLdLfRYJPMjVE2C6kByGx/cB5HqRnoOeipOlLTSsTVquo/L+vxCiiimZBRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/ 2Q== --_004_BYAPR11MB3207E12FA868D4ECCF064161C0C60BYAPR11MB3207namp_-- From nobody Mon Dec 14 23:55:23 2020 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 8D5423A0D6F for ; Mon, 14 Dec 2020 23:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 e3gwy-rmBKKK for ; Mon, 14 Dec 2020 23:55:20 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDB53A0E65 for ; Mon, 14 Dec 2020 23:55:20 -0800 (PST) Received: from [10.0.0.129] (unknown [23.138.112.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id BD07D540129; Tue, 15 Dec 2020 02:55:15 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Jared Mauch In-Reply-To: Date: Tue, 15 Dec 2020 02:55:15 -0500 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 15 Dec 2020 07:55:22 -0000 I can tell you by looking that it=E2=80=99s a leak (or poison) due to = the AS_PATH as 1299 <-> 3491 should be adjacent=20 If you go to route-views, you can see plenty of routes with _1299_3491_ - Jared > On Dec 15, 2020, at 1:45 AM, Jakob Heitz (jheitz) = wrote: >=20 > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 > finds suspected leaky AS paths. > However, not all routes with suspected leaky AS-PATHs should be = automatically dropped, > because some of them may not be unequivocal leaks. > A BGP monitoring service should provide alerts to all suspected leaks. > However, a router should automatically drop only unequivocal leaks. > =20 > https://bgpstream.com/event/258771 is listed as a leak. > > The as-path is the red line. > The black line is a customer-provider relationship that exists between > 37545 and 33765 as can be seen at = https://asrank.caida.org/asns?asn=3D33765. > Therefore, 33756 is an authorized carrier of traffic for 37545 and > ought to not be called out as a leaker. > The route may not have taken the black line because of a temporary > failure of that link. An apparently leaky detour should be allowed > for a temporary failure as long as all the ASes involved are in the > provider cone of either the source AS or the destination AS. > All ASes in the provider cone of an AS are either directly or = indirectly > authorized to carry traffic for that AS. > =20 > This is just one example. It's easy to find more. > =20 > ASPA should add a section that defines an unequivocal leak, such that > a BGP router can optionally drop only unequivocal leaks. > =20 > The definition of an unequivocal leak is based on the provider cone. > The provider cone of an AS consists of all the providers of that AS = and > all the providers of those providers and so on. > =20 > All providers in the provider cone of either the originator or the = receiver > of the route are permitted (contracted, actually) to carry the traffic = for the > route between these two ASes. Therefore, the AS-path is only invalid = if it > contains any ASes not within these provider cones. If valleys exist in = the > AS-path, but these valleys are entirely within these provider cones, = then > all the ASes in the AS-path are still permitted to carry the traffic = and the > route should be declared valid. > =20 > =20 > Regards, > Jakob. > =20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Dec 15 04:50:18 2020 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 E3D763A10D9 for ; Tue, 15 Dec 2020 04:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[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 KwuEqlhugohc for ; Tue, 15 Dec 2020 04:50:15 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70079.outbound.protection.outlook.com [40.107.7.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C3B3A10D4 for ; Tue, 15 Dec 2020 04:50:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CCt7a/VlO5ThCGOI8h3x6xPGcHyPScR1bDFE+XfVvdPo+RswKNM1VdGz+OEarJiUrYgsUCzDmZvYUZQPCZOaPES5DletlMND8kh4xJ6pk6RSHAbW64rQkWdCBvC+Pu9eb7pXeImoOuEz7kySi7VTZjdF0hi/QZcy0+yUcUt0vaiWGDuh/b30CzISMbggX9O78f7Ec+4e1siCgDplxnl4oTtu34Q2oOvIz+MVl6GUk5jP9b6xR29DvS66GkynkVRaiLZtVpstzQ2aRI1+RqHG7z8I28B+uiSOyHbNOuFmptTJpJi/OFXsBwbKCllhkqcU6fb3u8y5m8czWOc8gFuzLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W5nEw3BWVkt3R/AuXs76DONFCHder33Sq85kqSLDgEo=; b=NaDIEKJIN3X6JgXPc0l9xI2g5NttCbZylLgaZdFIJFvwGWxEAER802Gxfi0UqB6lSs8TGCgLen6NDLl9h+wJMdCMtkZYte0m1z7MYJrb7pe37F34gpAZQJcg7jlvNtjXcu4N7A46XDNICWk8oHpYoTSLNhEVe/rIp1BTMZZG4clquhIRXcXoI6t6NbTSxpNZyp76zP/gpfq9KqqMpos5av4KeayiDrF+EnxmgB6q0UD0I9ZvJqxfgmTJW5lRE9NdUXGJ/LLe65DGfbHd8GJ7nwM0SEBIq8Pcx7pnenqtPuG60/kJ3F79zH9GVtIBLiCJPPe4crHNM2bWWOgnPyakOw== 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=W5nEw3BWVkt3R/AuXs76DONFCHder33Sq85kqSLDgEo=; b=e8AOhrG5ZHrW7Ce2ZLBfGgnJC12ipmHG82ML93xufATqB9g7CmPe67kk34A5pdmyBEZj5PQvq05a4Ay2LGiKX3wc+BuCfXisHRTDh20xFZFaDhK0FUHMcR8WNBjhPrH8EXayw++M3f/R6r8RMkO3Y0HRNOoNrKckEsL9ZZys4r8= Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DBAP190MB1000.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:1a1::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.20; Tue, 15 Dec 2020 12:50:10 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda%3]) with mapi id 15.20.3654.026; Tue, 15 Dec 2020 12:50:10 +0000 Date: Tue, 15 Dec 2020 14:50:03 +0200 From: Ben Maddison To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Message-ID: <20201215125003.k4mnemxkmi2372rj@benm-laptop> References: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7fgej7vxsnk4t7ib" Content-Disposition: inline In-Reply-To: X-Originating-IP: [165.0.73.66] X-ClientProxiedBy: CTXP275CA0017.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::29) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (165.0.73.66) by CTXP275CA0017.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Tue, 15 Dec 2020 12:50:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f453658b-3733-4094-114d-08d8a0f7f523 X-MS-TrafficTypeDiagnostic: DBAP190MB1000: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +/I64rQutAF+5Lqwpz9C2f+hbtakEyiAz9TXhzZthhz0QKzX7RKMNTXyDSxNqpdDUrO9c/STDNNE6dJaBF5MTxEADYGx8PBjsPaGLEuvyn1xclSzI8H6w7doT/MBCcIAPVp4qe0yNsBU2a1KySqMowXyvQP7xxdKN77DfUWQ7Uhf/BrDQn61QI2w/wBjHuBsYznFcCrCFjQ+Pd0updHN8Cbh0rn0vn6TPsDLxDwfocDJoOzx41+TL41u0q/YYAwl8FKYwiUUFygMCAiTo8WcU92KRRyUPL/k7+En1/YQzyo9r3kcqM+8VoXnO9llE4cCTtMRvClJlADfyAL2EDilInQb/K0xFaKSay5Oj1/FwWkZ9ANuqBztB//TZMyfkVyVZs1+y5fs98mvp9aavcYFGfmE1oelYmBR+ymvszkH6luHvRSG8KkDLhjwun8eCAVxIrGzRV32txxlJwyzAQXPifUR+gbpdN4SqQfo/FPuFe8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(346002)(366004)(6666004)(4326008)(26005)(508600001)(1076003)(86362001)(6486002)(52116002)(66574015)(16526019)(966005)(2906002)(8676002)(44144004)(6496006)(186003)(66476007)(66556008)(66946007)(83380400001)(33716001)(5660300002)(21480400003)(956004)(9686003)(8936002)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?N878YkAfaszPXk5EPO2w7c5/uZumhTr691PvGjt5eN0IOTs0MkRxIv6pmvzo?= =?us-ascii?Q?CzI2LUy6sv/+8dd3i3vehJED52nG41BYzx3rD7eY7DTbFFpMW2n9/hh+mYWE?= =?us-ascii?Q?oeNfRBnK0SC5z+KWqvAK1zxlhbIdzgS8l51aBA9zhpZcMDIfO1drZACnTbP3?= =?us-ascii?Q?moYHO17p76YN/G9toE2Alc1NcY7Cs1+JK4MkzaWQzGvlO15LaqJqJDdeqWhP?= =?us-ascii?Q?2LLJcZm64FERti0fQt29ZU3ys+ElWOJYrHPagf5nhiYkBZV+4VonAl+PvhaS?= =?us-ascii?Q?inm6SjVqLDJj8kdnnSfpbHnV08FuRBKJRxFMhkEfulVB+EzmoH6nqdVF9qCZ?= =?us-ascii?Q?lr94fCu+blLymULxx5pxVaqrtyETk2la2IeM2OodI8Kcc1TBgP2tWSIGpQqv?= =?us-ascii?Q?m635NQI0MHcRnG+a3wCVpXmVSh91R+qi6+t9IzxQfJzNlUlelrJ0G49otGe1?= =?us-ascii?Q?/vyL3Cin0yLuGYGBilQRTP1HggcawUXUFfzf7su18wu41krobwM052Qn3y8M?= =?us-ascii?Q?19EpUkw3zbOrWre90bU3ZDDpQZj0SfIBUcuw6jlTt83BrY2ID8Xt9ulfZ4xj?= =?us-ascii?Q?XtRyPlUJqiSxy9+SbzPvYHfWO8U4rxmlI9irRp11NsZexlvtxTBQGoowlunE?= =?us-ascii?Q?En94Qr3ilaXEBJhjaz/xt8TLT+jTqOBcei4s6nuxF1B1VrV3ZzVUNE8BxZKO?= =?us-ascii?Q?71dC3RJs4HlX3iQWnM2RPu7TvHl1Rn1DICl64m22gzr3wn+mlQIatdwwJCKp?= =?us-ascii?Q?9WNvZ6vqsySO4zxB0UO9uXC1CJBFM9tCnMTFygod6xJJpyjticthwEAa5hnU?= =?us-ascii?Q?+5dyXQOjLPCJq3cecLW6z1feBSAHW08bbTYuJrLUBwjfmBMPCcG6YUOaWxim?= =?us-ascii?Q?nJCMRvNSz6D8MzCgv+jK1CtSe0J006i5KAJcyK9Tj4oYdXoX3MrEsne4HPss?= =?us-ascii?Q?WXoIPqlOV/ekmem4qUdqm1F3HYU9UlP6VDXmv/9YUEI=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2020 12:50:10.2529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-Network-Message-Id: f453658b-3733-4094-114d-08d8a0f7f523 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CcVpp1KR108gm3gGOXX+pBWNHcGADj1wFJQWcTHCuRHeOq2tbEp1Q2g00tud7dZ7VLcdYgFKtzEaMNYBYxi/3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAP190MB1000 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 15 Dec 2020 12:50:18 -0000 --7fgej7vxsnk4t7ib Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jakob, On 12/15, Jakob Heitz (jheitz) wrote: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 > finds suspected leaky AS paths. > However, not all routes with suspected leaky AS-PATHs should be automatic= ally dropped, > because some of them may not be unequivocal leaks. > A BGP monitoring service should provide alerts to all suspected leaks. > However, a router should automatically drop only unequivocal leaks. >=20 > https://bgpstream.com/event/258771 is listed as a leak. > [cid:image001.jpg@01D6D269.84D10C20] > The as-path is the red line. > The black line is a customer-provider relationship that exists between > 37545 and 33765 as can be seen at https://asrank.caida.org/asns?asn=3D337= 65. > Therefore, 33756 is an authorized carrier of traffic for 37545 and > ought to not be called out as a leaker. No. This is about as clear cut and obvious a leak as you could hope to find! 33765 is a customer of both 3491 and 37100. It is learning paths from the former, and advertising it to the later. If ASPA won't drop that on the floor then it's basically useless. > The route may not have taken the black line because of a temporary > failure of that link. An apparently leaky detour should be allowed > for a temporary failure as long as all the ASes involved are in the > provider cone of either the source AS or the destination AS. > All ASes in the provider cone of an AS are either directly or indirectly > authorized to carry traffic for that AS. >=20 I think this is a misunderstanding of the nature of the "authorisation" that an ASPA object describes. The question of whether an AS is authorized to carry traffic to a particular destination is orthogonal to the question of whether a route is being leaked. The question is: when ASX advertises path P to ASY, does ASX authorise ASY to propagate it to its non-customer peers. In the above example, I'd expect that the answer is no (although, one would need to get their hands on an ASPA signed by 3491 to be sure). > This is just one example. It's easy to find more. >=20 > ASPA should add a section that defines an unequivocal leak, such that > a BGP router can optionally drop only unequivocal leaks. >=20 > The definition of an unequivocal leak is based on the provider cone. > The provider cone of an AS consists of all the providers of that AS and > all the providers of those providers and so on. >=20 > All providers in the provider cone of either the originator or the receiv= er > of the route are permitted (contracted, actually) to carry the traffic fo= r the > route between these two ASes. Therefore, the AS-path is only invalid if it > contains any ASes not within these provider cones. If valleys exist in the > AS-path, but these valleys are entirely within these provider cones, then > all the ASes in the AS-path are still permitted to carry the traffic and = the > route should be declared valid. >=20 That would exclude some of the most common and harmful species of leaks. We most often see these when an AS provides transit, but filter towards their peers on based on prefix-lists (no community, as-path filters, etc). When (due to an outage, badly conceived traffic engineering, etc) they select a route as best which is originated by a customer but learned =66rom a peer, the route matches their egress filters, resulting in a leak. These cause congestion in unexpected places, send traffic through middleboxes that aren't configured for it, and generally cause hard to troubleshoot pain and suffering. Usually with collateral damage included. Mitigating this kind of thing is right at the heart of what makes ASPA a good idea. Let's not gut it please. Cheers, Ben --7fgej7vxsnk4t7ib Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/YsPsACgkQOkYk/rSL aGB2lhAAjcqFCIqaz5IZDO9gOOAMTQaipcdileE4xEcUX7w/mhp+dCFWi//4YN8c GwjKBzP46fMHY/ogM0EmXnnOQhg7CXAsBtFSLrl8IlMO7e1kb8xC8YAIpBSuzeH0 6TS1K6w4JCn9qOMM/yNKyJ9QKj1+jgr4STEyUUiCpeCbmuOcf0xiKKFfmY5d+Aet +uAg+5WmJmifq8e/cRkAQhzmT88PlecGox6ARiSNs6fK6fAq8/Uvdf6icR+oL/3h +kCBnD+JOOQle2QeG5U9Kql2yr9mtSfUisUpWaVKxhbXmWgbC2vp7hsUKVovcXiA uuoqSqa8z51WTbE4h0UJ6/OGRFBM56VcFl8RGTNwVskfxSFbF24GoTsyxhJ8/CKJ 7fAfb2JPCU2uUVQpFLP6pktHmuX6htlwCA38arb2y2YEADRQjQomJWyVeYIfnwgm AwB1+Bfqq9ITsHGI6LbSD2wI2VXjCuEAC3DSfphz/UiEn5+OlTpTzd92CtJn9mh+ jnl3Wv4+rVBETC94FZSGpQ+30h+1ogJAt5sv3emQapJ8a+F+RSLyr+h33gj5aW0J 8fRZGq1W7KLpeFgfePPYGFnBne6Bh2qWvHkyqSM16Vc28ogZrCwPTZ6ePkvneQ/x BEazvun2CGh17pk6Bme0vqf7EkKDdEtvtaougQe9EmfCdzVa9cE= =WPXb -----END PGP SIGNATURE----- --7fgej7vxsnk4t7ib-- From nobody Tue Dec 15 13:48:32 2020 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 46D203A0062 for ; Tue, 15 Dec 2020 13:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cr0shwa0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DKZj3NeV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uzXwwFQJ8RH for ; Tue, 15 Dec 2020 13:48:25 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAF33A07EA for ; Tue, 15 Dec 2020 13:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5186; q=dns/txt; s=iport; t=1608068898; x=1609278498; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=cr0shwa0Pt+6klhEOvHhgpwbQ9yQmciKvi5gaBKSgQqPuARU+HE9l5dC k5OL/ONMGnNfeNGaIvVgvkWc15NEX3SrhedZTNl4cSQsIWC44ZeIpXHDR TgeU13mSabYyvV3lNEi22s1iudFsq6SEam4gtA3CUXW3APUcvUnL2Icvq Q=; X-IPAS-Result: =?us-ascii?q?A0AjAgDqLdlf/4cNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4FSKSgHdVsvLoQ/g0gDjVoDmQqCUwNUCwEBAQ0BARgLCgIEAQGEB?= =?us-ascii?q?kQCF4FZAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBAQIBAQEQE?= =?us-ascii?q?QQNDAEBJQcEBwEEBwQCAQgRBAEBAQICJgICAiULFQgIAQEEDgUIGoI5TIJVA?= =?us-ascii?q?w4gAQ6hZwKBPIhpdn8zgwQBAQWBMwEDAgYBg10YghADBoEOKoJ1g3mGNiYbg?= =?us-ascii?q?UE/gRFDglY+gl0BAQIBFoFIFYMAM4IsgWkpAm8ZDx0KKgIWOQs8QHCPYYMjp?= =?us-ascii?q?Q0KgnSJI5JKoj2dHoF0lhsCBAIEBQIOAQEFgW0jgVdwFTuCaVAXAg2Je4QmD?= =?us-ascii?q?BeDToUUhUR0AjUCBgEJAQEDCXyHDiyBPlwBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AB17Y1B0lp7YwiJ+LsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFu6d1kVTKG4PW9/JJkazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutf0DZoTu04CISFw?= =?us-ascii?q?+5Mwdpdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,422,1599523200"; d="scan'208";a="610236215" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 21:48:17 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BFLmHNg011312 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2020 21:48:17 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 15:48:16 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 15:48:16 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 16:48:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SF5RKt+9BQzCoK/l1rP+T9DO42bZzp7IbZTAb6RBSegyUOZiWKt9uMyE1w60UaSt4EIw/yG57bT3y2RZTEEDGXpUDc6NtIrE5t5un0+iR7H5rKJXRGmzfshgUgbpSKwBidfeKPnpTgAZQNmehunl1JWFZJzLXw+dx6G3UuLKzg1ecZsp2sD9kEq1Cypz206XfKLwxk69VIq+80kOo+0zmSazJM/kPbaFvfpicMchDEgPT1NiQKI5AwzLtaRe2oV3ASWX94iELguvUxqBQ/BbwmH7k43KhVTCTDXLxbYJrC1lz6pa6ETLvpGMvj45gFbRoJi8SD40FcGvI1EMTeTSjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=M3jajI216CfdgJxGKat1MejPyWeVrJItB7EZ6rrCUGlZflaqA84fxhpJuNHe5GYFWeUOs8Qaf75kRxgMBVknStevdKiKoV/oekbV+HXOBriYKsl5Omxst99174NDs5mcq/sVwf54RH1VmFQQpTLS6WUq+nVPkjNyIszp8bQAkjpPriUKO95z1w/VQK/rCHrRYe/qslUo9cpLKPEivxdKgGwRI+t/S5jKdJx8dV80+zgT3nXfR4+I7uWnsUrIgi7X2B0nv1QgB3+0rqlAY5eLdx62FZPGNOGD4I8V3tI69rQMBI7HYzBk0f+1g4VMqh2+X16oXI8yYTYM4ogI/JDJcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TRtozaIBG8B9fQta9LNTYchLCadL67Et2vqvymvClGw=; b=DKZj3NeVhGtdO0DYRW0QZezkNwUdpHttJKhaDQy5ZIUIHjtZ5ZLXuHXY/pdpFjUaM4LpOdyAz+C9uK/5ZfNUzQj4I6427+djM6ZVpg5B1s78DmMN+EeVcgK7EI2Ov77kGEzd54GfXZotAs3dd1hKko2drKMyL6T/h6fA4H5cOmk= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3574.namprd11.prod.outlook.com (2603:10b6:a03:b1::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.15; Tue, 15 Dec 2020 21:48:15 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 21:48:15 +0000 From: "Jakob Heitz (jheitz)" To: Jared Mauch CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ASPA: Is this really a leak? Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wAC3NuAABpy6DA= Date: Tue, 15 Dec 2020 21:48:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: puck.nether.net; dkim=none (message not signed) header.d=none;puck.nether.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:45ca:9d3c:5636:a4db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7aead971-b641-4d38-ad93-08d8a143208a x-ms-traffictypediagnostic: BYAPR11MB3574: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /O7yeSb8bH8YUpCny+DWl1Wp2VFdf8z94PSfkrwKw+QKFlR72c4Xw3eRUbep6N9e+r1jgPnswqvGPKxWVfGe9bDDrBsAbfgaGiJg8o4vD1RLOBsVogJ7ulTT56W+3y40xW9cAr4BIBoKExhqvttUV2+hHsuOzqCUZJwgTS0pNwS1bb/r9OqsAq3dppvCVjyev7ChDTG8Fuhfd5XQeNmWkEJKTycVsuQCyBJII4L1QrChodOExWiEs+8ezbh31SzUkRf9Zmw1ZBY1ZsDLSSkVuirNSlgxF2t88zko92NxfL/AIABKRoCY3OeX8XbCmNW+MFihcAOxHwapoRgH5hidaSxYBvV6aLyZWlMF8a/sh8bMFogrdYBLGz4D7d0TH72luVBG71GokX/vIIiCThzY1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(346002)(6506007)(53546011)(66446008)(66556008)(66476007)(6916009)(8936002)(64756008)(33656002)(76116006)(8676002)(966005)(52536014)(5660300002)(9686003)(4326008)(4001150100001)(66574015)(508600001)(2906002)(86362001)(71200400001)(66946007)(186003)(83380400001)(7696005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c2g4YVNtWFlpT2V1eTNybHhYLzVvM3R4YmMzanpiVFI4OFNUYlBoS21EMVEr?= =?utf-8?B?eWVKdGZWZFUyRS82OTdNU0hLTzJIZEl1Z3pIdGc1SjRobGw4VlpFUEJ1c2Fr?= =?utf-8?B?Z3dmMk9abzhHTmhjREJMMDdrYWlPSXpXUFo1dU1QQ2xEcjY3bnp5Q0ZYd090?= =?utf-8?B?eUlUd09BcDYvNEViR3RtaklsNlhKWjZOdUpwOXl4bXA3U1dxRUs1Y1NSYm1E?= =?utf-8?B?bVRvVGVHY010VlRTUU5IbVFuU0dZNXorN3BEU0l5Vzl4R2o2M0E5aG8vRUJ3?= =?utf-8?B?SFpaQzNkelFuSXdLTUxFWFA4cmhrSFQ1MkNiMkxFYmFsUStxRk1sNk5EUnRF?= =?utf-8?B?K0ttUDBnZHNRZ2QwZ0pvR056L0pKNkl0N1dBbGpORlpCMVpiaExDdVI4bEdO?= =?utf-8?B?YU12cXN1MExYWTNpUGlpOENpN01aSGsxclcwbENkZXNyOE9xOHZ2Y1pLYjh5?= =?utf-8?B?SHI1Z0RXcDdtN0dqck8yRGNTWGFyeVZOVEZYYnFvZmZ4a1FZT2lkMHRlYmpM?= =?utf-8?B?NWh2NTIwY08veXlkcG5WeUxMSXNBWitMUFkvUTczZU9DRDVpSjhzdmRFZDli?= =?utf-8?B?RkZvQmR0VkxRSlJmTjZERnViRm1md3g2REtlR1BzOERlUEVBZVp4WGhHT1cw?= =?utf-8?B?N3V6M3R5MXMvTFNMZFRjakQ4VzNVLzQyWDlpR09PWE9OYStIcDY2REhTWmNP?= =?utf-8?B?Ym5Ca1RndlBzTjZlUkpEM3dsSnlUQkMxNTZhMlJrUjJjNWNWOGUwOEdTUFZR?= =?utf-8?B?Tmx1LzdDM3pSWjl2VUJCT1NqWUZFVElDNnN6c1dXT0w5b1UxTTBLZ3NKVU1u?= =?utf-8?B?cmMwanZtMGROZWhNbFRBZXE4UlhYSW9WaW5WM3REVEJqdHdxekF1Y3gydW5a?= =?utf-8?B?UW1FSTRtbUhkaGo5MENKS2J5a2c1M0srV0FjT2lqZ205dS9FYmMwRG80UFdF?= =?utf-8?B?SklJVjc4VE1GOEM4ZnlDQkU3dWQ4MEcrUVB3VkJUUWRvQlpVeVo2V0tiSXA0?= =?utf-8?B?Yk9JVWpZdE45UGdRMkVpRjhmVXE3T213WE9HQW13TWJRQVRLekNYeUpBMVhN?= =?utf-8?B?ZHcrWjdGMGdCRzErcGY3Um9CU2g2aEkxUnp1cjRhcHA5Q1NHeTU0TG1ZU2tr?= =?utf-8?B?TEhyQ0plaXovZlpmM3p1UGt5YThCZlBKU3RIYkdpK01vUElVWDhKR0RvTm0z?= =?utf-8?B?VHJNOGFhZmRFU1ZKdFNCQSt4T3AzcmFKeXJtK1pGTTRSZHhsaVEzRW5PTnZn?= =?utf-8?B?dFhxMTNTQUtRSGtFQ3RiTFU3b1ZHMnVZVGRkRGROUHAraVRPZktzV3JFUDlm?= =?utf-8?B?ZFd4V3RrK1ZrZElBbFpJazdLdXF3WmlSYzdxMk5kaUFnTTBGMzNvY0dEQVUy?= =?utf-8?Q?4Mr6+akcE1SElf15+tavzmF4MrbhSvyQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7aead971-b641-4d38-ad93-08d8a143208a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 21:48:15.2675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nnx1Izy0cK65pxH4qLzPx27Xvm0YnTGKed4geyYKMwG9BW1dxroVlDgYdROi+TShLILgwr27WtVkn2k9PIcjew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3574 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 15 Dec 2020 21:48:31 -0000 SW4gb2l4LWZ1bGwtc25hcHNob3QtMjAyMC0xMC0xMS0xODAwIGZyb20gcm91dGV2aWV3cywgSSBz ZWUgdGhlIGFzLXBhdGg6DQooMTI5OSA0MDA2NSAzNDkxIDEzODk5NSkuDQpGcm9tIGh0dHBzOi8v YXNyYW5rLmNhaWRhLm9yZy9hc25zP2Fzbj0xMzg5OTUsDQpJIHNlZSB0aGF0IDQwMDY1IGlzIGEg cHJvdmlkZXIgZm9yIDEzODk5NSwgc28NCigxMjk5IDQwMDY1IDEzODk5NSkgaXMgcG9zc2libGUu DQpJbmRlZWQsIHRoZXJlIGlzIGFub3RoZXIgcm91dGUgaW4gdGhlIHNhbWUgZmlsZSB3aXRoIGp1 c3QgdGhpcyBBUy1wYXRoLg0KVGhlIGZhY3QgdGhhdCA0MDA2NSB1c2VkIDM0OTEgdG8gcmVhY2gg MTM4OTk1IHJhdGhlciB0aGFuDQppdHMgZGlyZWN0IGxpbmsgaXMgbm9ib2R5J3MgYnVzaW5lc3Mg YnV0IGl0cyBvd24uDQoNCk5vdywgaWYgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIDQwMDY1IGFu ZCAxMzg5OTUgZGlkIG5vdCBleGlzdCwgdGhlbg0KSSBhZ3JlZSwgKDEyOTkgNDAwNjUgMzQ5MSAx Mzg5OTUpIHdvdWxkIGJlIGFuIHVuZXF1aXZvY2FsIGxlYWsuDQoNCldlIG5lZWQgdG8gZGlmZmVy ZW50aWF0ZSBiZXR3ZWVuIHN1Y2ggInRyYWZmaWMgZW5naW5lZXJpbmciIGxlYWtzDQphbmQgdW5l cXVpdm9jYWwgbGVha3MsIGVsc2UgQVNQQSB3aWxsIGNhdXNlIGEgbG90IG9mIGNvbGxhdGVyYWwg ZGFtYWdlLg0KDQpXZSBtdXN0IHN0YXJ0IHNsb3dseS4gRHJvcCBvbmx5IHdoYXQgd2UgYXJlIHN1 cmUgaXMgYmFkLg0KVGhlbiBjYXJlZnVsbHkgbWFrZSBpdCBzdHJvbmdlci4NCg0KUmVnYXJkcywN Ckpha29iLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2lkcm9wcyA8c2lk cm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSmFyZWQgTWF1Y2gNClNlbnQ6IE1v bmRheSwgRGVjZW1iZXIgMTQsIDIwMjAgMTE6NTUgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6 KSA8amhlaXR6PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IHNpZHJvcHNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbU2lkcm9wc10gQVNQQTogSXMgdGhpcyByZWFsbHkgYSBsZWFrPw0K DQpJIGNhbiB0ZWxsIHlvdSBieSBsb29raW5nIHRoYXQgaXTigJlzIGEgbGVhayAob3IgcG9pc29u KSBkdWUgdG8gdGhlIEFTX1BBVEggYXMgMTI5OSA8LT4gMzQ5MSBzaG91bGQgYmUgYWRqYWNlbnQg DQoNCklmIHlvdSBnbyB0byByb3V0ZS12aWV3cywgeW91IGNhbiBzZWUgcGxlbnR5IG9mIHJvdXRl cyB3aXRoIF8xMjk5XzM0OTFfDQoNCi0gSmFyZWQNCg0KPiBPbiBEZWMgMTUsIDIwMjAsIGF0IDE6 NDUgQU0sIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHo9NDBjaXNjby5jb21AZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOg0KPiANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtc2lkcm9wcy1hc3BhLXZlcmlmaWNhdGlvbi0wNg0KPiBmaW5kcyBzdXNwZWN0ZWQgbGVha3kg QVMgcGF0aHMuDQo+IEhvd2V2ZXIsIG5vdCBhbGwgcm91dGVzIHdpdGggc3VzcGVjdGVkIGxlYWt5 IEFTLVBBVEhzIHNob3VsZCBiZSBhdXRvbWF0aWNhbGx5IGRyb3BwZWQsDQo+IGJlY2F1c2Ugc29t ZSBvZiB0aGVtIG1heSBub3QgYmUgdW5lcXVpdm9jYWwgbGVha3MuDQo+IEEgQkdQIG1vbml0b3Jp bmcgc2VydmljZSBzaG91bGQgcHJvdmlkZSBhbGVydHMgdG8gYWxsIHN1c3BlY3RlZCBsZWFrcy4N Cj4gSG93ZXZlciwgYSByb3V0ZXIgc2hvdWxkIGF1dG9tYXRpY2FsbHkgZHJvcCBvbmx5IHVuZXF1 aXZvY2FsIGxlYWtzLg0KPiAgDQo+IGh0dHBzOi8vYmdwc3RyZWFtLmNvbS9ldmVudC8yNTg3NzEg aXMgbGlzdGVkIGFzIGEgbGVhay4NCj4gPGltYWdlMDAxLmpwZz4NCj4gVGhlIGFzLXBhdGggaXMg dGhlIHJlZCBsaW5lLg0KPiBUaGUgYmxhY2sgbGluZSBpcyBhIGN1c3RvbWVyLXByb3ZpZGVyIHJl bGF0aW9uc2hpcCB0aGF0IGV4aXN0cyBiZXR3ZWVuDQo+IDM3NTQ1IGFuZCAzMzc2NSBhcyBjYW4g YmUgc2VlbiBhdCBodHRwczovL2FzcmFuay5jYWlkYS5vcmcvYXNucz9hc249MzM3NjUuDQo+IFRo ZXJlZm9yZSwgMzM3NTYgaXMgYW4gYXV0aG9yaXplZCBjYXJyaWVyIG9mIHRyYWZmaWMgZm9yIDM3 NTQ1IGFuZA0KPiBvdWdodCB0byBub3QgYmUgY2FsbGVkIG91dCBhcyBhIGxlYWtlci4NCj4gVGhl IHJvdXRlIG1heSBub3QgaGF2ZSB0YWtlbiB0aGUgYmxhY2sgbGluZSBiZWNhdXNlIG9mIGEgdGVt cG9yYXJ5DQo+IGZhaWx1cmUgb2YgdGhhdCBsaW5rLiBBbiBhcHBhcmVudGx5IGxlYWt5IGRldG91 ciBzaG91bGQgYmUgYWxsb3dlZA0KPiBmb3IgYSB0ZW1wb3JhcnkgZmFpbHVyZSBhcyBsb25nIGFz IGFsbCB0aGUgQVNlcyBpbnZvbHZlZCBhcmUgaW4gdGhlDQo+IHByb3ZpZGVyIGNvbmUgb2YgZWl0 aGVyIHRoZSBzb3VyY2UgQVMgb3IgdGhlIGRlc3RpbmF0aW9uIEFTLg0KPiBBbGwgQVNlcyBpbiB0 aGUgcHJvdmlkZXIgY29uZSBvZiBhbiBBUyBhcmUgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0 bHkNCj4gYXV0aG9yaXplZCB0byBjYXJyeSB0cmFmZmljIGZvciB0aGF0IEFTLg0KPiAgDQo+IFRo aXMgaXMganVzdCBvbmUgZXhhbXBsZS4gSXQncyBlYXN5IHRvIGZpbmQgbW9yZS4NCj4gIA0KPiBB U1BBIHNob3VsZCBhZGQgYSBzZWN0aW9uIHRoYXQgZGVmaW5lcyBhbiB1bmVxdWl2b2NhbCBsZWFr LCBzdWNoIHRoYXQNCj4gYSBCR1Agcm91dGVyIGNhbiBvcHRpb25hbGx5IGRyb3Agb25seSB1bmVx dWl2b2NhbCBsZWFrcy4NCj4gIA0KPiBUaGUgZGVmaW5pdGlvbiBvZiBhbiB1bmVxdWl2b2NhbCBs ZWFrIGlzIGJhc2VkIG9uIHRoZSBwcm92aWRlciBjb25lLg0KPiBUaGUgcHJvdmlkZXIgY29uZSBv ZiBhbiBBUyBjb25zaXN0cyBvZiBhbGwgdGhlIHByb3ZpZGVycyBvZiB0aGF0IEFTIGFuZA0KPiBh bGwgdGhlIHByb3ZpZGVycyBvZiB0aG9zZSBwcm92aWRlcnMgYW5kIHNvIG9uLg0KPiAgDQo+IEFs bCBwcm92aWRlcnMgaW4gdGhlIHByb3ZpZGVyIGNvbmUgb2YgZWl0aGVyIHRoZSBvcmlnaW5hdG9y IG9yIHRoZSByZWNlaXZlcg0KPiBvZiB0aGUgcm91dGUgYXJlIHBlcm1pdHRlZCAoY29udHJhY3Rl ZCwgYWN0dWFsbHkpIHRvIGNhcnJ5IHRoZSB0cmFmZmljIGZvciB0aGUNCj4gcm91dGUgYmV0d2Vl biB0aGVzZSB0d28gQVNlcy4gVGhlcmVmb3JlLCB0aGUgQVMtcGF0aCBpcyBvbmx5IGludmFsaWQg aWYgaXQNCj4gY29udGFpbnMgYW55IEFTZXMgbm90IHdpdGhpbiB0aGVzZSBwcm92aWRlciBjb25l cy4gSWYgdmFsbGV5cyBleGlzdCBpbiB0aGUNCj4gQVMtcGF0aCwgYnV0IHRoZXNlIHZhbGxleXMg YXJlIGVudGlyZWx5IHdpdGhpbiB0aGVzZSBwcm92aWRlciBjb25lcywgdGhlbg0KPiBhbGwgdGhl IEFTZXMgaW4gdGhlIEFTLXBhdGggYXJlIHN0aWxsIHBlcm1pdHRlZCB0byBjYXJyeSB0aGUgdHJh ZmZpYyBhbmQgdGhlDQo+IHJvdXRlIHNob3VsZCBiZSBkZWNsYXJlZCB2YWxpZC4NCj4gIA0KPiAg DQo+IFJlZ2FyZHMsDQo+IEpha29iLg0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+IFNpZHJvcHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3Bz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRy b3BzIG1haWxpbmcgbGlzdA0KU2lkcm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQo= From nobody Tue Dec 15 14:10:52 2020 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 536A83A033F for ; Tue, 15 Dec 2020 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jGrg+mGn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D75c+o4t Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4Fm47ShYr1f for ; Tue, 15 Dec 2020 14:10:49 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB823A0365 for ; Tue, 15 Dec 2020 14:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4324; q=dns/txt; s=iport; t=1608070249; x=1609279849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=jGrg+mGnMTRIvABPycKtIMKdWZ+ndwLTYoxeQc1dG62ZdIdGu3eAVfvJ LuQfjbRHdlY/y0Mjeg/GgK9JGfYMUn3AtpYpgN8XLAB7Nn/qgJsijVaqL 0H5tbB7kEV6Z1XzgdYF9rywdDyjcsXH//ibGXGpz3lw/Geb6w3e5FvVFa 4=; X-IPAS-Result: =?us-ascii?q?A0AdBACuM9lfkJtdJa1iHQEBAQEJARIBBQUBQIFPgVIpK?= =?us-ascii?q?HxbLy6IBwONWgOZCoJTA1QLAQEBDQEBIwoCBAEBhEoCgXACJTgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXIBAQEBAgESKAYBASUGBQcBBAcEA?= =?us-ascii?q?gEIEQQBAQEeEDIdCAEBBA4FCAwOgjlLAYJVAw4gAQ6hagKBPIhpdIE0gwQBA?= =?us-ascii?q?QWBMwEDAgYBg2MYghADBoE4gnWKLyYbgUE/gRFDglY+gl0BAQIBFoFIg0iCL?= =?us-ascii?q?IISAlQbKB0mDgIWGCFHQARUGI9hqDAKgnSJI5JKgyaKJpRxnR6BdJYbAgQCB?= =?us-ascii?q?AUCDgEBBYFtIYFZcBWDJFAXAg2Je4QmDA4Jg06FFIVEdAI1AgYKAQEDCXyHD?= =?us-ascii?q?iyBPlwBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A1HXfWx/uabJwb/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZhCN6fBkllSPXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFMP3fVaUo3Cu43gVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,422,1599523200"; d="scan'208";a="615019490" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Dec 2020 22:10:48 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BFMAmPq006570 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2020 22:10:48 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 16:10:48 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Dec 2020 17:10:47 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Dec 2020 17:10:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQOkvMkfxUZCmJgw466qF23f8x1o9DxCmEl2aTcVrzn5d8BzQTFU78eXj4xNRlHJGiKPLLFR8v6UZzgJ5aaWNlTRbemLquKGmMQ2d6EbGOq11X2K4X2s/6csRtjF9Cn/IvCbU8PTyQe8tqNmV/KMGCcdtHTRW/Y9+t8kgv2Vx2rhh6Lofa5Jor6RP/BsN5fqBzgciEis194sO1XMF0bKAIhSvMW2So8UNbBpvPiVvCEOCOSjn5kjYBjXvYdp5fqZ+lUP7eRi7pHYoaOl617zzZzOLtF1xJWmTy+i1KtaHd25zs5kGxrfVwH26BJPLlLtyNc8gVCgh3FXUXHroDLl4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=lJxpQofa6g6aJUrvJCYvJHLGIQncNKhOXKuES7RoraqL5rTu1YeprT7bsAu+RlQIPLRHPwVNlqcoPFNxD/W6xDxsjNr3qXwElhA+DK6/zGVtNe4v6vGn1bpsuH3SKPiGmjhxl2rfSkqewaVSq3X9opDPaIH9CrYGZIsEkTBAbDWwRX9nLC/TzGouLurCqdvkIa+WYJbxgVNSm6jUUlup1VyBo9HpWFZOZGj/T5oeJzVdAEfqioIS50eMhZnj4JDoEgs2CT5FcwQBd1+7iEMR/mkjlAXgpjum+zoL5IXdDqEWIZz1I+iUQmstp+gExR1ikoIxGhTXGpDcmPNs5l5Rfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iV0AibE36J4S+C+RxvM4nLWsHl03MZHvX1CQI7t92bI=; b=D75c+o4tvaWUnFT5MFu6RS7Px9NWYbmMmF3tKhOUsX53MaeJa5SN3hbadgQpCjrri80vC8Uz+VigcD3bVE6NdlPm4yapSXlI2VWwcTfnYeMEaCG0N18o24fkcYLjSBXZEE4KvWxnAsumFPwFpV8XcAfDw3ZTt7K0JBRJuFdHEV8= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by SJ0PR11MB5120.namprd11.prod.outlook.com (2603:10b6:a03:2d1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.17; Tue, 15 Dec 2020 22:10:45 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Tue, 15 Dec 2020 22:10:45 +0000 From: "Jakob Heitz (jheitz)" To: Ben Maddison CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ASPA: Is this really a leak? Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wANKJOAABOAS7A= Date: Tue, 15 Dec 2020 22:10:45 +0000 Message-ID: References: <20201215125003.k4mnemxkmi2372rj@benm-laptop> In-Reply-To: <20201215125003.k4mnemxkmi2372rj@benm-laptop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:45ca:9d3c:5636:a4db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c23b8a2c-0151-49c0-56f9-08d8a146455f x-ms-traffictypediagnostic: SJ0PR11MB5120: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YEJxC4mJ8dyc1FhxrVMhzHNg6G1s+6Y1u588lvFiF1XX9RWFYFrrOZPIH1JH35a0qOB7u9GfMCia9dNHRdblYd6kaa8cpDTmvrStWkEwr9qnJaRQ1njInIkjhLXH1P5sfJJ+FLINq9lJA7p4e4HDBjWoR6Ewkcx5gcYNP/VrguB1YgwiET+yWFHfkHsGkpfctiaEGvRFPF3wS7SUlD63bfU9r9Li825U2qal4WzgAR4v2TjAE+q+QFPTYJwBqxQQnSHWXq3u5GrER4LWGMU9v0INlquvUBZzsrpqkUzINvddbSrrvRFlZJtk4xgktFW5cE1TQ8RiqTD+1E8f0N0GolfpKRFAxqy48pSQ3DTPsbFuJuJ6mejmnitr5Q1j365mNeDkke/f+RQOXyc3Xei/nw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(366004)(346002)(376002)(966005)(55016002)(9686003)(6506007)(53546011)(4326008)(186003)(8676002)(478600001)(71200400001)(83380400001)(66574015)(76116006)(64756008)(66446008)(66476007)(316002)(2906002)(66556008)(7696005)(5660300002)(33656002)(66946007)(52536014)(8936002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?5OOIHhJsszWiwJ55wNMDJ9FFco+s4izgIpjxGSm6+Y2o2kyT2x7UYYYylSd6?= =?us-ascii?Q?QD89shkSzRef0aZ7T2J3MPO/6jPtkuDtVfNI4EGBlxwnwCJv3dXugwR4Mz2a?= =?us-ascii?Q?sfFZxU1h0DSzdz2WL+KFJ6D2zswk0X6C/MBFyktaP5ajVDbOAd5nT+cu0Iw7?= =?us-ascii?Q?7PSVTZ02SHkXFe4luRnfEtKHI27l+sXMY08ZW6u9N78t0ZvzGxiw9GcZ620l?= =?us-ascii?Q?RHwn6sC1I4qSx9FeWI9xFZ/eUlF8Z9v/Rgbv0ATZOuXjlmjpBl7MtD1AI1Lu?= =?us-ascii?Q?B/XV3uEv6sxTiz7acLvrHUAm0lEIA54qMFpZanqDOwh1Pe9scFztRbpU5LoR?= =?us-ascii?Q?eDTkTVSc43nthc1z3Bf+HlUy++KkAPS1GYeImIMYGWRgC0eOE/ueuCB5A8Zn?= =?us-ascii?Q?hzsgLT51WZo9pVsPBcOi47GTK0sik75h+ELhdgbPILE4VBYezq7kVKPp1zko?= =?us-ascii?Q?DVjSARW5xr48apijPQ98z0qg1aRmzF5J0Qhm+Wgpy/ezPKYwdR/0KFGoPEk2?= =?us-ascii?Q?P1ASD9rWbNi8qbjxON7sGnOwB4Nxuqaa+sajH5mBCmMYido1YyG3X8sN9mUU?= =?us-ascii?Q?aCGdMRDx8yAhF+KDrEz9P5L5nQJ64042O8Gmb0QAVgHoZmUdp5dkKJrGcVHy?= =?us-ascii?Q?qQtosYzpb101KLVD+f0zkVOkt3rlySwY4bwrqlG86g0ShUplVkH3hmtKRb+g?= =?us-ascii?Q?aAUTdX1xsb4mJjwUvGrmrrTKJrcybcZRTw5+NL4nKSJLpB5++bfyAir2moV3?= =?us-ascii?Q?vtrnrnvJU2E9h0bupzsFNh80MNX8pEX5/FGolwoVe9xFm3F5eZlf4DtITdgQ?= =?us-ascii?Q?oEA3p0XruXlg8SXdS2skE4wNGwEd/EYRa/Y0CpwHZUL5oq979bQiNTfjRHji?= =?us-ascii?Q?eP/4u69oYgOxLGS/FYgKY69dXfOyTcVUZ2uVy/1YRpYvPaoYWj9xU/hLNlHE?= =?us-ascii?Q?6j2AahgXn1mtPX9IzlNeoNjz+fDYYDYAqzD+xtOAjxakWUdE2b82pd0eHiHp?= =?us-ascii?Q?2h1GIcA7Wb9p4dTW1WPYcFz2SYN0RvSCOzwoGz4J8uUsgcI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c23b8a2c-0151-49c0-56f9-08d8a146455f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2020 22:10:45.6014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p3XTzL2tERpUQMbn6hLJjvxzyPfCacZ8H5Ihym8oRo/AOW4vWvfCa2VDsQkiJIrG5XYDhtqzoj73DtMbH2j3dA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5120 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 15 Dec 2020 22:10:51 -0000 Ben, Your scenario is possible. However, it is only that: possible. That makes it a suspected leak, not an unequivocal leak. There are plenty of unequivocal leaks to stop. Let's start with those and not bring down a lot of unsubstantiated "suspected leaks". Regards, Jakob. -----Original Message----- From: Ben Maddison =20 Sent: Tuesday, December 15, 2020 4:50 AM To: Jakob Heitz (jheitz) Cc: sidrops@ietf.org Subject: Re: [Sidrops] ASPA: Is this really a leak? Hi Jakob, On 12/15, Jakob Heitz (jheitz) wrote: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 > finds suspected leaky AS paths. > However, not all routes with suspected leaky AS-PATHs should be automatic= ally dropped, > because some of them may not be unequivocal leaks. > A BGP monitoring service should provide alerts to all suspected leaks. > However, a router should automatically drop only unequivocal leaks. >=20 > https://bgpstream.com/event/258771 is listed as a leak. > [cid:image001.jpg@01D6D269.84D10C20] > The as-path is the red line. > The black line is a customer-provider relationship that exists between > 37545 and 33765 as can be seen at https://asrank.caida.org/asns?asn=3D337= 65. > Therefore, 33756 is an authorized carrier of traffic for 37545 and > ought to not be called out as a leaker. No. This is about as clear cut and obvious a leak as you could hope to find! 33765 is a customer of both 3491 and 37100. It is learning paths from the former, and advertising it to the later. If ASPA won't drop that on the floor then it's basically useless. > The route may not have taken the black line because of a temporary > failure of that link. An apparently leaky detour should be allowed > for a temporary failure as long as all the ASes involved are in the > provider cone of either the source AS or the destination AS. > All ASes in the provider cone of an AS are either directly or indirectly > authorized to carry traffic for that AS. >=20 I think this is a misunderstanding of the nature of the "authorisation" tha= t an ASPA object describes. The question of whether an AS is authorized to carry traffic to a particular destination is orthogonal to the question of whether a route is being leaked. The question is: when ASX advertises path P to ASY, does ASX authorise ASY to propagate it to its non-customer peers. In the above example, I'd expect that the answer is no (although, one would need to get their hands on an ASPA signed by 3491 to be sure). > This is just one example. It's easy to find more. >=20 > ASPA should add a section that defines an unequivocal leak, such that > a BGP router can optionally drop only unequivocal leaks. >=20 > The definition of an unequivocal leak is based on the provider cone. > The provider cone of an AS consists of all the providers of that AS and > all the providers of those providers and so on. >=20 > All providers in the provider cone of either the originator or the receiv= er > of the route are permitted (contracted, actually) to carry the traffic fo= r the > route between these two ASes. Therefore, the AS-path is only invalid if i= t > contains any ASes not within these provider cones. If valleys exist in th= e > AS-path, but these valleys are entirely within these provider cones, then > all the ASes in the AS-path are still permitted to carry the traffic and = the > route should be declared valid. >=20 That would exclude some of the most common and harmful species of leaks. We most often see these when an AS provides transit, but filter towards their peers on based on prefix-lists (no community, as-path filters, etc). When (due to an outage, badly conceived traffic engineering, etc) they select a route as best which is originated by a customer but learned from a peer, the route matches their egress filters, resulting in a leak. These cause congestion in unexpected places, send traffic through middleboxes that aren't configured for it, and generally cause hard to troubleshoot pain and suffering. Usually with collateral damage included. Mitigating this kind of thing is right at the heart of what makes ASPA a good idea. Let's not gut it please. Cheers, Ben From nobody Wed Dec 16 03:46:04 2020 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 4598F3A09E7 for ; Wed, 16 Dec 2020 03:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=algebras-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqST22b1Qf2C for ; Wed, 16 Dec 2020 03:45:58 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 5513B3A09EF for ; Wed, 16 Dec 2020 03:45:57 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id o19so21928047lfo.1 for ; Wed, 16 Dec 2020 03:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1z5HqNibHcvhahZr2HyLNYobRt9TC/X9zBqqb163+XE=; b=jGXwfccMoQAf+kO7x6SYSNVWKXTSWZx320QGTGoEqbcTdB9dn/XK5yYALQ3rZr+DRq prHl9QJq6Ny0te1CXbVWdC0zt5RwYF5RYTg4aDe7+P+V9Dfwy5bGNOh+g6H/af1zo4mQ H0xbz4EeWwrm+2WP2GK2E9VHLuqg8XGxvywblpWr09pRMSjJcCCYN2meGqqqzg5LwqBV XdLR1bQfJYd19P860ZgLfbuABCK8GGjJ6kQoX0Gk9TcruTT2t4zdP76OhHvZrUYHIjAg hr4b/pvtHnV5hJcqibfsJB+cfWAubzG0PkmEUVqZd9PTpB5twfuKE2blI2dApEroW9Gh ASSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1z5HqNibHcvhahZr2HyLNYobRt9TC/X9zBqqb163+XE=; b=NALSUwlOcTsTjSyTHMpBTmQ0UAXhiVtP8HbHgBvUEKjcnMQDmf2UFz+GZvsSkLEEHr lhwVSDSD7Fs7vpI03Bc3DW7Fd72cgbV8vHBxLg2kPz9mzmjJqGdjExU4g+KR/rFp2TN4 XzY9u1ItO8p5Ux4/sJc8liN7ihJsknNIHkcpU7ne9UYDpeE5veyjJyhyRW7zq+HCXJiM U+gQlfUFi9h5YJ2wiWSbwSW0W3ZrBFSZRluf5KvPvUo5eH1xSeyDLJFlSLRhh8bfO4fz EgodTQ1pITp7ex40IZ4yUR4yBJq2I/LjJbH04pDoHbpauN1HsPq8gm0FrCI+uqmXryOX OGaQ== X-Gm-Message-State: AOAM531ID66XJaqB8/Zy/aPi0BpKovI48/spSiLHnk4Co4pPLPt8aesB XcUbYh5/2mM6OD9I+/bGikfN3Ajtpho3uMEertjori7VK5NJkQfu X-Google-Smtp-Source: ABdhPJxWLm7bGzVm0PZWQ/GPN1mAccftt5j7FpLB3vXp87w3GSIerQ3GosF+iKoMxcKe0QQ3pUyqc7yLBO/D9maHB6o= X-Received: by 2002:a05:651c:2049:: with SMTP id t9mr14949976ljo.58.1608119154801; Wed, 16 Dec 2020 03:45:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Wed, 16 Dec 2020 21:45:43 +1000 Message-ID: To: Job Snijders Cc: SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] proposal to update SIDROPS charter (requirement for multiple implementations before IESG/RFC publication) 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, 16 Dec 2020 11:46:02 -0000 On Wed, Dec 9, 2020 at 12:28 AM Job Snijders wrote: > > Dear all, > > I propose some following text detailing a requirement for multiple > implementations to exist prior to RFC publication will be beneficial to > the working group. > > Our neighbors at the IDR working group are known to have a similar > requirement, which has dramatically improved the quality of that working > group's specifications and subsequently the deployability of IDR > technologies. I hope the same can be achieved in SIDROPS. > > IDR participants track implementation reports & interopability testing > through internet-drafts or their Wiki > https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports > > Here are some examples of what reports can look like: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rfc8203bis > https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations > > Proposed text to add to the SIDROPS charter: > > """ > Specifications produced by the SIDROPS working group are intended to > address a practical need where a standard specification can assist > both vendors and consumers of cryptographic PKIX products to be > assured that a standards conformant implementation will undertake > certain functions in a known manner, and that, as appropriate, > implementations of the standard specification from different vendors > will indeed interoperate in intended ways. The SIDROPS working group > requires interopability reports from at least two different > implementations of a proposed specification, prior to publication as > RFC. > """ > > Kind regards, > > Job > I think this would be sensible. From a CA, producer-side point of view, I think having confidence of interop demonstrated, and having this in both producer and consumer (signer and validator) would be net beneficial. cheers -george From nobody Wed Dec 16 08:40:35 2020 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 B2B943A10E4 for ; Wed, 16 Dec 2020 08:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 e736Ndt-khuF for ; Wed, 16 Dec 2020 08:40:32 -0800 (PST) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 11C533A1103 for ; Wed, 16 Dec 2020 08:40:31 -0800 (PST) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id 940064AC96; Wed, 16 Dec 2020 16:40:30 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 5EBD45640E6F; Wed, 16 Dec 2020 11:40:30 -0500 (EST) X-Mailer: emacs 25.2.2 (via feedmail 11-beta-1 I); VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24538.14458.724169.315853@oz.mt.att.com> Date: Wed, 16 Dec 2020 11:40:26 -0500 From: Jay Borkenhagen To: "Jakob Heitz \(jheitz\)" Cc: "sidrops@ietf.org" In-Reply-To: References: Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 16 Dec 2020 16:40:34 -0000 Jakob Heitz \(jheitz\) writes: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 > finds suspected leaky AS paths. No, not really. draft-ietf-sidrops-aspa-verification rejects routes whose AS_PATHs are contra-indicated by the expressed wishes of the AS resource-holders, as communicated by the set of validated ASPA records. It's thus up to each party publishing ASPA records to ensure that all necessary upstream and mutual transit relationships are explicitly authorized. Jay B. From nobody Wed Dec 16 10:41:29 2020 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 917E23A0AE5 for ; Wed, 16 Dec 2020 10:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 zOnuUo2edTgB for ; Wed, 16 Dec 2020 10:41:25 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30052.outbound.protection.outlook.com [40.107.3.52]) (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 E09783A0ADB for ; Wed, 16 Dec 2020 10:41:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Il7c5Ak/UVyZ4jZd+6uSXM9aLWJy3b0eES1oPQvap27vfWJltdqgbhKmIXq+k1wDN8plTe3NRXrI7lo1ZtJ9lkxQjUfJB7wio6HjpC2aiwPLJhdarFXwwDi1lXxT+uBzpKr/YZWwE0HOyVQlucwWatsFl0XUCWCj7WOjQOhccKHBJPkW1JQAfRLlTsTCvlk2K18RfqBzP+72Bbn3rfel8L0XxyoaDGaJ4BdDfSSI9K/9E1dWK05FDMOQC5rwS0RDseNSOQlBT4ln5lOicBftADFFE1tGIpp0jJOdA18dAg2qOnjPZG6+cYmrbHF9dg0DeoZoRn9NWHSjfAYksyIwXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5jDgKs7tFV7t1Rt+ALE6Lhhzhtn6s36j51RQUwYfF3w=; b=dhm8rieY+6cHKg72uzDGD2Rff/KlwaqHWcGyU8QhFKvCqAR8OaYAcplKuB3fvZMLvVRI22SFOGxB++NXMjA/gR0ldo8Y/+PwqiZ4x4PM5coNaK2FxgFN5c6RDY6pRZLVGwJO34nsFRYQlWc+xVaCNu3IU4R2CiAczDU1x8RZ6DIoXcLGOliqt0Y12pUIzTT+KlELUxdRzXRGSNiBiin5KtKNCgJJmU0IBlSqlYaBucq8JtY+Isc3iiInzEqn/prDGl1gmUWbf7O9SehZGu/bpp9lQvVOgztWqtFvyokaSpLt64ZD06BgzJCcTlhdpZq7La11ka68nXZ/fniqUfYfdw== 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=5jDgKs7tFV7t1Rt+ALE6Lhhzhtn6s36j51RQUwYfF3w=; b=e2gKtvtmnJhDnbZHtopEflaftK4HjG5FfPhOSgR2mJHCedjMHFkbM9nilBJysZhyAEfpn0j0FYTAUy8ncbQ7LDLZDR2edn9nPo3FT91gjh0gdoHdb0t3fWlI5HJ7QmDnpLSNJ8D6nV7FgQVrVs8ZFAAVToQWGPaq0R2AMVgT0Qs= Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB6P190MB0294.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:3e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.21; Wed, 16 Dec 2020 18:41:20 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda%3]) with mapi id 15.20.3654.026; Wed, 16 Dec 2020 18:41:20 +0000 Date: Wed, 16 Dec 2020 20:41:12 +0200 From: Ben Maddison To: "Jakob Heitz (jheitz)" Cc: "sidrops@ietf.org" Message-ID: <20201216184112.vd4fxfajtka64khm@benm-laptop> References: <20201215125003.k4mnemxkmi2372rj@benm-laptop> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g7pbxdvxqszxgrgs" Content-Disposition: inline In-Reply-To: X-Originating-IP: [160.119.236.50] X-ClientProxiedBy: JNXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::31) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (160.119.236.50) by JNXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:18::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Wed, 16 Dec 2020 18:41:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f88473fd-7163-4a16-2bf9-08d8a1f22e86 X-MS-TrafficTypeDiagnostic: DB6P190MB0294: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AJ8XiBLuex60Mph0judb2w3WFyaD/7qX/e6Y/w1oewqcymxRr12Pywudmry1HFpzXBawEjE7GxCuKvyJQMjuO4tU8eE8LYO9Q5mlWh79hLvTkT+efGfKoYSDERfO/A/NijyuKaqgz5LByZO1WPIS4oVedNVUgRUrEmD0a9LejU9KKwL06JtIkoDYdREyfYn1ZWGN+q64cBN+MZKsUEAGl52s1Mw0hjZMhuVa59e49BgkubLbQXa6p8sACowBLplqaoUVOcQNnO6vtB8KMWQDV9ePWHWTcgSN2WXkMqmBdXNjky2gVMjX0m7lQgNBqe7y/mqFNxE0++I3XFlyNOhlPezpDzZ29E1BRQ/YRLcDpHT7k1Wouk23bVt7PsEpr+oq+uO/dYsF31BOp2U25JWUiA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(396003)(366004)(39830400003)(346002)(376002)(136003)(21480400003)(6486002)(9686003)(2906002)(316002)(6496006)(186003)(44144004)(6666004)(478600001)(86362001)(8936002)(26005)(52116002)(1076003)(8676002)(66476007)(956004)(16526019)(33716001)(4326008)(66556008)(5660300002)(66946007)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?zfWWyngIfh/JcloCmFbbb1fBM6pdN6dF4hx5z+8UoCTi13ZX4S5DPAh9cPYL?= =?us-ascii?Q?T6EgOGFp4uYCCJ0oChWeavzFnVRPehYUeDINrfYNcrx4moG7vtjwqrkkxPoZ?= =?us-ascii?Q?MShvuqaAH8nYyPrHL+D7qhxuQpNH2DxllLwnGTqXuul0FgnLmb1zr2kx+ugI?= =?us-ascii?Q?U/do8uZsA5O7lFVPSNRQYS9x3TR2RyqmUcVLsCgwoWDN4jnQHJFKgZmjSsVh?= =?us-ascii?Q?pdjQu71EPjccEZuS1967g8eStdhUkeYoJhYo1+539QbvqUxoTyLxK2x+BoP7?= =?us-ascii?Q?K6ysIQsWbk9a7Rtf6NQGro1tqY+3ICLNPh4h230RsO5CsRyVtoCy+2xhtzK/?= =?us-ascii?Q?3gCpexdId81/bJygfCbhoHDcEmg+6a2DYw1Nyy6oHdE8aT9NSvokmlK3vBZV?= =?us-ascii?Q?PJyYpRPBub2iETqh/+xbf07HZRBLPAZpMaGQg9y89SZdIrr2OpXRYbT+bEpH?= =?us-ascii?Q?taksCepVz7rByuDf8y6CH7jp5IfUiUD77qu9spodIoeB1tgMCGn01u63Xldr?= =?us-ascii?Q?rcYHN8KOWTeWe+YVCx6QLvub9Iy4HvXyPufxSbb1wn++OBjBt8ffO6L7Sd9/?= =?us-ascii?Q?l+PBjyalcOEmUZG4m+jQ81RaiACzBMR0iW59OQO9e5pABTX7Zz7t2mkHuvJB?= =?us-ascii?Q?/QC2+n2DY2DXxfozfmg50LpaR0brA4uCMhz4i2PKdPYS+Vqne2zrpxoRFrxL?= =?us-ascii?Q?3IKhBvbYgSehSZkNfz8OyPG0gW6+aXpZt28Bb8vF5QGgoSqJJORjrkQzxnN3?= =?us-ascii?Q?PDwkFXWSDVgBSb5BC5d+mkIzUBo/S8MRay8sFYHgXCaLYyAJiBYFbDs+eXUy?= =?us-ascii?Q?gbqD82BO7iZ8Fp35g+8eW63QH5GOc984zLK+z0GZD6NfAZ+x5qrBzsgvQe8m?= =?us-ascii?Q?XTRLm3NmEBcUlptL2SempOTer8VkxmUN/CrmKkesP1xDwzvN3SVdCuPrB+EW?= =?us-ascii?Q?5M1isxfQRlFp45DiDv8N9tTlAx2bKVqRZUH9NdKPyxnvqrNlb99bCVxyAfr+?= =?us-ascii?Q?Myaz?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2020 18:41:20.6851 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-Network-Message-Id: f88473fd-7163-4a16-2bf9-08d8a1f22e86 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Dk3YMsU2ROy5fWOV57Gg/3iwxpnEWORtbtGF07+sCf+rT00rOmRzZKuKJTpEumaoT0epBHP1QuTRTAKeHvcyrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0294 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 16 Dec 2020 18:41:28 -0000 --g7pbxdvxqszxgrgs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jakob, On 12/15, Jakob Heitz (jheitz) wrote: > Ben, >=20 > Your scenario is possible. > However, it is only that: possible. > That makes it a suspected leak, not an unequivocal leak. Only because ASPA is not a thing yet. When it is, and we get to see an ASPA issued by 3491, I would bet my bottom dollar 33765 won't be in it. At that time, we can say unequivocally "that path is garbage", and drop it on the floor. > There are plenty of unequivocal leaks to stop. > Let's start with those and not bring down a lot > of unsubstantiated "suspected leaks". I don't think you'll find many more obvious than the one you picked up. But that isn't really the point. Cheers, Ben --g7pbxdvxqszxgrgs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/aVMcACgkQOkYk/rSL aGBKGg/+J+NbP2UyTcYsN6xPVd7yCrwEXM281hKj0RKi0u/2dAMtFiu+gRk2Wz4m pej16TKDKKTlKIqTMCwQZq3pF/SyfoYZpGCkDQo72sR6EhCq1NeW5XQfo79bnCa5 AeIbVbY26XeXOQ7eon3c8J4TXKI7LceChopVWm/aKC/+8t0CbmyhEe+87nFoq+8y oIaf7jy9KGBk72TMMfWHNKqET1D6cyoEGHtaOmiI/AmDNIA/6FejGGFVSI/AkyWD QYtfju6DnjOSQ5tIZpNHj+fhQKJAwfPd5G3/xNnFcUbEkRwAesQoj4YoVt020LWp wwxeMdnOBsuDDlKeKMUchv0RfO9ZNyUlwT4go4GskW6LaaoIEsgJiMA5NJmKBCF+ YKZSKV7QEpvPR+S2zjkr9OYKZGOSLHU3dMGoLppF62ZmtjdISKfkjJ7fHHPIkRm+ 1UKMlOgtK/IYBdsQBYncZQixHX1XvBd+Ji3NP2zSrSR+JTECS2KGapkwJQJ17Y0N UXlmnx5kf7EZqRLheQYrwSSp+12do2WV7F5y2NnjBD2AA4b0hmkg7Ht/QNCIsiXZ KtpWiA/BklR1viGrYFRFHokadVekW18zmppPvbulJr1+/A92gmkPp74O5mUwOUAy 8FN7+rDoH2YOHLry78+jydDD6YsJJyWwwkKbFKBXGPA0MKdqUlo= =hoRm -----END PGP SIGNATURE----- --g7pbxdvxqszxgrgs-- From nobody Wed Dec 16 11:58:01 2020 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 C32E73A0E93 for ; Wed, 16 Dec 2020 11:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FvTBYLtL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xUBi7yhD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORgodBnoHSeG for ; Wed, 16 Dec 2020 11:57:58 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036C83A0E94 for ; Wed, 16 Dec 2020 11:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1866; q=dns/txt; s=iport; t=1608148677; x=1609358277; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RBNiMMQJ1LmQBwGDg4n4iMgdGrq+Td4+Tss9DbJxQHg=; b=FvTBYLtL3Me1nnZD1kMlYP1Tgy/b1TlvyW4KsGQHCL9rfDWr0UfkKrUy 6p/gpEyCrxj+JejHVQT2U7vRd1FJfmudBMSim/Btqpwu3y9PUy+SBFNzc XyB+7v53rW0Tm4jfM7ZO4QDY7uZuTh4DCnuzvLV5VeDJvlGtgEVmrPGIq w=; IronPort-PHdr: =?us-ascii?q?9a23=3Ab+nsxx+JrCyQLv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZhSN7+9kgVXUR4Od7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkJPEcv0ekfU5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQBjZtpf/5xdJa1iGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBT4FSUQd1Wy8uiAcDjVsDmQqCUwNUCwEBAQ0BARg?= =?us-ascii?q?LCgIEAQGEBkQCgXACJTgTAgMBAQsBAQUBAQECAQYEcYVhDIVyAQEBBAEBEBU?= =?us-ascii?q?TBgEBLAQHAQsEAgEIEQQBAR8QJwsdCAEBBA4FCBqDBYJVAy4BDqIiAoE8iGl?= =?us-ascii?q?0gQEzgwQBAQWBNwKDexiCEAMGgTiCdYowJhuBQT+BEUOCVj6CXQEBAgGBXoN?= =?us-ascii?q?IgiyCEoEZDUQCExssPAciKl+mWZE2CoJ0iSOSSqI9nxKWGwIEAgQFAg4BAQW?= =?us-ascii?q?BbSOBV3AVO4JpUBcCDY4hg3GFFIVEdAI1AgYKAQEDCXyGfS2BO1wBAQ?= X-IronPort-AV: E=Sophos;i="5.78,425,1599523200"; d="scan'208";a="571782053" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Dec 2020 19:57:54 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BGJvsxX021601 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Dec 2020 19:57:54 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 13:57:54 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 16 Dec 2020 13:57:53 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 16 Dec 2020 14:57:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ox1NQY+6oVu5VOHwWDvLgFN7V3uJKKVk4S8J7ljWf6enG/vLmo/M9Jqitq5v1yTK/U3iszN3GCplvPkcZ84GGleopI4JgsRO6YkFHxLLrg8xTf9mf1Oq92YqFZu0FS0AiqhJG8FUm83Di2WfP3/9VQDqFR98TBAVXSTiPiSUBI96V3N5wdsLdo8BOPdUpht5XNHr8out7mGG1TLYZ23VJ25Ff5qAigydNb2EhAwMwrFwGqUahPdPQ5qd0UlrOxENAKLw+EWkySOdDz3f/6Ajzuflr0jftzLZwq1Zq/fApElMD1KuPf09IUVyplb8WINYHXeEk3/3ghZOCG6eJDhz6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ynn68dFr0Dc8+NjPw4XxiM2U6Ran1I4Ocx7wqZ+g2wc=; b=icHRhq0orR3nZBKghRkoFgh5UIKMyahZeIhK2FAgX2/NY7b6yk3sbOXd8WciNXfcPAzjBkuIrrSI1J7rdILC5hd3Ekyki53QkE2GFo2Aipz2r/vFjrYDM6blIcuLzvPz3ene6DGz0wouoUbqveQt3AN5mzE+iUzWWxQ12IYhJumOxpU8hfKPicvoAEDPfmuHqDrbuery6IdaOtqVy8wWhAWvynBnvTej7z/5bfTxlGHfZkS/GTApRhoaVhc3bEUZuICqrSuXgp3ccd33HwkLbApxDH9tR2WTGz1Bw9qnCc8aYZakLEdvBZM02hLolSiH2FDsOKMe96X/94KTpbmjCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ynn68dFr0Dc8+NjPw4XxiM2U6Ran1I4Ocx7wqZ+g2wc=; b=xUBi7yhDKzbifoa+21PTVupOkMCIYQEagcje1enyOprXbb/OMHNE+DeEqU/GrcumvY7sJeibphCcdzaFMLZt2qFoPYzDJUwvp2E623YR1Lv8oNLsdphQkLeantCjXODOK1ZI4N8hBlx6z/w1h5d4AC8JVfEIuo+XdModciVU8tM= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by SJ0PR11MB5149.namprd11.prod.outlook.com (2603:10b6:a03:2d1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.13; Wed, 16 Dec 2020 19:57:52 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Wed, 16 Dec 2020 19:57:52 +0000 From: "Jakob Heitz (jheitz)" To: Jay Borkenhagen CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ASPA: Is this really a leak? Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wBHfvcAAASgXmA= Date: Wed, 16 Dec 2020 19:57:52 +0000 Message-ID: References: <24538.14458.724169.315853@oz.mt.att.com> In-Reply-To: <24538.14458.724169.315853@oz.mt.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: braeburn.org; dkim=none (message not signed) header.d=none;braeburn.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:e82d:ab03:2132:19e4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7db092a5-7b0f-46eb-9a8c-08d8a1fcdf96 x-ms-traffictypediagnostic: SJ0PR11MB5149: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: reFwzqkBKRSD3LdT7kirIipuF+Mb4PLyxreiJEP+JvYMssPSWcYb0g1GIo7PY4Zg5pv/E5sDTIuKZGFNdfoe4YOSgHd/kbtD+ly8Wx0vOiSjnSkRfQKgO75LM+vG8TlZ19L98gugWeCowrWLijnIJFngMGs8ozkTQlo6qzw+/4OrcS9FyCKQSS9uzAUqBR2Aas7Do0CjKe4iXt606bbSbS1kzN31OypSo+Psk76Cc1CXuMheDePla6UFECmxQA6IlLY5JhbGiSNHlOUOLK+shSo2cFqbjMWelmzHFttBYG1+MNdItYT0rmlo2Q3BTMJirF4MencVrN5vqm+repHH2OCFoA+FARksx0SLSW9qKO5KYrTMfkazG6EFqCEeytIl1XDSRCj5FhqQSGp5EpG7pA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(346002)(396003)(376002)(66946007)(64756008)(53546011)(66446008)(52536014)(66476007)(316002)(83380400001)(8936002)(66574015)(71200400001)(66556008)(86362001)(55016002)(8676002)(5660300002)(9686003)(966005)(7696005)(2906002)(478600001)(186003)(6506007)(4326008)(6916009)(33656002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?iWTL+vLO62SJMYJ6hsy56ZC5709A8xdwuylhYSqYaZiSFTGipHx9MKz45lMB?= =?us-ascii?Q?BE/boQwRpCEmYCAfH9rVUccAxHe0JInLDSJ2srK9I7spbfG85tuYC9BYj3cB?= =?us-ascii?Q?qlLwxjtnrcJmFdPI8W1rAnYcj3mXDthv9aOExDWIU2BS6O3JnAcbCBigP3iH?= =?us-ascii?Q?6Xk7kehpQH24+NSEoTVjrKsaJh3Yse4K/UYfhA7Dj3UP1w1YBmCHW8/t8wQw?= =?us-ascii?Q?mNMbEqnQB9HL3etvfHkDtmhE2/1LzzNl94CQeXoQypa+7VjypGk7RTRMdYqD?= =?us-ascii?Q?WoyceAxxBXWtigU/Aw7fwi+PErz7B40xFMArHZ059kwMTIEYs/08uI9/cfC4?= =?us-ascii?Q?AuT+qoUrmNX2aThOihZUMdl3XtFmHitufEdVZ64bV6f2ZqJzCF207TQuc+et?= =?us-ascii?Q?FuYBK6OqmEFdT2Bm3jXBJGpwd/J0EqXFRv+LeJqAbmBJIAbkjzNsbInXxzhz?= =?us-ascii?Q?TN0vZU3ydQK3slRyT49pK4L+lhDj3UPeh7+UTevKnkbpJENwksThRki13EEM?= =?us-ascii?Q?3nPQ8TkZP1mdv/c52sbNvWNeGbMh081EsbFsFuelsUTDR6CgXr7wYk8I6hED?= =?us-ascii?Q?+YLPxH9qZSVVE6Qh1sABkGS0MczEp+Yx7qFeMftiNlLFly9sLpfjtK8SyElb?= =?us-ascii?Q?vSNjIOoRm+4ZWxKzedCxGNRaimEEKrfXaLd9zgRUDQw+BNJwcAB8QcsrVmUj?= =?us-ascii?Q?eWDgmrOjVd/0uK0pEak8uKldG/HFjxzP24ZXmYWaLIVbThBSmT442yyBk2IU?= =?us-ascii?Q?saHnIj2ShuZjYm8egCJ2tfTjKb8sc+ZAij5Op9B3LLvhIL6dzOVC1J78/ceM?= =?us-ascii?Q?ghyMFKkqPi1zFxy7CMul7YpWUOjRbdr7zJ+g2M8rFYoYHxltmHlp/U4DMQWD?= =?us-ascii?Q?OkMrIgE9D2NtGuijxx8NSY64uYu1EtTAe4yn/n5qqlF7pxk+BOm925CvE4U5?= =?us-ascii?Q?YJ5m/1Dq7v+iZ1MHYIcK6cCQkiBKTNgoZnLuWJi9hvJJN6qxkspuXAJU1vWu?= =?us-ascii?Q?788fjCtAuY9OTmiBUIJFoTsKzRka9L1l1M9FDNPZeFo906A=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7db092a5-7b0f-46eb-9a8c-08d8a1fcdf96 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 19:57:52.5686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lVSN74lB7YiSFkie5Dne21yg+vAZiKCx/pLj8CQzcDrE3FSsm4V9fWZzNi/BnAO8xumiAV//s2SAXwXldO+t+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5149 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 16 Dec 2020 19:58:00 -0000 Jay, I disagree that the algorithm in ASPA rejects routes whose AS_PATHs are contra-indicated by the expressed wishes of the AS resource-holders, as communicated by the set of validated ASPA records. I posit that it rejects more than that. Suppose AS1 has providers AS2 and AS20. AS20 is also a provider for AS2. What I am proposing is that AS2 should be allowed to divert traffic that it received from the Internet through AS20 on its way to AS1. Internet --> AS2 --> AS20 --> AS1. The algorithm stated in ASPA prevents that. Nobody is breaking any laws or contracts by doing that. Nobody is seeing any traffic that they are not permitted to by doing that. This kind of diversion happens frequently on the internet and ASPA should not prevent it. The big difference is that AS2 is a provider for AS1. If it were not, then ASPA absolutely should reject the path. Regards, Jakob. -----Original Message----- From: Sidrops On Behalf Of Jay Borkenhagen Sent: Wednesday, December 16, 2020 8:40 AM To: Jakob Heitz (jheitz) Cc: sidrops@ietf.org Subject: Re: [Sidrops] ASPA: Is this really a leak? Jakob Heitz \(jheitz\) writes: > https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-06 > finds suspected leaky AS paths. No, not really. draft-ietf-sidrops-aspa-verification rejects routes whose AS_PATHs are contra-indicated by the expressed wishes of the AS resource-holders, as communicated by the set of validated ASPA records. It's thus up to each party publishing ASPA records to ensure that all necessary upstream and mutual transit relationships are explicitly authorized. Jay B. _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Dec 16 13:11:29 2020 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 BC8B63A109F for ; Wed, 16 Dec 2020 13:11:27 -0800 (PST) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=ltri.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ysW_5I1oVC for ; Wed, 16 Dec 2020 13:11:26 -0800 (PST) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE223A109C for ; Wed, 16 Dec 2020 13:11:26 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Cx78r6TchzQl92 for ; Wed, 16 Dec 2020 22:11:24 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltri.eu; s=MBO0001; t=1608153084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GhCvgms7tax/mDHA1GuAHSHy9Nnb3idzcacakT2+qUk=; b=m1lT5kAUWS+J+H6OykRJ9AcQaoSCIJlYPRSVpsC2zIYaWSWj9digSV/D8JTZFmwy3w+VIM CLcVTkc0o3v1NYqby0/yiYFRmF2TAZ10kLa8qpdQPMD2/123poAGl1Lz3o4T2a0X4+UzCb o0VcYVy93gKttAxSqDkzj2C/XDvMbu0LxtxcWw9u7/RvkHrVx2TAcKqHFvdPHiCVMX8wx3 IE+h7V0Coth2zkVHXkrZn0E2c7JCyjzASyGkCxF0jGjUDDfWZlexb2ZlPQb/NoKLOe1R4T 7dqMC+kJOJsIxB23yqASJOWbj0Qnt31dwtuShAUzvIv9Uvh0poqd2k7X+Hk4LA== Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id W_hKYh7GFYCO for ; Wed, 16 Dec 2020 22:11:22 +0100 (CET) Received: by mail-il1-f175.google.com with SMTP id q5so3314990ilc.10 for ; Wed, 16 Dec 2020 13:11:21 -0800 (PST) X-Gm-Message-State: AOAM533RZCwul23u/4ERTG9jiZOwuaJ2mxFJKn0Nce2T491m9y0NEcaz 8kY1PlBzal1ZWaFOFcyIXMcRa0ad3cUGwWOnDfI= X-Google-Smtp-Source: ABdhPJxmDmyycR83Qpi6/gCYs1wjRUJ6ubSItNWPCS9s8ST1XpypNaqeFVK/EWTcho66kDF4NZMKfwS7QEqTzg09m4k= X-Received: by 2002:a92:ba82:: with SMTP id t2mr7459943ill.139.1608153080004; Wed, 16 Dec 2020 13:11:20 -0800 (PST) MIME-Version: 1.0 References: <24538.14458.724169.315853@oz.mt.att.com> In-Reply-To: From: Lukas Tribus Date: Wed, 16 Dec 2020 22:11:08 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Jakob Heitz (jheitz)" Cc: Jay Borkenhagen , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" X-MBO-SPAM-Probability: X-Rspamd-Score: -2.56 / 15.00 / 15.00 X-Rspamd-Queue-Id: A33E51833 X-Rspamd-UID: 7c91b2 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 16 Dec 2020 21:11:28 -0000 Hello Jakob, On Wed, 16 Dec 2020 at 20:57, Jakob Heitz (jheitz) wrote: > > Jay, > > I disagree that the algorithm in ASPA rejects routes whose AS_PATHs are > contra-indicated by the expressed wishes of the AS resource-holders, > as communicated by the set of validated ASPA records. > > I posit that it rejects more than that. > > Suppose AS1 has providers AS2 and AS20. > AS20 is also a provider for AS2. > > What I am proposing is that AS2 should be allowed to divert traffic > that it received from the Internet through AS20 on its way to AS1. > Internet --> AS2 --> AS20 --> AS1. > The algorithm stated in ASPA prevents that. > > Nobody is breaking any laws or contracts by doing that. I disagree. AS2 is breaking the contract which is that it won't announce my routes to non-customers peers. The fact that we are talking about AS1 originated routes which is a customer of both AS20 and AS2 doesn't change that. AS20 AS1 is an as-path that AS2 must not announce to non-customers, unless specifically authorized by AS20. AS2 doesn't get to share AS20 routes, whether the origin-as AS1 is a common customer or not. AS20 must decide whether this is acceptable or not. Not AS2 and not AS1. > Nobody is seeing any traffic that they are not permitted to by doing that. I disagree. If I'm AS20 and my customer AS2 shares prefixes with non-customers without authorization, I will order AS2 (my customer) to stop. I don't care if those routes are AS1 originated. What if AS2 has insufficient capacity to deal with the traffic? AS20 has SLAs with AS1, but if AS2 suddenly thinks it has to be a transit provider for AS20->AS1, then AS20 can no longer guarantee those SLA's, because suddenly AS2 will pick up the traffic. What if AS1 specifically disconnects AS2 to route around temporary technical issues in the AS2 network? Now AS2 is still involved, despite best efforts of both AS1 and AS20 to not traverse it. This is an unauthorized announcement (unless AS20 says otherwise), and a nightmare with real technical and contractual consequences. If my customer AS2 insists on doing this, actively impeding my ability to guarantee SLA's to AS1, then I will disconnect AS2. You can bet that I will have the legal/contractual power to do so. > This kind of diversion happens frequently on the internet and > ASPA should not prevent it. It happens frequently by mistake because of the use of static prefixes list instead of BGP communities. It also causes damage. If this basic and common leak is not something that ASPA prevents, then I'm afraid a lot of network operators won't even bother with ASPA. > The big difference is that AS2 is a provider for AS1. Your opinion is that this changes something. I'm saying it doesn't change anything at all. The example you provided causes a number of issues for all 3 parties involved. Nobody wants this: AS1 doesn't want this, because it cannot reroute around technical problems in AS2 by disconnecting it. It is multihomed for a reason. AS2 doesn't want this, because it would just give AS20 free transit and overload it's own network with traffic that is not generating revenue (but may happen erroneously due to static prefix list). AS20 doesn't want this, because it will be unable to guarantee SLA's to AS1 when an unauthorized transit provider is involved. If this is something that both AS2 and AS20 agree on, then the proper authorizations will be in place and all is good anyway. - regards, lukas From nobody Wed Dec 16 23:50:02 2020 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 5CDF83A152C for ; Wed, 16 Dec 2020 23:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g6jqMqJe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=R9ILUZaN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5ydgTzaLuum for ; Wed, 16 Dec 2020 23:49:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921EE3A152B for ; Wed, 16 Dec 2020 23:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5482; q=dns/txt; s=iport; t=1608191398; x=1609400998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=g6jqMqJel1UpmtN2CgbcrE7eT49acJ+bXVDbRkC6iCXCSXO+8i0qoe8v V00+C9AlPxuHonKeGxOJt5Tp5VMQqF2kAc3GMlTzaJk8+Q2VdMJhKNyd0 G9LaTL0o3rb8vap5qpwtjIWFwwBsedTvwKsdeAxV4AvtOp9L4BZHMD+EG w=; IronPort-PHdr: =?us-ascii?q?9a23=3A4dfkOR0qywYQj4pPsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGvadpkEXIG4jGuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHWnK0kTFdutL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAAA9Ddtf/49dJa1iGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBPgMBAQELAYFRUQeBUC8uhD+DSAONXQOBBZgHglM?= =?us-ascii?q?DVAsBAQENAQEtAgQBAYRKAheBWQIlNwYOAgMBAQsBAQUBAQECAQYEcYVhDIV?= =?us-ascii?q?yAQEBAQIBEhEEDQwBATcBBAcEAgEIEQQBAQECAiYCAgIwFQgIAQEEDgUIGoV?= =?us-ascii?q?aAw4gAaMTAoE8iGl2fzODBAEBBYUwGIIQCYEOKgGCdIJqTkKGNiYbgUE/gRF?= =?us-ascii?q?DgiE1PoJdBIE/IIMVM4IsgWkpNS4OAWIIIw4NVhIpKQFfkwKlDQqCdJAWi1e?= =?us-ascii?q?iPbBbhFMCBAIEBQIOAQEFgWwkgVdwFTuCaVAXAg2OIYNxilh0AjUCBgoBAQM?= =?us-ascii?q?JfIZqAiYEA4E4XwEB?= X-IronPort-AV: E=Sophos;i="5.78,426,1599523200"; d="scan'208";a="844374967" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Dec 2020 07:49:57 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BH7nvpP016387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2020 07:49:57 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 01:49:57 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Dec 2020 02:49:55 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 17 Dec 2020 01:49:55 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dFXqe/TUBbBrXHmH+fvKey/fkE6oaGqE8O9cckUHk9IdrbLP/j7eXeqmqo1xDuLDQfcHDWlCffXO+kSm/DmLN+rK3ZPf5NGh0ZVztk3pmfg4sFxkAoMetsMcfZ+xbED7I8lM37k2YpXSTUJP180cX7mcjSs/k9oxLCBpKaloPKpjYaFN21s0UIW6MoP3Ex4YPzP6WQABw+NmKLwJZhZnD72OmPkDfg4uX02bBE4Q4Mmw6YYLTM1LsfWYNWsN3VzWVGk68CGEmY4YL+pDZiCXudHQoi5U7REEbrycIq+6S11Sy4Czk/99pjvr0wG+ONaNWumbiJ2cJY1YM0aRBdRCyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=UA5FWl1A9jbV9yt2EaFxleUih5QZ9dmXYhu48HcFq5mt39FlNtunkL+ra7rTiYYa15j2F+HQeo4eb4q7rRNP1PG9Kk2mixKuq2sdLcmZkYeGH33zOtOvGSSWF4RVnCIniVd0Rit20EOzWTNmhiJU8MV6OgRTDviTRNdkOUp6UFK/GCHHpR6dJKb/rgH0DhPfBh02KSRScmQ9ESOdsyNDNvKDNTdgSLeEHSxNvYdxjz8E+r7rtkMyiNc8urQfQe1NV0qmtaim4+2TRye/Sso1mNMC9vAHHjOcE2iYkD/pLGNRH8FFuoM8zO7qYI4o/TPrqj3ym3k/vSqP12NHOb8PKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hAf8bCjmk1oltLAXq2OFVrtP4CNkrE/8QRlKVbBBIhc=; b=R9ILUZaN9ASgxG1nEHvdZvapsNKNoCNwIVTKGYU4l8qs5+P0ymJ0lAANrUpvZeVCQcmQIKeF3Q12cfJ4mTzYAS3JpM2AyDp3CVFJR8VlgQmZjYJWKXOaePgsHehuP1NTm1ystZxTLkWdBUGpzOjKACQsp0CxMq5ptwMOVPFnhlE= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3335.namprd11.prod.outlook.com (2603:10b6:a03:1d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.19; Thu, 17 Dec 2020 07:49:53 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::2581:444d:50af:1701%4]) with mapi id 15.20.3654.025; Thu, 17 Dec 2020 07:49:53 +0000 From: "Jakob Heitz (jheitz)" To: Lukas Tribus CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ASPA: Is this really a leak? Thread-Index: AdbSrCwFetkGBNO+QeG28ivY3Q354wBHfvcAAASgXmAABNPhAAAWKsvg Date: Thu, 17 Dec 2020 07:49:53 +0000 Message-ID: References: <24538.14458.724169.315853@oz.mt.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ltri.eu; dkim=none (message not signed) header.d=none;ltri.eu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:647:5701:46e0:e82d:ab03:2132:19e4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f4df225-c0bb-4fc7-dfe6-08d8a26056f3 x-ms-traffictypediagnostic: BYAPR11MB3335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FCDTr+wxIUidipsy3ml1AddI4KCg+W0UkvynOmVr4uTny2dzY8Ugv0vNRRQIGtfDUsc14iMeZplgDpImg7b9HHarLp39eVqF+0Ghs1Ts5xpIM5hNKRNrooPArXnEy67mrcoCrnJhA1N/9kJBX5Hlt/zcjsN7QQ6bj346yRK8YuoqJOk9Pkn3OJhur+ETbixAwUy9yjywcnay5gPdEwvhregpTcaq/7S9cyvalXfr3IsBKtQTc/tCZVcWxICHXBFQLonnVBE8vnza7RdoCNE9EF+OYtUoHcPNIRHC8lw7HUihNkkViNWZiP23CO5CSI9e x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(396003)(366004)(136003)(346002)(4326008)(66556008)(186003)(52536014)(316002)(478600001)(6506007)(86362001)(5660300002)(66946007)(66446008)(2906002)(64756008)(33656002)(7696005)(83380400001)(8936002)(66476007)(9686003)(8676002)(66574015)(6916009)(53546011)(55016002)(71200400001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?dHNCSTUwTkk3STF4WUlJMWZnbDBWTCtwRkpEZnNmS2V3L1pVT0RDTER2Rndh?= =?utf-8?B?WEZVN0lWVHJHV2YwWTJ0K0hwSnN2azZWc0FXRVUyTWJUOTE0M1VCZVhwOVFS?= =?utf-8?B?NEhrMjRmemFONjc3M2svZnRCWjhaM3hPamtRRklUelFnTmtYRGwrOHlBUG9K?= =?utf-8?B?NFJmV2VHOHBFMHREMlBkeDBOSEJjeFZJcVFNVEtPOVpGL05vY2lUNXhCRGZ6?= =?utf-8?B?ZjhBT2l2NU5hWHZIQXVpWU5DQjdyaXBXbXFCTFVFZ3N4RnUzQ3hBckVoRVI0?= =?utf-8?B?WDVFMFRQOUl3Q3ZQMm5pYllzZWpOMGxqYUxoWUw2NmoweG5KMkRiM1cxQUJ6?= =?utf-8?B?VFJta01na2VGMmthNHRkU1J3WUVCN2FoNEhlOUNrRVFMMUtiYnU3RllDYTNu?= =?utf-8?B?YmxqVGJvcXprNzZ6bU9MWnZVSWQ4ajhENnliZ2VBcThPNEhodGtad0pjSmIx?= =?utf-8?B?ZWxKV3QyMHZ4ZTlpUHROMnBFZi82YlA0aHgrbzByM1M2dHlSZVh6dGFpSTQy?= =?utf-8?B?TGxoZDkxQmdVVkJrM1AzM0ZmL2NORlBFR0xvL1dqOHFnSGtDTG1UeENHZHRV?= =?utf-8?B?TXNKbE9kUTBzWTFBcTBEZHpFMVNFOHM2cGFYZ3VPWmdQdkQ1MjBJdlFHZnBO?= =?utf-8?B?WVVPWHFMS2ZNd0pTcEhRcHlqRUJnd3ROQ1RsSmRhK1JXWkJrUXo0dkxPejR5?= =?utf-8?B?aHVaQ2FqakdTWEFmdXFVbkJIODI5UzVmNElzTi9IMFRONlRYM0Y4NW5JcjF5?= =?utf-8?B?U2U5MXk3T2IvRkhQdkFuZG5XaWpaVkdKQUc0eDNSSTdVREVFdlBzVGMzUGVv?= =?utf-8?B?OE0zR0ZMTEcwRTFtV253Zys1Qm84OWVvdEJhNko2eWpmVmJyUFp5K0lWTTRR?= =?utf-8?B?T3RmUndpcndMK2djNEdua0JvSDFqS2tMSSsyM0N5MUxPamQwU1hjZ1hjV292?= =?utf-8?B?VHhwUCttVE5rUThmSHY5aDYza0VWZDhJOEIyM3NSR0oyN1dLME1CQ0RLaTJZ?= =?utf-8?B?U2IzSGdEVCtQTnJ2MVl1NDBzdmZ1TEdxYWRYUmNTbjdRQUQ4RUI2cVdDRjFa?= =?utf-8?B?Q1ZXR09xd1lWNWNiZzZLZGd5UjRkMEttd0c4Mkd6UU1ubDU5M3g2N09sajlM?= =?utf-8?B?QXF2QWdjczZ1MlNIMTVjak1kd29OS3BRSVlqOVEzRjBIZkFEMjdFK3I2TUZK?= =?utf-8?B?QWR3Z056MEh5NGRkKzlOMzMzYnFOK3dTYXlDcVhzQTVRc2lSWDEzc2Rta0Zy?= =?utf-8?B?cktvUDlwanNod2RsRzc0NjcwK3llMUxZT2JzY0cwREVaTnBnbnpkeTJ2bHl4?= =?utf-8?B?WVJQYUIvSXQ4SEtvS3Q0aGhSbjZ3WG11YVZXY0thWEVZdGtubm9mZ2JocEJK?= =?utf-8?Q?yNR/tj5GJ+TAMSKmOkEiSOguJahY5HRM=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f4df225-c0bb-4fc7-dfe6-08d8a26056f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 07:49:53.1398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 45NpSzd5tEkMQj8p2WhzOed801+txeorvv/H1bic8XxMPPBO6+nLv8NpBuxX+2xs+xPSIwtS3VF6KxsB7NEFzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3335 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 17 Dec 2020 07:50:00 -0000 VGhhbmtzIEx1a2FzLiBHb29kIGV4cGxhbmF0aW9uLg0KDQpTbywgaWYgQVMyMCB3ZXJlIHRvIGFs bG93IHRoaXMsIHdvdWxkIGl0IGxpc3QgQVMyIGFzIGEgcHJvdmlkZXIgaW4gaXRzIEFTUEEgcmVj b3JkPw0KDQpSZWdhcmRzLA0KSmFrb2IuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBMdWthcyBUcmlidXMgPGx1a2FzQGx0cmkuZXU+IA0KU2VudDogV2VkbmVzZGF5LCBEZWNl bWJlciAxNiwgMjAyMCAxOjExIFBNDQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBj aXNjby5jb20+DQpDYzogSmF5IEJvcmtlbmhhZ2VuIDxqYXliQGJyYWVidXJuLm9yZz47IHNpZHJv cHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU2lkcm9wc10gQVNQQTogSXMgdGhpcyByZWFsbHkg YSBsZWFrPw0KDQpIZWxsbyBKYWtvYiwNCg0KDQpPbiBXZWQsIDE2IERlYyAyMDIwIGF0IDIwOjU3 LCBKYWtvYiBIZWl0eiAoamhlaXR6KQ0KPGpoZWl0ej00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y Zz4gd3JvdGU6DQo+DQo+IEpheSwNCj4NCj4gSSBkaXNhZ3JlZSB0aGF0IHRoZSBhbGdvcml0aG0g aW4gQVNQQSByZWplY3RzIHJvdXRlcyB3aG9zZSBBU19QQVRIcyBhcmUNCj4gY29udHJhLWluZGlj YXRlZCBieSB0aGUgZXhwcmVzc2VkIHdpc2hlcyBvZiB0aGUgQVMgcmVzb3VyY2UtaG9sZGVycywN Cj4gYXMgY29tbXVuaWNhdGVkIGJ5IHRoZSBzZXQgb2YgdmFsaWRhdGVkIEFTUEEgcmVjb3Jkcy4N Cj4NCj4gSSBwb3NpdCB0aGF0IGl0IHJlamVjdHMgbW9yZSB0aGFuIHRoYXQuDQo+DQo+IFN1cHBv c2UgQVMxIGhhcyBwcm92aWRlcnMgQVMyIGFuZCBBUzIwLg0KPiBBUzIwIGlzIGFsc28gYSBwcm92 aWRlciBmb3IgQVMyLg0KPg0KPiBXaGF0IEkgYW0gcHJvcG9zaW5nIGlzIHRoYXQgQVMyIHNob3Vs ZCBiZSBhbGxvd2VkIHRvIGRpdmVydCB0cmFmZmljDQo+IHRoYXQgaXQgcmVjZWl2ZWQgZnJvbSB0 aGUgSW50ZXJuZXQgdGhyb3VnaCBBUzIwIG9uIGl0cyB3YXkgdG8gQVMxLg0KPiBJbnRlcm5ldCAt LT4gQVMyIC0tPiBBUzIwIC0tPiBBUzEuDQo+IFRoZSBhbGdvcml0aG0gc3RhdGVkIGluIEFTUEEg cHJldmVudHMgdGhhdC4NCj4NCj4gTm9ib2R5IGlzIGJyZWFraW5nIGFueSBsYXdzIG9yIGNvbnRy YWN0cyBieSBkb2luZyB0aGF0Lg0KDQpJIGRpc2FncmVlLiBBUzIgaXMgYnJlYWtpbmcgdGhlIGNv bnRyYWN0IHdoaWNoIGlzIHRoYXQgaXQgd29uJ3QNCmFubm91bmNlIG15IHJvdXRlcyB0byBub24t Y3VzdG9tZXJzIHBlZXJzLiBUaGUgZmFjdCB0aGF0IHdlIGFyZQ0KdGFsa2luZyBhYm91dCBBUzEg b3JpZ2luYXRlZCByb3V0ZXMgd2hpY2ggaXMgYSBjdXN0b21lciBvZiBib3RoIEFTMjANCmFuZCBB UzIgZG9lc24ndCBjaGFuZ2UgdGhhdC4NCg0KQVMyMCBBUzEgaXMgYW4gYXMtcGF0aCB0aGF0IEFT MiBtdXN0IG5vdCBhbm5vdW5jZSB0byBub24tY3VzdG9tZXJzLA0KdW5sZXNzIHNwZWNpZmljYWxs eSBhdXRob3JpemVkIGJ5IEFTMjAuIEFTMiBkb2Vzbid0IGdldCB0byBzaGFyZSBBUzIwDQpyb3V0 ZXMsIHdoZXRoZXIgdGhlIG9yaWdpbi1hcyBBUzEgaXMgYSBjb21tb24gY3VzdG9tZXIgb3Igbm90 Lg0KDQpBUzIwIG11c3QgZGVjaWRlIHdoZXRoZXIgdGhpcyBpcyBhY2NlcHRhYmxlIG9yIG5vdC4g Tm90IEFTMiBhbmQgbm90IEFTMS4NCg0KDQo+IE5vYm9keSBpcyBzZWVpbmcgYW55IHRyYWZmaWMg dGhhdCB0aGV5IGFyZSBub3QgcGVybWl0dGVkIHRvIGJ5IGRvaW5nIHRoYXQuDQoNCkkgZGlzYWdy ZWUuIElmIEknbSBBUzIwIGFuZCBteSBjdXN0b21lciBBUzIgc2hhcmVzIHByZWZpeGVzIHdpdGgN Cm5vbi1jdXN0b21lcnMgd2l0aG91dCBhdXRob3JpemF0aW9uLCBJIHdpbGwgb3JkZXIgQVMyICht eSBjdXN0b21lcikgdG8NCnN0b3AuIEkgZG9uJ3QgY2FyZSBpZiB0aG9zZSByb3V0ZXMgYXJlIEFT MSBvcmlnaW5hdGVkLg0KDQpXaGF0IGlmIEFTMiBoYXMgaW5zdWZmaWNpZW50IGNhcGFjaXR5IHRv IGRlYWwgd2l0aCB0aGUgdHJhZmZpYz8gQVMyMA0KaGFzIFNMQXMgd2l0aCBBUzEsIGJ1dCBpZiBB UzIgc3VkZGVubHkgdGhpbmtzIGl0IGhhcyB0byBiZSBhIHRyYW5zaXQNCnByb3ZpZGVyIGZvciBB UzIwLT5BUzEsIHRoZW4gQVMyMCBjYW4gbm8gbG9uZ2VyIGd1YXJhbnRlZSB0aG9zZSBTTEEncywN CmJlY2F1c2Ugc3VkZGVubHkgQVMyIHdpbGwgcGljayB1cCB0aGUgdHJhZmZpYy4NCg0KV2hhdCBp ZiBBUzEgc3BlY2lmaWNhbGx5IGRpc2Nvbm5lY3RzIEFTMiB0byByb3V0ZSBhcm91bmQgdGVtcG9y YXJ5DQp0ZWNobmljYWwgaXNzdWVzIGluIHRoZSBBUzIgbmV0d29yaz8gTm93IEFTMiBpcyBzdGls bCBpbnZvbHZlZCwNCmRlc3BpdGUgYmVzdCBlZmZvcnRzIG9mIGJvdGggQVMxIGFuZCBBUzIwIHRv IG5vdCB0cmF2ZXJzZSBpdC4NCg0KDQpUaGlzIGlzIGFuIHVuYXV0aG9yaXplZCBhbm5vdW5jZW1l bnQgKHVubGVzcyBBUzIwIHNheXMgb3RoZXJ3aXNlKSwgYW5kDQphIG5pZ2h0bWFyZSB3aXRoIHJl YWwgdGVjaG5pY2FsIGFuZCBjb250cmFjdHVhbCBjb25zZXF1ZW5jZXMuIElmIG15DQpjdXN0b21l ciBBUzIgaW5zaXN0cyBvbiBkb2luZyB0aGlzLCBhY3RpdmVseSBpbXBlZGluZyBteSBhYmlsaXR5 IHRvDQpndWFyYW50ZWUgU0xBJ3MgdG8gQVMxLCB0aGVuIEkgd2lsbCBkaXNjb25uZWN0IEFTMi4g WW91IGNhbiBiZXQgdGhhdCBJDQp3aWxsIGhhdmUgdGhlIGxlZ2FsL2NvbnRyYWN0dWFsIHBvd2Vy IHRvIGRvIHNvLg0KDQoNCj4gVGhpcyBraW5kIG9mIGRpdmVyc2lvbiBoYXBwZW5zIGZyZXF1ZW50 bHkgb24gdGhlIGludGVybmV0IGFuZA0KPiBBU1BBIHNob3VsZCBub3QgcHJldmVudCBpdC4NCg0K SXQgaGFwcGVucyBmcmVxdWVudGx5IGJ5IG1pc3Rha2UgYmVjYXVzZSBvZiB0aGUgdXNlIG9mIHN0 YXRpYyBwcmVmaXhlcw0KbGlzdCBpbnN0ZWFkIG9mIEJHUCBjb21tdW5pdGllcy4gSXQgYWxzbyBj YXVzZXMgZGFtYWdlLiBJZiB0aGlzIGJhc2ljDQphbmQgY29tbW9uIGxlYWsgaXMgbm90IHNvbWV0 aGluZyB0aGF0IEFTUEEgcHJldmVudHMsIHRoZW4gSSdtIGFmcmFpZCBhDQpsb3Qgb2YgbmV0d29y ayBvcGVyYXRvcnMgd29uJ3QgZXZlbiBib3RoZXIgd2l0aCBBU1BBLg0KDQoNCj4gVGhlIGJpZyBk aWZmZXJlbmNlIGlzIHRoYXQgQVMyIGlzIGEgcHJvdmlkZXIgZm9yIEFTMS4NCg0KWW91ciBvcGlu aW9uIGlzIHRoYXQgdGhpcyBjaGFuZ2VzIHNvbWV0aGluZy4gSSdtIHNheWluZyBpdCBkb2Vzbid0 DQpjaGFuZ2UgYW55dGhpbmcgYXQgYWxsLg0KDQpUaGUgZXhhbXBsZSB5b3UgcHJvdmlkZWQgY2F1 c2VzIGEgbnVtYmVyIG9mIGlzc3VlcyBmb3IgYWxsIDMgcGFydGllcw0KaW52b2x2ZWQuIE5vYm9k eSB3YW50cyB0aGlzOg0KDQpBUzEgZG9lc24ndCB3YW50IHRoaXMsIGJlY2F1c2UgaXQgY2Fubm90 IHJlcm91dGUgYXJvdW5kIHRlY2huaWNhbA0KcHJvYmxlbXMgaW4gQVMyIGJ5IGRpc2Nvbm5lY3Rp bmcgaXQuIEl0IGlzIG11bHRpaG9tZWQgZm9yIGEgcmVhc29uLg0KQVMyIGRvZXNuJ3Qgd2FudCB0 aGlzLCBiZWNhdXNlIGl0IHdvdWxkIGp1c3QgZ2l2ZSBBUzIwIGZyZWUgdHJhbnNpdA0KYW5kIG92 ZXJsb2FkIGl0J3Mgb3duIG5ldHdvcmsgd2l0aCB0cmFmZmljIHRoYXQgaXMgbm90IGdlbmVyYXRp bmcNCnJldmVudWUgKGJ1dCBtYXkgaGFwcGVuIGVycm9uZW91c2x5IGR1ZSB0byBzdGF0aWMgcHJl Zml4IGxpc3QpLg0KQVMyMCBkb2Vzbid0IHdhbnQgdGhpcywgYmVjYXVzZSBpdCB3aWxsIGJlIHVu YWJsZSB0byBndWFyYW50ZWUgU0xBJ3MNCnRvIEFTMSB3aGVuIGFuIHVuYXV0aG9yaXplZCB0cmFu c2l0IHByb3ZpZGVyIGlzIGludm9sdmVkLg0KDQpJZiB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGJv dGggQVMyIGFuZCBBUzIwIGFncmVlIG9uLCB0aGVuIHRoZSBwcm9wZXINCmF1dGhvcml6YXRpb25z IHdpbGwgYmUgaW4gcGxhY2UgYW5kIGFsbCBpcyBnb29kIGFueXdheS4NCg0KDQoNCg0KLSByZWdh cmRzLA0KbHVrYXMNCg== From nobody Thu Dec 17 00:33:41 2020 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 A825E3A14E8 for ; Thu, 17 Dec 2020 00:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 rahAEbSsLlXV for ; Thu, 17 Dec 2020 00:33:37 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150083.outbound.protection.outlook.com [40.107.15.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83303A0FE8 for ; Thu, 17 Dec 2020 00:33:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dvkmijgLJUCKPguzfuL9RttnvSU4tz+cxoil3VBdBUqn6spC4SzWxWbwFHzPUKaIy3YjoXaX52Y/asa85xvaCS7oYYD0C9MqovUDMwHUHIdo7JK4p2y7IJSSoBmsPDgbRh/nDlU/LIiLsks+IsC/aN8PQDtfr5ueWOmwvC7zMmqJ4Cegnotwpl/E2QDMpMn05N4Vl9mg3e9TA0WJ+QQcU9dJgWSkh1O8xnfk1T2AQe6afWbCyY9uhvHQkObbCnFar5SPZFc5jwpNXIdZT+hW3L8CjMIJkP1I8H4tp2Pgrw7XhE2gbROmfpuVTfFjd7BTcQz9AYFCt01/nrQX/k4TrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RW8rWHwxx28vjYOOAwq5dSa13sECbx9oHRnXiznhHdU=; b=Lymm9QJmWodsPAj1wrsRRGwE3/qFEz1HGxOEJ1lbLgAPKW3F3uGk0/0M2NZrXTMruBrKZT0w45L0NwOiZETmigzus4dMF2vkB02MeXSqg0g+jChUK7T9+/ibOUerCRcNBZl0uBz0zUUlwfwGCspMqE+xeWNqBOgPPobJLg9AgcHeDqL+AelEItVE/LugozfdpG+lgxPMihtXk11RA6IWGaafhjv50RtxiOxkwNKo79JEbzEzZYbxYNZJdt3cscwGvQzgdcnJ0rJk7kAXYldvs1FjMqLeQDqbZ0C06a/NQ7TgveKBLf5DHgSWCxQYPMY+yomVEc8ILcZxVgD/RtzAyA== 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=RW8rWHwxx28vjYOOAwq5dSa13sECbx9oHRnXiznhHdU=; b=IjPzo0HgOvuAxdK+v5Ir9K+z1c6hG2s6/C4s/Esj+jTiOzb99w3U7MqYCmb7ownc6yvuH3+c2aAZfTTsqm9bqUZR8Dxa3vzcG4emSr2CZ1oq4Zc7jygpTVC+TfqNgZrbM0606JRM+fOhQpHkTneZf3xQWmYNwIvFvn9RZan1gx4= Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB9P190MB1225.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:223::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Thu, 17 Dec 2020 08:33:29 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::cdc3:7ba:4bf7:dcda%3]) with mapi id 15.20.3654.026; Thu, 17 Dec 2020 08:33:29 +0000 Date: Thu, 17 Dec 2020 10:33:23 +0200 From: Ben Maddison To: "Jakob Heitz (jheitz)" Cc: Lukas Tribus , "sidrops@ietf.org" Message-ID: <20201217083323.f44p7jy2x4kwglfi@benm-laptop> References: <24538.14458.724169.315853@oz.mt.att.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qmjo6f2kcvih2du5" Content-Disposition: inline In-Reply-To: X-Originating-IP: [165.0.73.66] X-ClientProxiedBy: CTXP275CA0048.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::36) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (165.0.73.66) by CTXP275CA0048.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Thu, 17 Dec 2020 08:33:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e8db37b7-2eb3-4943-3596-08d8a2666e64 X-MS-TrafficTypeDiagnostic: DB9P190MB1225: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bkozfmRDXg7ph9QDhYriZMY6O0/m6bv2T17zeF4tkrzMFuOfW1Zd/3nRoCBSwdlk19LrsIl9TfvNK0/itUw+IwjVeSQ7h7mWjmaCzcQko9RbDgeiivsdJCMKYhafOo8LANjWyU8Y+gs7ZS6C9kr+9VY/BaZFw01VGTqOx3yCmbNx+38lovi1zxyATwM1MGQPy5K/C3Mj2Y5plzn9nG+XjxuQYjskJFQ2N3mBJ0X1y+z6cEhWOvvTcrhem/3F5Oz0kgFRmTPefGNi62lFQ3bP8tXDJH888MjAj9HapsqnP4CgtYuXj7h5uPPpYKnCdIVlQbKRGZvXcQgRz7UoJxxeqGEoFdjpfMXLQD3K3RKZZL6+l83W5CXQsykSQ0cM7fqCSCzX8YpNBBprE8nHfTKbIg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(136003)(346002)(396003)(376002)(39830400003)(366004)(956004)(66946007)(6486002)(2906002)(16526019)(66556008)(1076003)(8676002)(33716001)(26005)(52116002)(9686003)(6496006)(21480400003)(8936002)(86362001)(6666004)(186003)(4326008)(5660300002)(316002)(478600001)(44144004)(66476007)(54906003)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?U/NNO4NkNb0XCF3R005rXXALTok5gVbV99VLm+bVt3sPxYRW9GNYnsZMmGpB?= =?us-ascii?Q?JHRRfdQD/YSQ5MsODJQHyscaFwXRw4cvdRAdwcATx82W+i9wprtT659NLMDD?= =?us-ascii?Q?82cc9+K87pz1OwqIW9edrN30NpNejdLGsEo7K2fWROlowKzwkaXasNen4Wrr?= =?us-ascii?Q?QAUhWX9ZPadBN/idHCoO4DRL4KDFXtV5cLdr5jxsQUfVqIEs/SehvW2xch7L?= =?us-ascii?Q?/RHQ8bsMp13MCIGGrG8j6WNBbHTw08/vUp5XDc7xtZxdjvn60o89+B0+MIKr?= =?us-ascii?Q?A7WD1Ca8XWx7H10Thh+twlMPQSQZP9oRCOzmr+IcYKW/dxIfGyTJEdO497k9?= =?us-ascii?Q?dKKWGgSxU4yKTy9fH/VuUqC/ggnKzVZAlvq6rYicGBld2jbwGZU4FTs6Us1Q?= =?us-ascii?Q?wyBpT3XX2jzviosXx6qqMV84Yx3FWmNV6i23Z86fMoX/RHQinPgYO8x95/JI?= =?us-ascii?Q?aDeOvMLDiXJy1E7ZGLhez5H6QfvevsM92nNcyDFmQLq1963uqvkYGVpVb1Ii?= =?us-ascii?Q?Cz5U2PTHS1X4Gr4dsBW1NtU4LxX903p0q1LqKP4y4Ch0e8CWsy/3Ft1tNqbB?= =?us-ascii?Q?l/m6Q2yezmKlBPJSaDM3AKXCt5qyxmeOihHepRncuzYO1zqeXMIA0MUID6Ui?= =?us-ascii?Q?vGEMbAUxwPbVSlo39WF/1TWIJoQ5Fe6XC4kJNyW7IAnWlkx8xo1rVxkXb37B?= =?us-ascii?Q?Jn67vRhDfuUIAd8hupb8ecSfpfQhxEvPFrQXVlS25qefKf3Flt4XtaPMwncF?= =?us-ascii?Q?YPTFVQ35Qerpww6gVCZjDbdLtL07NiLGK1bKYaGxkLmkLKOL4HQWqYmoIxMx?= =?us-ascii?Q?Z0T8iu/Mxjm3tCkpbYLaUtCOZo9knadFyJBSSHcjeGHi6lw7Q8FW2RWXAZoS?= =?us-ascii?Q?Az1NwPGqSubyBoHjFx47atRkElJh6kOGPaJHz4v8FvcwootzQnDUnJJDs0W6?= =?us-ascii?Q?L9nr8qldxzsJaa/8WdBxvblpaThHRGXFOolO9SD0+0Y=3D?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2020 08:33:29.4474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-Network-Message-Id: e8db37b7-2eb3-4943-3596-08d8a2666e64 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jTCmgJRliAPqb4SCNwQIXLZffmOz+V2qrmtWAVOisGRy6+DiUrOY5bkSb+78J18S6Y7yXQYSmDQZqfkevFlycw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P190MB1225 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 17 Dec 2020 08:33:40 -0000 --qmjo6f2kcvih2du5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/17, Jakob Heitz (jheitz) wrote: > Thanks Lukas. Good explanation. >=20 > So, if AS20 were to allow this, would it list AS2 as a provider in its AS= PA record? >=20 Yup, spot on. Or, of course, not bother creating an ASPA at all, in which case *any* of its neighbors would be allowed to announce transit for it. Cheers, Ben --qmjo6f2kcvih2du5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/bF9IACgkQOkYk/rSL aGDSOQ/9HTKcolMemOWkue/0rUB8nwclLHbpVX5pjfMBosU8coZQpFq8pFwkZvOl g96r6aWUmF5MJTUs9P0r3Ht+LO6Nd9wpj9brB9tYPz/4fuJm8yafmcjk0ZRmLkWO xLkxnVZMkDX+LmcATu/rxJ7cJKvoMHAj9RVUjcIDCSWpfXE3O4JKSlazDpg28ZxZ pQzlwSBBr485b4v90IyK4d6f54wbddrMgQDKlcxIIopwY8PNcrCNvkh5gyvQcziy ynhia5OwFOE1b/369jaAdX0mIGX47Aq8H0J3jTAuu3YpebPcAHB6ScnwNp1Oj3Vk 3enKk5ShVyi5qd7QoGnekHfgUqbZQ08nwrENpNu5b/q6JFULTjhLqMNW3gLx4oWP MZ2UeM4O9URqokTnyo2+cv4H5DwExM049gJwv+DxihfokDX/o5lmBHgnJAw4bHqP t5GEqhjFd0KWQdoAKozEgwXmACxaU00sfSF4BY4INWVmnARfavnzSJQRlND/FKJb M41Jbgab1D6uTN+JEfYqRLQfJ2Koyzk0/ZdzjgaFoOVwNynklqwxzHfGg9h4B0WP +LHjUZWKt3d4xbUgX4DjThR4Hea73apnl1LsY50y6jolaJPKtkptfbIftZZzMhFL rRhp/x0KReBNilYby3IYMQ+oQNjuUnIK5R+SkMw0WT6/vwOK1DY= =CQme -----END PGP SIGNATURE----- --qmjo6f2kcvih2du5-- From nobody Thu Dec 17 04:23:12 2020 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 9CA703A033F for ; Thu, 17 Dec 2020 04:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ltri.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE7eDcuV9ep5 for ; Thu, 17 Dec 2020 04:23:09 -0800 (PST) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712B13A017E for ; Thu, 17 Dec 2020 04:23:09 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4CxWNp65CVzQjkp for ; Thu, 17 Dec 2020 13:23:06 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ltri.eu; s=MBO0001; t=1608207785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kwQdUqX2eG5WWgLDI4Dj+i7dg0qiLnDvq2Jk6MZxUvE=; b=Acp9/1M4ksYSPEkDo10+u78w/CzbkywChxuhZxm44xiij6AuQef8J7iZv0XLKQAFQEpogT +kjZKDRNRtOWXy+WjL9mcZRfOgi6NjhirxOXt5Nfr/lrowsKuttpS/vRRGi12p4wijD3/u QKHwZ1D+YcO8/UegDZ+gYMb8qrxZb2DrxYLc615AYsrxBEgth6KzhoVmdwmMzBO5HfvCrB UaJSbuvZMVLDBw86wBUh3onfeRizqcGS7KpRnZhjFbAiMbpGQE1krV10JiTJAQuUx+70WU TaCCEDD/pAGO/Xqo3os1m/cPUpWhop0Tl8TWTXL42Ijoo8fNYuIAOWciBrMVyA== Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id ngchkCeqwPsy for ; Thu, 17 Dec 2020 13:23:01 +0100 (CET) Received: by mail-io1-f51.google.com with SMTP id q137so27280939iod.9 for ; Thu, 17 Dec 2020 04:22:59 -0800 (PST) X-Gm-Message-State: AOAM533KWJh+om4dYrhch7JbpE03JC2Tpvhkceo722h9mMGS/7zv9Ko4 GP9EC4MR4NV44lrka/adVnyXKQ3YBXs4eDQfpaE= X-Google-Smtp-Source: ABdhPJxhKBWV9sS9XKlYOZLoOVmKeP373QALnLIBsiMkUgk9wu3gOv4q1c/Odbgpb8wPl0CnY5qBMgQF2jQ/1PiF4d8= X-Received: by 2002:a5e:dc43:: with SMTP id s3mr45977168iop.101.1608207778197; Thu, 17 Dec 2020 04:22:58 -0800 (PST) MIME-Version: 1.0 References: <24538.14458.724169.315853@oz.mt.att.com> In-Reply-To: From: Lukas Tribus Date: Thu, 17 Dec 2020 13:22:46 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Jakob Heitz (jheitz)" Cc: Lukas Tribus , "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" X-MBO-SPAM-Probability: X-Rspamd-Score: -2.09 / 15.00 / 15.00 X-Rspamd-Queue-Id: D5D031850 X-Rspamd-UID: e02e71 Archived-At: Subject: Re: [Sidrops] ASPA: Is this really a leak? 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, 17 Dec 2020 12:23:11 -0000 Hello Jakob, On Thu, 17 Dec 2020 at 08:49, Jakob Heitz (jheitz) wrote: > > Thanks Lukas. Good explanation. > > So, if AS20 were to allow this, would it list AS2 as a provider in its ASPA record? Yes, I'm saying that AS20 has to authorize AS2 as a provider in the ASPA record. This would also mean that AS2 would be authorized to be transit for the entire AS20, not only AS20 -> AS1. This is a drawback that AS20 has to consider here. You can't have your cake and eat it too ... However I don't think this is a problem in practice, because like I wrote in the other email, usually nobody wants this. And more complex situations can always be authorized with multiple ASPA records (just like mutual transit relations in section 7). I would also suggest that ASPA should remain as simple as possible. Exceptions to the basic rules as per the draft will make it more difficult for network operators and implementators - in all steps (implementing the code, training folks, actually deploying it in a network, troubleshooting live issues). We want as much traction as possible from both global and regional network operators. ROV and it's implementations are complex and hard enough. lukas From nobody Thu Dec 17 10:16:40 2020 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 A8CD73A0E4D; Thu, 17 Dec 2020 10:16:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: nathalie@ripe.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160822899861.15080.7153139507711726374@ietfa.amsl.com> Date: Thu, 17 Dec 2020 10:16:38 -0800 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 110 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, 17 Dec 2020 18:16:39 -0000 A new meeting session request has just been submitted by Nathalie Trenaman, a Secretary of the sidrops working group. --------------------------------------------------------- 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: 100 Conflicts to Avoid: Chair Conflict: idr rtgwg grow Technology Overlap: opsec rtgarea Key Participant Conflict: dnsop People who must be present: Keyur Patel Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Dec 18 00:28:19 2020 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 74B803A1160 for ; Fri, 18 Dec 2020 00:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=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 Hp_NXAdHTZCP for ; Fri, 18 Dec 2020 00:28:15 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 AE5ED3A115E for ; Fri, 18 Dec 2020 00:28:14 -0800 (PST) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 5AC7760845; Fri, 18 Dec 2020 08:28:12 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1608280091; bh=knisq2iOJuZtfpfJA80QyKYcS4ElBEv2umDtGm0PT9o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=YuUhIi9/TFxJiaDx4pMqZpE07DlfGhNKrnDkIy1ZPzLlxSc9anBhW8bDOi+as5pSE zeVaVO6NkwVhKMeFKYieSOI0x66C5SAr2N4XG1qZGAJnLKtCog+pOpzaED3b1AyL9I u/7td4afLtTEO6vI3JQkK/rIiYkfortuxwAKhEtKlcwQCMYMcoBrgQ/PhHGt2bOynH P+q7be6uyyls1+YfG/vn8aM5T7fojLhTu8UbSRxEYUMl3xYcQZqgEW3henBMNZmhIO d3J+bPHqt6+CNZ5RLlLsQ7jB42VNL+vlQlDhXgCWdrrQYasi7puNBFbKQuJprZO6z4 7mY8f6dpAZM0Q== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 18 Dec 2020 09:28:03 +0100 Cc: Benno Overeinder , SIDR Operations WG , Martin Hoffmann , Ben Maddison Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> To: Job Snijders Archived-At: Subject: Re: [Sidrops] 6486bis: referenced object validation 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, 18 Dec 2020 08:28:17 -0000 Dear group, > On 4 Dec 2020, at 22:23, Job Snijders wrote: >=20 > Dear group, >=20 > On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote: >> On 6486 in particular there was a strong desire communicated by >> operators that RPs behave the *same* way. >=20 >> Which is why we were hesitant to implement the changes suggested by >> you in the GH issue.=20 >=20 > I have a celebratory moment to share with all of you, below is a > terminal transcript and some hashes which will allow you to confirm my > findings. >=20 > In summary: rpki-client, fort and routinator now follow the same = approach. I believe it's being adopted by octo and the ripe ncc = validator as well. I am not sure about rpstir and rcynic. This begs the question whether we should seek to reword the -bis text to = essentially just insist that all current objects on a manifest should be = present and accounted for, instead of the more complicated text that it = has now which has resulted in at least two cases where all objects under = an RIR were rejected - if implemented. It will come as no surprise, that = I for one would welcome that change. Let me quote Martin's motivation and suggestion in Reply to Ben's email = earlier in this thread: > On 4 Dec 2020, at 11:16, Martin Hoffmann = wrote: >=20 > Ben Maddison wrote: >>=20 >> As a result of the incident last night that caused the number of VRPs >> output by some RPs (certainly routinator, possibly others too) to = drop >> dramatically, a couple of us have been going over the observed >> behaviour in comparison with the current text of 6486-bis. >>=20 >> It appears from Job's analysis [1] that the incident was triggered >> when several resource certs that were listed on an APNIC issued >> manifest became invalid due to their 'notAfter' time expiring, which >> in turn caused the affected RPs to consider the manifest invalid and >> fail the fetch. >>=20 >> It should be perfectly legitimate for a manifest to list objects = which >> will become invalid during the lifetime of the manifest, or which are >> not yet valid when the manifest is generated (for pre-staging). >> The presence of such objects should not invalidate the manifest. >=20 > I think the incident shows a general flaw in the approach that > anything being wrong with any of the objects published by the CA > should lead to all the CA=E2=80=99s objects being invalidated: It = prohibits a > CA from publishing invalid objects on purpose. >=20 > The validity time is only one such case. Another one that we already > know about is changing resource entitlements in the CA certificate. > This case is actually worse since the CA itself has no influence on > this happening and, as the protocols are now, there is no automated > way of agreeing on a timeline for the process. >=20 > It is not entirely unlikely that we will encounter more such issues in > the future. >=20 > So perhaps instead of trying to work around each of these issues as > they arise, we should go back and look at what started this revision = in > the first place. That was an observation that by manipulating a > publication point=E2=80=99s objects, an attacker can force a route = announcement > to become RPKI invalid. >=20 > The current approach does solve this problem but it also attempts to > solve a different problem: to protect a CA from accidentally = publishing > invalid data. But as we found out, that requires anticipating the > intentions of a CA. Perhaps it is better to trust a CA and accept that > if it fails there will be problems for its resources. >=20 > Under this approach, the manifest expresses which objects the CA > intended to publish. If all the objects listed on the manifest are > present with a matching hash, the publication point reflects the = intent > of the CA and can be processed. If it contains invalid objects, these > can be discarded individually. >=20 > This approach will be simpler and easier to implement. It will avoid > the invalidation of the entire CA because of expired or not yet valid > CA certificates or changing resource entitlements. It may, however, > lead to a partial set of objects applying to a particular resource. > That may be intentional or by accident. Whether it is better to reject > the partial set accepting that an intentionally partial set is = rejected > or to accept an accidental partial set to be included depends on the > particular application of RPKI. For ROV, rejecting the set may be > better (although there are consequences of that, too) whereas for > router keys or Ghostbuster records including it would seem to be fine. >=20 > In other words, the proposal is to simplify the text for section 6.4 > to say: >=20 > The RP MUST acquire all of the files enumerated in the manifest > (fileList) from the publication point. If there are files listed > in the manifest that cannot be retrieved from the publication > point the fetch has failed and the RP MUST proceed to Section = 6.7; > otherwise, proceed to Section 6.5. >=20 > In addition, section 6.6 can be repurposed to specify the behaviour in > case of invalid objects. As a proposal: >=20 > 6.6. Invalid Files >=20 > If files listed in on the manifest fail the validity tests > specified in [RFC6487] and [RFC6488], the fetch has not > necessarily failed. However, applications of the RPKI may define > specific consequences if one or more files are invalid. >=20 > Alternatively, this section can provide the rules for existing > applications of the RPKI, i.e., ROV, BGPsec, and GBR as well as > delegation to child CAs. >=20 > I understand that this proposal is a departure from our current > approach, but I would like to ask the working group to consider it > nonetheless as it keeps validation relatively simple and, by = separating > out the individual steps of the overall process, should limit the > number of unforeseen consequences. >=20 > Kind regards, > Martin > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Dec 18 08:28:39 2020 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 D6B0A3A09F9 for ; Fri, 18 Dec 2020 08:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 YCpaAFoEd-ET for ; Fri, 18 Dec 2020 08:28:35 -0800 (PST) Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (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 F16023A09BD for ; Fri, 18 Dec 2020 08:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1608308914; bh=mDt4VLoeJ12A0zwJwOmV+8VA+wz0TDvGqbdCPSrA/4Y=; h=To:From:Subject:Date:References:From:Subject; b=GwEZ66cd+keObmBiaRyOzg+8GE/guo5/ZDmkPdIO3Ij4od8jRgITSSwCb7hWeAC+m2kXU0ix++zGv0Xcb4fNeLpntgNUTwXnzKdHaClw/zI7j1I5as6/MUHepIY0FNKRhxOKtO694OYZ/dGQkwraQqgyC/rt2/iWShkmYmWZ4XvoFAdGvX7R0kCBHRNekW37oQl9cSXpIU7bxFihjeYiPbsat8ynyNMrdlsyGJSXLE658uixZjQoEXk5WaAa33aBzXfKK7oF50FX3DovOzY+8CQ6lGM5/u4d3A2wVK8yCAmRUaA0jFGICrnq+Bhj+J9ttaGeMJa5W2pjp+O1SgCd8Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608308914; bh=CGLF1MqyubzM5BnDeBxH+JV2QxBvKMnHvsIfuR7wEw5=; h=To:From:Subject:Date:From:Subject; b=X1Eq9QxmtPretiQnmxbCCscMJApfCTT+mhHbM4ET5P220fLLoWiDkpu9Mr3e97N9U0l+3mRs0E5K6K0rj9RwHxFmb82p4iHvn3bgIIEV5fEN7ODKHjKsjqi8rQIF58A0fUzsmWYzlilzdf2PgkEH4j0SKMcQGmAUUrf59hi4FXa2MjnyE/pnhKKV40HNLzz75vPIaDLuBI/RoIu/MAJZRmcCAOTS2wOsk5K2VoD8CVohqCXrc2GaWRZQbdSFKfNvtVFhf4gCW7XLLBSXLgkb6nnXXYXAVBLWakSkDEpvaUcAfSYtbmQIOiTDWGQyebIQwgLD98machWfkUApKTdSVg== X-YMail-OSG: 65dmvT0VM1n_QM2SdCX8QBKsrEtuHt2zlKZ4Y4CCgtOyxgWFQHZQo8lMbmeaCpI 32Pl.PQFl9vR7fEn2S4TQ7tn5wc9mj9bi_1eXCL_vWOGx75dWb78xDWNX_e_mwrzCYs_MI3Lue3t GtbT60FjeUrJ84.ja98V2VQH6uOMUx5IYKfaX3rMsAg3FbyBCSsLTPLOWxTc2h0OgOKaTxl6Ig9K VYdfArK.eQZfDaesd9KPhC49DAhNLXgftEm4JphMpPrIP.SBeGB6KRqxj7ZY97vunUXNFDQ0MB_W .nKEqTBmvlpgR5S1M36EGiNTD0GTldAfq8cS1eJeo47lpB8ZNzBYDC22z.jqt60jZldYMd6UBrG0 ERd9anGXOewUI6lNnyX8JJdD7EseZn5LXrOvjQHTxJLF8MAMBlCG2J_2YCQ2yxEOehKILsfK84qk RnlRgkrz7ggevrZDXZn3PlA1dr5YKp1ImgqQnNU1UlILu4Y_B8nScnR7itMlzDCP1dbsRw1Ui4q7 REVZ2QxUsfrg3te88zQnpl8wgt3.KzwI118NuzR66TuITIe74eRHcCrL0WLXQtdxocEJjmSHfb2R fWJZdVi.CVzr.blHvWj7zXFzJcAl39vIfO.FExnOe1ZMuKJF9WYCWmoV_FqeJ8bdPVy27Uqj5tNf ZelR37zkJXSyigHCxZzpznn5uifurHfQcvqZE33Z1aOu4QdOFxKEngFwZIXaPYCAhar6jSioXfWx 6h90yv.2jkCMwRiwdlKjFATkkbXDAUA6CYKnH8r8wFwfOFgrCvLEO0kZZ0FXpbn7pVFJMbY9UTeo kNT4uQ9zCflhSgX8wgh2xU6CCTcO65UjAlfpo8PJtUwMjvJPWkxG5zVLp2vKm4Djk6tFAgR59lhl xb_33CudJNP9qBfe1haMg7LXdsbo4I6qOFMi.EYmeF8ceh.BjZlaKSjssd3hq7nOnkEfQh58k0nY T1D7j_uCc.RfphqUM.0N_aoSf7jRMOuQfRXIBIhIS0lXzv08WVl3V9xj8fXInFiLGGlMtEYhaYih 0lrAGUKrxyTE20TWR9jvOBn2NIPg5rq25zAq8l330iLh6aO_beRbqoYSpAQCYRIWYB.7ZwLC4s43 jn1TwTqHnfOl8VSfycIhhFg590PkpHU0_iLg7mHx3Lxk3aI90xKtBnnuPlRMtbEgcn8Ww58gF6ue PrH7vbIyNRNnoMparg4kw_9BN0gRFZxNm_w1zTXrOOKRKIB8NzZDZYZJD_W60vG1HwAGKfNrhnKK p6k8.u2keKV2Q3HcG3X47adPdYdhpFuE643iygrEnqKJ0zEDlpi4ao2stNLbTXOSah4DfAJliPCg u7NINL9xYgqupRHzIYN.GKfwRooFkaqsLS9.gPO6y_QsD5GtaIHoiXCdDKiSDtL2C_1TgRYkho8d fyeRA5LG8nipKcXhSUfOhvMdxqGMFK_T5g77Wfc_iDAkoLEsGAtO72A25ThSg5U7jLFuPt9PMcUb 5bI6M8lA9yHoAuPxKeE2lT51XX._zqQx4oTszurzrSP910xfFCkYTTHip4IJN1qF.0HXxarxXIPO KkEuPc1D7_n.P4bRS23W0M.B1C4Wl.w5te4yRWzi3qujR4Z_jyu7Kn79QbEhVV37rlj1ziKDYVY1 GCHDxI5TGxHaVzY4vUFvoo5M73UPUB2qiVHbigIllK0R1_yys5oY0H3B7tUFSeYYh_L16bwo6EUs avzhesPD1BL_gjm4nTpp4xEfsCdEJudG0q8D5_K1In.cDLovbeVdzR4lG99QGbEnWuLvo9RaOa18 vJn_aU0Wi24xWcK_wb6F3WWSoVR4No.TLLW3eWO.pCRg0VlXbeCmfAohVs2JF2p2Sja.a7x1Egq2 nqJfSqnQOYqqXpz0IvAqSSBN3nULs4GghbaDlF.tGlQ5DAscnqEdsDhvofVIX9vUMAeFKuRVPF2y up5lw8Eck4ein0_Or1dGRbX8xeWotsAWF.34H4uipec6QadT55tnZ7alJK8dfe9NN3YA_1ZYRjAH BC8Cv9Ndo5coDKCmMNLqKqw21IXl0PqTQMlEmDkAt3w5l5KrFLhRYu83s8uDWIGgr48Jx8qZmwUk gm2SgjZT8lrZSB7WEGGc07JM6pHSJQ3CrwPdtuaifdSh9bHHXrw7J2tMqA2CoQj6oDarOPqtiVPq 4m0S3GD96grwTTMwnknjRXW9sH7Ff51HhkV3y8OALOXoMfrDDazdjBBriS.rKa66tV2klu9S8lhY 6fRL8x3WVxYlVbipmAQe.ffwXGBoTwgpRQwvMrATWKb_f_tGpH5poDIq.1oro4S0SmYvQR_hss1Z f_RTYTZ8cq7hDJ.b8NJ9Hnvo2Xf6qEaECEB7lMjH74TXLjlVI608w8d150Du5gb7IqxrT2OYeyT4 QA_eAK_sTe429uJ1wiR_v9CfhDg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 18 Dec 2020 16:28:34 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 89b3dd82edcac33aaac7d2525bb535db; Fri, 18 Dec 2020 16:28:30 +0000 (UTC) To: "sidrops@ietf.org" From: Stephen Kent Message-ID: <12001c46-2fe3-6616-2969-f97d247e972e@verizon.net> Date: Fri, 18 Dec 2020 11:28:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------55DA7E5AC43C53AC633D6C98" Content-Language: en-US References: <12001c46-2fe3-6616-2969-f97d247e972e.ref@verizon.net> X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: [Sidrops] revised text for section 6 of 6486bis 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, 18 Dec 2020 16:28:38 -0000 This is a multi-part message in MIME format. --------------55DA7E5AC43C53AC633D6C98 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Based on the numerous comments posted over the past 2+ weeks I have revised the text of section 6 of the document. The revised text focuses exclusively on using a Manifest to ensure that the set of files retrieved from a pub point match those that were posted by the cognizant CA instance. Thus, for example, the text no longer requires that the files being retrieved be verified based on RFC 6488.  As a result, there is no need to enumerate the object types that are mandatory to support. Consequently, there is no need to specify how to deal with files that are retrieved but that are not among the mandatory-to-support object types. All of that now belongs in other documents, given the newly-agreed upon scope limitation for Manifest processing. For example, the section no longer requires that there be only one CRL, consistent with the notion that the purpose of the manifest is to ensure that the retrieved objects matches what the CA published. Because we have removed the object validation constraints from this document, we can no longer state that "The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to achieve the same results with regard to validation of RPKI data." Instead, the text now states: "The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure thatthe RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files." Steve -------- 6.Relying Party Processing of Manifests Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters).As noted earlier, manifests are designed to allow an RP to detect manipulation of repository data, errors by a CA or repository manager, and/or active attacks on the communication channel between an RP and a repository. Unless all of the files enumerated in a manifest can be obtained by an RP during a fetch operation, the fetch is considered to have failed and the RP MUST retry the fetch later. [RFC6480] suggests (but does not mandate) that the RPKI model employ fetches that are incremental, e.g., an RP transfers files from a publication point only if they are new/changed since the previous, successful, fetch represented in the RP's local cache.This document avoids language that relies on details of the underlying file transfer mechanism employed by an RP and a publication point to effect this operation.Thus the term "fetch" refers to an operation that attempts to acquire the full set of files at a publication point, consistent with the id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see below). If a fetch fails, it is assumed that a subsequent fetch will resolve problems encountered during the fetch.Until such time as a successful fetch is executed, an RP SHOULD use cached data from a previous, successful fetch.This response is intended to prevent an RP from misinterpreting data associated with a publication point, and thus possibly treating invalid routes as valid, or vice versa. The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files. Moreover, in operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to acquisition or validation of RPKI data. Note also that there is a "chicken and egg" relationship between the manifest and the CRL for a given CA instance.If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious error.In this case the fetch has failed; proceed to Section 6.7. Similarly, if the CRL is not listed on a valid, current manifest, acquired during a fetch, the fetch has failed; proceed to Section 6.7, because the CRL is considered missing. 6.1.Manifest Processing Overview For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are acceptable.The tests described below (Section 6.2 to Section 6.6) are to be performed using the manifest identified by the id-ad- rpkiManifest URI extracted from a CA certificate's SIA.All of the files referenced by the manifest MUST be located at the publication point specified by the id-ad-caRepository URI from the (same) CA certificate's SIA.The manifest and the files it references MUST reside at the same publication point.If an RP encounters any files that appear on a manifest but do not reside at the same publication point as the manifest the RP MUST treat the fetch as failed, and a warning MUST be issued (see Section 6.7 below). Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances will appear at the same publication point.Manifest processing is to be performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate. 6.2.Acquiring a Manifest for a CA The RP MUST fetch the manifest identified by the SIA id-ad- rpkiManifest URI in the CA certificate.If an RP cannot retrieve a manifest using this URI, or if the manifest is not valid (Section 4.4), an RP MUST treat this as a failed fetch and, proceed to Section 6.7; otherwise proceed to Section 6.3. 6.3.Detecting Stale and or Prematurely-issued Manifests The RP MUST check that the current time (translated to UTC) is between thisUpdate and nextUpdate.If the current time lies within this interval, proceed to Section 6.4.If the current time is earlier than thisUpdate, the CA has made an error; this is a failed fetch and the RP MUST proceed to Section 6.7.If the current time is later than nextUpdate, then the manifest is stale; this is a failed fetch and RP MUST proceed to Section 6.7; otherwise proceed to Section 6.4. 6.4.Acquiring Files Referenced by a Manifest The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point, the fetch has failed and the RP MUST proceed to Section 6.7; otherwise, proceed to Section 6.5 6.5.Matching File Names and Hashes The RP MUST verify that the hash value of each file listed in the manifest matches the value obtained by hashing the file acquired from the publication point.If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then the fetch has failed and the RP MUST proceed to Section 6.7; otherwise proceed to Section 6.6. 6.6.Out of Scope Manifest Entries If a current manifest contains entries for objects that are not within the scope of the manifest (Section 6.2), the fetch has failed and the RP SHOULD proceed to Section 6.7; otherwise the fetch is deemed successful and the RP will process the fetched objects. 6.7.Failed Fetches If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST issue a warning indicating the reason(s)for termination of processing with regard to this CA instance.It is RECOMMENDED that a human operator be notified of this warning. Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch.This implies that the RP MUST not try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. --------------55DA7E5AC43C53AC633D6C98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Based on the numerous comments posted over the past 2+ weeks I have revised the text of section 6 of the document. The revised text focuses exclusively on using a Manifest to ensure that the set of files retrieved from a pub point match those that were posted by the cognizant CA instance.

Thus, for example, the text no longer requires that the files being retrieved be verified based on RFC 6488.  As a result, there is no need to enumerate the object types that are mandatory to support. Consequently, there is no need to specify how to deal with files that are retrieved but that are not among the mandatory-to-support object types. All of that now belongs in other documents, given the newly-agreed upon scope limitation for Manifest processing.

For example, the section no longer requires that there be only one CRL, consistent with the notion that the purpose of the manifest is to ensure that the retrieved objects matches what the CA published.

Because we have removed the object validation constraints from this document, we can no longer state that "The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to achieve the same results with regard to validation of RPKI data." Instead, the text now states: " The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files."

Steve

--------

6.  Relying Party Processing of Manifests

 

   Each RP must determine which signed objects it will use for

   validating assertions about INRs and their use (e.g., which ROAs to

   use in the construction of route filters).  As noted earlier,

   manifests are designed to allow an RP to detect manipulation of

   repository data, errors by a CA or repository manager, and/or active

   attacks on the communication channel between an RP and a repository.

   Unless all of the files enumerated in a manifest can be obtained by

   an RP during a fetch operation, the fetch is considered to have

   failed and the RP MUST retry the fetch later.

 

   [RFC6480] suggests (but does not mandate) that the RPKI model employ

   fetches that are incremental, e.g., an RP transfers files from a

   publication point only if they are new/changed since the previous,

   successful, fetch represented in the RP's local cache.  This document

   avoids language that relies on details of the underlying file

   transfer mechanism employed by an RP and a publication point to

   effect this operation.  Thus the term "fetch" refers to an operation

   that attempts to acquire the full set of files at a publication

   point, consistent with the id-ad-rpkiManifest URI extracted from a CA

   certificate's SIA (see below).

 

   If a fetch fails, it is assumed that a subsequent fetch will resolve

   problems encountered during the fetch.  Until such time as a

   successful fetch is executed, an RP SHOULD use cached data from a

   previous, successful fetch.  This response is intended to prevent an

   RP from misinterpreting data associated with a publication point, and

   thus possibly treating invalid routes as valid, or vice versa.

 

   The processing described below is designed to cause all RPs with

   access to the same local cache and RPKI repository data to acquire

   the same set of validated repository files. It does not ensure that

   the RPs will achieve the same results with regard to validation of

   RPKI data, since that depends on how each RP resolves any conflicts

   that may arise in processing the retrieved files. Moreover, in

   operation, different RPs will access repositories at different times,

   and some RPs may experience local cache failures, so there is no

   guarantee that all RPs will achieve the same results with regard to

   acquisition or validation of RPKI data.

 

   Note also that there is a "chicken and egg" relationship between the

   manifest and the CRL for a given CA instance.  If the EE certificate

   for the current manifest is revoked, i.e., it appears in the current

   CRL, then the CA or publication point manager has made a serious

   error.  In this case the fetch has failed; proceed to Section 6.7.

   Similarly, if the CRL is not listed on a valid, current manifest,

   acquired during a fetch, the fetch has failed; proceed to

   Section 6.7, because the CRL is considered missing.

 

 

 

 

6.1.  Manifest Processing Overview

 

   For a given publication point, an RP MUST perform a series of tests

   to determine which signed object files at the publication point are

   acceptable.  The tests described below (Section 6.2 to Section 6.6)

   are to be performed using the manifest identified by the id-ad-

   rpkiManifest URI extracted from a CA certificate's SIA.  All of the

   files referenced by the manifest MUST be located at the

   publication point specified by the id-ad-caRepository URI from the

   (same) CA certificate's SIA.  The manifest and the files it

   references MUST reside at the same publication point.  If an RP

   encounters any files that appear on a manifest but do not reside at

   the same publication point as the manifest the RP MUST treat the

   fetch as failed, and a warning MUST be issued (see Section 6.7

   below).

 

   Note that, during CA key rollover [RFC6489], signed objects for two

   or more different CA instances will appear at the same publication

   point.  Manifest processing is to be performed separately for each CA

   instance, guided by the SIA id-ad-rpkiManifest URI in each CA

   certificate.

 

6.2.  Acquiring a Manifest for a CA

 

   The RP MUST fetch the manifest identified by the SIA id-ad-

   rpkiManifest URI in the CA certificate.  If an RP cannot retrieve a

   manifest using this URI, or if the manifest is not valid

   (Section 4.4), an RP MUST treat this as a failed fetch and, proceed

   to Section 6.7; otherwise proceed to Section 6.3.

 

6.3.  Detecting Stale and or Prematurely-issued Manifests

 

   The RP MUST check that the current time (translated to UTC) is

   between thisUpdate and nextUpdate.  If the current time lies within

   this interval, proceed to Section 6.4.  If the current time is

   earlier than thisUpdate, the CA has made an error; this is a failed

   fetch and the RP MUST proceed to Section 6.7.  If the current time is

   later than nextUpdate, then the manifest is stale; this is a failed

   fetch and RP MUST proceed to Section 6.7; otherwise proceed to

   Section 6.4.

 

 

 

6.4.  Acquiring Files Referenced by a Manifest

 

   The RP MUST acquire all of the files enumerated in the manifest

   (fileList) from the publication point. If there are files listed in

   the manifest that cannot be retrieved from the publication point, the

   fetch has failed and the RP MUST proceed to Section 6.7; otherwise,

   proceed to Section 6.5

 

 

6.5.  Matching File Names and Hashes

 

   The RP MUST verify that the hash value of each file listed in the

   manifest matches the value obtained by hashing the file acquired from

   the publication point.  If the computed hash value of a file listed

   on the manifest does not match the hash value contained in the

   manifest, then the fetch has failed and the RP MUST proceed to

   Section 6.7; otherwise proceed to Section 6.6.

 

6.6.  Out of Scope Manifest Entries

 

   If a current manifest contains entries for objects that are not

   within the scope of the manifest (Section 6.2), the fetch has failed

   and the RP SHOULD proceed to Section 6.7; otherwise the fetch is

   deemed successful and the RP will process the fetched objects.

 

6.7.  Failed Fetches

 

   If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST

   issue a warning indicating the reason(s)for termination of processing

   with regard to this CA instance.  It is RECOMMENDED that a human

   operator be notified of this warning.

 

   Termination of processing means that the RP SHOULD continue to use

   cached versions of the objects associated with this CA instance,

   until such time as they become stale or they can be replaced by

   objects from a successful fetch.  This implies that the RP MUST not

   try to acquire and validate subordinate signed objects, e.g.,

   subordinate CA certificates, until the next interval when the RP is

   scheduled to fetch and process data for this CA instance.

 

--------------55DA7E5AC43C53AC633D6C98-- From nobody Wed Dec 23 06:49:27 2020 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 3BE003A100E; Wed, 23 Dec 2020 06:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my80ZU7yqrsv; Wed, 23 Dec 2020 06:49:22 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806483A100D; Wed, 23 Dec 2020 06:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id: From; bh=/6qkskhF82u0rCEJq+heqtbAaeHCaFccFlC376q94rI=; b=p5S6h2HwL7G/DA2P4Hql HzuoIPnLytXRFvYrmvS0G9pBcZSCoFSS0u4AH4SbIwe4Q8pN3BScUXuj+O/YDuAMlUkKBehhWqUID oyyBiOqGUW1/nFEi64dW2WTrx2pmtmVN91uZijDaBcKgDtZev/QA7PXp7+lLKyj9b6oBSr0ivsJec s7ZJIrmjnfUvpEStFo6/SWNC3AnbTZ+kdUoUYPePojCydlhXnrNNy2sE9fN/ddpZlRCJmBfRPoA8u yPoaKA+y0cyAQm4KyeegTo+L74Th+qG/5b8ibktc7E5yKAboRROJ5mjHItO9HwEXNeoxP4p+EdWeP 4ARP59feBe6dtw==; Received: from bufobufo.ripe.net ([193.0.23.13]:59992) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1ks5S3-0008hn-4f; Wed, 23 Dec 2020 15:49:19 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::49e]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1ks5S3-0003W4-0b; Wed, 23 Dec 2020 15:49:19 +0100 From: Ties de Kock Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_20CFF4DD-D0E6-454C-A870-BBBD2CF44548" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 23 Dec 2020 15:49:18 +0100 In-Reply-To: <12001c46-2fe3-6616-2969-f97d247e972e@verizon.net> Cc: "sidrops@ietf.org" To: Stephen Kent References: <12001c46-2fe3-6616-2969-f97d247e972e.ref@verizon.net> <12001c46-2fe3-6616-2969-f97d247e972e@verizon.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1fd8510189c0560caae68c12fefe64590 Archived-At: Subject: Re: [Sidrops] revised text for section 6 of 6486bis 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, 23 Dec 2020 14:49:25 -0000 --Apple-Mail=_20CFF4DD-D0E6-454C-A870-BBBD2CF44548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I was reading the draft, and I could not understand the intent of = Section 6.6, out of Scope Manifest Entries. To me, this paragraph seems to be either a leftover from an earlier = version of RFC 6486 (6.1.5/6.1.6) or a reference to Section 2 (manifest scope). In = the latter case, it goes against the notion of just using the manifest to verify = that the publication point contains the files the CA intended to publish. I would propose to remove the section in its current form, but in that = case, I think we need some text that clarifies how RPs should handle unknown = objects. Kind regards, Ties > On 18 Dec 2020, at 17:28, Stephen Kent = wrote: >=20 > Based on the numerous comments posted over the past 2+ weeks I have = revised the text of section 6 of the document. The revised text focuses = exclusively on using a Manifest to ensure that the set of files = retrieved from a pub point match those that were posted by the cognizant = CA instance. >=20 > Thus, for example, the text no longer requires that the files being = retrieved be verified based on RFC 6488. As a result, there is no need = to enumerate the object types that are mandatory to support. = Consequently, there is no need to specify how to deal with files that = are retrieved but that are not among the mandatory-to-support object = types. All of that now belongs in other documents, given the = newly-agreed upon scope limitation for Manifest processing. >=20 > For example, the section no longer requires that there be only one = CRL, consistent with the notion that the purpose of the manifest is to = ensure that the retrieved objects matches what the CA published. >=20 > Because we have removed the object validation constraints from this = document, we can no longer state that "The processing described below is = designed to cause all RPs with access to the same local cache and RPKI = repository data to achieve the same results with regard to validation of = RPKI data." Instead, the text now states: " The processing described = below is designed to cause all RPs with access to the same local cache = and RPKI repository data to acquire the same set of validated repository = files. It does not ensure that the RPs will achieve the same results = with regard to validation of RPKI data, since that depends on how each = RP resolves any conflicts that may arise in processing the retrieved = files." >=20 > Steve >=20 > -------- >=20 >=20 > <>6. Relying Party Processing of Manifests > =20 > Each RP must determine which signed objects it will use for > validating assertions about INRs and their use (e.g., which ROAs to > use in the construction of route filters). As noted earlier, > manifests are designed to allow an RP to detect manipulation of > repository data, errors by a CA or repository manager, and/or = active > attacks on the communication channel between an RP and a = repository. > Unless all of the files enumerated in a manifest can be obtained by > an RP during a fetch operation, the fetch is considered to have > failed and the RP MUST retry the fetch later. > =20 > [RFC6480] suggests (but does not mandate) that the RPKI model = employ > fetches that are incremental, e.g., an RP transfers files from a > publication point only if they are new/changed since the previous, > successful, fetch represented in the RP's local cache. This = document > avoids language that relies on details of the underlying file > transfer mechanism employed by an RP and a publication point to > effect this operation. Thus the term "fetch" refers to an = operation > that attempts to acquire the full set of files at a publication > point, consistent with the id-ad-rpkiManifest URI extracted from a = CA > certificate's SIA (see below). > =20 > If a fetch fails, it is assumed that a subsequent fetch will = resolve > problems encountered during the fetch. Until such time as a > successful fetch is executed, an RP SHOULD use cached data from a > previous, successful fetch. This response is intended to prevent = an > RP from misinterpreting data associated with a publication point, = and > thus possibly treating invalid routes as valid, or vice versa. > =20 > The processing described below is designed to cause all RPs with > access to the same local cache and RPKI repository data to acquire > the same set of validated repository files. It does not ensure that > the RPs will achieve the same results with regard to validation of=20= > RPKI data, since that depends on how each RP resolves any conflicts=20= > that may arise in processing the retrieved files. Moreover, in=20 > operation, different RPs will access repositories at different = times, > and some RPs may experience local cache failures, so there is no > guarantee that all RPs will achieve the same results with regard to > acquisition or validation of RPKI data. > =20 > Note also that there is a "chicken and egg" relationship between = the > manifest and the CRL for a given CA instance. If the EE = certificate > for the current manifest is revoked, i.e., it appears in the = current > CRL, then the CA or publication point manager has made a serious > error. In this case the fetch has failed; proceed to Section 6.7. > Similarly, if the CRL is not listed on a valid, current manifest, > acquired during a fetch, the fetch has failed; proceed to > Section 6.7, because the CRL is considered missing. > =20 > =20 > =20 > =20 > 6.1. Manifest Processing Overview > =20 > For a given publication point, an RP MUST perform a series of tests > to determine which signed object files at the publication point are > acceptable. The tests described below (Section 6.2 to Section 6.6) > are to be performed using the manifest identified by the id-ad- > rpkiManifest URI extracted from a CA certificate's SIA. All of the > files referenced by the manifest MUST be located at the > publication point specified by the id-ad-caRepository URI from the > (same) CA certificate's SIA. The manifest and the files it > references MUST reside at the same publication point. If an RP > encounters any files that appear on a manifest but do not reside at > the same publication point as the manifest the RP MUST treat the > fetch as failed, and a warning MUST be issued (see Section 6.7 > below). > =20 > Note that, during CA key rollover [RFC6489], signed objects for two > or more different CA instances will appear at the same publication > point. Manifest processing is to be performed separately for each = CA > instance, guided by the SIA id-ad-rpkiManifest URI in each CA > certificate. > =20 > 6.2. Acquiring a Manifest for a CA > =20 > The RP MUST fetch the manifest identified by the SIA id-ad- > rpkiManifest URI in the CA certificate. If an RP cannot retrieve a > manifest using this URI, or if the manifest is not valid > (Section 4.4), an RP MUST treat this as a failed fetch and, proceed > to Section 6.7; otherwise proceed to Section 6.3. > =20 > 6.3. Detecting Stale and or Prematurely-issued Manifests > =20 > The RP MUST check that the current time (translated to UTC) is > between thisUpdate and nextUpdate. If the current time lies within > this interval, proceed to Section 6.4. If the current time is > earlier than thisUpdate, the CA has made an error; this is a failed > fetch and the RP MUST proceed to Section 6.7. If the current time = is > later than nextUpdate, then the manifest is stale; this is a failed > fetch and RP MUST proceed to Section 6.7; otherwise proceed to > Section 6.4. > =20 > =20 > =20 > 6.4. Acquiring Files Referenced by a Manifest > =20 > The RP MUST acquire all of the files enumerated in the manifest > (fileList) from the publication point. If there are files listed in > the manifest that cannot be retrieved from the publication point, = the=20 > fetch has failed and the RP MUST proceed to Section 6.7; otherwise,=20= > proceed to Section 6.5 > =20 > =20 > 6.5. Matching File Names and Hashes > =20 > The RP MUST verify that the hash value of each file listed in the > manifest matches the value obtained by hashing the file acquired = from > the publication point. If the computed hash value of a file listed > on the manifest does not match the hash value contained in the > manifest, then the fetch has failed and the RP MUST proceed to > Section 6.7; otherwise proceed to Section 6.6. > =20 > 6.6. Out of Scope Manifest Entries > =20 > If a current manifest contains entries for objects that are not > within the scope of the manifest (Section 6.2), the fetch has = failed > and the RP SHOULD proceed to Section 6.7; otherwise the fetch is > deemed successful and the RP will process the fetched objects. > =20 > 6.7. Failed Fetches > =20 > If a fetch fails for any of the reasons cited in 6.2-6.6, the RP = MUST=20 > issue a warning indicating the reason(s)for termination of = processing > with regard to this CA instance. It is RECOMMENDED that a human=20 > operator be notified of this warning. > =20 > Termination of processing means that the RP SHOULD continue to use > cached versions of the objects associated with this CA instance, > until such time as they become stale or they can be replaced by > objects from a successful fetch. This implies that the RP MUST not > try to acquire and validate subordinate signed objects, e.g., > subordinate CA certificates, until the next interval when the RP is > scheduled to fetch and process data for this CA instance. > =20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_20CFF4DD-D0E6-454C-A870-BBBD2CF44548 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all,

I was reading the draft, and I could not understand the = intent of Section 6.6,
out of Scope Manifest = Entries.

To = me, this paragraph seems to be either a leftover from an earlier version = of
RFC 6486 (6.1.5/6.1.6) or a reference to Section = 2 (manifest scope). In the latter
case, it goes = against the notion of just using the manifest to verify that = the
publication point contains the files the CA = intended to publish.

I would propose to remove the section in its current form, = but in that case, I
think we need some text that = clarifies how RPs should handle unknown objects.

Kind regards,
Ties


On 18 = Dec 2020, at 17:28, Stephen Kent <stkent=3D40verizon.net@dmarc.ietf.org> wrote:

Based on the numerous comments posted over = the past 2+ weeks I have revised the text of section 6 of the document. = The revised text focuses exclusively on using a Manifest to ensure that = the set of files retrieved from a pub point match those that were posted = by the cognizant CA instance.

Thus, for example, the text no longer = requires that the files being retrieved be verified based on RFC = 6488.  As a result, there is no need to enumerate the object types = that are mandatory to support. Consequently, there is no need to specify = how to deal with files that are retrieved but that are not among the = mandatory-to-support object types. All of that now belongs in other = documents, given the newly-agreed upon scope limitation for Manifest = processing.

For example, the section no longer requires that there be = only one CRL, consistent with the notion that the purpose of the = manifest is to ensure that the retrieved objects matches what the CA = published.

Because we have removed the object validation = constraints from this document, we can no longer state that "The = processing described below is designed to cause all RPs with access to = the same local cache and RPKI repository data to achieve the same = results with regard to validation of RPKI data." Instead, the text now = states: " The processing described = below is designed to cause all RPs with access to the same local cache and = RPKI repository data to acquire the same set of validated repository files. It does = not ensure that the RPs will achieve = the same results with regard to validation of RPKI data, since that depends on how each RP resolves = any conflicts that may arise in processing the retrieved = files."

Steve

--------


6.  Relying Party = Processing of Manifests

 

   Each RP must = determine which signed objects it will use for
   validating = assertions about INRs and their use (e.g., which ROAs = to
   use in the = construction of route filters).  As noted = earlier,
   manifests are designed to allow an RP to detect = manipulation of
   repository data, = errors by a CA or repository manager, and/or active
   attacks on the = communication channel between an RP and a repository.
   Unless all of the = files enumerated in a manifest can be obtained by
   an RP during a fetch = operation, the fetch is considered to have
   failed and the RP = MUST retry the fetch later.

 

   [RFC6480] suggests = (but does not mandate) that the RPKI model employ
   fetches that are = incremental, e.g., an RP transfers files from a
   publication point = only if they are new/changed since the previous,
   successful, fetch = represented in the RP's local cache.  This = document
   avoids language that = relies on details of the underlying file
   transfer mechanism = employed by an RP and a publication point to
   effect this = operation.  Thus the term = "fetch" refers to an operation
   that attempts to = acquire the full set of files at a publication
   point, consistent = with the id-ad-rpkiManifest URI extracted from a CA
   certificate's SIA = (see below).

 

   If a fetch fails, it = is assumed that a subsequent fetch will resolve
   problems encountered = during the fetch.  Until such time as = a
   successful fetch is = executed, an RP SHOULD use cached data from a
   previous, successful = fetch.  This response is = intended to prevent an
   RP from = misinterpreting data associated with a publication point, = and
   thus possibly treating invalid routes as valid, = or vice versa.

 

   The processing = described below is designed to cause all RPs with
   access to the same = local cache and RPKI repository data to acquire
   the same set of = validated repository files. It does not ensure that
   the RPs will achieve = the same results with regard to validation of 
   RPKI data, since = that depends on how each RP resolves any conflicts 
   that may arise in = processing the retrieved files. Moreover, in 
   operation, different = RPs will access repositories at different times,
   and some RPs may = experience local cache failures, so there is no
   guarantee that all = RPs will achieve the same results with regard to
   acquisition or = validation of RPKI data.

 

   Note also that there = is a "chicken and egg" relationship between the
   manifest and the CRL = for a given CA instance.  If the EE = certificate
   for the current = manifest is revoked, i.e., it appears in the current
   CRL, then the CA or = publication point manager has made a serious
   error.  In this case the = fetch has failed; proceed to Section 6.7.
   Similarly, if the = CRL is not listed on a valid, current manifest,
   acquired during a = fetch, the fetch has failed; proceed to
   Section 6.7, because = the CRL is considered missing.

 

 

 

 

6.1.  Manifest Processing = Overview

 

   For a given = publication point, an RP MUST perform a series of tests
   to determine which = signed object files at the publication point are
   acceptable.  The tests described = below (Section 6.2 to Section 6.6)
   are to be performed = using the manifest identified by the id-ad-
   rpkiManifest URI = extracted from a CA certificate's SIA.  All of = the
   files referenced by = the manifest MUST be located at the
   publication point = specified by the id-ad-caRepository URI from the
   (same) CA = certificate's SIA.  The manifest and the = files it
   references MUST = reside at the same publication point.  If an = RP
   encounters any files = that appear on a manifest but do not reside at
   the same publication = point as the manifest the RP MUST treat the
   fetch as failed, and = a warning MUST be issued (see Section 6.7
   below).
 

   Note that, during CA = key rollover [RFC6489], signed objects for two
   or more different CA = instances will appear at the same publication
   point.  Manifest processing = is to be performed separately for each CA
   instance, guided by = the SIA id-ad-rpkiManifest URI in each CA
   certificate.

 

6.2.  Acquiring a Manifest = for a CA

 

   The RP MUST fetch = the manifest identified by the SIA id-ad-
   rpkiManifest URI in = the CA certificate.  If an RP cannot = retrieve a
   manifest using this = URI, or if the manifest is not valid
   (Section 4.4), an RP = MUST treat this as a failed fetch and, proceed
   to Section 6.7; = otherwise proceed to Section 6.3.

 

6.3.  Detecting Stale and = or Prematurely-issued Manifests

 

   The RP MUST check = that the current time (translated to UTC) is
   between thisUpdate = and nextUpdate.  If the current time = lies within
   this interval, = proceed to Section 6.4.  If the current time = is
   earlier than = thisUpdate, the CA has made an error; this is a failed
   fetch and the RP = MUST proceed to Section 6.7.  If the current time = is
   later than = nextUpdate, then the manifest is stale; this is a = failed
   fetch and RP MUST = proceed to Section 6.7; otherwise proceed to
   Section = 6.4.

 

 

 

6.4.  Acquiring Files = Referenced by a Manifest

 

   The RP MUST acquire = all of the files enumerated in the manifest
   (fileList) from the = publication point. If there are files listed in
   the manifest that = cannot be retrieved from the publication point, the 
   fetch has failed and = the RP MUST proceed to Section 6.7; otherwise, 
   proceed to Section = 6.5

 

 

6.5.  Matching File Names = and Hashes

 

   The RP MUST verify = that the hash value of each file listed in the
   manifest matches the = value obtained by hashing the file acquired from
   the publication = point.  If the computed hash = value of a file listed
   on the manifest does = not match the hash value contained in the
   manifest, then the = fetch has failed and the RP MUST proceed to
   Section 6.7; = otherwise proceed to Section 6.6.

 

6.6.  Out of Scope = Manifest Entries

 

   If a current = manifest contains entries for objects that are not
   within the scope of = the manifest (Section 6.2), the fetch has failed
   and the RP SHOULD = proceed to Section 6.7; otherwise the fetch is
   deemed successful = and the RP will process the fetched objects.

 

6.7.  Failed = Fetches

 

   If a fetch fails for = any of the reasons cited in 6.2-6.6, the RP MUST 
   issue a warning = indicating the reason(s)for termination of processing
   with regard to this = CA instance.  It is RECOMMENDED = that a human 
   operator be notified = of this warning.

 

   Termination of = processing means that the RP SHOULD continue to use
   cached versions of = the objects associated with this CA instance,
   until such time as = they become stale or they can be replaced by
   objects from a = successful fetch.  This implies that = the RP MUST not
   try to acquire and = validate subordinate signed objects, e.g.,
   subordinate CA = certificates, until the next interval when the RP is
   scheduled to fetch = and process data for this CA instance.

 


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


= --Apple-Mail=_20CFF4DD-D0E6-454C-A870-BBBD2CF44548-- From nobody Wed Dec 23 08:41:32 2020 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 7AD373A0C36 for ; Wed, 23 Dec 2020 08:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 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, HTML_OBFUSCATE_10_20=0.093, 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=no 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 cmQSLbTcZMFv for ; Wed, 23 Dec 2020 08:41:28 -0800 (PST) Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 D6E3A3A0BFF for ; Wed, 23 Dec 2020 08:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1608741686; bh=moC4S0dyZhVXK6G0SZAPTCstZv+0WWsPO9k3vPtVEuk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=g8tACHXcul1gKsHUobilByCNKqhktfb6A40iiQuxWxgl0Jpqph6bSbXOdx3/xU40RvKciFKXZuapIMHM157BdNtY6FX2utoaqQSN8dkj4kIAMFNcKO9+r7X7pcDWMyvK/CFrszU0cEcFbVLZ7TF2nZhPKo27IkCv/W8ZiqKFfTQJ5tFjD70XtYKZfBZNq4byP094hQ6RWhfQwskDMhDxqixvXWOcAqgTqnuX8Qs8ugTU8F8FNBe7sPyHZe4pHhGfaBOm4HFySBE9tMLl0foUmMoeSBMZvfOTsYhFr83hc4K0M6d16j57YlPaBe8vYLTjYdFHzc9rr2Yx8AouDPP81g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608741686; bh=jaHMqZNShxITDOxsxZX3hbxBaxg6cNAZwAnC4d2NnfR=; h=Subject:To:From:Date:From:Subject; b=ovkjhD+FrzqaDidpY6mUD5HM4BguXvcTQfJa5MAgPVM0WQn52Y4rvb+5f6OmpN11xX0UP9Sn+nLWALUVy+mAaKD4dqxQk9mKgYwF5h1CpHcxNM5gYiJ+6BOTSb0Er3ajVKflQYhIVW+ajcOmrI7x8SF0/lsQBt/dXSJEH23JMfg79Ae8L0QrHibyoHtJRMVBbmo2pyLloPTtM9ZpuZWsS2DmMu6kbcdDWPdcsoI3q86xpCADHpFmgGc1/PR4Tg82BIonA2yFzG5SWQw29R1wxWbpG6vr69wTJ3nK3dtdBO8cNQ0Psk7K0yZ1ZCCfz8+naYabXxl9dia+7N51mANcDw== X-YMail-OSG: 7gwRcQUVM1nndAQ2gsD_q6iX9UCtzxKZihZ6oGG0JEGQdXaTbQcxyeoIi96L.N0 .taJs1KYkGW7.QWLHMtdMrIElflkOv2PoJGkejw_iyIPWGQCmNR9ELJOwwSueNT8psyo2Zw7DMhh WiGc6TWYLswxWkKiGxC_RJrQBP3WgQduYpzWoKQBdmGCpqw1xMQpJ33SAFVwkzhi8hLiEUTVzCk7 gLXYPpiwGy5YQsm1HqOckIjNspYoexnohwXDUZWwpQtdLzjnAON6MVYi8Wud_to_1Am58A_Yz7Nx 0jYOD7qnXlPYDjjfGxTkaEjcbJyAlr6rTSeLMuJDzrmbgKzgri.6cVJBTunvcwVCyT1mo.3Jb3vC iGuDNJbEuSFwkeKm3ATaeV_xRENjajPrtgRvbNsETmaDL75dbZR2MwhxuizF5eQt5YlHGJTAKJ.. KQDAjD9MGu7_pbDCHd36v8DePyUBun0dv3Cd6IlhXOp4M0PrpeOvre7_OcF_eWzt1bHV5PkMVU07 znDvZCtofEuXvlllHMFDS.n2kkRWVZl2HSgI3cfoeB3sgefG0ogazstPke6IqKjqrwdu5Mz_rg9q WKEWXV3scxHUqGsqcS.9tzqLdoeqNCfuKwCUa8X_Drom1lnF_vBm2AeJG8o8HhXOh.Ic6w2vpYZe 4hs.OWVEdl1nJ9IQuAOS_lfXH2e3TQmk3eR0HEaSB1FzFFmOcjoyfl4k7FnCdUQfjL2exJS7AjgV nF9w0lqAvIlF.gZ1J1DCqihSwiDAcTAEBELZxHQLIg.8Nwkgkr64JrnEE8DfsUF43Cv7mg2My1t5 BxqeoYkAulEcVYL_eYqAjns3XDsNbdoIm8NyIvDuKo4kd1IxqBamQhI3R1tjV.e8vY988yGASbOn VlxtJbKydSeHLxsBI7luW1stfg0sTonIKQbCTirWbTvBDdPSZPsJ7XQh03BdFmknileqDOX2X.FL fjKHQ2_1UaFgYHqO9PeLvXEkZhBGdaFwe7jHZYVsV4kK4XJjTC20DBqO5NvSvk25Uo6o6V7Ohq0j PG2WRnkrEA5Qyhes5epRxyaDLvBqoKOHnXzol.egOHpNroukouaKExRGlQw_7wUMYSaKWgIAvpWr V4lY2OvYruMFGqcNRQf7iuqmgVHJXpmqErKcJmld6G_tl4fe88fUS0q6.ewd4R9KV9gtp6o2iLbx 5_ajPwT.drfncyh5DguDOuLBiSFItdYDuLeu8zvRU4zaa.YfbGyWwwavNiaM4yWNpgx29m5CtcGF CYTwvTI7iXBFW740EghdhLA.PilYNa3fzN6rJgaOrWmpcpvfS.XoiPz_i12G_r7RVEuvdGgubkN4 w6kCjDcuTL9W84LrA1I0KMavQb_NwwvUzHgf3xLfygUl9x0SixX2hSGmMWq00_Ro4A.hiM30V9FB xEiu8.u7O.Ew0L22BKn7IZ0e3lXeJrP_zL83zPwD26KzJzYFGcK.otuMp1F8m9mCKP5g91_QdCBr Xwb6HwqIKztcX4_0WGQ37qWYAH5iZeBSavHhzPqyw.HEE_iR.uY5sPiv7WlmcJifdu1nD1pWypPG .wjSXjbgjwXeHe8s2lfCMIPoGoZV5N1lLufgIbGdk_FCAasNlGEAUlf8m0HrmCi3fcSBIwkd3UzT PMBuyMdKIMda.KS0QvstnwNB3Sd849.oecFlnoSxWZxVMsdqM1yTaSeTW0ybIo60z6UFJJrI.whk s9WRlPoHLij3b0ptIYu3BRQofz2fsVzyNlczW8hOqA2f6bZTBfW9WgkLISNSUC7m726fPb4ZTL86 r9qzt6C.c5f53z6QLh93FFjwl71uKZL_A0EqERHiDvzsxYhESs2kvcd35YGfT50Bm9ENM.kYeCLt GItYBVFj1fnDvxAcsu4tk2MX9GFIRyFH67L3zZPeBCDNOFoaG6eaC8Bfz1Vrb8_eVBTuDqynj757 yLxGh4psV2bmpwxd5vQfy7QS74UXk5ERuM1SZnMcHsjp1X0iLvDeHe67tD54le24er.dgac_vDtH l0HFIVmudSqyRGpmlPKMpLd7f5QwYetI07pZQATddpFuSsmwh.tO.Pm28RLD48JENHLgsif.kmIO UNU829HaOmAMWSkMXk_VwZRi10LRgeOKzi_smVovNhnWvw2D385sCEsK50.tC86wIw8KfX93ha5a 5_OvAqVecfYxFl2u5UjC5avj_dK9_K183q7nEfqpNCeTM1AtTrCL2SS4Ed_wL3T4eM6nXwiobjdX z0SKGZ0vQTgHSQN9HI7aJpuvZOuWEwcl2iD82nK_Nc2t1WrB.YNL7rFOB8HUoAJuhaNZdi8Y9a4c qnNRytABjlQ7f8Fr_3mgKGs5qF6zFLjQfSm7xgvAN5u0SFISi02T68iELoq26Rv9Q4gV.Vj43zSN afFOTIIZU2zBzkMIuOFyssbmKporqqzZicVo3BsV0yW4_D2vUpS1Tzl6dcv28Y1hB62Tn1iu9fK_ QgBbsbQ4E Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 23 Dec 2020 16:41:26 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f21bf2fef6d2d6956d9f79c29cf9768a; Wed, 23 Dec 2020 16:41:21 +0000 (UTC) To: sidrops@ietf.org References: <12001c46-2fe3-6616-2969-f97d247e972e.ref@verizon.net> <12001c46-2fe3-6616-2969-f97d247e972e@verizon.net> From: Stephen Kent Message-ID: <877cb93a-2715-b608-9cbd-01b4a89a04db@verizon.net> Date: Wed, 23 Dec 2020 11:41:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF63A1DFAFF9D02A168E7BC8" Content-Language: en-US X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] revised text for section 6 of 6486bis 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, 23 Dec 2020 16:41:31 -0000 This is a multi-part message in MIME format. --------------DF63A1DFAFF9D02A168E7BC8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Ties, You make a good point. The text in 6.6 is a hold over from previous revisions. It does go against the notion of using the manifest only to ensure that the files retrieved by an RP are the same as the ones published by the relevant CA. So, I have removed that text as shown below. Removing the requirement to verify that the retrieve files match the manifest scope will not be a concern if we can identify other RPKI RFCs that require the RP to perform all of the same checks. The scope of a manifest is defined in Section 2 of 8486 as: ��� 1. the set of (non-expired, non-revoked) certificates issued and published by this CA, �� 2. the most recent CRL issued by this CA, and �� 3. all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA The cert validation described in 6487 should ensure that all of the certs encountered are not revoked and not expired, so #1 is satisfied elsewhere. Similarly, 6487 requires an RP to check that is has acquired a current CRL, although is does not address the issue of having encountered multiple CRL files as part of a fetch. That still seems to be an area where some additional clarification of behavior is needed. It is not clear that #3 above is addressed in other RFCs. If a ROA is missing, because the CA failed to publish it, it's not clear which other PKIX RFC will cause an RP to detect this. Similarly, if a subordinate CA cert is missing from the pub point, and the manifest, it's not clear how an RP will detect this (possibly erroneous) omission by the CA. The simple requirement that what is retrieved is what was published will have been met, but this still allows several forms of CA errors to go undetected by an RP. Steve ----- 6.Relying Party Processing of Manifests Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters).As noted earlier, manifests are designed to allow an RP to detect manipulation of repository data, errors by a CA or repository manager, and/or active attacks on the communication channel between an RP and a repository. Unless all of the files enumerated in a manifest can be obtained by an RP during a fetch operation, the fetch is considered to have failed and the RP MUST retry the fetch later. [RFC6480] suggests (but does not mandate) that the RPKI model employ fetches that are incremental, e.g., an RP transfers files from a publication point only if they are new/changed since the previous, successful, fetch represented in the RP's local cache.This document avoids language that relies on details of the underlying file transfer mechanism employed by an RP and a publication point to effect this operation.Thus the term "fetch" refers to an operation that attempts to acquire the full set of files at a publication point, consistent with the id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see below). If a fetch fails, it is assumed that a subsequent fetch will resolve problems encountered during the fetch.Until such time as a successful fetch is executed, an RP SHOULD use cached data from a previous, successful fetch.This response is intended to prevent an RP from misinterpreting data associated with a publication point, and thus possibly treating invalid routes as valid, or vice versa. The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files. Moreover, in operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to acquisition or validation of RPKI data. Note also that there is a "chicken and egg" relationship between the manifest and the CRL for a given CA instance.If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious error.In this case the fetch has failed; proceed to Section 6.6. Similarly, if the CRL is not listed on a valid, current manifest, acquired during a fetch, the fetch has failed; proceed to Section 6.6, because the CRL is considered missing. 6.1.Manifest Processing Overview For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are acceptable.The tests described below (Section 6.2 to Section 6.5) are to be performed using the manifest identified by the id-ad- rpkiManifest URI extracted from a CA certificate's SIA.All of the files referenced by the manifest MUST be located at the publication point specified by the id-ad-caRepository URI from the (same) CA certificate's SIA.The manifest and the files it references MUST reside at the same publication point.If an RP encounters any files that appear on a manifest but do not reside at the same publication point as the manifest the RP MUST treat the fetch as failed, and a warning MUST be issued (see Section 6.6 below). Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances will appear at the same publication point.Manifest processing is to be performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate. 6.2.Acquiring a Manifest for a CA The RP MUST fetch the manifest identified by the SIA id-ad- rpkiManifest URI in the CA certificate.If an RP cannot retrieve a manifest using this URI, or if the manifest is not valid (Section 4.4), an RP MUST treat this as a failed fetch and, proceed to Section 6.6; otherwise proceed to Section 6.3. 6.3.Detecting Stale and or Prematurely-issued Manifests The RP MUST check that the current time (translated to UTC) is between thisUpdate and nextUpdate.If the current time lies within this interval, proceed to Section 6.4.If the current time is earlier than thisUpdate, the CA has made an error; this is a failed fetch and the RP MUST proceed to Section 6.6.If the current time is later than nextUpdate, then the manifest is stale; this is a failed fetch and RP MUST proceed to Section 6.6; otherwise proceed to Section 6.4. 6.4.Acquiring Files Referenced by a Manifest The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point, the fetch has failed and the RP MUST proceed to Section 6.6; otherwise, proceed to Section 6.5 6.5.Matching File Names and Hashes The RP MUST verify that the hash value of each file listed in the manifest matches the value obtained by hashing the file acquired from the publication point.If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then the fetch has failed and the RP MUST proceed to Section 6.6; otherwise he fetch isdeemed successful and the RP will � process the fetched objects. 6.6.Failed Fetches If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST issue a warning indicating the reason(s)for termination of processing with regard to this CA instance.It is RECOMMENDED that a human operator be notified of this warning. Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch.This implies that the RP MUST not try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. --------------DF63A1DFAFF9D02A168E7BC8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Ties,

You make a good point. The text in 6.6 is a hold over from previous revisions. It does go against the notion of using the manifest only to ensure that the files retrieved by an RP are the same as the ones published by the relevant CA. So, I have removed that text as shown below.

Removing the requirement to verify that the retrieve files match the manifest scope will not be a concern if we can identify other RPKI RFCs that require the RP to perform all of the same checks. The scope of a manifest is defined in Section 2 of 8486 as:

��� 1. the set of (non-expired, non-revoked) certificates issued and published by this CA,

�� 2. the most recent CRL issued by this CA, and

�� 3. all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA

The cert validation described in 6487 should ensure that all of the certs encountered are not revoked and not expired, so #1 is satisfied elsewhere. Similarly, 6487 requires an RP to check that is has acquired a current CRL, although is does not address the issue of having encountered multiple CRL files as part of a fetch. That still seems to be an area where some additional clarification of behavior is needed.

It is not clear that #3 above is addressed in other RFCs. If a ROA is missing, because the CA failed to publish it, it's not clear which other PKIX RFC will cause an RP to detect this. Similarly, if a subordinate CA cert is missing from the pub point, and the manifest, it's not clear how an RP will detect this (possibly erroneous) omission by the CA. The simple requirement that what is retrieved is what was published will have been met, but this still allows several forms of CA errors to go undetected by an RP.

Steve

-----


6.��Relying Party Processing of Manifests

�

���Each RP must determine which signed objects it will use for
���validating assertions about INRs and their use (e.g., which ROAs to
���use in the construction of route filters).��As noted earlier,
���manifests are designed to allow an RP to detect manipulation of
���repository data, errors by a CA or repository manager, and/or active
���attacks on the communication channel between an RP and a repository.
���Unless all of the files enumerated in a manifest can be obtained by
���an RP during a fetch operation, the fetch is considered to have
���failed and the RP MUST retry the fetch later.

�

���[RFC6480] suggests (but does not mandate) that the RPKI model employ
���fetches that are incremental, e.g., an RP transfers files from a
���publication point only if they are new/changed since the previous,
���successful, fetch represented in the RP's local cache.��This document
���avoids language that relies on details of the underlying file
���transfer mechanism employed by an RP and a publication point to
���effect this operation.��Thus the term "fetch" refers to an operation
���that attempts to acquire the full set of files at a publication
���point, consistent with the id-ad-rpkiManifest URI extracted from a CA
���certificate's SIA (see below).

�

���If a fetch fails, it is assumed that a subsequent fetch will resolve
���problems encountered during the fetch.��Until such time as a
���successful fetch is executed, an RP SHOULD use cached data from a
���previous, successful fetch.��This response is intended to prevent an
���RP from misinterpreting data associated with a publication point, and
���thus possibly treating invalid routes as valid, or vice versa.

�

���The processing described below is designed to cause all RPs with
���access to the same local cache and RPKI repository data to acquire
���the same set of validated repository files. It does not ensure that
���the RPs will achieve the same results with regard to validation of�
���RPKI data, since that depends on how each RP resolves any conflicts�
���that may arise in processing the retrieved files. Moreover, in�
���operation, different RPs will access repositories at different times,
���and some RPs may experience local cache failures, so there is no
���guarantee that all RPs will achieve the same results with regard to
���acquisition or validation of RPKI data.

�

���Note also that there is a "chicken and egg" relationship between the
���manifest and the CRL for a given CA instance.��If the EE certificate
���for the current manifest is revoked, i.e., it appears in the current
���CRL, then the CA or publication point manager has made a serious
���error.��In this case the fetch has failed; proceed to Section 6.6.
���Similarly, if the CRL is not listed on a valid, current manifest,
���acquired during a fetch, the fetch has failed; proceed to
���Section 6.6, because the CRL is considered missing.

�

�

�

6.1.��Manifest Processing Overview

�

���For a given publication point, an RP MUST perform a series of tests
���to determine which signed object files at the publication point are
���acceptable.��The tests described below (Section 6.2 to Section 6.5)
���are to be performed using the manifest identified by the id-ad-
���rpkiManifest URI extracted from a CA certificate's SIA.��All of the
���files referenced by the manifest MUST be located at the
���publication point specified by the id-ad-caRepository URI from the
���(same) CA certificate's SIA.��The manifest and the files it
���references MUST reside at the same publication point.��If an RP
���encounters any files that appear on a manifest but do not reside at
���the same publication point as the manifest the RP MUST treat the
���fetch as failed, and a warning MUST be issued (see Section 6.6
���below).

�

���Note that, during CA key rollover [RFC6489], signed objects for two
���or more different CA instances will appear at the same publication
���point.��Manifest processing is to be performed separately for each CA
���instance, guided by the SIA id-ad-rpkiManifest URI in each CA
���certificate.

�

6.2.��Acquiring a Manifest for a CA

�

���The RP MUST fetch the manifest identified by the SIA id-ad-
���rpkiManifest URI in the CA certificate.��If an RP cannot retrieve a
���manifest using this URI, or if the manifest is not valid
���(Section 4.4), an RP MUST treat this as a failed fetch and, proceed
���to Section 6.6; otherwise proceed to Section 6.3.

�

6.3.��Detecting Stale and or Prematurely-issued Manifests

�

���The RP MUST check that the current time (translated to UTC) is
���between thisUpdate and nextUpdate.��If the current time lies within
���this interval, proceed to Section 6.4.��If the current time is
���earlier than thisUpdate, the CA has made an error; this is a failed
���fetch and the RP MUST proceed to Section 6.6.��If the current time is
���later than nextUpdate, then the manifest is stale; this is a failed
���fetch and RP MUST proceed to Section 6.6; otherwise proceed to
���Section 6.4.

�

�

6.4.��Acquiring Files Referenced by a Manifest

�

���The RP MUST acquire all of the files enumerated in the manifest
���(fileList) from the publication point. If there are files listed in
���the manifest that cannot be retrieved from the publication point, the�
���fetch has failed and the RP MUST proceed to Section 6.6; otherwise,�
���proceed to Section 6.5

�

�

6.5.��Matching File Names and Hashes

�

���The RP MUST verify that the hash value of each file listed in the
���manifest matches the value obtained by hashing the file acquired from
���the publication point.��If the computed hash value of a file listed
���on the manifest does not match the hash value contained in the
���manifest, then the fetch has failed and the RP MUST proceed to
���Section 6.6; otherwise he fetch is� deemed successful and the RP will
� process the fetched objects.

�

�

6.6.��Failed Fetches

�

���If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST�
���issue a warning indicating the reason(s)for termination of processing
���with regard to this CA instance.��It is RECOMMENDED that a human�
���operator be notified of this warning.

�

���Termination of processing means that the RP SHOULD continue to use
���cached versions of the objects associated with this CA instance,
���until such time as they become stale or they can be replaced by
���objects from a successful fetch.��This implies that the RP MUST not
���try to acquire and validate subordinate signed objects, e.g.,
���subordinate CA certificates, until the next interval when the RP is
���scheduled to fetch and process data for this CA instance.
--------------DF63A1DFAFF9D02A168E7BC8-- From nobody Sat Dec 26 08:26:47 2020 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 5DADF3A09EF; Sat, 26 Dec 2020 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QkKkX37xdfeX; Sat, 26 Dec 2020 08:26:43 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 302AD3A09F6; Sat, 26 Dec 2020 08:26:42 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (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 1196460896; Sat, 26 Dec 2020 16:26:39 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 268b599c; Sat, 26 Dec 2020 16:26:33 +0000 (UTC) Date: Sat, 26 Dec 2020 16:26:33 +0000 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] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) 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, 26 Dec 2020 16:26:46 -0000 Dear group, On Thu, Nov 19, 2020 at 10:04:50AM -0500, Christopher Morrow wrote: > Howdy WG Folks! > During our last Face-to-Face meeting the authors of: > draft-michaelson-rpki-rta > > presented their document and requested (in meeting and via email to > the list) a call for Working Group Adoption. The abstract of the > document is: > > "This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources." > > let's have a read-through, think about applicability to SIDR-OPS as it > relates to the technology we build and operate (technology and > business intersection), and provide feedback on the list before > 10/12/2020 (Dec 10th). I support adoption, and I am willing to try to create a validator implementation based on OpenBSD's rpki-client. During implementation feedback in the current document & questions can be shared with the group, hopefully increasing the document's readability for future implementers. A particular use case stands out to me: the PeeringDB platform could use RTAs to validate ownership of PeeringDB "IX" and "Network" objects, greatly increasing reliability of its user-submitted database, while further reducing friction in its onboarding processes. I would like to recommend the authors to include a copy of the RFC 7942 section 2.1 boilerplate text in the draft (optionally to be removed by the RFC Editor) to help track implementations. Please make it clear the 'signer' and 'validator' components are implemented separately. Congratulations to both APNIC and NLNetlabs for already having implemented such an incredibly innovative application of the RPKI. I'm certain RTAs will prove to be useful in a myriad of B2B processes. Kind regards, Job From nobody Sat Dec 26 09:19:06 2020 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 64C723A0B2D; Sat, 26 Dec 2020 09:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 Mee610ftE097; Sat, 26 Dec 2020 09:19:04 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 24F3C3A0B21; Sat, 26 Dec 2020 09:19:04 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id l7so3271993qvt.4; Sat, 26 Dec 2020 09:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=172UKzNyNtVhzLbn3dBG5CQctR7W6f5G3SG/0mT5WOI=; b=YxSLMJRn3Hs/RohD9k+VOUoeM8mm/00iFxiLL7azVWaqybN30mSik9EB16AnVzJTmU m4m8RyYGEmaoQuM/BXNpWXxiLtFVCvtY/K4D5uKRfF88hj6CHs+Q47GT4DhDxNvotQdE wF915SWyMcmZDJEoTDmGeaez9hZMDdT05uBNtkJ8BOy3w3ZwpwHYjvHiiPn1o1YxfdHA YoNp6U+FhlUXr3UfbAG1Hpk2MLo/qY84JwIg2yT1u3r2j7XgGg2A4viVX0jms97U75Wz k/SpwRNK4o8eGi4Xnm2twMA4Na+8Ei2pJwm56JzK0tfdJRrhjCc+feXzObSo+kIMMR7k 2PwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=172UKzNyNtVhzLbn3dBG5CQctR7W6f5G3SG/0mT5WOI=; b=s6HxEocztGGhnKiB4K7m+OzHL/gQ+pM1tGi/NYeBhVmFuXa+4yBbEYunYUMezDDHru GXFd75SVbYayhyDMqFHQFPC+xCJbQlBPLnD6TpVdiecAbelpinxMKkORFv9CypPvws5A v77sJUE/y9v4nZ4tjgxOhw8wL4AWOLOe2na0+LevyfXG0NgThREhd+g5pZL1MDg85lsc 3QAeHSkCCQ6MszgxnhBihadvCsBxKOyc/xkwTh/rbqOUHDKZ1lUmW4W8LBjPc7SaWmTW Aw8MDee+KpnNwxAc5rzYfcnp2NV1QgEH7qvW6Qp819eubJJXoSlwOc9+9a0OF7vnEBWl pukg== X-Gm-Message-State: AOAM530qRp03wMC+6BrNe4K7RgQrMciv66DKBC3aW0Vk4rbwHpRkqzVP mVAhjesWHccf+xgF51P9WYH1oGH22bLAEoKBhs5PFhe7snI= X-Google-Smtp-Source: ABdhPJwnNWFgi7MsScXCqRHdH/Pkpw4ldTbGYyRv2PO//oHfcGAxoEgrO6UDGOZpmYigIdwIC6NysGvYKwzzUJyk6nc= X-Received: by 2002:a05:6214:a94:: with SMTP id ev20mr40116144qvb.56.1609003142725; Sat, 26 Dec 2020 09:19:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sat, 26 Dec 2020 12:18:51 -0500 Message-ID: To: SIDR Operations WG , SIDROps Chairs , sidrops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] WG-ADOPTION - draft-michaelson-rpki-rta - Ends 12/10/2020 (Dec 10 2020) 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, 26 Dec 2020 17:19:05 -0000 It sounds like there are enough folk curiousinterested/with-use-cases that this draft can get picked up by SIDROPS for some more work/discussion. Could the authors please submit a draft in their own time with the properly re-named title/etc? :) thanks! -chris (also, happy holidays) On Thu, Nov 19, 2020 at 10:04 AM Christopher Morrow wrote: > > Howdy WG Folks! > During our last Face-to-Face meeting the authors of: > draft-michaelson-rpki-rta > > presented their document and requested (in meeting and via email to > the list) a call for Working Group Adoption. The abstract of the > document is: > > "This document defines a Cryptographic Message Syntax (CMS) profile > for a general purpose Resource Tagged Attestation (RTA), for use with > the Resource Public Key Infrastructure (RPKI). The objective is to > allow an attestation, in the form of an arbitrary digital object, to > be signed "with resources", and for validation to provide an outcome > of "valid with resources". The profile is intended to provide for > the signing of an attestation with an arbitrary set of resources." > > let's have a read-through, think about applicability to SIDR-OPS as it > relates to the technology we build and operate (technology and > business intersection), and provide feedback on the list before > 10/12/2020 (Dec 10th). > > Thanks! > -chris > co-chair-persona From nobody Sat Dec 26 09:51:01 2020 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 5EA3B3A0B8F for ; Sat, 26 Dec 2020 09:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 g37cxkC8m5Gg for ; Sat, 26 Dec 2020 09:50:56 -0800 (PST) Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 6BA253A0A81 for ; Sat, 26 Dec 2020 09:50:55 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (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 4F45A602C8 for ; Sat, 26 Dec 2020 17:50:52 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 173bb77b; Sat, 26 Dec 2020 17:50:49 +0000 (UTC) Date: Sat, 26 Dec 2020 17:50:49 +0000 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] feedback on draft-michaelson-rpki-rta 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, 26 Dec 2020 17:50:59 -0000 Dear group, Reading draft-michaelson-rpki-rta-02 while writing some work-in-progress code, I have some suggestions that hopefully improve the ease of use of RTAs. WIP: http://sobornost.net/~job/rpki-client-rta.patch.txt While it is useful property of RTAs they can be exchanged via email or webforms (aka 'private B2B'), I also envision use cases where RTA objects are best distributed through a publication protocol (public INR holder statements). I forsee increased interoperability if the document specifies some constraints on how to publish RTAs via RSYNC/RRDP, if the Resource Holder chooses to use that path. Some suggestions for text are included below. Of course, from a cryptographic validation and 'permissionless innovation' point-of-view the 'standalone' use of RTAs (without IANA actions) is perfectly valid and applicable, however from an interopability point-of-view I would encourage the group to also go through the motions on describing how to publicly publish RTAs, and thus target Standards Track. Kind regards, Job --------------------- OLD: Intended status: Experimental NEW: Intended status: Standards Track --------------------- Section 8 OLD: An RTA and its associated EE certificates MAY appear on an RPKI Manifest and MAY be published in a repository. NEW: An RTA and its associated EE certificates MAY appear on an RPKI Manifest and MAY be published in a repository. If an RTA appears on an RPKI Manifest, the RTA's file extension MUST be '.rta'. ---------------------- OLD: Section 9 IANA is entirely off the hook on this one. NEW: Section 9.1 OID The IANA is requested to reference the '1.2.840.113549.1.9.16.1.36' OID as Resource Tagged Attestations in the RPKI Signed Objects registry created by [RFC6488]. Section 9.2 File Extension IANA is requested to an item for the Ghostbusters Record file extension to the "RPKI Repository Name Scheme" created by [RFC6481] as follows: '.rta', 'Resource Tagged Attestation', ref: [draft-michaelson-rpki-rta] Section 9.3 Media Type The IANA is requested to register the media type application/rpki-rta as follows: Type name: application Subtype name: rpki-resourcetaggedattestations Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries an Resource Tagged Attestation [draft-michaelson-rpki-rta] Applications that use this media type: RPKI users. Additional information: Content: This media type is a signed object, as defined in [draft-michaelson-rpki-rta], which contains an arbitary canonicalized payload as defined above in this document. Magic number(s): None File extension(s): .rta Person & email address to contact for further information: George Michaelson Intended usage: COMMON Restrictions on usage: None Author: George Michaelson Change controller: George Michaelson -------------------------- From nobody Tue Dec 29 02:14:25 2020 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 3E07A3A134B for ; Tue, 29 Dec 2020 02:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 hpLnkpTV-RSn for ; Tue, 29 Dec 2020 02:14:20 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FA83A134C for ; Tue, 29 Dec 2020 02:14:19 -0800 (PST) Received: (qmail 46778 invoked by uid 1000); 29 Dec 2020 10:14:12 -0000 Date: Tue, 29 Dec 2020 11:14:12 +0100 From: Claudio Jeker To: Job Snijders Cc: sidrops@ietf.org Message-ID: <20201229101412.GA56136@diehard.n-r-g.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 10:14:23 -0000 On Sat, Dec 26, 2020 at 05:50:49PM +0000, Job Snijders wrote: > Dear group, > > Reading draft-michaelson-rpki-rta-02 while writing some work-in-progress > code, I have some suggestions that hopefully improve the ease of use > of RTAs. WIP: http://sobornost.net/~job/rpki-client-rta.patch.txt I checked your diff and the draft. I think one thing in the draft. There is a big issue with the fact that RTA can be cross signed by multiple certs. No other resource in RPKI does that and it causes some issues with the validation process. Until now each CA repo could be checked independently once ready but now RTA files suddenly have interdependencies that need special attention. I would like to know why this complication is needed for RTA - what is the actual use case where multiple signers are necessary. I currently don't see why this is required (especially since the resources (ASnum and IP blocks) need to be allowed by all those CA certs. Your diff needs some work to actually do the full validation. We should not punt this off to 3rd party. Also in rta_parse() the calloc uses a wrong sizeof() rta instead of roa (or better just use sizeof(*p.res)). RFCs like this need some demo resources to play with. -- :wq Claudio From nobody Tue Dec 29 04:10:27 2020 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 597A63A138A for ; Tue, 29 Dec 2020 04:10:26 -0800 (PST) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SUfarhQIW4nv for ; Tue, 29 Dec 2020 04:10:23 -0800 (PST) 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 EC7713A1386 for ; Tue, 29 Dec 2020 04:10:22 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (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 ACB5D60199 for ; Tue, 29 Dec 2020 12:10:19 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id cbad3371; Tue, 29 Dec 2020 12:10:15 +0000 (UTC) Date: Tue, 29 Dec 2020 12:10:14 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <20201229101412.GA56136@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201229101412.GA56136@diehard.n-r-g.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 12:10:26 -0000 Dear group, On Tue, Dec 29, 2020 at 11:14:12AM +0100, Claudio Jeker wrote: > There is a big issue with the fact that RTA can be cross signed by > multiple certs. No other resource in RPKI does that and it causes some > issues with the validation process. Until now each CA repo could be > checked independently once ready but now RTA files suddenly have > interdependencies that need special attention. I would like to know > why this complication is needed for RTA - what is the actual use case > where multiple signers are necessary. I currently don't see why this > is required (especially since the resources (ASnum and IP blocks) need > to be allowed by all those CA certs. I agree. Removing subjectKeyIdentifers greatly simplifies the RTA concept without compromising its application and utility for the use cases I'd like to deploy. With the following new formal definition in mind: ResourceTaggedAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, resources ResourceBlock, digestAlgorithm AlgorithmIdentifer, messageDigest OCTET STRING } Having the 'resources' listed in the payload (and of course require those to match what was delegated to the issuing entity, just like is done with ROAs) makes sense to me, because this way the Relying Party can understand which of many subordinate resources attested. For example in the use case I envision for PeeringDB.com: An entity who have 2 ASNs (199036 and 15562, archived example: http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/ZrvTEk3dw4Cs6zD65ee6glPlruQ.cer.html) wishes to sign-up for PeeringDB.com. They only want to proof to PeeringDB they own AS 15562 (so AS 199036 is out of scope in this B2B process). The PeeringDB.com interface in the sign-up process generates a file with some random contents, hashes this random data, and then expects the Resource Holding entity to put the message digest in a RTA. Also they expect at least resource 'AS 15562' in the 'resources' field. The operational benefit is that looking at just the validated RTA payload one can figure out which resource created the digest. INR ownership verification process: Entity holding resources <-> PeeringDB.com 15562, 199036 | ---> Express desire to prove ownership for 15562 --> | Generate file with some random data | Generate message digest X for the file | Store digest X as part of onboarding attempt <--- Request INR holder to create RTA with message digest X <--- Generate RTA with at least | 15562 as resource, and digest X | in RTA payload | ---> send the RTA file via email or webform to PeeringDB ---> | Validate RTA, pull out payload. | Compare whether the digest in the | RTA payload matches digest X | stored as part of the onboarding | attempt >From a validation perspective, the above process to me seems sufficient (and state of the art!) for BYOIP / BYOAS purposes. Even if digest X is intercepted, the onboarding process is not compromised (assuming the Trust Anchors are not compromised). Of note should be that the attested file itself is not even exchanged between the two parties, merely indicating which digest is expected, and seeing this partciular digest in a valid current RTA is the attestation. The advantage of using a message Digest as 'nonce' is that both the use case of just proving ownership vs attesting digital objects (files). So that part I like a lot, RTA can be used to both form relations and attest file contents. Just like ROAs, Ghost Buster Records, or Manifests *payloads* don't have a set of additional subjectKeyIdentifers referencing to things in the outer enveloppe, I think RTAs might be better off without them. Look forward to feedback from others. > RFCs like this need some demo resources to play with. Yes. Kind regards, Job From nobody Tue Dec 29 04:58:35 2020 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 122723A13B4 for ; Tue, 29 Dec 2020 04:58:34 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 ChhJjxDPls0F for ; Tue, 29 Dec 2020 04:58:32 -0800 (PST) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (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 B9D6A3A13AC for ; Tue, 29 Dec 2020 04:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1609246710; bh=3xUGroxH85JSLquJ5ke8ZFOYBo/PiaVkkTLx8JJdUFA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=HabrJs9ssFHWCjlt0ssFo0E2NffGZ0YRrch2mhHSijajeo7VYd9TT1a+wLvc7XIIkpFvA40VsbLrFoTAvOnk/ep4FvTBhdXjcFcTlVR98xZGM6vVMSZh4qtl9nXHPSd8Sk9EOKa9ZFrmG4+yWDYb2UG+BkFvBjCO9NXzb0X99fbv1CRr8iLObmx0xnv3WMd7nRgGQzOd2b4xd16b0Ad41izYmsxe75782OW6BwG3FsCv9tTxQCJnd0qmoQeoCbhopZaoL2yfmOziddfoWiKVsUUwEN52DpxfOGs4HGlJP7XX46xXGgRUjvOsUAN9T0K+TikGMS9xGU5IK7vI3/BznQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609246710; bh=xDE25LeizFwkYpzeSWFJAan/rX37I8mrifEPhjXT/H5=; h=Subject:To:From:Date:From:Subject; b=tnESz5MNLXmbhXF3iKsWzwgO4mSiiBCQd4ZPe/urif40gHabNjzE3R5USuuDDhVcrJeTdlKD4/YMYQi8E3gDJhBzT7QVXhjthUeDQDiw87tqDKIO/qJ35y28f1K8idthIq87QlP/MHZj4Sr68HItr5J+3nJX95bDZPZd7+Oe8BibWFeEWKVf1F9R2Q6MnxrQ1WHme38spGUt7a4aWwbp3HFIfKY3lbjP2ry7z1+yVuf/jFet6mT7+gokkNSXN5wmW8sLBhjbTskCJOkDjloAgtsbBCAHIzf/eVL9V+/nQDPp0GS5WUPydQ5I/B6x+2S5TI3s/+y1jCVos8Yu0b1Atw== X-YMail-OSG: WG17Z4EVM1m3CR2IvH7kqeHqrV_H5BKenoULW4qjakotuUO0IiBeYNID9DUdqWc Iyw5Kg.3Rlav8zu1XPKfTXtsjDgt.rLaUt1f4rSBSvOwDbm_AAQSwDZeEFzn4X2uvxrJ9_JbNuZt r_0yUvlnRfFWngsR3w.lmz.ogCvdMg2TPmqViYPgPdYOSOPFFs7GGmEQb0N27Axx9VqtkiShPiWy 0dInzPLoRIQu246Sd0JRr7WEJeva.YyhgVvZ67OhDBP60rKZiZXfISjAV5xO9lg8tiImNd.MOfM6 olS8KiOPHjGQR6yNXgbViofXu9IvrilCzBGiRZy8KdoE2IsGOCa9BsJAkTci7Qb5APZ57RBwWOkw _Abwwf49KmSNUUZ7QwdfMn8IYMGBLSD7dxRqxUNz4HpPLTdT72oOzZIMU0CAYXfGUo6vZfTMheqZ A1RJLk50cXpAUyPq8yU81jP0NJtcS0IKQhWo1CE7Z7d20.oS3._jlPNnYAAeDJSQ10FQi73tOnF0 c9Sre_FDiTx8eS_JHdJhUqn569sjf5xp2VMlfEvMIXyLYo3ZpkME7Q.UjK6uxBa0xfkxCA7_h2so RMHjRrfwNkNq.tRRymo1angtJCrNedfjUKv5oOGvtvRpES4lrN8LLNI41qsUwtt4yvJiKh5eekM1 tnK4XlfcyFm6MQ7B_.L7ZmpRVf6H8Qgst8hchsl1CJZMmyKcRK8eSAJjh0CRDCAttDNZJY7t.8I2 T4Oaj_9_2vU0opyvoweFWHXXwdajBxpVwtTzq0kOgIMLjdbrtvCaaAIXS1wAU81mnkfOnxTVkex5 0hluCq59PvIWV9dT1fv8kUj4dfWBEYBBsOeBZQGb8AwcLh2XsX1BdoYkgtPOZV1c22OkV4xSfZBw 0zdH7TX6VaajSJIQzWkqegx2cm11rphYE6kIxynn9xgLuH9LKHhTu_lRlVoO5k5tm9TsZBBTFTO2 CT9QM0iGxyhtHNAJ8.0rXZHrB0okDYXinbC0DedZsB3MfKMmScTA3z9UOAJlBX9xij3Qg8kDG8fP 6kXMt3AL1M4n7ZgTE.TaFURQaxzNsxGZj0hBHB4qsAYl2ptgyarGmVzrqrddZnRClZW2Q_SZHyr. CDdTMvQUVYOjObtLOrMAcJeo8QnitDZ3pS_zslGR6aWoOEzraoHAD_mWVNFLyLZmdhu9j0.l93qr B63sSSX6ihMtdMAnOEBqfpI9xykV_TIWZMf07RicfxPfBqRuHeWhkf.AipPmeYb6XtgCgGNd8Saj V2J4zYFWpawgBPoBgurt6YaO7IuBjWTvX6DkmKIilSUNUsE3Pm7OYek79T.u5pTTPr8EjhIJ63Hn XT6Sue8E4sRzx3j0JuFp34R42eKcZf7De42nQ4fkxKjHQyHgbT9I8R1KXBXyMXKnuM9BLkmz.ZtM Pdd974Y3ds0znHDHcRE4OE8Eh5mE7rrLdHVqcBu5DmZDPMZtoA6rVSrhWCsWSbZ4r9hW7r7BHZHg ec_JUg2g55MUul3gQrYP5D63aFMCGgiVrF105ek6rnmWid09WbBk5mP8xQtTptZb_A1Jb31xdG_e gEi8igvaZ_iKX2seIXpPm5P7umyb.cd0__DvxhLBXNrOhSUA_D3AsqEznU.S9qaTZ.DQcOKgWtjb 52ZSZNtRHnMn.iMnzPRh6avMgKOPgJdxYwalTISXKKSIlExGq_18AkUCTWw_QTcgz80g29Jjppq5 fhl4f7cpef11f76qWQXwyTf1617PWs6nsMim5_v0wIQeg9TFq4clzlRLLI1FoeFHmOEYdni4BzTB 2H9cXwgd13cJdfuKCWn_WrJwBwmqxz3Sh2kIQMuTkYyLNJewOcsG3Qn7sbCoXCRop8_8HnIydrDY jJhQ3KSaNkX94LaCGLiw7T4dQ64iX9tkIs75KXjAD_teRl9AphIkADWHByNX.PPPx7s6lUB5K4JD 0zuT1GsokGIZ3PhZKVIrDFoBNrzmaxnHURDhf92VxKSAE79EcBdTV2JPj6OSovqynbGjNYCzQIIV a2T6TXu2BcATWl7rx6R0XN3EWYQZQx0g3h7QEnEVb7m7M.hg94n2xKRfAJGXpfbRDrVqOteJdUAV o71Dbj9Ls_AyLMzgrNRt.2SdKbl5bWo7AJXzCjmzIeh9KBPC._8VTcJfgsKgHQroGsrm8JV55.MM Q9sZniGFqAzS71CbMCNPsp7CvSRovw3G0Dn8Q2tSYTn0mxVMrygrMhAcfUH.MCHzTioZGEjwl517 sRmDBFO8ZJZ.L.g71uMJvcalgopIPX.i3wadXwqGsKxhroyUm.wWJIPZhR9.agZYumX6jzMOCMK5 WdpPche1VCNX4t2b932RoiWXF5u4rzqfAM8r3hIh9XA4QaCKO7TfeWwZ8bEaarDof9BXbCzJAm7d zgtFr1T1R73hPF35HhRzlQM4ZVWV9DpRACvoSLtIZb3sxXB8nBHTx5.rLgmLrBmXrvElhM_0RjjS xPZwntGnVvb7pEA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 Dec 2020 12:58:30 +0000 Received: by smtp414.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e035ac2e199632f7b3c73b01ad080933; Tue, 29 Dec 2020 12:58:30 +0000 (UTC) To: sidrops@ietf.org References: <20201229101412.GA56136@diehard.n-r-g.com> From: Stephen Kent Message-ID: <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> Date: Tue, 29 Dec 2020 07:58:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 12:58:34 -0000 Claudio & Job, RFC 6488 (2.1.6.2) requires use of the SKI in the sid for all "signed objects" in the RPKI. Is the proposal to not use an SKI in the RTA format compatible with this? Steve From nobody Tue Dec 29 07:16:46 2020 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 631723A1439 for ; Tue, 29 Dec 2020 07:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 3tKr1oSuqISj for ; Tue, 29 Dec 2020 07:16:44 -0800 (PST) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBDE3A1438 for ; Tue, 29 Dec 2020 07:16:41 -0800 (PST) Received: (qmail 22960 invoked by uid 1000); 29 Dec 2020 15:16:39 -0000 Date: Tue, 29 Dec 2020 16:16:39 +0100 From: Claudio Jeker To: Stephen Kent Cc: sidrops@ietf.org Message-ID: <20201229151639.GD56136@diehard.n-r-g.com> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 15:16:45 -0000 On Tue, Dec 29, 2020 at 07:58:29AM -0500, Stephen Kent wrote: > Claudio & Job, > > RFC 6488 (2.1.6.2) requires use of the SKI in the sid for all "signed > objects" in the RPKI. > > Is the proposal to not use an SKI in the RTA format compatible with this? No that is not what I was after. The usage of SKI as per RFC 6488 (2.1.6.2) is absolutly fine. My problem with the RTA draft are these points of the draft (section 3): The differences between this RTA profile and the profile specified by the RPKI Digitally Signed Object template are as follows: o Section 2.1 of [RFC6488] specifies a single SignerInfo object. An RTA MAY contain more than one SignerInfo object. o Section 2.1.4, and Section 3 of [RFC6488] specify that the certificates field contains a single EE certificate. The certificates field of an RTA contains precisely the same number of EE certificates as there are SignerInfo objects in the RTA, where each EE certificate is needed to validate the signature in each SignerInfo. In addition, the certificates field MAY contain a collection of CA certificates that would allow a RP to validate the EE certificates. Up until now all objects only had a single EE cert and a single SID and all the linking done with the SKI was a 1-to-1 mapping resulting in a simple tree structure with the trust anchor as root. This draft allows for multiple EE certs and so multiple paths up to the trust anchors. This makes handling RTA a lot more complex than any other object under RPKI. It also results in a lot more failure conditions since there are more EE certs involved in the validation process. -- :wq Claudio From nobody Tue Dec 29 07:57:16 2020 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 31B9A3A1450 for ; Tue, 29 Dec 2020 07:57:15 -0800 (PST) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aC2WL4r7xfkr for ; Tue, 29 Dec 2020 07:57:12 -0800 (PST) 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 E76C83A144F for ; Tue, 29 Dec 2020 07:57:11 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (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 2F298600E4 for ; Tue, 29 Dec 2020 15:57:09 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 72836234; Tue, 29 Dec 2020 15:57:07 +0000 (UTC) Date: Tue, 29 Dec 2020 15:57:07 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201229151639.GD56136@diehard.n-r-g.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 15:57:15 -0000 On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote: > Up until now all objects only had a single EE cert and a single SID and > all the linking done with the SKI was a 1-to-1 mapping resulting in a > simple tree structure with the trust anchor as root. > This draft allows for multiple EE certs and so multiple paths up to the > trust anchors. This makes handling RTA a lot more complex than any other > object under RPKI. It also results in a lot more failure conditions since > there are more EE certs involved in the validation process. And even worse, the complexity doesn't appear to provide any benefits: as can be seen from my example [1], with a reduced RTA eContent profile the BYOIP / BYOAS use case doesn't require a set of SKIs in the eContent. If a signer wants to create a RTA for some multi-signer x509 pem encoded file (or their vacation photos), they are free to do so, what the hash in the RTA eContent represents is out of scope. I believe a RTA should conceptually be very similar to a single RFC 6486 'FileAndHash', except instead of associating the hash with a IA5String 'file', the hash is associated with one or more Resources delegated to the Resource holder. Optionally, the hash is associated with an arbitary digital object outside the RPKI, onlookers won't know if the hash in the RTA econtent is the message itself or a digest of another digtal object. A cool property! Further more (just like in manifests) we can encourage the use of one-time-use EE certificates. The CA MAY choose to sign only one RTA with each generated private key, and generate a new key pair for each new version of the RTA. After generating the RTA the keypair can be destroyed. The draft-michaelson-rpki-rta-02 itself describes the presence of these additional certificates as a 'burden' (section 10): """ RTA objects themselves may appear in repositories, and are constrained in size to the ASN.1 encoded burden of the set of certificates which are sufficient to describe the RFC3779 resources associated with the signatures. """ So, why not just remove it? :) It is possible the RTA authors forsee use cases where the 'multiple signatures' offers irreplaceable value, I'm not sure. If this is the case, perhaps a second effort can be spun up: 'A Simplified RTA Profile'. In this separate second effort a lot of code can be re-used from the original RTA implementation, making sure no coding efforts went to waste. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/sidrops/WCDklq3lOR0LX2ZZkziMlxyWTaU/ From nobody Tue Dec 29 08:15:14 2020 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 A72123A0C2F for ; Tue, 29 Dec 2020 08:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 qfLgSLgaPGir for ; Tue, 29 Dec 2020 08:15:10 -0800 (PST) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 5525B3A0C2A for ; Tue, 29 Dec 2020 08:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1609258503; bh=brwZxaCIJGrmNBu9Xcv72jXKf8la6AQgv7Gjsms2EAI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=jR8Fpdr8JtRS0QzSh1+wmfPffT0lyii/Ify/z1XUHD22gNp2VxkPEXSMvnHqOWK0FUHbxt+EbHFc8bM3vBuff3GCGeYOClR9wxuw9XyY77b/ZTsgj9UY0wfckeg3i/y3/mpuPz83HJyMvXfFRx3L1lV/kFX0lNBpdL1Ud2Cz2jqKr8tLWRsATB8VGAg7Bv6n81qwEhuk6QVwLPdCK5cwCTYebUu4s2USCSntDLeOpinpE1OoPfECQMnwnXgUEbvcX72XmEYq7J4JVUX0PvVLaFs2mvwniU+XWKoQi2xt15TIpmMZxhsDbisbAa22CEx/ewPqpB8Rcw61i4/bSZSWhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609258503; bh=lQdLr28Idt9m5ix0UlpcSI/elMwKU1jQgZEzMPsi9qv=; h=Subject:To:From:Date:From:Subject; b=JPmctj6fD+DtB051nJE4XH+ZP9NfwO7F3D+AS/kRDcT+r/F9xf881ZtaCZHJ01mVDt/N7ufsIs0j0e7fMWKTl0WUsVrdOH/qMOJTdp8uwt9TIAqLD104OKhWHNwWuYPCYJz3aQP71UZmp5BYCAUbto93U36YlonOhPPczmrseVqzkuSyktHBELu7si2KWVMa1g7gb2hpq52LN/VpAajUKabND1XbBv6BaIfF4a4UjDWcKaXN1uUFyvr/DFgcDa3D+Ss+o1ICpC9Z4xFggQYg6Y+l/HXtGY22F+LhPmXLPK1/7aEcrPuV7lP+2Cfkxeeai+zxrS4us8MPgYMFSCnAbA== X-YMail-OSG: vicsW6MVM1k7u0Jxha5YvfV6..GawmUajFMLioEmnZiSUZkrOksJr9LlGtJmVZY 3r9W4ZVBYnAV.UaPZQaL1LQTmaHZbYp3TLGPzTE2Xz2BD5STi5HmAsct9JT_KYRNqgelbVlB4uBA CIKF5vX0GFE7PwV_eJ3gBbACvhhGjNTIME06q7P3GrSUWdLRUSGV9ZJnaeYBLmr8V0L_Pw96KzSk TG9kdlSUW_0XPjS_hwCLfC8tk3pGwZybi2G7Syvnv1oVdnxzmRRT23OY5319Em8uGe789UBe5n4Z uXXbhO4gyzyeUHM1GDo7zoz7s4sQ89IJfDu4PCaRi8WsLMaB4M.xbtXFCY9tdkUyEz5Vpg7rMuSw QBen3ZdttoEIHlYEcimn4Dv1RUpnFfY_ay2j1IzxihN3qInu2ngssv8DelBTDZEtJwaAmhIBXrts Sm2FFp3fJ1Hdtvs8AfeNlPTy.fdsy4_t9Z2wSlJ4xUmo1tVRrXjoePt8zJybVVtYYjO4aCoQfhBZ 5GBiT1mLECU9to3QnVZ2tWN3Tg0ZYDwWYmuhBmwzdgjUu.4gH31DDdbS8ODIPkjxZOHiXGk7wk.P z1pFlwhQ16chgsKDMfTUSR1In62J52315mgdVDW86u6yhIXCjMsASGN7p.smu3DSjNl1ilTv_iDr v8FJ1xyosUq6hwpuhwCJtWFAq8630eS237D4avYJvHSZRvD4qKig3YjslsN4ijXBQ88cHZRsTCSV xBrBgd36liA7izP.DHV_QYB1SAhrJEgchiZCL.4ZJhDXKn5xf47fBHjpg1__EyQkfvKKGh1gNK2Z b_.ZPDXuo1XJTvXHMIgb3teYehxHIXoJBCcjfo.3y23WMhzzUqgocbrSfWJNQkTf1wX0BGubmbLO CopYTMUctIVSdeYOL2T9YpJywlm0ENZjN5E4CK67hyxnVsbSq5itWMitgvaHjDHmqh.IoGZGsTgo N8c7KxiCxq5WH6OkjMpTo2j3sq3nqUSg6C4A3LC5jgiA7R0.sTFLCM7JsFxBzFCNKcAPG_1qp9gP TIKGaNjvk.UO.LrHl5Oj7QgtsAnnFnrpJ_wxg.4bLcHJLQTMfZziDwclvl_D6qfAldBOmXMR0uqn 63d2PyYv67kLcbxOlHcg4WcCwkGCp2315y1gadK8YEuQ2c.z2uP9Xxksv4zmvNXbzP7E1C1fohtT siXFUOMqzdKGj0DZAcKQQmtAseyU99YtIiGdTtMn.5t.gL5z5hqAkpyGxTQScvPCJL_AJucBRwLI vpkrolxxWWmu8_vS2PoBsiBP328l76KfvalUFXUlBENkCVjjHsrPRLSQT_l3M1Y1pFjAgI.9lVX9 A1GKyh.KlL7Ua19RyeHglia1gVIfNiwzQxRVeFjcJPrfPeFg2ZDmL2VLmX2UxNrYE3CweQc1KZVO 4K_sqKCcrx1IbyvGlED_URGAwva0y0QRciYae.ZAiowd9Ducw.rywlAc7zB.GOgRrzTM3WRKoiAy CNVI_mFzORowXOaHd6l5BL8gAmgxOExZHuchklnw4ZG2tEIVGxxsxs18J9Por03YjpoNrK7HfMzC 2TalCc6srZzbXtaWzTCNgq19VD5W2lQcti6xG5Omtj9VuP7u4T.zrVwSWrL3B0S2pn2fWC_jLq1I T4LXVy_7kfVfWy9H11UG8RFTT7MQSabnDLQ60PamSG8AOCRt9UHG6At3XJa_XFbtPinq1qaHYY72 5HngXAzy0vwYq1IgXVdd_P874wIWU0GRXg8hMdnKBc6p1UJP.VFjj7dfxtkgwf__Q8wVQOU4vouC 7cgDu3TxO_MODgviwWHIx_xEL.cEQgmHsvvPbOZeqXblh12o79RBxkJnQVWT5or335TWKWyMuZDy C5tdbb1rofnP0Wy5S7kC0MPN7RfHXC8u3iDZW7h39uLupuARc2B_4A_n_gbd2BkfAzX.4Bc_2D1t WSzU3NRi8Kfg15aM33Qey3GejBetP0HFng6C.1rQZJNZveS3EAtl0nv_b6q2NyG1ReoDQfnRh4VI UnPdbQl_Qh.1Krav176kNLv8VXGPekIdgPShZ9HPCQR7FpxmicYxS_1RGaNsX6dTMrPa8tPUJI1F hHwmf9nFH.9hAI6EmHIiuIO12n.Pzky3.67nh4tHJJ32K8DBg2QzViRSWewg4Y8sE0ceBGocNT2s QZNxYCE31MZrzYy3vLYdX7XnRPxwGeWuhQyvsPUc_pT1ITrfojaQxaAhpZ6jPMlOSi6RXVzaOdLY INsWY2rTSbxu3C6e3IQ.FAy5Afpph2y4B.uDuhH2SPJ3riL6_aedrIwgvziDIwM8RO9WnWhyicjI e9PcARPAJkw.mR1q4cwtmZClm0u.H.ETE96Zyg5dp.erVt.3gLF9GT7aQSjRpTZsDWE24zBW6L0A EtRlFr6npAMqQPo3.EXCM1.tqp4qDTqxSodn06FUvJMNDcpOEbpThsNH.9g_9.SbIiZZ0CkfMXLg 5tU29MQgLP7PP8myhjJzNDCWYC5B7FFlaG1hZgDZ3Sowe1ZldtVKRRCVo5XLaXqMQEofRFeCvhGK o2ohGHJBYllg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 Dec 2020 16:15:03 +0000 Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID afef25046bfeccaaa12904b30506c516; Tue, 29 Dec 2020 16:14:58 +0000 (UTC) To: Claudio Jeker Cc: sidrops@ietf.org References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> From: Stephen Kent Message-ID: <6c577d9e-05f2-fbdd-a2e1-4c49a781ebb6@verizon.net> Date: Tue, 29 Dec 2020 11:14:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201229151639.GD56136@diehard.n-r-g.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 29 Dec 2020 16:15:12 -0000 Claudio,On Tue, Dec 29, 2020 at 07:58:29AM -0500, Stephen Kent wrote: >> Claudio & Job, >> >> RFC 6488 (2.1.6.2) requires use of the SKI in the sid for all "signed >> objects" in the RPKI. >> >> Is the proposal to not use an SKI in the RTA format compatible with this? > No that is not what I was after. The usage of SKI as per RFC 6488 > (2.1.6.2) is absolutly fine. My problem with the RTA draft are these > points of the draft (section 3): > > The differences between this RTA profile and the profile specified by > the RPKI Digitally Signed Object template are as follows: > > o Section 2.1 of [RFC6488] specifies a single SignerInfo object. An > RTA MAY contain more than one SignerInfo object. > > o Section 2.1.4, and Section 3 of [RFC6488] specify that the > certificates field contains a single EE certificate. The > certificates field of an RTA contains precisely the same number of > EE certificates as there are SignerInfo objects in the RTA, where > each EE certificate is needed to validate the signature in each > SignerInfo. In addition, the certificates field MAY contain a > collection of CA certificates that would allow a RP to validate > the EE certificates. > > Up until now all objects only had a single EE cert and a single SID and > all the linking done with the SKI was a 1-to-1 mapping resulting in a > simple tree structure with the trust anchor as root. > This draft allows for multiple EE certs and so multiple paths up to the > trust anchors. This makes handling RTA a lot more complex than any other > object under RPKI. It also results in a lot more failure conditions since > there are more EE certs involved in the validation process. > thanks for the clarification. Your characterization of the added complexity and validation failure possibilities is worrisome, given the trouble RPs have had just trying to deal with the comparatively simple RPKI signed object validation process. Steve From nobody Wed Dec 30 06:48:53 2020 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 2513B3A0BDF for ; Wed, 30 Dec 2020 06:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qqneaftG24T for ; Wed, 30 Dec 2020 06:48:48 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (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 E39E93A0BDC for ; Wed, 30 Dec 2020 06:48:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PxJ8LgZuvJgKWYjFaC47c1LL2ROZ7G8GOHcsE70klCNIVh7kzhRQvCTtnoC2flD2vI1Vg9ZR17CtMmrwB3motyIi70zLQEoE9JLy/PQgq8J5wcGThE1RoVqoYAxuguyGaXGrz+p1qaqg/bybq+/QMD/GMcAvhtx7vUABC7G+6nROWybxkLf78LsbOIFMYHqEx+HkL0hfH+RwpE49CkrZN8SfcjduJBeYZyuOwUgo48nmQOc0DrVAMklREW8i+t8KDRAOtSYHb2+m+zQvf8MqGpMqKIbk6Pn1mmRN5PJnhalho81y6Cx2gIBo1/gxA+y1IOFOHlPuRdt9DU5Br2QRrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cYQHAY7+gqEU71B6YejzhI9vo9wFkZFuNi3OHWT8YsE=; b=Dk1zzLbn1LHYnFmBSvyxeOPvBMMiZTetxEaGI6HScNhJrwLcqrx7kecxw/jQdxS4QjLEz6mW9ulrtm6oKkN9I/kNw+wjdFTNnrmkdr+Dbf2hWd9+3M0kjeMY2UhfPEjLUabe9TEnZjfPad7o1DqOPiXKN0AMY+RD9heUtlUuv3hvQbSJaMz5V4s1vqsbBwc9MCUHiAPEF5HabM8nomH+2EmkcP4X+AwBdOjVC5InhAcoLsYyum5S6RIf3xWAWQI26XdPUaMa43cMiYiddN2ip9HQKwFVk9OIvB4lhC/sUu1gw1GN+mYQ3aE1+0nspASJR4GulmPH+A/kMWpjcWCpww== 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=cYQHAY7+gqEU71B6YejzhI9vo9wFkZFuNi3OHWT8YsE=; b=j/vt3zuC4D92AQisoE5NviILYyU7x615bSVe9cI0owiE15yhDtKbGWoqKJ+bMy3o0sAAJ/gAGgoJXQeHi2Kue+6i601BfeBVq6R+7nD3BOJbg4hlUoUX0if6e5GJk8jyfqm0F0kFY//t3+9zCoFOrpdI8g/tdHg0ilw08Rvex9Q= Authentication-Results: sobornost.net; dkim=none (message not signed) header.d=none;sobornost.net; dmarc=none action=none header.from=workonline.africa; Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB8P190MB0697.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:125::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27; Wed, 30 Dec 2020 14:48:44 +0000 Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2%4]) with mapi id 15.20.3721.020; Wed, 30 Dec 2020 14:48:44 +0000 Date: Wed, 30 Dec 2020 16:48:36 +0200 From: Ben Maddison To: Job Snijders Cc: sidrops@ietf.org Message-ID: <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> References: <20201229101412.GA56136@diehard.n-r-g.com> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ohsmfggd3g24j2qp" Content-Disposition: inline In-Reply-To: X-Originating-IP: [160.119.236.50] X-ClientProxiedBy: JNXP275CA0017.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:19::29) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (160.119.236.50) by JNXP275CA0017.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:19::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.27 via Frontend Transport; Wed, 30 Dec 2020 14:48:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 889d6706-da9f-4030-ec13-08d8acd2017a X-MS-TrafficTypeDiagnostic: DB8P190MB0697: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UHmROQk9nxBpzBkgfNp557VUdO6hWLe3iEApsJZfBb2/cHmgm1Qve4n9BgGza09DFoCirKQJEdYZc83lrG7eeW7Y6lpH/3TEO6h9B4HYMOxpNxTmk3EgDEvjmUQ5m7cudnt10tNYsksYEKF1jccS038/oU0IJeIKQlkYbs0e/tnsczn9ltcHrStU0dxOWtGEhp3T9FYGL/xvUBtIPGzU2AOrHsD9cjpQV+NZSN0AL9ojoHxtKPyHNtPLGpEVaQtrlyPGcgTknNdKdIGp+ClvoqGqQ01s5Ynwx64lcnw6AQzEtWTmwktzzqac165i9c+kj6kafrNU75O1+4MgsYwy/fTDmfufxmqh4L9KbkfAmkEUikNkKNywBLTvR2G+wJ3AAoxf541L+MyHSpe39/YtZLrmRvAFq/A5cfPD+Qfz8/Pv5SpipxfnR98R5itEA7RH22cttN+Da/VRpDc/Qw7esg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(136003)(396003)(376002)(39830400003)(366004)(346002)(2906002)(86362001)(8936002)(6496006)(956004)(44144004)(21480400003)(83380400001)(5660300002)(478600001)(8676002)(6916009)(9686003)(52116002)(6666004)(6486002)(1076003)(33716001)(316002)(4326008)(66556008)(66476007)(186003)(26005)(66946007)(16526019)(46492008)(2700100001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?biOJfFDkttUIWAGysEZuB2LaZDUa4TVvx9XZ+FkmjV8nIJbULfEdzMPXTImT?= =?us-ascii?Q?lhTvwnbH687xd+J5U2XTbo9l+iDasftBfajYhFkDwaUQXsMxO3Hpvswl94B9?= =?us-ascii?Q?6k6GGgDpwE79bvhLnMLWld6GOOYzI4BO4kdWBuoTJaVo3sy2+ZVCPoXUb1q/?= =?us-ascii?Q?6Njh3bziRJTLMrch/aw1aodmr40Y017UsXS+bPT1NXs4ykeEFWO2Ftsqf/62?= =?us-ascii?Q?gO9YQ4BGhm/BPc62g/ss/mJNEFwjT/GIjkqGy1xO2cSN5g4eGxnstHnnTubf?= =?us-ascii?Q?Ht0ekhSzufCcAYprPg3eDt225SIYBfM7dmkuPoC4eijQxQvNU+2BKOvTTNSs?= =?us-ascii?Q?yHmrS3A8lRyHrWyXBbvKHyVX3VHPMUbiajx5vE4+MU9n4jHYE+zSJLKT9CEd?= =?us-ascii?Q?i9NRL2R+nd5aU2BCOZINMkbWFeQrhjpJ5bS75u731gFBx8Or163WJaJ60rNc?= =?us-ascii?Q?7+qkAAwESf3glrtDG/Wm+Dgl9GsstEfyv8WT15ZqoOY0yPcVjVu2ZOBtpIaa?= =?us-ascii?Q?8gsA9ZkgpE8wxQp7QE9pd1tpTvCMA3hU8CX5+trNT2FeIAh0hvH634K/vYwi?= =?us-ascii?Q?0O3XBKYgDvZEHzgEUXcXUclp/SUIXh+31GWcL/qeH0qqUTzaTf5y9LGhX+U2?= =?us-ascii?Q?hyXkGpQYPBGUoSWzxZxWsfconskwb7q60Dt1wf4lfhxLtQe85fx+upqH0FAj?= =?us-ascii?Q?UOoqsJF6iMDCMTUYjHVlS92GKqkGgjeVkkfbmNSOk90/yDBc1ClFPf4hN840?= =?us-ascii?Q?hmjEShi07rtpHpSobMxxfIR7pidv8+HliM+1NgvvQ5nxjAjHcnK2QiVqIhaZ?= =?us-ascii?Q?yB/3QRSWnpC3CDjLS0F2mhZALon8B1ZzQzf5GJiqaGX3dzhgv0/aIdPjCcVb?= =?us-ascii?Q?8olm6jKCUPUXj0UFHdHMmv0khH5d57yME9Uw+mAWdufUuUDutLYh5BC5cAF9?= =?us-ascii?Q?aNz/9O3xTQxe/xb70h4TaAa7qv8AbvUH8XZFIFnpax8nGI17weReFodF3KrM?= =?us-ascii?Q?9KLZ?= X-OriginatorOrg: workonline.africa X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Dec 2020 14:48:43.8906 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7 X-MS-Exchange-CrossTenant-Network-Message-Id: 889d6706-da9f-4030-ec13-08d8acd2017a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: GCxjAOVwuVQD9/bi6JETzVvbryOGOtviUgAyiTgwIziiuk115xcKoBgulCM83Zkj796ae3W5cuKjWl39ubJKYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P190MB0697 Archived-At: Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta 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, 30 Dec 2020 14:48:51 -0000 --ohsmfggd3g24j2qp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/29, Job Snijders wrote: > On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote: > > Up until now all objects only had a single EE cert and a single SID and > > all the linking done with the SKI was a 1-to-1 mapping resulting in a > > simple tree structure with the trust anchor as root. > > This draft allows for multiple EE certs and so multiple paths up to the > > trust anchors. This makes handling RTA a lot more complex than any other > > object under RPKI. It also results in a lot more failure conditions sin= ce > > there are more EE certs involved in the validation process. >=20 > >=20 > It is possible the RTA authors forsee use cases where the 'multiple > signatures' offers irreplaceable value, I'm not sure. FWIW, all the use cases that I have in mind for RTA need only a single signer. I have been trying to think of some creative uses that can't be solved by separate objects, and I can't think of any. Thus, if this change can speed up implementation then I'm all for it. Cheers, Ben --ohsmfggd3g24j2qp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEadkaB2uV5dm5UllaOkYk/rSLaGAFAl/sk0QACgkQOkYk/rSL aGAhsA/+O2duGsgiT0d9/NVRUdbEuR7Ehld1nY9BJmnFj789pnoEhmA1l4lFptqL lcCfyYDjAnTyPS+ldxcKTMJbz/odgrK9OUTpfssjr6BrhvtwX4Wq6zL2B396znzs ZyWMaioy5j3EQr3m3aJbjK13oBtPVOgO1XWblpzKP9UxbNTyTqEv7eQi8j8gpPHk 6aTHXunNAaJKUuMS8GnmG99x6CAFrm/H40wOc2D/df8rZlTTl8wgZm9BBx90tUUr jHe/BMs8N+b4dJzSR4K86bPjcQr51EuRsRUCk3ir/PWvsVj+c1H2FAr4YoLoOjEE VqisKToX0saysSXD0mm/WO3ahlTyxkl65ilDQleOoAOZm2kPuPRA4t5DD6uxvKLK UTXmxUWoye8bEALfMWiUQNfxw/tMPfFrZ0qxqtn8Lhw1AwqE+bYVE6x9TXekt+SP FVb7zqFu1I5u0rr6GPwJ2fSfip8mZmUlpCiOGdkWEX83B6rLRunocZTFmr+strIA ZvRUZaHFE7H/GfoYVZD27CqqqgGJMP2HZ1AJQbbhzFU1obW+r/pF/o/uwrK/74SH YDiyMXqv3nW8YZkFTrefwckY+I7MugaAHPm2WAlLrBTypPMh/PCGrtdnUy8aPRPx yB1J9I328p3+9+wYEOjsAKkhdbpbDZPlgBDaWAVe2nFjXLAC1N0= =Gwo5 -----END PGP SIGNATURE----- --ohsmfggd3g24j2qp-- From nobody Wed Dec 30 09:15:41 2020 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 5E2FE3A0A26 for ; Wed, 30 Dec 2020 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 Pd_l2qNkGrst for ; Wed, 30 Dec 2020 09:15:34 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [46.182.8.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 AD4B13A0A1E for ; Wed, 30 Dec 2020 09:15:33 -0800 (PST) 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.16.1/8.16.1) with ESMTPSA id 0BUHFPxW015593 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Dec 2020 17:15:26 GMT (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: Keyur Patel Cc: "sidrops@ietf.org" References: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com> From: Nick Hilliard Message-ID: <640b6603-f0bb-41d9-1b2e-99f5e2eb9dbc@foobar.org> Date: Wed, 30 Dec 2020 17:15:24 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.43 MIME-Version: 1.0 In-Reply-To: <33FBAE0F-1D61-4EC3-82D0-11807AC24687@arrcus.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-05 - Ends 28/December/2020 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, 30 Dec 2020 17:15:40 -0000 Keyur Patel wrote on 11/12/2020 20:38: > A working group last call has been re-opened for > draft-sidrops-bgpsec-validation-signaling-05, “BGPsec Validation State > Signaling”. Please reply to the list with your comments. The WGLC will end > on December 28, 2020. > > The latest draft can be found > at:https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05. I'd like to see further work on validation-signaling-via-bgp-community drafts suspended, on the grounds that they are fundamentally harmful due to how they cause large-scale routing churn. This includes this draft, which I believe should not progress to be published as an rfc. Routing validation in the dfz has taken off a bit in the last year or two, and we're only now beginning to see how it behaves at scale. It's rather obvious in retrospect, but if there's a change in the validation state of a prefix, and if you're signaling this using bgp communities, then this causes the NLRI to be updated with the new community. In turn this will cause a bgp UPDATE to be sent. By contrast, if this is handled using native routing validation (i.e. rov / bgpsec), then the update is only flooded if the best path changes. Obviously a single update isn't a big deal, but what happens when there are systemic problems in the routing validation rpki? Every affected prefix is updated and if this is already the best path, then the new update may be flooded across the relevant routing domain. This has been happening a bit recently and it would be fair to assume that from time to time, routing validation component failures are going to happen. When this happens, the last thing you want is extraneous updates trashing the control planes on your network. Excess instability is something that needs to be designed out of protocols, not acknowledged as something which can be ignored. This is separate to all the other issues that have been raised by Job a couple of months ago, which I'm not really sure were adequately addressed by the draft authors. Nick