From nobody Tue Aug 11 09:57:20 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 9F5E23A0811; Tue, 11 Aug 2020 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Ae3ZWQSZpNMO; Tue, 11 Aug 2020 09:57:17 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 B90B03A0857; Tue, 11 Aug 2020 09:57:16 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id n129so6609192qkd.6; Tue, 11 Aug 2020 09:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=V0shTxYuvPYVHLhDOeYQrJ7w+fIsRbvzEk2OTCUCh04=; b=jOSTbxELsfFND741rcmYved+GN06PrurO1j3l1DSVGsC4B+HdBlX/vLek1hqWnPwCM T7FMRVobOrRGstx4Sof/jYxxd2l+BaIxufv9gYOmF28Ejk2jGQLslV3UnsX2PM++d+vA W/eNyr1jF3pD9pfIhsEZwvsj1gntuna5Hig0Cu8jnVRsz8sIgkUHV7ho7br2/KRndz9J o6wwZ7K6n9nc1q3Tc5bujU7H63GIIWwVX+40eeSTkp7Fw6b6keXsUf2PjQSKnX21MeLg 36j2afY914hQNyoOGJzy3zNAwlFRIIIsBBqYD6PH22rAhFMIIw/hIxz/Snw8UvL9fTWf Q+jg== 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=V0shTxYuvPYVHLhDOeYQrJ7w+fIsRbvzEk2OTCUCh04=; b=UbIcGq7KvRwOkiY4Ab5dQOl2EWGmeHpZrIlMgIFPNy51MkB757MfBLReqwz0dtU9Tf N/Mz3i5s4C63glJilr6axxzZE/hAHePJWEECPoEARV5wJ8KK24Z+MsBU0qoL6/eIE3Eu zyMMsrhvn+sH30JI/TGhq9Ij4DfLkqsbLNtifOg9/GJL5t7mWYkX6FWkBEzcnS74AWHP Yw1NVPDYr4ho90O3fWX0d+CSWCmYEuyRlO8m81b13EeZUndlYko2/p6VWhLsJT50DsK7 e1ZMnu4dhU6AHDLVR+RQBwHYVCdSC0AzIDJ6ycmPMKt1nY5/OVDNaKk+yynp2arNHpnc /6qw== X-Gm-Message-State: AOAM531SGtCXUAVLA9RYM2TmT8RpuOQ41mkMDFuGq7dfAoU01iWA4Oi+ Cf6a8ow9Q2vfnuBz5HgN/Lxj13NRSEOT/TzxrAV2tHrW X-Google-Smtp-Source: ABdhPJxl2NI4mwqxhSP6tNPHGaqcWE5q2RxHsUhr6xkqLKHMQM2OhXPadluQ9myLY3WQHje2jFi44FXI/nb+6t831Oo= X-Received: by 2002:a05:620a:89a:: with SMTP id b26mr1979246qka.175.1597165035335; Tue, 11 Aug 2020 09:57:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Tue, 11 Aug 2020 12:57:04 -0400 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-ymbk-sidrops-6486bis - ENDS: 07/23/2020 (July 23) 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, 11 Aug 2020 16:57:19 -0000 howdy Folks! I forgot to mention this at our face-to-face(virtual) meeting, but this call ended with success. Could the authors please file an updated (name) draft in the proper folder and we can progress to next stage? :) thanks! -chris co-chair-persona On Thu, Jul 9, 2020 at 2:32 PM Christopher Morrow wrote: > > Howdy WG Folks! > The authors of the 6486-bis document: > draft-ymbk-sidrops-6486bis > > would appreciate you all spending a few minutes to read/review and > comment about adoptability in the working group. The abstract of same: > > "This document defines a "manifest" for use in the Resource Public Key > Infrastructure (RPKI). A manifest is a signed object (file) that > contains a listing of all the signed objects (files) in the > repository publication point (directory) associated with an authority > responsible for publishing in the repository. For each certificate, > Certificate Revocation List (CRL), or other type of signed objects > issued by the authority that are published at this repository > publication point, the manifest contains both the name of the file > containing the object and a hash of the file content. Manifests are > intended to enable a relying party (RP) to detect certain forms of > attacks against a repository. Specifically, if an RP checks a > manifest's contents against the signed objects retrieved from a > repository publication point, then the RP can detect "stale" (valid) > data and deletion of signed objects." > > Thanks for your consideration, reading and commentary! > -chris > co-chair persona From nobody Tue Aug 11 10:01: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 1A23F3A0826; Tue, 11 Aug 2020 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=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 8RLRY0moS75d; Tue, 11 Aug 2020 10:01:31 -0700 (PDT) Received: from relay.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A093A0814; Tue, 11 Aug 2020 10:01:31 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by relay.ops-netman.net (Postfix) with ESMTPS id 1DBEA3C21AB; Tue, 11 Aug 2020 17:01:30 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id E67E2236; Tue, 11 Aug 2020 17:01:29 +0000 (UTC) Date: Tue, 11 Aug 2020 17:01:29 +0000 Message-ID: <87tux9xgk6.wl-morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] [WG ADOPTION] rfc-8211-bis - Ends 2020-28-08 (Aug 28 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: Tue, 11 Aug 2020 17:01:33 -0000 Howdy WG Folks! The authors of RFC8211 have prepared an update to their document: https://tools.ietf.org/id/draft-kent-sidrops-8211bis-00.txt The abstract being: " This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data." the updates are meant to take into account the updated language in the pending RFC6486-bis document. Let's have a read, decide if this should be adopted by the WG for work/cleanup/refresh and have a decision back to the list/authors as of 28/8/2020 - August 28 this year (2020). Thanks! -chris co-chair-persona From nobody Tue Aug 11 11:45: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 866073A0B8C for ; Tue, 11 Aug 2020 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 (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 tlXH_eHYbjRr for ; Tue, 11 Aug 2020 11:45:13 -0700 (PDT) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2069.outbound.protection.outlook.com [40.107.102.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D449A3A0B87 for ; Tue, 11 Aug 2020 11:45:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LGuIXIzb18Df+bNAU7oXExaPiTub6huAFqWOYu9e4O27N/KxND88k7a6Ygt7iWjx1nOOsJWockiu8/FgPu0hd986NV7K8f2BXrGVHk16blg9DTsIRjvUVtHY9IJ8uU03HDQZ6vr3zv/RCb2YF5lzWFDvXiX1l6kTC5IrMO/JnV5TwpWIz/l3NHknuPbB9RWC5cjdKj9bludWVR1VHYtjbI+ejZXNb3kVFbRo/xLvVtwxsYw0kB2tBP1KXbGOESxa+eh+3CxrBKk6d/hL9LQCU6FlqxSJ58SDiXDuilXIuk1pjDO9ETLOk3BeB0CYEIDBmLFtqCbGsQkPukkrM5bXVQ== 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=4KHXmo4yb9RvstXf7WfAt3JGYJ3JIEC/pYQ2zmgE3DE=; b=FnzQR7U+glbf6Ks9z6GfRPwBCdppSyxPOqfynHOolxDfUmGfSdFTFT2fBti36edHuPK/Cb1kO0OOoCp0/zeSGAX2ZJMapibUX3wX+Rn2BoGQonzepxeIb0z1lTz2QEJBrTItWQuDTqwAe1KVBXfZv/shGB2iTu4OUVMs/QE7N6UGcm0aLjDf2ygzpTJPDsA3io9fXNn6VsVAvA1dv6Ym5ICLZycXdiM01MgyKWm5qbFbWjD3u8fMgioa2O1jEPsBuRgDJVbK+TuzGHVTPS7EbNbcaxqygbirawcCzNpPnzpBPfihef8rdqW2MDqquX9lSMrlbqcNeo+ZBijT+bhr4A== 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=4KHXmo4yb9RvstXf7WfAt3JGYJ3JIEC/pYQ2zmgE3DE=; b=ppo8zAu55W06unXWPJE5MufB6cZa4B4RSxO/eTZr9pPg4+v/GGFenYsuSO6ZeKBADvIDcys4wmlWiwEH3hdm8oi04u2M5esm8JpkjfYnEpfwQFypmdBapYiUvnKOR+aL5Kka5pZAwnyhDoJjZhhencb+qE3WJMo11Em5BpRqb8c= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BY5PR18MB3761.namprd18.prod.outlook.com (2603:10b6:a03:24d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Tue, 11 Aug 2020 18:45:06 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::a59d:e0fa:b08d:8c91]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::a59d:e0fa:b08d:8c91%7]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 18:45:06 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcA+HFL2ap5d5eEGUfZX0DE6/EA== Date: Tue, 11 Aug 2020 18:45:05 +0000 Message-ID: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 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: 2088e505-ca85-4025-933f-08d83e26aa54 x-ms-traffictypediagnostic: BY5PR18MB3761: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8UK7vOH05vpl/2vjI3U/j4Aa/QtwXQit98S/WwOfNovTztPVn++kDnEre5qrNst+1+7N7Qfhp/9Ir9HIpUw9z6vJEFUX2MsTs0y/0UhR04oup8omdVImSNoLWVhtlPtW7g01JGkz941DWkC62k/jXWocHAEBm+Pxh2mUy1TEGQIEo01tf0ebxorcfO1L2Kx2Uba7QuTHTL5BDwbVJ+Z+GUEoEt77zgfbOoIi9IGQBAwzMn9kZqG1Oqot59yjJueCIYEmkx0u8qhlpT2bjUsQPhXX4fY+SsxEf7QifTLh9wyJZW4nRXHEUWtvFsIqVVlgC//HaHDGlSYcgp8432zfHo73nh2xokEUzlDMD0OoamZ8aA9YIEP1/KNOGxjcZHzDteqMqX0wM+0ZFeV6tcY6iQ== 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; SFTY:; SFS:(346002)(376002)(366004)(136003)(396003)(39830400003)(316002)(8936002)(2906002)(36756003)(966005)(6916009)(508600001)(6512007)(6486002)(66446008)(64756008)(8676002)(6506007)(4744005)(66556008)(76116006)(66476007)(86362001)(83380400001)(71200400001)(66946007)(2616005)(5660300002)(166002)(186003)(33656002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qXSkYS2y/Kq0FQGa7J4d2qX7q+IQExIUD4zGiBLLEA5HREHQ3yDZZnaIlnS+t98fE2jXdPfgmPohKOkYdf50G/3hb5Gv/T2WsSCRWZn+eYRZxe4v38bN/kmUHqKRL5NHd1TUSJhzD5eKCHaTlcPBu8XjZ1bELxYtcZx3lfpwpntnmndz4cNXlpybpbMrRNNzvGLxgKkCPGlDwy26gm/hhlu9M1WgMVLh/fmgKrXVg3sDX04Bw+7uY57B4DepYFNzrYZ8NeZfp6HjMTjZd0KIKXYy6tmr03ofpFOrwqaUcX5f4TRxoqlLJOj+B6dm7dobGhIVv/s1fsPZg8Gwu0coNp27qLGB9umjuSp72Vt5wh6dM9km8EbB4E2y0CSPoiTaONUYUo72XirZ60G71A5Q24jgjhUKw1qUzRXQihqXlgC2EDIjr1vayZR/kdH8J7xjo2fVk8bhtwL4cWS1p+DMkQZuau/aMxC2h+3FOBa6KLKktdGisUpeZkqU/HfTK3XiS+LFRExfRIRe38i/IUmP3hP9gU/2KUoH2nY3Vw6rStaErdYcsZPKqYDOO2cpwt2QmrlFoLwx6KYL1/6fK38l7uPwfCd06HY8mkt1Zz1cRU072D/tAW2yiACJDt84XP+SY+KFuNJwsC9dT6NGLV5Vvg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6A0CA35A4BA34063BDA8B93B17636B4Barrcuscom_" 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: 2088e505-ca85-4025-933f-08d83e26aa54 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 18:45:05.9224 (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: P9BAjlpnsEtHLQVOcCrDCq1EhvlHCAnwqdD75CKUrbOYONOs3oeSCt4hoGvxsJdwN87pCDxMtNyBrOFL6hybFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3761 Archived-At: Subject: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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: Tue, 11 Aug 2020 18:45:15 -0000 --_000_6A0CA35A4BA34063BDA8B93B17636B4Barrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVk IGZvciBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMywg4oCcQkdQ c2VjIFZhbGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxp c3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBBdWd1c3QgMjUsIDIw MjAuDQoNClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6ICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMuICBBdXRo b3JzLCBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSdyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSIHRoYXQgaGFzbid0IGJlZW4gZGlzY2xvc2VkLg0KDQpSZWdhcmRzLA0KS2V5 dXINCg0K --_000_6A0CA35A4BA34063BDA8B93B17636B4Barrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <9B977068F710A54D87A80C3357287C9E@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 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBGb2xrczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRh dGlvbi1zaWduYWxpbmctMDMsIOKAnEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25hbGluZ+KA nS4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhlPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldHTEM8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2lsbA0KIGVuZCBvbiBBdWd1 c3QgMjUsIDIwMjAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+VGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDs8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdw c2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIiB0aXRsZT0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIj48c3Bh biBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzPC9zcGFuPjwvYT48L3NwYW4+ LjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5BdXRob3JzLCBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSdy ZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIHRoYXQgaGFzbid0IGJlZW4gZGlzY2xvc2VkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktleXVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6A0CA35A4BA34063BDA8B93B17636B4Barrcuscom_-- From nobody Tue Aug 11 13:58: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 616BA3A0F4F for ; Tue, 11 Aug 2020 13:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFX7r3v-MvKX for ; Tue, 11 Aug 2020 13:57:59 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357E33A0F52 for ; Tue, 11 Aug 2020 13:57:47 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 07BKveVN033973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2020 21:57:41 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Keyur Patel Cc: "sidrops@ietf.org" References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> From: Nick Hilliard Message-ID: Date: Tue, 11 Aug 2020 21:57:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.25 MIME-Version: 1.0 In-Reply-To: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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: Tue, 11 Aug 2020 20:58:07 -0000 Keyur Patel wrote on 11/08/2020 19:45: > A working group last call has been requested for > draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State > signaling”. Please reply to the list with your comments. The WGLC will end > on August 25, 2020. In general, replicating validation functionality using BGP communities is a poor idea and from an ops point of view, it seems wiser as a long term objective to push vendors to support bgpsec than to implement hacks like this. For this reason I don't support publication of the draft as an rfc. Major issues: 1. The draft lacks a problem statement and a sunset clause. 2. Previously there's been a good deal of discussion on sidrops about RPKI validation state signalling. Several problems were listed here: > https://mailarchive.ietf.org/arch/msg/sidrops/YV1WfoxQNiwfOjtKIY1d6YJjRxM/ Most of the problems associated with validation state signalling identified in that email also apply to bgpsec validation state signalling, namely: - crypto authentication is lost - different and incompatible set of signalling hooks In particular all the problems associated with RPKI validation state signalling over eBGP also apply to bgpsec state signalling over eBGP. Defining this as non-transitive is a good start, but the language needs to change to ensure that it cannot escape an ASN. Can I suggest the following text changes: change: > If the router supports the extension as defined in this document, it > SHOULD attach the BGPsec path validation state extended community to > BGPsec UPDATE messages sent to BGP peers by mapping the locally > computed validation state into the last octet of the extended > community. This SHOULD be done automatically for iBGP peers and > configurable for eBGP peers (see below). to: > If the router supports the extension as defined in this document, it > SHOULD attach the BGPsec path validation state extended community to > BGPsec UPDATE messages sent to iBGP peers by mapping the locally > computed validation state into the last octet of the extended > community. and change: > By default, routers SHOULD enable use of this > community on all iBGP sessions and routers SHOULD disable the use of > this community on all eBGP sessions. Implementations MUST NOT send > more than one instance of the origin validation state extended > community and MUST drop (without processing) the BGPsec path > validation state extended community if received over an External BGP > (eBGP) peering session that has not be explicitly configured to > enable processing. to: > By default, routers SHOULD enable use of this > community on all iBGP sessions. Implementations MUST NOT send > more than one instance of the origin validation state extended > community, MUST NOT attach the BGPsec path validation state extended > community to BGPsec UPDATE messages sent to eBGP peers and MUST drop > (without processing) the BGPsec path validation state extended community > if received over an eBGP peering session. Nick From nobody Tue Aug 11 14:29:50 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 0F5943A0C02; Tue, 11 Aug 2020 14:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <159718138373.27046.9776740350311238316@ietfa.amsl.com> Date: Tue, 11 Aug 2020 14:29:43 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 21:29:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-00.txt Pages : 17 Date : 2020-08-11 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-6486bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 11 16:01: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 66D053A0DEF for ; Tue, 11 Aug 2020 16:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKnHR28OhOn7 for ; Tue, 11 Aug 2020 16:01:41 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2119.outbound.protection.outlook.com [40.107.89.119]) (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 E93103A0E7C for ; Tue, 11 Aug 2020 16:01:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0kdkr4Ura4YQ15eqjwODAgcjy6gsXqp7/FVsh/5H+mrZjvQUhua7J67jNixWGNWTPHqhlhnvSJ4qjO+oyDgOg49p8RKfN1iaIvpNy2SnNxrq8gKtBWebpESzxmAvkq39l5kgNT9jB3I0NR8aTx65Rv4R0n+IJF39kXqZah1yzVdOVQGABWlQhRlHDyAbENawiJPBRaFHUvemUdy/8AqvoIf0T9UPMR3a9gyvyfn3MrzLPfwMaeHXUcuq1ATJnCWVOUkayTnkpxqI9DlCYIElQtAtZZ4FHa6XPLqCM8nid576e4ctUfh8aWiDL4RIehkI96M0hjNSh24ebgqkCT7zQ== 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=mU8uNf6VGLWXmKTs+rlSvPiRf9I234NYUZn3DEwezqw=; b=YOWcI26bREyftPcP1VJexl9UCeTC+7WjqDxpDiULtN5emxNhEbOsSaezzmfANnfZzEyl4Ej56vAL7WlheZjVqf9WwXTYBbIX6de/Hn9VUlCW/mLBOpmITbrptTzSqncjpsQoXtIUUfEPQI1aVBCK6ebV8E5yDSJJYi17blCdX9Y0pznx7vlsIEQk4CPz+J0yYRxnhatX77+bHeW1UNITM9VnLkQ0etCqtW1332lkrygP+zwccLFm9oteJ4fSq4AcQtlmvZ//sjarkIXEmWQvraFSdAh6VT2arBzGDGcf9+uI5FV4NJOOsXsgsenIsatYCNIVETzH/7k8mareoJdUsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mU8uNf6VGLWXmKTs+rlSvPiRf9I234NYUZn3DEwezqw=; b=UjAQpK9t8SeSFxdk5LLK7Dn5lobXBB31/YsVwrKf7raAltfTXnNWFY24UkTconqRYqDzEOCH2YKaP8lAHV2TtL+1njULUwoG1yIWTwnF0ngNk/bzX0Ur0+5erzv7M5/0mWXwO5zl1Lgyy44KMe4bIiIM3eZyiUYIybZ4zPf5I04= Received: from MN2PR09MB3359.namprd09.prod.outlook.com (2603:10b6:208:ff::18) by BL0PR0901MB4372.namprd09.prod.outlook.com (2603:10b6:208:1c3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Tue, 11 Aug 2020 23:01:38 +0000 Received: from MN2PR09MB3359.namprd09.prod.outlook.com ([fe80::38ff:9752:eff9:6fae]) by MN2PR09MB3359.namprd09.prod.outlook.com ([fe80::38ff:9752:eff9:6fae%7]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 23:01:38 +0000 From: "Borchert, Oliver (Fed)" To: Keyur Patel , "sidrops@ietf.org" CC: "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcDNem3F6+hzGREywHXXgZ97TUA== Date: Tue, 11 Aug 2020 23:01:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6b01:218::df] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b2be7200-badd-4128-b49a-08d83e4a8128 x-ms-traffictypediagnostic: BL0PR0901MB4372: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ye2H9x90xgloD0CS+jcRiTDRKzjaomKE/nauERTwM8BHobtxVfWXiBJvxGIlLNPTGeBL2bnI1AQU5RSHQLMiGf2i5zy+BWaXnBwj4Ig2mSOmKbaLxXruKneeCpWXnf1Nk+3mLjSNGCww9bEJ4fyrgzsE4BDpyO/VkTRD1AK2wgRVLf8Lc55SVmq1MLWCiI5D1QHIwQtdjH/5RFlu348JaQNJrb7NuSfqDs+rL6CB2L9c9ieAUQB8OijINMgxswUQSz+Hwhgx8+7X+WEIHthqPOT5ahpoUNxTT/IWec4LCMxTTVE+sePEikxjaXaHYYlsKnYKc7yci+CCMJwjYqKm89Ucthfr/t3e1fyEZaccsgP9DmKr7jpyCORLN84EYQ1OCgC4Kj+3SbUP+eUJZiBtDg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB3359.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(346002)(376002)(396003)(186003)(33656002)(5660300002)(66556008)(66946007)(66476007)(110136005)(76116006)(6506007)(66446008)(64756008)(8936002)(316002)(6512007)(6486002)(86362001)(36756003)(53546011)(4326008)(478600001)(966005)(8676002)(107886003)(4744005)(2906002)(71200400001)(2616005)(83380400001)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JvTSwTdTq+abmeKI5XtUqKKEDi+dzvRZN2LIoEZnknoLmsCQJxrjeqdZCJ/SDrLDGMrqySDJ0ILXxxrHyiKu+FCDvD9Sqh4vzdbb4GLIVRvs6H9EMU3h2fpv3GoB5XgVh2PV6wLxp2w1UdvR45s3hoWjMaVFqIUzVTpBo7lhffbfYhOPqsoLg287SrFzxLkpQ34zs3FDrZY1KKQfq5c8Hr6wFTDr8vhPyjEbvsXuEM28oVZefo5rSoqhdoD3ARiWv7XwyRcrg9OgSiKBbDTnS+UUNLore44UGirJILMYojBJZvg3GZJ5nfA3vSC75ilZXu5UZwKunSTZvCTl9b35Jn9yBzZPgk+hqzoQJV5tBAKxk6LTccviG/tX5LSpcsWmNpx4q9nHCVb+mDDIrkbQsRi1MWDQjxyAxOI1HzAr4Q66iqGvpWDW8Fx+14SWYGapkWx1jAlnI0pR4rhSlzTg38q4t5lWarcoVY0hGhBppo7R5/zUltU58ZMP0LT5ivBdSEumKSVF9L5EIrqXY2p/BldmSzzCFco0Rra1ZDi3oAUF0mUHLer7TeO30UaJSwYyS1yPUldUgM8MfXb7LRAq1xMHBAuTK7INrr9IU5g8YCyDmqZHveNBfsObuqpFIAZew32ax0gpYv0dILW7+einH2Tg3eHcU/LmWkh5hMDT+ro= Content-Type: multipart/alternative; boundary="_000_EB62BEE3376A4B28BC486097A75D72DBnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB3359.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2be7200-badd-4128-b49a-08d83e4a8128 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 23:01:38.6506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JPY8wV7ITA6dcYLOgptXd/8r6IzXPfUbQ3Wx0cCVi2EqpZvc8PSr9bEhY1SBV/7TsHkUfVA7JP9H9E5Yl7vezw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4372 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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: Tue, 11 Aug 2020 23:01:50 -0000 --_000_EB62BEE3376A4B28BC486097A75D72DBnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiwNCg0KT2xpdmVyDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQs IENvbXB1dGVyIFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQg VGVjaG5vbG9neQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4 LjQxMTcNCg0KDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEF1 Z3VzdCAxMSwgMjAyMCBhdCAyOjQ1IFBNDQpUbzogInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3Bz QGlldGYub3JnPg0KU3ViamVjdDogW1NpZHJvcHNdIFtXR0xDXSBkcmFmdC1zaWRyb3BzLWJncHNl Yy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMyAtIGVuZHMgMjUvQXVndXN0LzIwMjANCg0KSGkgRm9s a3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBk cmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMywg4oCcQkdQc2VjIFZh bGlkYXRpb24gU3RhdGUgU2lnbmFsaW5n4oCdLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0 aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBBdWd1c3QgMjUsIDIwMjAuDQoN ClRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDM8aHR0cHM6Ly9nY2Mw Mi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWdu YWxpbmctMDMmZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0NlOTEy MDc2MjI0ZGM0MTMyNTU0ZjA4ZDgzZTI2YjcwMSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzElN0M2MzczMjc2ODMyOTM1MTYzNzUmc2RhdGE9dnlSWkF3MXpPMWlSVVJ4 bGpDVjI0cmwxYXpKdG1rUlUxalR1Qlo0eGw5SSUzRCZyZXNlcnZlZD0wPi4gIEF1dGhvcnMsIHBs ZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRoZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNjbG9zZWQuDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQo= --_000_EB62BEE3376A4B28BC486097A75D72DBnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <7F51913576A4D24FA35CF04E38DC856A@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJ Y29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb3VyaWVyIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVy O2NvbG9yOmJsYWNrIj5PbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPk5hdGlvbmFsIEluc3Rp dHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oR1ZvaWNlKSArMS4y NDAuNjY4LjQxMTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q291cmllciI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+U2lkcm9wcyAmbHQ7c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg S2V5dXIgUGF0ZWwgJmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1 ZXNkYXksIEF1Z3VzdCAxMSwgMjAyMCBhdCAyOjQ1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtz aWRyb3BzQGlldGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5bU2lkcm9wc10gW1dHTENdIGRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRp b24tc2lnbmFsaW5nLTAzIC0gZW5kcyAyNS9BdWd1c3QvMjAyMDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBGb2xrczo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5BIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJl cXVlc3RlZCBmb3IgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMs IOKAnEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25hbGluZ+KAnS4gUGxlYXNlIHJlcGx5IHRv IHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldHTEM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+d2lsbA0KIGVuZCBvbiBBdWd1c3QgMjUsIDIwMjAuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Y2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1 dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdDo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtc2lkcm9wcy1iZ3BzZWMt dmFsaWRhdGlvbi1zaWduYWxpbmctMDMmYW1wO2RhdGE9MDIlN0MwMSU3Q29saXZlci5ib3JjaGVy dCU0MG5pc3QuZ292JTdDZTkxMjA3NjIyNGRjNDEzMjU1NGYwOGQ4M2UyNmI3MDElN0MyYWI1ZDgy ZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MzI3NjgzMjkzNTE2Mzc1JmFt cDtzZGF0YT12eVJaQXcxek8xaVJVUnhsakNWMjRybDFhekp0bWtSVTFqVHVCWjR4bDlJJTNEJmFt cDtyZXNlcnZlZD0wIiB0aXRsZT0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNp ZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDM8L2E+ PC9zcGFuPi48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+QXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhl ciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Ns b3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktleXVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EB62BEE3376A4B28BC486097A75D72DBnistgov_-- From nobody Wed Aug 12 10:38: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 7FA993A07EA for ; Wed, 12 Aug 2020 10:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axgB0aHLXUYK for ; Wed, 12 Aug 2020 10:38:50 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2139.outbound.protection.outlook.com [40.107.91.139]) (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 967CE3A07B0 for ; Wed, 12 Aug 2020 10:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cakCcPUyhmalcXUO0MuHDW8o46wJp/BotP5CGYiJqZtusVpjJFVsBkrZ+DYeLfE3pe+TY/Y2LgRaH3bWPsYe9QgkdVYi6dHhKK9E8pMNFkMv74OCRFRTEU5oi2O5bspQbcbxwjsSh89hIksVfd/IM7wjPz3Xbb1+WSX0pszrpgIttYPD+ONWimG/LhJL3aliovRzrduZdpfL2ZzlUhF5hE16U4GS0M5pmhEsDFtmSMYNxOFPnHwvHJg4nHLUAR2AH4tVWoPSUrlBvXILK6akMwowW/Pnf8wxzp6Wue4YLbOgG4psuwTdSMQeD4kIxwiR8DRlmkMLDgtpHuOgRauybg== 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=o/Gb/qMVCZQ68/mqACpbaTp8czcH0SUQUyAxD/ZaU+E=; b=J1A/hKq7gbFMjDRHsBxV50ZsetopMrd7UXFevzldlqLwa31CDbEQ4F/HRdMo/rZ74fS1hsG8QUM7UHpnurqbWPUerj3qsi5X5hcczM5Oilow+qU/52YZCQUoPt4Jj/66/eIJEiEkA+A7g3zkBD1TQUmLnWOKsWv40u4swsQlyjz8JH5axYFcyTVAeRC1scGY+ynH6l1JldN0BvCH8vmjH52bKFEXGwCMwMtsHHdAwLh7ONeKE+bZDCmi8A/xpDkOFeyw9bhe0oHBVnhpQ+rkTPczIVxO+UtvZS+oHINsM0Ork2Ppcc3hK4nBJmsxwmRnoupsc5v0/PhOtdrNfIFkhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o/Gb/qMVCZQ68/mqACpbaTp8czcH0SUQUyAxD/ZaU+E=; b=mGfuC99hpdJD2/E0Wx/tzGBGuHQOS8YePx1BWC7dVLG9ehETe94F2Yt1BSqrhZ6P8gb9ihCCk3IG9WLHxzpD0VpqI/48bqK+nkF3W9gobx5sli/FSWYLDKAUfVsxNcqrno5/I397E3KXjCpOKkN3S7D9XTYaPKtDisFMns0fpPM= Received: from MN2PR09MB4860.namprd09.prod.outlook.com (2603:10b6:208:210::9) by MN2PR09MB3646.namprd09.prod.outlook.com (2603:10b6:208:a5::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 12 Aug 2020 17:38:48 +0000 Received: from MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::7c8f:4ad1:7165:a25f]) by MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::7c8f:4ad1:7165:a25f%4]) with mapi id 15.20.3261.024; Wed, 12 Aug 2020 17:38:48 +0000 From: "Montgomery, Douglas C. (Fed)" To: "sidrops@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcM9vNigd5BJ5P0KVwtdV3ADZwg== Date: Wed, 12 Aug 2020 17:38:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20080530 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:162::4a] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d8a7971b-6f00-403d-1018-08d83ee69233 x-ms-traffictypediagnostic: MN2PR09MB3646: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KeGxnjQtVZRwesFO18s+/IodpxhU0yOJW/Umje9F5PvOIMBfnzP9KCyYW+2x87SkdI3O4pwMApzkJExp84yEgWe66M97OZ2Pro49m3+8IK2HI8WrpKL6wHm4n8cXx3ppmzr9hRqGMz8fY119RfOIsH0w47BCEFItNxlIomJhlT2deg4HUg4KGRxMqev5jRZLFYBXgrGzIJH4oUEnsfgauBqQFf2nZFcrrbOIXA1mw/I5VgzFqM45AnEgZUUL5CDGoPjjjljBiXs8oiWZ/f6MbYiBLNjc7nnahz3Sr7kwkL3qVRDGWftJIbnp4v1/VQH6/mQW/0aS1sIx1NUQ4oelLvDP6wfK+P8XfH82lwrNfPCgpf5/DY9G9m4PVg8V7Pp8myLri9so9lAuf7TWTmxxrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4860.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(6486002)(4744005)(6916009)(33656002)(316002)(8936002)(6512007)(8676002)(166002)(478600001)(83380400001)(6506007)(91956017)(5660300002)(86362001)(2906002)(2616005)(186003)(71200400001)(76116006)(36756003)(66476007)(64756008)(66446008)(66556008)(966005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: x8KLQGtaTf3WqIW1pYLOyAaYYaaBFcL8FMQRsru03HtOaKIO7SE4iKmT0rF09r2Aq6WXWf9W9gTGUr5rpo+t9TG9BtKUSAcgFKrxstki4+H3sdex83KkS4wrLH2/mqP0sPxwYr72cvp1jtthGp4buD9WAqANFXwnb3JAMaeeOGDnSRfAiHMqjCyjORIPimfJNBoNC1IqefjiDPshiaSkDrDJ16eLZ2bBxBzkMaEm8D0PFJZ4iMdGu/V+H2P6r2ZtfFkDJnhsHzP84NtOcI+d74TiyI4QbNAgf59hYyHFt3bQdjR7WBJsHN+ZQAycEE1+58rgBzzbnIbdiB9RVFNEz2lhxh2j1Iw6bz4VQbEbHtzO/b6N1H0QN2hEcfbG9DzYcUYREHGIZl0KG48f9gPOEXvrTA3cJIVC7d1sbuy9J2vI3/LYpj+aOvWWjTZjwGFgk6oETP5kTVYpFtR00FOoN75tvObfC92t4izElpijbNlyPZbxFJNM/zo2Re2eW5ubr4JUVPyQ2dncg6w+Oghi9dn6rCaxNQhhMSVYNOMxv0B3M82yOhgNv38MIjYJyiXNcvqwX9FdBrnSpzoILtiLaGhPRpd8XITFpKA7nTaM2p/7zk6O5ZSUbNsIbB0PpAN3AApRlxMTecD6q5bfBoNRbIBgWQQlOKv1WWhMvfyGEsc= Content-Type: multipart/alternative; boundary="_000_BD505828EE7C45E1BB49AFA8D8F218BBnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4860.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8a7971b-6f00-403d-1018-08d83ee69233 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2020 17:38:48.8438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q7jF0uuh7KBkh2gUou0CPBeZIvhW7qh2ADVXOcUSzwuFi4Fy+FXe76URHNQHVSiz X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB3646 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 12 Aug 2020 17:38:53 -0000 --_000_BD505828EE7C45E1BB49AFA8D8F218BBnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUg0KDQpkb3VnbQ0KLS0NCkRvdWdNIEAg TklTVA0KDQpGcm9tOiAiSUVURi1TaWRyb3BzIExpc3Q6IiA8c2lkcm9wcy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb20+DQpEYXRlOiBU dWVzZGF5LCBBdWd1c3QgMTEsIDIwMjAgYXQgMjo0NSBQTQ0KVG86ICJzaWRyb3BzQGlldGYub3Jn IiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtTaWRyb3BzXSBbV0dMQ10gZHJhZnQtc2lk cm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMgLSBlbmRzIDI1L0F1Z3VzdC8yMDIw DQoNCkhpIEZvbGtzOg0KDQpBIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVl c3RlZCBmb3IgZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMsIOKA nEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIFNpZ25hbGluZ+KAnS4gUGxlYXNlIHJlcGx5IHRvIHRo ZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhlIFdHTEMgd2lsbCBlbmQgb24gQXVndXN0IDI1 LCAyMDIwLg0KDQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0OiAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzPGh0 dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlk YXRpb24tc2lnbmFsaW5nLTAzJmRhdGE9MDIlN0MwMSU3Q2RvdWdtJTQwbmlzdC5nb3YlN0M5YmFk YzM0Y2VhY2Q0ZTc2NTJiYzA4ZDgzZTI2YjZjNSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzElN0M2MzczMjc2ODMyOTk1NDE5Nzkmc2RhdGE9bkJ1NUlNelF0NHRNck1S Y09ocmMxQmNaekhnQmhKRXV2eHpBSUg4JTJCbDk4JTNEJnJlc2VydmVkPTA+LiAgQXV0aG9ycywg cGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhlciB5b3UncmUgYXdhcmUgb2YgYW55IHJlbGV2 YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC4NCg0KUmVnYXJkcywNCktleXVyDQoN Cg== --_000_BD505828EE7C45E1BB49AFA8D8F218BBnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwg ZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7DQoJ Y29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50 IElQUjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5kb3VnbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5E b3VnTSBAIE5JU1Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtJRVRGLVNpZHJvcHMgTGlzdDomcXVvdDsgJmx0 O3NpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsICZs dDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBBdWd1c3Qg MTEsIDIwMjAgYXQgMjo0NSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2lkcm9wc0BpZXRmLm9y ZyZxdW90OyAmbHQ7c2lkcm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W1Np ZHJvcHNdIFtXR0xDXSBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0w MyAtIGVuZHMgMjUvQXVndXN0LzIwMjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Y2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1h bGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+QSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRy YWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2lnbmFsaW5nLTAzLCDigJxCR1BzZWMgVmFs aWRhdGlvbiBTdGF0ZSBTaWduYWxpbmfigJ0uIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRo IHlvdXIgY29tbWVudHMuIFRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5XR0xDPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPndpbGwNCiBlbmQgb24gQXVndXN0IDI1LCAyMDIwLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2NhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2Nj MDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LXNpZHJvcHMtYmdwc2VjLXZhbGlkYXRpb24tc2ln bmFsaW5nLTAzJmFtcDtkYXRhPTAyJTdDMDElN0Nkb3VnbSU0MG5pc3QuZ292JTdDOWJhZGMzNGNl YWNkNGU3NjUyYmMwOGQ4M2UyNmI2YzUlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRl YyU3QzElN0MxJTdDNjM3MzI3NjgzMjk5NTQxOTc5JmFtcDtzZGF0YT1uQnU1SU16UXQ0dE1yTVJj T2hyYzFCY1p6SGdCaEpFdXZ4ekFJSDglMkJsOTglM0QmYW1wO3Jlc2VydmVkPTAiIHRpdGxlPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlv bi1zaWduYWxpbmctMDMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaWRyb3Bz LWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMzwvYT48L3NwYW4+LjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BdXRo b3JzLCBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSdyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSIHRoYXQgaGFzbid0IGJlZW4gZGlzY2xvc2VkLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2NhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47Y2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+S2V5dXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BD505828EE7C45E1BB49AFA8D8F218BBnistgov_-- From nobody Thu Aug 13 12:45:40 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 80D343A07E8 for ; Thu, 13 Aug 2020 10:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCGmvOttTYXn for ; Thu, 13 Aug 2020 10:54:02 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.136.136.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0761A3A0F3A for ; Thu, 13 Aug 2020 10:53:55 -0700 (PDT) Received: from CAS01CHA.corp.arin.net (cas01cha.corp.arin.net [10.1.30.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTPS id 0D27E10757B3 for ; Thu, 13 Aug 2020 13:53:55 -0400 (EDT) Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS01CHA.corp.arin.net (10.1.30.62) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 13 Aug 2020 13:53:55 -0400 Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Thu, 13 Aug 2020 13:53:55 -0400 From: John Curran To: "sidrops@ietf.org" Thread-Topic: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved Thread-Index: AQHWcZq2hd8cgII59EKc0bG2pPBa2Q== Date: Thu, 13 Aug 2020 17:53:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.136.136.37] Content-Type: text/plain; charset="utf-8" Content-ID: <203BD54338262D4094D97E7A9032586A@corp.arin.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 13 Aug 2020 12:45:40 -0700 Subject: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved 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, 13 Aug 2020 17:54:04 -0000 UlBLSSBmb2xrcyAtIA0KDQoJSW4gdGhlIHByb2Nlc3Mgb2YgdXBncmFkaW5nIG91ciBIU00geWVz dGVyZGF5LCBBUklOIHVwZGF0ZWQgaXRzIFJQS0kgc2lnbmluZyBpbmZyYXN0cnVjdHVyZSBpbmNv cnJlY3RseSDigJMgdGhlIHJlc3VsdCB3YXMgYW4gZW5jb2RpbmcgZXJyb3IgaW4gb3VyIG1hbmlm ZXN0IHRoYXQgY2F1c2VkIHJwa2ktY2xpZW50IGFuZCBGT1JUIHZhbGlkYXRvcnMgbm8gbG9uZ2Vy IGNvbnNpZGVyIEFSSU7igJlzIFJQS0kgZGF0YSB0byBiZSB2YWxpZC4gKHNlZSBhdHRhY2hlZCBz ZXJ2aWNlIGFubm91bmNlbWVudCkgDQoNCglUaGlzIGhhcyBiZWVuIHNpbmNlIHJlc29sdmVkIGFu ZCB3ZeKAmXJlIGluIHRoZSBwcm9jZXNzIG9mIHJlaXNzdWluZyBST0FzIGNyZWF0ZWQgZHVyaW5n IHRoZSB0aW1lLiAgV2UgYXJlIG5vdCBhd2FyZSBvZiBhbnkgZGVsZWdhdGVkIHJlcG9zaXRvcmll cyBpbXBhY3RlZCBkdXJpbmcgdGhpcyBwZXJpb2QuIA0KDQoJT3VyIHRoYW5rcyB0byB0aGUgT3Bl bkJTRCB0ZWFtIC0gU2ViYXN0aWFuIEJlbm9pdCwgVGhlbyBCdWVobGVyLCBKb2VsIFNpbmcsIEpv YiBTbmlqZGVycywgYW5kIENsYXVkaW8gSmVrZXIgLSB3aG8gd2VyZSBpbnN0cnVtZW50YWwgaW4g aHVudGluZyBkb3duIHRoaXMgaXNzdWUuIA0KDQoJSeKAmWxsIHByb3ZpZGUgYSBtb3JlIGRldGFp bGVkIHBvc3QtbW9ydGVtIGhlcmUgb25jZSBhdmFpbGFibGUuDQoNCk15IGFwb2xvZ2llcyBmb3Ig dGhlIHNlcnZpY2UgaW1wYWN0LA0KL0pvaG4NCg0KSm9obiBDdXJyYW4NClByZXNpZGVudCBhbmQg Q0VPDQpBbWVyaWNhbiBSZWdpc3RyeSBmb3IgSW50ZXJuZXQgTnVtYmVycw0KDQo9PT0gIGh0dHBz Oi8vd3d3LmFyaW4ubmV0L2Fubm91bmNlbWVudHMvMjAyMDA4MTMvDQoNClJQS0kgU2VydmljZSBO b3RpY2UgVXBkYXRlDQoNClBvc3RlZDogVGh1cnNkYXksIDEzIEF1Z3VzdCAyMDIwIA0KU2Vydmlj ZSBVcGRhdGUgDQoNCkFmdGVyIHVwZ3JhZGluZyBvdXIgSFNNIG9uIFdlZG5lc2RheSwgQXVndXN0 IDEyLCAyMDIwLCBKb2IgU25pamRlcnMgcmVwb3J0ZWQgdG8gdXMgdGhhdCBvdXIgUlBLSSByZXBv c2l0b3J5IHdhcyBubyBsb25nZXIgdmFsaWRhdGluZyB1c2luZyBycGtpLWNsaWVudCBvciBmb3J0 LiBVcG9uIGludmVzdGlnYXRpb24sIGl0IHdhcyBkaXNjb3ZlcmVkIHRoYXQgd2UgaGFkIGFuIGVu Y29kaW5nIGVycm9yIGluIG91ciBuZXcgc29mdHdhcmUuIChTcGVjaWZpY2FsbHksIHRoZXJlIHdh cyBhIG1pc21hdGNoIGluIHRoZSDigJxwYXJhbWV0ZXJz4oCdIGZpZWxkIGJldHdlZW4gdGhlIOKA nGFsZ29yaXRobSBpZGVudGlmaWVy4oCdIG9mIHRoZSBjZXJ0aWZpY2F0ZSBhbmQgdGhlIGNlcnRp ZmljYXRlIFRvIEJlIFNpZ25lZCBbVEJTXS4gVGhlIFRCUyBzZXQgdGhlIOKAnHBhcmFtZXRlcnPi gJ0gYXMgbnVsbCBhbmQgdGhlIGNlcnRpZmljYXRlIGFzIGVtcHR5LikNCg0KQSBmaXggaGFzIGJl ZW4gbWFkZSBhbmQgdGhlcmUgd2lsbCBiZSBhIHBlbmRpbmcgZGF0YSBjbGVhbiB1cCBpbiB0aGUg bmV4dCBmZXcgZGF5cyB0byBmaXggc29tZSBvZiB0aGUgUk9BcyBjcmVhdGVkIGR1cmluZyB0aGUg aW50ZXJpbS4NCg0KV2Ugd291bGQgbGlrZSB0byB0aGFuayBTZWJhc3RpYW4gQmVub2l0LCBUaGVv IEJ1ZWhsZXIsIEpvZWwgU2luZywgSm9iIFNuaWpkZXJzLCBhbmQgQ2xhdWRpbyBKZWtlciwgZnJv bSB0aGUgT3BlbkJTRCBwcm9qZWN0IChodHRwczovL29wZW5ic2Qub3JnICksIGFzIHRoZXkgc3Bl bnQgY29uc2lkZXJhYmxlIHRpbWUgd29ya2luZyB3aXRoIHVzIHRvIGlkZW50aWZ5IHRoZSByb290 IGNhdXNlIG9mIHRoZSBpc3N1ZS4NCg0KUmVnYXJkcywNCg0KUmljaGFyZCBKaW1tZXJzb24NCkNo aWVmIE9wZXJhdGluZyBPZmZpY2VyDQpBbWVyaWNhbiBSZWdpc3RyeSBmb3IgSW50ZXJuZXQgTnVt YmVycyAoQVJJTikNCj09PQ== From nobody Thu Aug 13 19:31: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 B59063A0C27 for ; Thu, 13 Aug 2020 19:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Cs9qow5Hkk for ; Thu, 13 Aug 2020 19:31:33 -0700 (PDT) Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (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 524773A0C24 for ; Thu, 13 Aug 2020 19:31:33 -0700 (PDT) Received: by mail-qv1-xf44.google.com with SMTP id s15so3686427qvv.7 for ; Thu, 13 Aug 2020 19:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mA4BzYOtR1328Q/5aHnIuNhfFHz6mmTFnohNLEhZJ6Q=; b=IpvpxmTSvdUHyfISxIjDC6digT+T2STk99XLcqw98Xh/SnL1QGEOEq9PYXpR161VG5 DYwlODy9fTokg6VFbE7NyAInPr4ls17QBgQk+nEaEqFVLdh+Z4a9hxivZZSRt6YlvKG8 F7m6K8PFJkJs1vObf7/0g6qVlvIa73mqCek5HCXr2sLCVaAPbYzUUAwMlvuClQe80xGh mx/8Dq1+SykR8yeQxu4nRdWT5Jx6NF0sIaWA7cezk/Pxl/ujyzeuap3vnBlmq+c7oW1I MgAx/nfeCI7SsF8djLlgNZ9EFEAzha7z2A3Z/JoFJMlPdBYY6wX7bZCX6JjrOm2BzF7/ CHKw== 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=mA4BzYOtR1328Q/5aHnIuNhfFHz6mmTFnohNLEhZJ6Q=; b=pukM2dSJWO6cxOZS9dPkfB+3Znp22PJZlSpDI7oKbAj8lLsuqCTTgyCTRz63KMaH4P BNSy8akisQgpbRQ9XAn0cW+7BN/znkmCZSe+i7x4g95WqRpf36VgCu5qaDWvhqJgw26K 1IEn4bVRybPZJ+RhEQ7JisxUFE1JSGdfUPgWx37xpCb/REiAYu8GCyBLPVr13xj2KVGe OXm6wI58+Oya38i8G/R9sy4rGqJGxn0Q0QTL2A89B+bLAtoVd+p4SETjApT7kK1q5ZUW i/BnLDAc7h+yhghVLigSBhp20VCw0GABm810jyD1EiEOOtjlEV7PJpIkA4tnv1/XFz55 Qaqg== X-Gm-Message-State: AOAM533j2ramq5lXXkTAPmEX4VM6ZtEQHldshqc4k2Nd1gG9fVQ/eJtd XsicnT8BK2rV/wGrd1LRMMiMeqGI4y81QRPCOyQ= X-Google-Smtp-Source: ABdhPJyiY2gAAczL1cdjktjEofzhOtoZhIiGyYlvE+nD7yroZLrVLIJjfixV6yV5R9JmMksecx+R+itzIaIBBO/8LmU= X-Received: by 2002:ad4:4dc5:: with SMTP id cw5mr812859qvb.238.1597372292276; Thu, 13 Aug 2020 19:31:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Thu, 13 Aug 2020 22:31:21 -0400 Message-ID: To: John Curran Cc: "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 02:31:35 -0000 howdy john! 1st: thanks for the pointer/RFO/report... (again, learning from others mistakes means maybe we'll have less pain going forward? :) ) 2nd: thanks for the call out to community members who helped poke the bear here and get to a solution! :) On Thu, Aug 13, 2020 at 3:45 PM John Curran wrote: > > RPKI folks - > > In the process of upgrading our HSM yesterday, ARIN updated its R= PKI signing infrastructure incorrectly =E2=80=93 the result was an encoding= error in our manifest that caused rpki-client and FORT validators no longe= r consider ARIN=E2=80=99s RPKI data to be valid. (see attached service anno= uncement) > Are there lessons learned here for the other validators and CA folk? Are there test cases we can use in other CA deployments? (both RIR and delegated) -chris > This has been since resolved and we=E2=80=99re in the process of = reissuing ROAs created during the time. We are not aware of any delegated = repositories impacted during this period. > > Our thanks to the OpenBSD team - Sebastian Benoit, Theo Buehler, = Joel Sing, Job Snijders, and Claudio Jeker - who were instrumental in hunti= ng down this issue. > > I=E2=80=99ll provide a more detailed post-mortem here once availa= ble. > > My apologies for the service impact, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > =3D=3D=3D https://www.arin.net/announcements/20200813/ > > RPKI Service Notice Update > > Posted: Thursday, 13 August 2020 > Service Update > > After upgrading our HSM on Wednesday, August 12, 2020, Job Snijders repor= ted to us that our RPKI repository was no longer validating using rpki-clie= nt or fort. Upon investigation, it was discovered that we had an encoding e= rror in our new software. (Specifically, there was a mismatch in the =E2=80= =9Cparameters=E2=80=9D field between the =E2=80=9Calgorithm identifier=E2= =80=9D of the certificate and the certificate To Be Signed [TBS]. The TBS s= et the =E2=80=9Cparameters=E2=80=9D as null and the certificate as empty.) > > A fix has been made and there will be a pending data clean up in the next= few days to fix some of the ROAs created during the interim. > > We would like to thank Sebastian Benoit, Theo Buehler, Joel Sing, Job Sni= jders, and Claudio Jeker, from the OpenBSD project (https://openbsd.org ), = as they spent considerable time working with us to identify the root cause = of the issue. > > Regards, > > Richard Jimmerson > Chief Operating Officer > American Registry for Internet Numbers (ARIN) > =3D=3D=3D > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Aug 14 04:32: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 1C6683A0FB3 for ; Fri, 14 Aug 2020 04:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M6No4B2tmQF for ; Fri, 14 Aug 2020 04:32:31 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [192.136.136.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF073A0FA2 for ; Fri, 14 Aug 2020 04:32:31 -0700 (PDT) Received: from CAS01CHA.corp.arin.net (cas01cha.corp.arin.net [10.1.30.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTPS id 2F8B510757BB; Fri, 14 Aug 2020 07:32:28 -0400 (EDT) Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS01CHA.corp.arin.net (10.1.30.62) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 14 Aug 2020 07:32:27 -0400 Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Fri, 14 Aug 2020 07:32:27 -0400 From: John Curran To: Christopher Morrow CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved Thread-Index: AQHWceMId69U4v5740qdgSmyMWUcvqk3vHMA Date: Fri, 14 Aug 2020 11:32:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.136.136.37] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 11:32:33 -0000 T24gMTMgQXVnIDIwMjAsIGF0IDEwOjMxIFBNLCBDaHJpc3RvcGhlciBNb3Jyb3cgPGNocmlzdG9w aGVyLm1vcnJvd0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gaG93ZHkgam9obiENCj4gLi4uDQo+ IEFyZSB0aGVyZSBsZXNzb25zIGxlYXJuZWQgaGVyZSBmb3IgdGhlIG90aGVyIHZhbGlkYXRvcnMg YW5kIENBIGZvbGs/DQo+IEFyZSB0aGVyZSB0ZXN0IGNhc2VzIHdlIGNhbiB1c2UgaW4gb3RoZXIg Q0EgZGVwbG95bWVudHM/IChib3RoIFJJUiBhbmQNCj4gZGVsZWdhdGVkKQ0KPiAuLi4NCj4+ICAg ICAgICBJ4oCZbGwgcHJvdmlkZSBhIG1vcmUgZGV0YWlsZWQgcG9zdC1tb3J0ZW0gaGVyZSBvbmNl IGF2YWlsYWJsZS4NCg0KSGVsbG8gQ2hyaXMhDQoNCiAgIFNob3J0IGFuc3dlciAtIHNlZSBhYm92 ZSAoaS5lLiDigJxJ4oCYbGwgcHJvdmlkZSBhIG1vcmUgZGV0YWlsZWQgcG9zdC1tb3J0ZW0gaGVy ZSBvbmNlIGF2YWlsYWJsZS7igJ0pDQoJDQogICBJbiB0aGUgbWVhbnRpbWUsIEnigJlsbCBzcGVj dWxhdGUgYSBiaXQg4oCTIHdhcm5pbmcgdGhhdCB0aGlzIGlzIHRoZSB2aWV3IGZyb20gMTBrbSB1 cCBieSBzb21lb25lIHdpdGggb25seSBhbiBvZmZoYW5kIGtub3dsZWRnZSBvZiBzdWNoIHRoaW5n cyDigJMgDQoNCgkxKSBDQSBvcGVyYXRvcnMgKGUuZy4gQVJJTikgc2hvdWxkIHRlc3QgYWdhaW5z dCBhIGxhcmdlciBwb3J0aW9uIG9mIHRoZSB2YWxpZGF0b3IgZWNvc3lzdGVtIHdoZW4gZG9pbmcg bWFqb3IgY2hhbmdlcy4gDQoJMikgQVJJTiBuZWVkcyBtb3JlIGRpdmVyc2UgYW5kIGNvb3JkaW5h dGVkIHRlc3QgZW52aXJvbm1lbnQgdXNhZ2UgYnkgdGhlIFJQS0kgY29tbXVuaXR5IA0KCTMpIEFk ZGl0aW9uYWwgc3RyaW5nZW5jeSB0byBzcGVjcyBmb3IgdGhlIG1vcmUgY29tbW9uIHZhbGlkYXRv cnMgd291bGQgaGVscCBpbiBzb21lIGNhc2VzIA0KDQogIElmIHlvdeKAmXJlIGxvb2tpbmcgcmln aHQgbm93IGZvciBpbnNpZ2h0IG9mIHRoaXMgaW5jaWRlbnQgc3VmZmljaWVudCBmb3Igd3JpdGlu ZyB0ZXN0IGNhc2VzLCBJ4oCZZCBsb29rIGF0IEpvYuKAmXMgT3BlbkJTRCB3cml0ZXVwIC0gDQog IDxodHRwOi8vc29ib3Jub3N0Lm5ldC9+am9iL2FyaW4tbWFuaWZlc3QtaXNzdWUtMjAyMC4wOC4x Mi50eHQ+DQoNCkJlc3Qgd2lzaGVzIChhbmQgc3RheSBzYWZlISkNCi9Kb2huDQoNCkpvaG4gQ3Vy cmFuDQpQcmVzaWRlbnQgYW5kIENFTw0KQW1lcmljYW4gUmVnaXN0cnkgZm9yIEludGVybmV0IE51 bWJlcnMNCg0KDQoNCg0KDQo= From nobody Sat Aug 15 14:19: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 597853A089F for ; Sat, 15 Aug 2020 14:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHPAQVjdFfdc for ; Sat, 15 Aug 2020 14:19:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3F73A081D for ; Sat, 15 Aug 2020 14:19:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1k73aS-0000Hw-Hz; Sat, 15 Aug 2020 21:19:37 +0000 Date: Sat, 15 Aug 2020 14:19:36 -0700 Message-ID: From: Randy Bush To: John Curran Cc: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved 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, 15 Aug 2020 21:19:41 -0000 thanks for the preliminary post mortem > 3) Additional stringency to specs for the more common validators would > help in some cases fwiw, one dragon lab instance sra is running is so old it is rsync only, and so did not see the problem. the assorted dragon labs instances i watch did not report anything. they quietly fell back from rrdp to rsync per spec. this is both good news, things worked as expected, and bad news, they knew something went wrong and did not report it. in general, the rpki infrastructure lacks alerts and lacks reporting channels other than ghostbuster records. this week our (john kristoff doing the heavy lifting) short paper was accepted at imc. will shout when there is camera ready. from the abstract In this short paper, we introduce a framework to observe RPKI relying parties (i.e., those that fetch RPKI data from the distributed repository) and present insights into this ecosystem for the first time. Our longitudinal study of data gathered from three RPKI certification authorities (AFRINIC, APNIC, and our own CA) identifies different deployment models of relying parties and (surprisingly) larger inconsistent fetching behavior, which might affect robustness in Internet routing. Our results reveal that some relying parties are not able to connect to specific publication points at all. randy From nobody Sat Aug 15 14:59:30 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 6E3AD3A0916 for ; Sat, 15 Aug 2020 14:59:29 -0700 (PDT) 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 ceTgemP2zjAi for ; Sat, 15 Aug 2020 14:59:28 -0700 (PDT) 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 0E5573A0915 for ; Sat, 15 Aug 2020 14:59:27 -0700 (PDT) Received: from bench.sobornost.net (218-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.218]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 987B6EE0160; Sat, 15 Aug 2020 21:59:26 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id d7f93f34; Sat, 15 Aug 2020 21:59:25 +0000 (UTC) Date: Sat, 15 Aug 2020 21:59:24 +0000 From: Job Snijders To: sidrops@ietf.org Cc: John Curran Message-ID: <20200815215924.GA11460@bench.sobornost.net> 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] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved 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, 15 Aug 2020 21:59:29 -0000 On Sat, Aug 15, 2020 at 02:19:36PM -0700, Randy Bush wrote: > thanks for the preliminary post mortem > > > 3) Additional stringency to specs for the more common validators would > > help in some cases > > fwiw, one dragon lab instance sra is running is so old it is rsync only, > and so did not see the problem. > > the assorted dragon labs instances i watch did not report anything. > they quietly fell back from rrdp to rsync per spec. this is both good > news, things worked as expected, and bad news, they knew something went > wrong and did not report it. >From my observations RPKI data with a signature identifier discrepancy was distributed both via RRDP and RSYNC. This was not a transport protocol specific event. A copy (made during the outage window) is available here: http://sobornost.net/~job/arin-broken-state-20200812.tar.gz Kind regards, Job From nobody Sat Aug 15 15:11:28 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 3FD9B3A0953 for ; Sat, 15 Aug 2020 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_4uFScJYv8k for ; Sat, 15 Aug 2020 15:11:26 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.136.136.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED073A094F for ; Sat, 15 Aug 2020 15:11:25 -0700 (PDT) Received: from CAS01CHA.corp.arin.net (cas01cha.corp.arin.net [10.1.30.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id 2F8AC10757B4; Sat, 15 Aug 2020 18:11:25 -0400 (EDT) Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS01CHA.corp.arin.net (10.1.30.62) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 15 Aug 2020 18:11:24 -0400 Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Sat, 15 Aug 2020 18:11:24 -0400 From: John Curran To: Randy Bush CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved Thread-Index: AQHWceMId69U4v5740qdgSmyMWUcvqk3vHMAgAI2YgCAAA54gA== Date: Sat, 15 Aug 2020 22:11:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.136.136.37] Content-Type: text/plain; charset="utf-8" Content-ID: <09FBFDD12B917747B66EFF3DF80B6E43@corp.arin.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved 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, 15 Aug 2020 22:11:27 -0000 SGkgUmFuZHkhDQoNCk9uIDE1IEF1ZyAyMDIwLCBhdCA1OjE5IFBNLCBSYW5keSBCdXNoIDxyYW5k eUBwc2cuY29tPiB3cm90ZToNCj4gDQo+IHRoYW5rcyBmb3IgdGhlIHByZWxpbWluYXJ5IHBvc3Qg bW9ydGVtDQoNCk5vIHByb2JsZW3igKYgIChmYWlybHkgb2JsaWdhdG9yeSBhZnRlciBwcmVjaXBp dGF0aW5nIHByb2R1Y3Rpb24gaW5mcmFzdHJ1Y3R1cmUgc2VydmljZXMpIA0KDQo+PiAzKSBBZGRp dGlvbmFsIHN0cmluZ2VuY3kgdG8gc3BlY3MgZm9yIHRoZSBtb3JlIGNvbW1vbiB2YWxpZGF0b3Jz IHdvdWxkDQo+PiAgIGhlbHAgaW4gc29tZSBjYXNlcw0KPiANCj4gZndpdywgb25lIGRyYWdvbiBs YWIgaW5zdGFuY2Ugc3JhIGlzIHJ1bm5pbmcgaXMgc28gb2xkIGl0IGlzIHJzeW5jIG9ubHksDQo+ IGFuZCBzbyBkaWQgbm90IHNlZSB0aGUgcHJvYmxlbS4NCj4gDQo+IHRoZSBhc3NvcnRlZCBkcmFn b24gbGFicyBpbnN0YW5jZXMgaSB3YXRjaCBkaWQgbm90IHJlcG9ydCBhbnl0aGluZy4NCj4gdGhl eSBxdWlldGx5IGZlbGwgYmFjayBmcm9tIHJyZHAgdG8gcnN5bmMgcGVyIHNwZWMuICB0aGlzIGlz IGJvdGggZ29vZA0KPiBuZXdzLCB0aGluZ3Mgd29ya2VkIGFzIGV4cGVjdGVkLCBhbmQgYmFkIG5l d3MsIHRoZXkga25ldyBzb21ldGhpbmcgd2VudA0KPiB3cm9uZyBhbmQgZGlkIG5vdCByZXBvcnQg aXQuDQo+IA0KPiBpbiBnZW5lcmFsLCB0aGUgcnBraSBpbmZyYXN0cnVjdHVyZSBsYWNrcyBhbGVy dHMgYW5kIGxhY2tzIHJlcG9ydGluZw0KPiBjaGFubmVscyBvdGhlciB0aGFuIGdob3N0YnVzdGVy IHJlY29yZHMuDQoNClNvbWV0aGluZyB0aGF0IHdlIGFsbCBzaG91bGQgcHJvYmFibHkgc3BlbmQg c29tZSB0aW1lIHRoaW5raW5nIGFib3V0IOKAkyANCnBhcnRpY3VsYXJseSBhcyB0aGUgZGVwZW5k ZW5jeSBvbiB0aGlzIGluZnJhc3RydWN0dXJlIGluY3JlYXNlcy4gDQoNCj4gdGhpcyB3ZWVrIG91 ciAoam9obiBrcmlzdG9mZiBkb2luZyB0aGUgaGVhdnkgbGlmdGluZykgc2hvcnQgcGFwZXIgd2Fz DQo+IGFjY2VwdGVkIGF0IGltYy4gIHdpbGwgc2hvdXQgd2hlbiB0aGVyZSBpcyBjYW1lcmEgcmVh ZHkuICBmcm9tIHRoZQ0KPiBhYnN0cmFjdA0KPiANCj4gICAgSW4gdGhpcyBzaG9ydCBwYXBlciwg d2UgaW50cm9kdWNlIGEgZnJhbWV3b3JrIHRvIG9ic2VydmUgUlBLSQ0KPiAgICByZWx5aW5nIHBh cnRpZXMgKGkuZS4sIHRob3NlIHRoYXQgZmV0Y2ggUlBLSSBkYXRhIGZyb20gdGhlDQo+ICAgIGRp c3RyaWJ1dGVkIHJlcG9zaXRvcnkpIGFuZCBwcmVzZW50IGluc2lnaHRzIGludG8gdGhpcyBlY29z eXN0ZW0NCj4gICAgZm9yIHRoZSBmaXJzdCB0aW1lLiBPdXIgbG9uZ2l0dWRpbmFsIHN0dWR5IG9m IGRhdGEgZ2F0aGVyZWQgZnJvbQ0KPiAgICB0aHJlZSBSUEtJIGNlcnRpZmljYXRpb24gYXV0aG9y aXRpZXMgKEFGUklOSUMsIEFQTklDLCBhbmQgb3VyIG93bg0KPiAgICBDQSkgaWRlbnRpZmllcyBk aWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMgb2YgcmVseWluZyBwYXJ0aWVzIGFuZA0KPiAgICAo c3VycHJpc2luZ2x5KSBsYXJnZXIgaW5jb25zaXN0ZW50IGZldGNoaW5nIGJlaGF2aW9yLCB3aGlj aCBtaWdodA0KPiAgICBhZmZlY3Qgcm9idXN0bmVzcyBpbiBJbnRlcm5ldCByb3V0aW5nLiBPdXIg cmVzdWx0cyByZXZlYWwgdGhhdCBzb21lDQo+ICAgIHJlbHlpbmcgcGFydGllcyBhcmUgbm90IGFi bGUgdG8gY29ubmVjdCB0byBzcGVjaWZpYyBwdWJsaWNhdGlvbg0KPiAgICBwb2ludHMgYXQgYWxs Lg0KDQoNClRoYW5rcyBmb3IgdGhlIGluZm8g4oCTIGRlZmluaXRlbHkgc29tZSBpbnRlcmVzdGlu ZyB3b3JrIQ0KL0pvaG4NCg0KSm9obiBDdXJyYW4NClByZXNpZGVudCBhbmQgQ0VPDQpBbWVyaWNh biBSZWdpc3RyeSBmb3IgSW50ZXJuZXQgTnVtYmVycw0KDQoNCg0KDQoNCg== From nobody Mon Aug 17 07:31:49 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 EEB863A15A9 for ; Mon, 17 Aug 2020 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpKtdNIVd4eD for ; Mon, 17 Aug 2020 07:31:38 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C753A15A1 for ; Mon, 17 Aug 2020 07:31:37 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::743]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 375B02D466 for ; Mon, 17 Aug 2020 16:31:35 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Mon, 17 Aug 2020 16:31:34 +0200 From: Martin Hoffmann To: sidrops@ietf.org Message-ID: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:31:48 -0000 Heisann, I started to implement the rules laid out in section 6 "Relying Party Processing of Manifests" of the draft and now have a few questions and remarks. I decided to split these up into separate messages. So, expect a few more messages ... * * * It is not quite clear how to deal with failed fetches. Section 6.4 dictates that invalid signed objects (but curiously not invalid certificates or CRLs) fail a fetch. The consequence of this is that a fetch already fails if a single ROA (or worse: a single ghost-buster record) is expired. Section 6.7 now states that I should keep using "cached versions of the objects associated with this CA instance." What does that actually mean? What are these objects associated with the instance? The objects listed on the new manifest or the old manifest? Or does objects here mean validated output generated earlier? If indeed it means RPKI objects, then doesn=E2=80=99t the expired ROA essentially block all updates to the other objects to the CA? That would strike me as counter-productive in terms of robustness. This rule also blocks skipping objects of types I don=E2=80=99t know or care about. I will have to at least do signed object validation on them, which means reading and parsing them and then do signature validation. If that is intended, I think this should be called out explicitly in the document. But I=E2=80=99m not even sure it provides any benefit. I, say, I am validat= ing a resource tagged association (RTA, [0]), I don=E2=80=99t care about the RO= As at all. Does the RTA become invalid because a CA somewhere in the validation chain had an expired ROA? Kind regards, Martin [0] https://datatracker.ietf.org/doc/draft-michaelson-rpki-rta/ From nobody Mon Aug 17 07:47:30 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 7EDB33A0ECA for ; Mon, 17 Aug 2020 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3EPpmY3cBRk for ; Mon, 17 Aug 2020 07:47:20 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF70C3A0E9F for ; Mon, 17 Aug 2020 07:47:20 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b904::743]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 1CCA42D4DA for ; Mon, 17 Aug 2020 16:47:19 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Mon, 17 Aug 2020 16:47:18 +0200 From: Martin Hoffmann To: sidrops@ietf.org Message-ID: <20200817164718.2ef60645@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Sidrops] 6486-bis: Out of Scope Manifest Entries X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:47:29 -0000 Hej igen, I am not entirely sure what to make of section 6.6 "Out of Scope Manifest Entries" of the draft 8486-bis. It essentially says that all objects that are not in the scope of the manifest make the whole fetch break. I suppose this is here to deal with multiple CRLs? But does it also include cases where issued certificates are expired or revoked? Section 2 (the section references 6.2, but I suppose this is a mistake) doesn=E2=80=99t quite make that clear since it has non-expired and non-revoked in parentheses. Does it also cover other objects that are not signed objects? I am assuming that anything that isn=E2=80=99t a .crl or .cer must be a signed object to allow for addition of new objects while staying compatible with older relying party software. In this case, these would already have stopped the fetch in section 6.4 as not validating signed objects. Perhaps the section could be made more clear and list what exactly constitutes out of scope entries? Kind regards, Martin From nobody Mon Aug 17 11:34: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 A0EFC3A0927 for ; Mon, 17 Aug 2020 11:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 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.949, 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 rLAYnjW6DUcn for ; Mon, 17 Aug 2020 11:34:26 -0700 (PDT) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 B58573A090B for ; Mon, 17 Aug 2020 11:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1597689264; bh=oJ2AECXYQl31f6AUJMnPN6jODQIsOteMcw6YEK7dYS0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=uAbr+m1YKtWuG+y5lN1nZJwQ70KSqYn457W4kcAgsRckOCqkFpZaiZ9RZDkctoz5b31z8Zgn9nTUw0xpapKVJGVKM8p76kdQM5KDOyu6aOoAqDRws7RIKXT5YtFGI39hLSkirug26tzkcBL5wRN3WZs6feikk0cs5/3iOo6rHRHe54+DMfGjU3CH05ON1W4QyG7C8qm25v5pp0s8MC9TWi5lsaU3CrCbg3EKVfp/QaZX6pMROyvtStgCASmziuc572hUpjF+IQf0T3+duqEoH+uZuSvgUw+Gxl7ynd/Zyekt0K9eMJUHdQl9669kn9tYk5dWrYdEs+Md6bjbnKn4Iw== X-YMail-OSG: _ssm404VM1nsBejokvbyDYr09iP49W3yAf7QnbL52uYLOVDArRy6xkqJYKEVNEV swmjqwVleP1ehf_gtZ.Yrr7bLDzuRk6BU8kES9B8KuY7z3Y9jPZPXZMnocLD0Vwn2bT35EZxAZTb k3EenTZuKyW9jnDrIcvkDdbTApgn_wsqx80VN.jgIC3zMOIKHjDpFvMWNKfNI2qxBP2C5xwCLkR6 Y35kIcAe4BnruhOomFgrtNtaHig1NroInDNkT_eKClYcYy62S73sng3Sqlw8p2fp.WUhmbbHV9AZ 2yMNplEDV8RT0120A_Tuwiw79SMckPFpIzhnb3kMrgDDMMn8ogK8pwUAd2krkDI1bbRjzgOVelNX rAGLvOcdE0mF4GmHmKJSckOyKGM2htoAJbglimRu5tm.7LcaqAUvKnH2wG5p2sXTMurIacxyCoAS _IJBPyBInsAXVok0hopgsrjBuRCQIDlGKaObMrDNZDZHDCVBheOzsTkYdNcsRltu2ysRwcJWpnrH xKW.gj7aZV9gg0A4U_vz73ybZVGj1xvP4n3brH45eC21bN5NZbrqTSro9_KIScRdocFT2dZAvz2B NBhWQtrhloacfCnhjAxqtYiAgmmzxlYYNNAf9r9MEIYbmFzCGHonVXEGh5MCoLMxGUlG5GzRtqYN LgBSa1TBWMUhpsgkSmW8XAX6QynDRpmnQoeWKogTHdB6NsZTYhel14ovqNUvRuFYw6t8veyeaawb oBEtLr_Jy1Hje8vrnsQ66CntMXnkUq8z6TsShmjyrzr7JHGNOEx2IJKcrX_tp.xx5V_UeNYD9r5c og77_v_rrrHh0WfOf6obtum3J0tB_hVnNUDF70fTq3wIw5zjXHnSkmK5FX9i1.Lt7Bokg7oIrtJM gisZNGAxHLpPWNvW6K2RJ_R_YHOXYvPwQiLgwd9GImCzkFLCg2XALZDDqrNcIiWE7FTi8vXREbYY X.KqpZSiko.8uCkwwFVA8b.7ggKcjVSFONH1btNtLfKZ3V6hfsA.p9w3k4E8_16EV_3bAd9JEDyQ z6uJDXHvzDF5fAjPQ16OarCdH8twxwKz20YVjjqm5Fme52z2BFSsttuUHV5mPpkiMWlxRyAZ54Ay JBwYFbmf_0MYQ867YRJBqcJe4CcQ_tOMPJRiHvxCZwHtFHGE_3qonxvNXaY23zzifzP_y2oSEL7J V_cLvynDJmvONw_qv_D1yhtEYzTOTUNBWhMVH5Uw264e2iTPRik0ODnvqmhkJ0sbOm8M5zugIbpn FIoWCvq87e_2sqEpKX11WHpiu21_AF_SSBVUqNJn7DmFMeOjPKz2F7FJbdrfF0BOx9IqvJbv6VIm Cj2n8V.26LkSxwc5RvOQkB1fI63zkf5tlmVyG8bp1lQhzWfWKpKODs43QUSAzFKs1v8P3yUvyvkH EZ1k1rn6aB4h1nhPZYpd7P3fGgseMqYhG34XynBFVsBPL4Yrx_VZCErICpujr_eD9Few- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Aug 2020 18:34:24 +0000 Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa610df0fcfbdeca2064b56940f30946; Mon, 17 Aug 2020 18:34:21 +0000 (UTC) To: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> From: Stephen Kent Message-ID: Date: Mon, 17 Aug 2020 14:34:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:34:28 -0000 Martin, > Heisann, > > I started to implement the rules laid out in section 6 "Relying > Party Processing of Manifests" of the draft and now have a few > questions and remarks. I decided to split these up into separate > messages. So, expect a few more messages ... > > * * * > > It is not quite clear how to deal with failed fetches. The overall response to a failed fetch is described in the intro to Section 6, as well as in 6.7. the intro states:    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.  ... Section 6.7 reiterates this description of what to do, and provide more details re what "termination of processing" means. > Section > 6.4 dictates that invalid signed objects (but curiously not invalid > certificates or CRLs) fail a fetch. The consequence of this is that a > fetch already fails if a single ROA (or worse: a single ghost-buster > record) is expired. Section 6.4 deals with acquiring all files referenced by a manifest, including certs and CRLs. The text says:    The RP MUST acquire all of the files enumerated in the manifest    (fileList) from the publication point.  This includes the CRL, each    object containing an EE certificate issued by the CA, and any    subordinate CA and EE certificates. > Section 6.7 now states that I should keep using "cached versions of the > objects associated with this CA instance." What does that actually > mean? What are these objects associated with the instance? The objects > listed on the new manifest or the old manifest? Or does objects here > mean validated output generated earlier? The phrase "CA instance" is used throughout Section 6 to accommodate CA key or alg rollover. So, a CA instance refers to a CA cert and the objects issued under it, as indicated by the SIA info. This is described in Section 6.1, which notes to use the id-ad-rpkiManifest URI, as well as in the intro to Section 6. The cached versions of objects refers to certs, CRLs, and signed objects that were validated during a previous fetch cycle, and which are not stale/expired. > If indeed it means RPKI objects, then doesn’t the expired ROA > essentially block all updates to the other objects to the CA? That > would strike me as counter-productive in terms of robustness. Are you positing the case where the cache contains an expired ROA for a CA instance, and a fetch that would have replaced the expired ROA fails? In that case, the cache entry for that ROA would no longer be valid, but I don;'t think that would affect other cache entries for the CA instance. Yes, this re-write of 6486 trades off robustness for more restrictive manifest checking. > This rule also blocks skipping objects of types I don’t know or care > about. I will have to at least do signed object validation on them, > which means reading and parsing them and then do signature validation. > If that is intended, I think this should be called out explicitly in > the document. If a manifest points to objects that are not CRLs, certs, ROAs, etc., then it is in error. But, your question seems to be what processing has to be performed on the files contained in an apparently valid manifest, right? Section 6.4 and RFC 6488 defines the tests to be performed, and 6.4 explicitly cites 6488. What additional info do you feel is needed here? > But I’m not even sure it provides any benefit. I, say, I am validating > a resource tagged association (RTA, [0]), I don’t care about the ROAs > at all. Does the RTA become invalid because a CA somewhere in the > validation chain had an expired ROA? I have not examined the RTA ID, and it's an expired draft, so ... Steve From nobody Mon Aug 17 23:37: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 315DB3A17B7 for ; Mon, 17 Aug 2020 23:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToaE--oLs6jT for ; Mon, 17 Aug 2020 23:37:02 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2DF3A17B6 for ; Mon, 17 Aug 2020 23:37:01 -0700 (PDT) Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8E2ED2E489; Tue, 18 Aug 2020 08:36:59 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Tue, 18 Aug 2020 08:36:59 +0200 From: Martin Hoffmann To: Stephen Kent Cc: sidrops@ietf.org Message-ID: <20200818083659.1922a98c@grisu.home.partim.org> In-Reply-To: References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 06:37:04 -0000 Stephen Kent wrote: > =20 > Are you positing the case where the cache contains an expired ROA for > a CA instance, and a fetch that would have replaced the expired ROA > fails? No, I am talking about a case where the ROA can be fetched successfully and matches the manifest hash, but its EE certificate is expired. Section 6.4 says that "if [files] fail the validity tests specified in [RFC6488]", the fetch has failed. Thus, the expired EE certificate in the ROA fails the complete fetch of all objects associated with the CA. So, not replacing an expired ROA in a publication point makes the entire CA not update anymore. I.e., any other objects that now expire cannot be replaced until that ROA is also replaced. You could argue =E2=80=9CDon=E2=80=99t do that, then=E2=80=9D but this appr= oach doesn=E2=80=99t make the RPKI more robust but rather makes it break more easily on simple oversights. > > This rule also blocks skipping objects of types I don=E2=80=99t know or= care > > about. I will have to at least do signed object validation on them, > > which means reading and parsing them and then do signature > > validation. If that is intended, I think this should be called out > > explicitly in the document. =20 > If a manifest points to objects that are not CRLs, certs, ROAs, etc.,=20 > then it is in error. How do you introduce new object types in this case? There will always be relying parties that run old software that doesn=E2=80=99t know of them.= You rather have to assume that objects of unknown types are signed objects with unknown content. If you do that, the current draft stipulates that you have to read, parse, and validate them -- and then throw away the content. This still means that all object types added to the RPKI must be signed objects. Whether that is okay or not, I don=E2=80=99t quite know. > But, your question seems to be what processing > has to be performed on the files contained in an apparently valid > manifest, right? Section 6.4 and RFC 6488 defines the tests to be > performed, and 6.4 explicitly cites 6488. What additional info do you > feel is needed here? I would like the document to explicitly state how to deal with object types appearing on a manifest that a replying party does not know. If nothing else then to make the document more helpful for implementers. > > But I=E2=80=99m not even sure it provides any benefit. I, say, I am > > validating a resource tagged association (RTA, [0]), I don=E2=80=99t ca= re > > about the ROAs at all. Does the RTA become invalid because a CA > > somewhere in the validation chain had an expired ROA? =20 >=20 > I have not examined the RTA ID, and it's an expired draft, so ... RTA validates signed objects distributed via alternative means using the PKI published as part of the RPKI. I.e., one of the CA certificates published via the RPKI has issued the EE certificate used in that signed object. In order to validate that object, I do not need to look at any ROAs or GBRs, only certificates, CRLs, and manifests. Should validation of that object fail if there is an expired ROA published by one of the CAs along the validation chain? Kind regards, Martin=20 From nobody Tue Aug 18 12:51: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 86DC03A0B13 for ; Tue, 18 Aug 2020 12:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QWg3cQ_rt16j for ; Tue, 18 Aug 2020 12:51:03 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 3E6EB3A0A3B for ; Tue, 18 Aug 2020 12:51:03 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id a5so22313777ioa.13 for ; Tue, 18 Aug 2020 12:51:03 -0700 (PDT) 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=2TPlGs3G1rTGR7Ecm330qElrB5dxonfKYm/FbPQQcgo=; b=VqlsSTyhaf94brW74leooEJ0ZY0+mQd4wMGOwvJp5cx4GH3ojiRqQ7haZdYiT5kOYJ 2JcH2b1aZaFPeXEi/1wXe5mAfM6QGNzDWXVgbLOg1UYKBedycYus5Zaug2ehxeLYe9dL 4oMOaqZHS28U1J9aLy6fJgMgEheSxEEBcBJreVTtW4xnVrfACFzmoH6gyFgeYXJ5JF7I FyHUaIv9z7cARB/i3xT0Tg5DJb+UKMpOXENQewrHq0e/2nRvN1Vy6ULkz2CNa4X2huu8 YSSb8JqW4+ruIpNIDsSpk5GuL+P9DWaUCsqAbbcy3fuqoWB8nCtY4TSsG6mwQjWZRUVd tdFw== 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=2TPlGs3G1rTGR7Ecm330qElrB5dxonfKYm/FbPQQcgo=; b=RqnPOOsxlWL3JeMCTSvcviOH/R00eme/EYjzKtNzMf0zZaHHUxvtvh7fbnet4XgRlJ F1sSV78F3ExFNRiV6ioSkkt3Ngb03YoevD73XUJoub06NyG5wjWFAFP8G56ZCVqAnwnG k/prE7WS6lzNd3bkWiC6KYrbGjwVuaYzlmQcerVong4/4oys1SnBb8XX1CHPaakJtsXu vV4xlD4eWyM1qXpUbBIirOViGzxZiKDTZ2VprA9QWpaUWybFoZeuWEYR4SQybz8nmoSP LsI0a6uSn2e0C5Ny3PwyXKVrZbhsbWeUhiZZF8l6nnK1U7xFPaPRtFOWM5kBTxRev9hC wsSA== X-Gm-Message-State: AOAM5317ojYOobs6//mBOqsTm4YV+hrjesIiNCo8TGxpno4SqwsOW7zv THthcFhI/XMK927zXC4MJhzphaWUafS5IgfCdnt1oA== X-Google-Smtp-Source: ABdhPJyET0cVdpoNfirtXx/yEOoA2gScbUz5nDC2tJ40j+XralemiaC3Udlw9t5fCBh1cAlVfj4uLtNCzsPiYrq6v4E= X-Received: by 2002:a02:a905:: with SMTP id n5mr21161959jam.64.1597780262036; Tue, 18 Aug 2020 12:51:02 -0700 (PDT) MIME-Version: 1.0 References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> In-Reply-To: <20200818083659.1922a98c@grisu.home.partim.org> From: George Michaelson Date: Wed, 19 Aug 2020 05:50:51 +1000 Message-ID: To: Martin Hoffmann Cc: Stephen Kent , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:51:08 -0000 FYI we fully intend resubmitting RTA, we were waiting for the second implementation (the work Martin is doing) to have input of merit to spin the new version. It would be plausible to resubmit for the November IETF. Two running code! We designed RTA to be complete outside of a repo, so it can be used privately between B2B partners. Not that its things cannot "be" on the manifest, but that there is no dependency on the repo framework beyond the TA, because the passed data is the chain for validation. This matters to people who want to conduct activity outside of the BGP validation problem, which is an 'all data needed' problem. B2B uses of RTA are not directly about all data. Its different. (provisioning is typically the use case here and the intent is to show the request to route, originate, provision is valid, because control of the resource can be demonstrated. its inherently a one-to-one conversation) RTA objects have an OID, are in the registry of types. So there is a meta-question implicit here, that the set of OID which can be referenced from a Manifest is NOT bound, and CAN increase, so validators have to be written in a way which expect to deal with unknown signed things: The system is not closed, and there will be others in future. I think the validation of a manifest MUST NOT fail simply because unknown objects exist on the Manifest, especially if the OID lies in the arc of RPKI definitions. Martin's question is also on the other side of the deal: If a manifest is showing a repository is incomplete, does it cause formal invalidation of all things in the manifest, which has potential to make validation of the 'complete' chain we send in RTA not work because now, an object on the RTA validation path is questioned for other reasons. I tend to the view that only things which invalidate the certificates matter, ROA or other elements are not contributing to the validity of the RTA. This is because they are not material to the validity of the object. If it was a 'whole repo' problem I could argue otherwise. It is not. It is inherently constrained. Specifically Missing CRL.. I have more concerns about. That would mean we cannot authentically deny the objects being validated. -G On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann wr= ote: > > Stephen Kent wrote: > > > > Are you positing the case where the cache contains an expired ROA for > > a CA instance, and a fetch that would have replaced the expired ROA > > fails? > > No, I am talking about a case where the ROA can be fetched successfully > and matches the manifest hash, but its EE certificate is expired. > Section 6.4 says that "if [files] fail the validity tests specified in > [RFC6488]", the fetch has failed. Thus, the expired EE certificate in > the ROA fails the complete fetch of all objects associated with the CA. > > So, not replacing an expired ROA in a publication point makes the > entire CA not update anymore. I.e., any other objects that now expire > cannot be replaced until that ROA is also replaced. > > You could argue =E2=80=9CDon=E2=80=99t do that, then=E2=80=9D but this ap= proach doesn=E2=80=99t make > the RPKI more robust but rather makes it break more easily on simple > oversights. > > > > This rule also blocks skipping objects of types I don=E2=80=99t know = or care > > > about. I will have to at least do signed object validation on them, > > > which means reading and parsing them and then do signature > > > validation. If that is intended, I think this should be called out > > > explicitly in the document. > > If a manifest points to objects that are not CRLs, certs, ROAs, etc., > > then it is in error. > > How do you introduce new object types in this case? There will always > be relying parties that run old software that doesn=E2=80=99t know of the= m. You > rather have to assume that objects of unknown types are signed objects > with unknown content. If you do that, the current draft stipulates that > you have to read, parse, and validate them -- and then throw away the > content. > > This still means that all object types added to the RPKI must be signed > objects. Whether that is okay or not, I don=E2=80=99t quite know. > > > But, your question seems to be what processing > > has to be performed on the files contained in an apparently valid > > manifest, right? Section 6.4 and RFC 6488 defines the tests to be > > performed, and 6.4 explicitly cites 6488. What additional info do you > > feel is needed here? > > I would like the document to explicitly state how to deal with object > types appearing on a manifest that a replying party does not know. If > nothing else then to make the document more helpful for implementers. > > > > But I=E2=80=99m not even sure it provides any benefit. I, say, I am > > > validating a resource tagged association (RTA, [0]), I don=E2=80=99t = care > > > about the ROAs at all. Does the RTA become invalid because a CA > > > somewhere in the validation chain had an expired ROA? > > > > I have not examined the RTA ID, and it's an expired draft, so ... > > RTA validates signed objects distributed via alternative means using > the PKI published as part of the RPKI. I.e., one of the CA > certificates published via the RPKI has issued the EE certificate used > in that signed object. > > In order to validate that object, I do not need to look at any ROAs or > GBRs, only certificates, CRLs, and manifests. > > Should validation of that object fail if there is an expired ROA > published by one of the CAs along the validation chain? > > Kind regards, > Martin > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Aug 19 05:29: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 5D1033A08C7 for ; Wed, 19 Aug 2020 05:29:09 -0700 (PDT) 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 7Byt_78-AF70 for ; Wed, 19 Aug 2020 05:29:07 -0700 (PDT) Received: from out20-2.mail.aliyun.com (out20-2.mail.aliyun.com [115.124.20.2]) (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 C18F63A03F6 for ; Wed, 19 Aug 2020 05:29:06 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08532675|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0103137-2.71311e-05-0.989659; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16378; MF=madi@rpstir.net; NM=1; PH=DS; RN=4; RT=4; SR=0; TI=SMTPD_---.IKCGVvG_1597840137; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.IKCGVvG_1597840137) by smtp.aliyun-inc.com(10.147.41.138); Wed, 19 Aug 2020 20:28:58 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: Date: Wed, 19 Aug 2020 20:28:55 +0800 Cc: Martin Hoffmann , Stephen Kent , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <4A06A42E-8379-4E28-8539-73B61F78A261@rpstir.net> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> To: George Michaelson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 12:29:09 -0000 George, > 2020=E5=B9=B48=E6=9C=8819=E6=97=A5 03:50=EF=BC=8CGeorge Michaelson = =E5=86=99=E9=81=93=EF=BC=9A >=20 > FYI we fully intend resubmitting RTA, we were waiting for the second > implementation (the work Martin is doing) to have input of merit to > spin the new version. It would be plausible to resubmit for the > November IETF. Two running code! >=20 > We designed RTA to be complete outside of a repo, so it can be used > privately between B2B partners. Not that its things cannot "be" on the > manifest, but that there is no dependency on the repo framework beyond > the TA, because the passed data is the chain for validation. This > matters to people who want to conduct activity outside of the BGP > validation problem, which is an 'all data needed' problem. B2B uses of > RTA are not directly about all data. Its different. (provisioning is > typically the use case here and the intent is to show the request to > route, originate, provision is valid, because control of the resource > can be demonstrated. its inherently a one-to-one conversation) Do you mean RTA validator has nothing to do with RPKI repository sync, = given the RTA use-case just requires the INR holder to provide all the = necessary certificates to construct the validation path down to TA? It reminds me of the similar model in RFC 6494 where the RPKI is used = for IPv6 SeND.=20 Di From nobody Wed Aug 19 15:15: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 CE3AD3A0D05 for ; Wed, 19 Aug 2020 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rlJWkzZmCJ96 for ; Wed, 19 Aug 2020 15:15:29 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 11F1B3A0D0B for ; Wed, 19 Aug 2020 15:15:28 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id g19so330326ioh.8 for ; Wed, 19 Aug 2020 15:15:28 -0700 (PDT) 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=p9oS8zZqdXARxHJwbg27xRYL2ihxyUCLenMugVkcqME=; b=qqENcHtXMxGAfYnLyaInXsx1+urJH6haYIuq0z8co/jh7vyQqJXvEY2afDSwEcOvOZ VJCfdHztyDzakESVO6Fa9zVeRLj/g0x3nn58yjL0nOV1ZcPB0mm+4vZlSMVjwEMiujyH bW/5LdTqfuJ2SmiNT6AO4imxvzzjCwZnVh8NAGRff16jpp1qUfPA3vBWaj/7HyOPdERc jlwKyg1u7rQkrZdzhtuichr2gXRZ2em6JDeMbuUFM4teGS0ZDbtU+bazyfHmk9hkZBuh Bl+KU51SxyDvtkWpEEAkFwPjm+6cEVvkWU7XmoN23RHQbgynpKCaNOTjeM7S+zZ3sfwU /EFw== 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=p9oS8zZqdXARxHJwbg27xRYL2ihxyUCLenMugVkcqME=; b=aJOkgsfvkiuF6MUVAfT3WErKg+9DSCg1FLfcg4d3zXa/YQW+BgMF/EwUUPRDXR7pAb tFnnappZg2r9ldMhD29+qgVY7ayXZzRy/AED0qf9wryIKMEcmvLFy0Rv57dOoruu7yti hNX9ND8tto+/5pUwPmkAjG9366dhVp8NJuHWddl6lBqjDqNO+cQPEnUzCycWIsVn54C5 jASCWZTItgbobapckssANSZlSNDjDgJ3C74yuwfBi+oWvlDROIFOm8ix56XXkE8d/sfL nJY0WNftloJzX0CPfY6le61iLqFNWQOHfDzzfwmnUq2BzEihAw1ZwJqVqs2mgdGk53Gt HOeA== X-Gm-Message-State: AOAM533i90M1mKaql4ViMrMLdrq/n/3gOP5tnA1Y30j+s0h0N/6XGK2I EuVslSCu84uZYw/TK61OfOHzH4Mztt6xHw6Gy5aG9MD2PIijKA== X-Google-Smtp-Source: ABdhPJzHxYerfOB7kXC/OErCWqSYbGevrrxwDNxu7yNNzcWc67YSpR2kov+X0dka6oCbj98BGHX1t/Syz0kO0xcsDQY= X-Received: by 2002:a6b:6204:: with SMTP id f4mr94539iog.56.1597875327642; Wed, 19 Aug 2020 15:15:27 -0700 (PDT) MIME-Version: 1.0 References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <4A06A42E-8379-4E28-8539-73B61F78A261@rpstir.net> In-Reply-To: <4A06A42E-8379-4E28-8539-73B61F78A261@rpstir.net> From: George Michaelson Date: Thu, 20 Aug 2020 08:15:16 +1000 Message-ID: To: Di Ma Cc: Martin Hoffmann , Stephen Kent , SIDR Operations WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 22:15:31 -0000 Yes. This is what I mean. The fly in the ointment is the CRL. I think we need to be very sure about how you source a CRL which invalidates things being used to validate a bundle. Is it acceptable to use a CRL which was applicable when the object was constructed? I think this is weaker than requiring the CRL to be checked for applicability at the time you validate. To do that, you have to be online and have access to all CRL from all Repo along the validation path. -G On Wed, Aug 19, 2020 at 10:29 PM Di Ma wrote: > > George, > > > 2020=E5=B9=B48=E6=9C=8819=E6=97=A5 03:50=EF=BC=8CGeorge Michaelson =E5=86=99=E9=81=93=EF=BC=9A > > > > FYI we fully intend resubmitting RTA, we were waiting for the second > > implementation (the work Martin is doing) to have input of merit to > > spin the new version. It would be plausible to resubmit for the > > November IETF. Two running code! > > > > We designed RTA to be complete outside of a repo, so it can be used > > privately between B2B partners. Not that its things cannot "be" on the > > manifest, but that there is no dependency on the repo framework beyond > > the TA, because the passed data is the chain for validation. This > > matters to people who want to conduct activity outside of the BGP > > validation problem, which is an 'all data needed' problem. B2B uses of > > RTA are not directly about all data. Its different. (provisioning is > > typically the use case here and the intent is to show the request to > > route, originate, provision is valid, because control of the resource > > can be demonstrated. its inherently a one-to-one conversation) > > Do you mean RTA validator has nothing to do with RPKI repository sync, gi= ven the RTA use-case just requires the INR holder to provide all the necess= ary certificates to construct the validation path down to TA? > > It reminds me of the similar model in RFC 6494 where the RPKI is used for= IPv6 SeND. > > Di > From nobody Fri Aug 21 11:45:05 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 485793A0DAF for ; Fri, 21 Aug 2020 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.949, 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 IxfM2MGOHd_Y for ; Fri, 21 Aug 2020 11:45:00 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 0B1533A0DAE for ; Fri, 21 Aug 2020 11:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598035498; bh=a8GPCSmA2qt52MlKmcSqZKORx5mk1mz6DzT68YDmkf8=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=V5GLcK6Q0oMCR2iZg5RsnIV2QwPP9AfIpcVOSm0yA0BUAq9dT/+hJI+o7/ovuhTxkioEURiM9G5ZswJ2q6M0dNqVGFmkTg9JNsToDfhT2Pa0z9FksfwYX8gP6LwxSowx70dZcrobzP2M/Y4XKJbw+7096xRaOAoewvZuRK8JcW8p+7KIWGwpTnaViaHQwVT3O1BMZyO7qHS0isBz/4pTEal/0eZVDavZ0wdp76oFwICF3J+W4s34NBH1YN9aIAh2rCoVxHyc3Fbkh4M1Pd/0YMyMS6WF3VVqclozmwU2Tk2Seo5zhZQ599yqroZ6ejU+nprdC5GefwpxhSq0eVHHxw== X-YMail-OSG: oI8T8QoVM1kN3Gnqqz.X8jI.6CsvBmm.u8q9FNWrkfG7BWip6fGjUyptcR8Hu1Z xvBvlX8XGsel0O.ES1OrDdD7_3P_24ugu0JPVdycBS.5eMzKuakaLsrvGBXAc_sTLCmhI1W6zBid vDQZoQlwdXe.9BDrkQvtxIdWEV0C637eEbFszFMlQTdIUIoh8VGXaQQ_qY5..cqFGW.lMYVOcKtg _iZieRDE0A2ed8eoUuvz1ASS82Ca0S1h8ZIlqkwkWyD2c9jDj97hhFZ3vH10K3sEh_fmXylItN7Z 6fd_nsnAusmeVGDJXGCNI_4q6GM4K4ZGWkWzLsIWCQjPUqCnwwn50GxUgVKGzFzcNxdaNXfUZCuS hrAjDLmbB3IZ6T4G4e0we0tIQVEP4blZNxxkI.nfFYA_BuTS7mzRovrP1_FEHSPYVQ4kofmOvYto 10DgAYtmYPZKHjJJg9rDDRKX0zkNy9cXCP_4MCl9dMhcz.Abv9XECJeYgIveACTPjGA4Wj8LhbAF ESsxucx7Fy289RbPhaiKIpkIwCX7pFmgl6JgWsty5AWYiW3x3QCfObz8XpY0jUf2sNuI5yStFfUN O4Cn9uzJSnw3j8BiC8oOTEKXhrxoJPjSgDMXtczdtdrIpPT.IssIxZhMZdAzWEn_TYTd84ft.b2Y NYcpOF.fBvfjAPkhqPj9x1Tz0cQE02t6BQieUiYJQJ1CssWXX_udtMZ80mJpJzdpKcNqATs46TNj s6oATP6HAN.4TRRC07liOTPvEKb2_3TB0bLO_i.kznndWMngNGYWC8IdKtXkxe4CFRFfQa66Yq7J HLFzm6MD99YqQRvzxL_WMst.I5ABXcVlKt8sLH8JAdn4FBFLtVb0jd9gcOJgsUoru0QKhIA0uDDZ al2BjLJx.C.XcYvHkJVTiduQr4iCeaXv0L3iwvGL53gY5ATtOBlpXOO18cQQu8mNuShLFeTNwjqn sXttSJPU.2CsZBZUNzphj9.zIjdp8_I2S8XlSebsOVpaMVVG9TB3wToW1kLzAgefF1QEPJimryjI cNrstVezRQnmhIdEx7M7RmApf1jBgB_Xi1Idy9FIMy32Bo8BiN9YjQktoLtU2z9hMDJTmafeVpe5 CBLkJgB.xJe8Ywixrt8kKwoTdpAuWNPnSgP84mfLufaWPt18903CPC27m8FFPDp8mJCc4PG57tp3 i3L3mdEE1qwB.TOtHwU8_AAZT40KQ4SxdDl8Aem_TajWGLToYaSl.qwz5WKI57xpyIPvzzaUSGP7 Mx8YdkUqMa0Mfb4ufZ0LFIgGg4TZbSDDAcEL8Fb_C9wZcuSBJz9_Qln3Xno4uFvRtT3c9bqLPeQW qC48zkCLerlFVhauLdQeC.5leRWgU8segZgOuEFV.MtupGYsaxtV5bfL37GmvFddkApOKtvTbK3N EurSNE1Z.gCo7D449Esm6nNK7_BKzCmgbxRY.TCSKQKHiG3qgOAhlr9taia08FylcyD4YokMOZJs CkPSoF.8uEd_ImhZkYCsrn2ywctaOhHB37eS5yVc3EVNuOVUEtdABnLh0knxWP816Z5bRO1BBROU 7O87t1jSWh5xmWpsjK.nC8dkXASPqW9kDAFJyVYi_5pgQGWDm_A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 21 Aug 2020 18:44:58 +0000 Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b66873e2a54a97bca25158ab62bdac0b; Fri, 21 Aug 2020 18:44:57 +0000 (UTC) From: Stephen Kent To: George Michaelson , Martin Hoffmann Cc: SIDR Operations WG References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> Message-ID: <4d2396bd-0fc0-b19c-546d-7d63a2966003@verizon.net> Date: Fri, 21 Aug 2020 14:44:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 21 Aug 2020 18:45:02 -0000 George, Thanks for the background re RTA. I think your comments address the issue Martin raised: the data structure is designed to be "complete outside of a repo" and, unlike the other objects at a pub point, this one carries a full validation path to some TA, not to the CA associated with the pub point. So, I don't think an RTA should be stored in the RPKI repo system, and thus it ought not appear in a manifest. You raise the "meta-question"of whether the set of data items that can be stored at a pub point, and thus included on a manifest, is bounded. I believe that new data items might be defined for storage in the repo system, and that, if they are, they should be covered by the manifest. However, such items ought to be consistent with the overall RPKI functionality, not just signed objects that someone wants to piggyback on the RPKI repo system. Let's not encourage the RPKI to be more like an IRR DB. Steve > FYI we fully intend resubmitting RTA, we were waiting for the second > implementation (the work Martin is doing) to have input of merit to > spin the new version. It would be plausible to resubmit for the > November IETF. Two running code! > > We designed RTA to be complete outside of a repo, so it can be used > privately between B2B partners. Not that its things cannot "be" on the > manifest, but that there is no dependency on the repo framework beyond > the TA, because the passed data is the chain for validation. This > matters to people who want to conduct activity outside of the BGP > validation problem, which is an 'all data needed' problem. B2B uses of > RTA are not directly about all data. Its different. (provisioning is > typically the use case here and the intent is to show the request to > route, originate, provision is valid, because control of the resource > can be demonstrated. its inherently a one-to-one conversation) > > RTA objects have an OID, are in the registry of types. So there is a > meta-question implicit here, that the set of OID which can be > referenced from a Manifest is NOT bound, and CAN increase, so > validators have to be written in a way which expect to deal with > unknown signed things: The system is not closed, and there will be > others in future. I think the validation of a manifest MUST NOT fail > simply because unknown objects exist on the Manifest, especially if > the OID lies in the arc of RPKI definitions. > > Martin's question is also on the other side of the deal: If a manifest > is showing a repository is incomplete, does it cause formal > invalidation of all things in the manifest, which has potential to > make validation of the 'complete' chain we send in RTA not work > because now, an object on the RTA validation path is questioned for > other reasons. > > I tend to the view that only things which invalidate the certificates > matter, ROA or other elements are not contributing to the validity of > the RTA. This is because they are not material to the validity of the > object. If it was a 'whole repo' problem I could argue otherwise. It > is not. It is inherently constrained. > > Specifically Missing CRL.. I have more concerns about. That would mean > we cannot authentically deny the objects being validated. > > -G > > On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann wrote: >> Stephen Kent wrote: >>> Are you positing the case where the cache contains an expired ROA for >>> a CA instance, and a fetch that would have replaced the expired ROA >>> fails? >> No, I am talking about a case where the ROA can be fetched successfully >> and matches the manifest hash, but its EE certificate is expired. >> Section 6.4 says that "if [files] fail the validity tests specified in >> [RFC6488]", the fetch has failed. Thus, the expired EE certificate in >> the ROA fails the complete fetch of all objects associated with the CA. >> >> So, not replacing an expired ROA in a publication point makes the >> entire CA not update anymore. I.e., any other objects that now expire >> cannot be replaced until that ROA is also replaced. >> >> You could argue “Don’t do that, then” but this approach doesn’t make >> the RPKI more robust but rather makes it break more easily on simple >> oversights. >> >>>> This rule also blocks skipping objects of types I don’t know or care >>>> about. I will have to at least do signed object validation on them, >>>> which means reading and parsing them and then do signature >>>> validation. If that is intended, I think this should be called out >>>> explicitly in the document. >>> If a manifest points to objects that are not CRLs, certs, ROAs, etc., >>> then it is in error. >> How do you introduce new object types in this case? There will always >> be relying parties that run old software that doesn’t know of them. You >> rather have to assume that objects of unknown types are signed objects >> with unknown content. If you do that, the current draft stipulates that >> you have to read, parse, and validate them -- and then throw away the >> content. >> >> This still means that all object types added to the RPKI must be signed >> objects. Whether that is okay or not, I don’t quite know. >> >>> But, your question seems to be what processing >>> has to be performed on the files contained in an apparently valid >>> manifest, right? Section 6.4 and RFC 6488 defines the tests to be >>> performed, and 6.4 explicitly cites 6488. What additional info do you >>> feel is needed here? >> I would like the document to explicitly state how to deal with object >> types appearing on a manifest that a replying party does not know. If >> nothing else then to make the document more helpful for implementers. >> >>>> But I’m not even sure it provides any benefit. I, say, I am >>>> validating a resource tagged association (RTA, [0]), I don’t care >>>> about the ROAs at all. Does the RTA become invalid because a CA >>>> somewhere in the validation chain had an expired ROA? >>> I have not examined the RTA ID, and it's an expired draft, so ... >> RTA validates signed objects distributed via alternative means using >> the PKI published as part of the RPKI. I.e., one of the CA >> certificates published via the RPKI has issued the EE certificate used >> in that signed object. >> >> In order to validate that object, I do not need to look at any ROAs or >> GBRs, only certificates, CRLs, and manifests. >> >> Should validation of that object fail if there is an expired ROA >> published by one of the CAs along the validation chain? >> >> Kind regards, >> Martin >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Aug 25 17:11:37 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 3BE4D3A08CF for ; Tue, 25 Aug 2020 17:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY20HuOHTUvn for ; Tue, 25 Aug 2020 17:11:34 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2090.outbound.protection.outlook.com [40.107.89.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A2C3A08D4 for ; Tue, 25 Aug 2020 17:11:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=COD9kONVT57miTcd0GvPd12SZ+mcIha6fcLutCio0meFljthKNPzuSoPfr2FGsbrF0TgkgvfaKp5nyHBKOXLSCWugz8KT7MOBLaYFGQWZBfQDHx5KVaG+NdYChNOzLuX4bH+QqHH7Bwo1N2liWGUUC5yM6i0hFEA8wx/SpnW0gXIIh1cEUt4m/0Q1ViPSy/elgiFSh3NmNIOgl878M9JLcUB6n2IUVztymumeeM05hryGrbQ0F8uDaucZWdkxWT2yLPg032d0ZbJDUBm2++IA2FRoxqsc8dkDIwBrw6P1/gnZ1aLyJG9x9SZ+Udmt5pP1cao5YvXIHTRbMFHn40nsQ== 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=KHaMckMMm1N3nKCy1k0i/+27kmCyptk2zyThL5K0iv8=; b=QbLrVXr7U4Oh7liaeSsmsxSx32xY5XbxmxzlyPRFKYlfenS9jrSILWDwdUXqORnX98Ke5DEs+Zz0HqKHxlqXncgwTi15V3Udl5zc/8CP+gi9cpbrh1DjL1jwkLci5giNHhMjgUNadVZ6aqtHcOzPF0XIWUuzggFto/TDKMW06bOQirqceoFnUQOmgr9xIMXFBLOn8ms5yHq5yKF4XyR8djAzU6d9cz0qldWHf8It6GecR3GdXk0KE+WhZ0NYlSwYUyYV4lUaRzbsJCV8RLrOJ6Fm311zX6ad7TI6P1Z5rtYvhFYv1j9MTgYCi6a/LDKs1ETl/43vpxKvLIbGn+FEAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KHaMckMMm1N3nKCy1k0i/+27kmCyptk2zyThL5K0iv8=; b=nXQ70EZ3gDra1JgwVj7hULTOCwjqVluWZrq0uOEniHEas53I7X+eT7suWY0O3sZTJZarINNL9tiE9zh2nhAaR8DV+oI8rGsbVe2U7xZk6WlrcVnp435krL5xemsLaiUrrEVUaNDGf3Ui54gnKlcF2yPmS6EpZu2Trgrbc+SXHDI= Received: from BLAPR09MB6963.namprd09.prod.outlook.com (2603:10b6:208:289::7) by MN2PR09MB5900.namprd09.prod.outlook.com (2603:10b6:208:220::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Wed, 26 Aug 2020 00:11:32 +0000 Received: from BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc]) by BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc%6]) with mapi id 15.20.3305.026; Wed, 26 Aug 2020 00:11:32 +0000 From: "Borchert, Oliver (Fed)" To: Nick Hilliard , Keyur Patel CC: "sidrops@ietf.org" , "Borchert, Oliver (Fed)" , "Montgomery, Douglas C. (Fed)" , Daniel Kopp Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcA+HFL2ap5d5eEGUfZX0DE6/EKkzY/mAgBXzwIA= Date: Wed, 26 Aug 2020 00:11:31 +0000 Message-ID: References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:223::89] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 99ce6dd2-3d0b-4dba-5b1d-08d849549656 x-ms-traffictypediagnostic: MN2PR09MB5900: x-ms-exchange-transport-forked: True 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: MBU322+JYOSkKeFx2PuRBG2zl5eiFjSmTRoJmk6Ub/Yhbw6wuwOFtxyfHtJ9XNJBX0xg0fmZEY/XLYEp+oCDhaImpI0CEobLrbDGTVdeDTO7LRCkffB9q7W8kSlOtfMaX7tBpQkBTyQISqpS1+Bu845auzRG/Z/IG69LUYI1zbD33qM+7l9VzT3VBNzjDd1FjCHnhoYs+xQF9gUpPoCH0OLJmEIOSZzHQmUlS/l+u7AP6/NBImzLCOXhivbJtgWWHSVrVqyr/COWMWjwmz9cOJ/sjBvhqLlHkIBsJ18VTzX0IHt8WgajWSU7cvCKM5oqpa1jCwIpcAgCqoNUVYCOQCDhTSCCpymhP/jhTmEhOkzXQGm7a9qkdtIzLtKGuMES+CX/ykpiUiwiD65j5zTqFw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6963.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(376002)(396003)(39850400004)(76116006)(66574015)(186003)(66556008)(66446008)(6506007)(64756008)(33656002)(66946007)(86362001)(71200400001)(66476007)(8676002)(316002)(54906003)(110136005)(5660300002)(6486002)(6512007)(36756003)(966005)(4326008)(8936002)(91956017)(83380400001)(2906002)(478600001)(2616005)(45080400002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: znmg9cdgnOReAdRRPcHsIL06nL11tbMjvcIyizcqeJjym4d0kZPENY/qww7rMKgOBjUb87/Q78YXU3+gCjuwm/olrJ4XlGHbspbXhhW27D1R70FZFlXHt+vvnc29AEVMV7QDDKwUAEsa+x4xhe26XmAoIqAT32fGrtYauGVUf9Wvbc39nYQ6nsKPcy9X+41Ti+jvdMxlJcJ+nGb3HoBXN94lbYkjKRN4yGB0Vok/pY1MTYSnOffyLqKx7T3iFoAmaCSD/YYAsZdQFZa2UydBEibCfbi1PoKsH/8w4Wl0mcJLhadXMlYr6K2tMQuFmSabW/wbvN5dynDIHB40zlCg42U0/BL9OeYppi5ht676RFKyvX1LXyw9oKE9S1iGc2uRSgw/do9nyZCT5NPCuFDN/uIsnrFprs3O7gWYZ8QEa3z0UaWrfT3kDD1IolPI91htJVVGVH2yX1RqSgiPOCP3FANVCK7PbsX0QC/Kcj4nJLSoSGFyE8dv1mEyFVQlVgh1OxQDzY65AkVSkt47VwZs8Rp1ePI9DTefhvMZkKderld/0W4a9QoRoeg4ecZn0KxUzPsAy8APac5Ciepbx14nT0RSkwJziheM3cxXKuozHm7W/n2ZzJL4cNLdKk4s5ZD7YnFVqBqSlveKwsfSl9MQTFPTgBuU2qQkemM2ohAQxZI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6963.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99ce6dd2-3d0b-4dba-5b1d-08d849549656 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 00:11:31.9873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EVvIpzJ3ShUDu5TxSBkXk3h3fGnyluTY5hNSbXoQW3GPSCehUq3sRDPYHAdak2K8JI2WpkrEAOlZ1J1Hl0Z8pw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5900 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 00:11:36 -0000 TmljaywNCg0KVGhpcyBwb2ludCBoYXMgYmVlbiBtYWRlIGluIHRoZSBwYXN0IChhYm91dCBvcmln aW4gdmFsaWRhdGlvbiBzaWduYWxpbmcpIGFuZCBJIHRoaW5rIGl0IGlzIGEgYml0IG9mIGEgcmVk IGhlcnJpbmcuDQoNCk9wZXJhdG9ycyBjYW4gYW5kIGFyZSBzaWduYWxpbmcgdmFsaWRhdGlvbiBz dGF0ZSB0b2RheSB3aXRoIGFkLWhvYyB1c2Ugb2YgY29tbXVuaXRpZXMuICBPcGVyYXRvcnMgZG8g dGhpcyBmb3IgbXVsdGlwbGUgcmVhc29ucywgaW5jbHVkaW5nIHByb3ZpZGluZyBzb21lIHJlc2ls aWVuY2UgdG8gdGhlIHN5c3RlbSBzaG91bGQgYSByb3V0ZXIgbG9zZSBhY2Nlc3MgdG8gdmFsaWRh dGluZyBjYWNoZXMsIHRvIGRldGVjdCBhbmQgZGlhZ25vc2UgUlBLSSBzdGF0ZSBza2V3IGFtb25n IHJvdXRlcnMgaW4gdGhlIHNhbWUgbmV0d29yayBldGMuICAgTm90IGhhdmluZyBhIHN0YW5kYXJk aXplZCBlbmNvZGluZyBvZiB0aGlzIHByYWN0aWNlIHdvbid0IGJlIHRoZSBkZXRlcm1pbmluZyBm YWN0b3Igb2YgaG93IHRoaXMga2luZCBvZiBzaWduYWxpbmcgaXMgdXNlZC4NCg0KSW4gdGhlIGNh c2Ugb2YgQkdQc2VjLCB0aGUgbmVlZCBmb3IgZGlhZ25vc3RpY3MgYW5kIHJlc2lsaWVuY2Ugd2ls bCBiZSBldmVuIGhpZ2hlci4gIFJlbWVtYmVyIHRoZXJlIGlzIG5vICJub3QgZm91bmQiIGluIEJH UHNlYyB0byBmYWxsIGJhY2sgdG8gbG9zcyBvZiBjb250YWN0IHdpdGggUlBLSSBkYXRhLiAgSWYg c3VjaCBzaWduYWxpbmcgYWxzbyBmYWNpbGl0YXRlZCBwZXJmb3JtYW5jZSBvcHRpbWl6YXRpb25z IG9yIGltcGxlbWVudGF0aW9uIG9mIGNvbnNpc3RlbnQgcG9saWN5IGRlY2lzaW9ucyBvbiByb3V0 ZXJzIHRoYXQgaGF2ZSBkZWZlcnJlZCB0aGVpciBvd24gdmFsaWRhdGlvbiBwcm9jZWR1cmVzLCBp dCBhY3R1YWxseSBtaWdodCBlbmNvdXJhZ2UgbW9yZSBkZXBsb3ltZW50IHRoYW4gZGlzY291cmFn ZSBpdCBhcyB5b3Ugc3VnZ2VzdC4NCg0KSW4gc2hvcnQsIEkgc2VlIHN1Y2ggbWVjaGFuaXNtcyBh cyBzdXBwb3J0aW5nIGFuZCBlbmNvdXJhZ2luZyBkZXBsb3ltZW50IG9mIHRoZXNlIHRlY2hub2xv Z2llcyAtIG9yIGF0IHdvcnNlIGJlaW5nIGEgbm9uLWZhY3RvciB0byB0aGUgYWRvcHRpb24gcXVl c3Rpb24gLSBhcyB0aG9zZSB3aG8gd2FudCB0byBkbyB0aGlzIGluIG5vbi1zdGFuZGFyZCB3YXlz IHdpbGwganVzdCBjb250aW51ZSB0byBkbyBzby4NCg0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1 dGVyIFNjaWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5v bG9neQ0KKE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcN CiANCg0K77u/T24gOC8xMS8yMCwgNDo1OSBQTSwgIlNpZHJvcHMgb24gYmVoYWxmIG9mIE5pY2sg SGlsbGlhcmQiIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG5pY2tAZm9v YmFyLm9yZz4gd3JvdGU6DQoNCiAgICBLZXl1ciBQYXRlbCB3cm90ZSBvbiAxMS8wOC8yMDIwIDE5 OjQ1Og0KICAgID4gQSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQg Zm9yIA0KICAgID4gZHJhZnQtc2lkcm9wcy1iZ3BzZWMtdmFsaWRhdGlvbi1zaWduYWxpbmctMDMs IOKAnEJHUHNlYyBWYWxpZGF0aW9uIFN0YXRlIA0KICAgID4gc2lnbmFsaW5n4oCdLiBQbGVhc2Ug cmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCAN CiAgICA+IG9uIEF1Z3VzdCAyNSwgMjAyMC4NCg0KICAgIEluIGdlbmVyYWwsIHJlcGxpY2F0aW5n IHZhbGlkYXRpb24gZnVuY3Rpb25hbGl0eSB1c2luZyBCR1AgY29tbXVuaXRpZXMgDQogICAgaXMg YSBwb29yIGlkZWEgYW5kIGZyb20gYW4gb3BzIHBvaW50IG9mIHZpZXcsIGl0IHNlZW1zIHdpc2Vy IGFzIGEgbG9uZyANCiAgICB0ZXJtIG9iamVjdGl2ZSB0byBwdXNoIHZlbmRvcnMgdG8gc3VwcG9y dCBiZ3BzZWMgdGhhbiB0byBpbXBsZW1lbnQgaGFja3MgDQogICAgbGlrZSB0aGlzLiAgRm9yIHRo aXMgcmVhc29uIEkgZG9uJ3Qgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGUgZHJhZnQgYXMgDQog ICAgYW4gcmZjLg0KDQogICAgTWFqb3IgaXNzdWVzOg0KDQogICAgMS4gVGhlIGRyYWZ0IGxhY2tz IGEgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIGEgc3Vuc2V0IGNsYXVzZS4NCg0KICAgIDIuIFByZXZp b3VzbHkgdGhlcmUncyBiZWVuIGEgZ29vZCBkZWFsIG9mIGRpc2N1c3Npb24gb24gc2lkcm9wcyBh Ym91dCANCiAgICBSUEtJIHZhbGlkYXRpb24gc3RhdGUgc2lnbmFsbGluZy4gIFNldmVyYWwgcHJv YmxlbXMgd2VyZSBsaXN0ZWQgaGVyZToNCg0KICAgID4gaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0 Zi5vcmclMkZhcmNoJTJGbXNnJTJGc2lkcm9wcyUyRllWMVdmb3hRTml3Zk9qdEtJWTFkNllKalJ4 TSUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0NmMzcx MDc5MjI0MWQ0YmFlMTViYzA4ZDgzZTM5N2Q4YyU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1 YzYxZGVjJTdDMSU3QzAlN0M2MzczMjc3NjM5MzYyOTgyODAmYW1wO3NkYXRhPWpmYkdmcGVMdlNr YmpqTVlqSXh6SHRLQSUyQm1XM2wlMkI2RXNreThRR3J3MU5RJTNEJmFtcDtyZXNlcnZlZD0wDQoN CiAgICBNb3N0IG9mIHRoZSBwcm9ibGVtcyBhc3NvY2lhdGVkIHdpdGggdmFsaWRhdGlvbiBzdGF0 ZSBzaWduYWxsaW5nIA0KICAgIGlkZW50aWZpZWQgaW4gdGhhdCBlbWFpbCBhbHNvIGFwcGx5IHRv IGJncHNlYyB2YWxpZGF0aW9uIHN0YXRlIA0KICAgIHNpZ25hbGxpbmcsIG5hbWVseToNCg0KICAg IC0gY3J5cHRvIGF1dGhlbnRpY2F0aW9uIGlzIGxvc3QNCiAgICAtIGRpZmZlcmVudCBhbmQgaW5j b21wYXRpYmxlIHNldCBvZiBzaWduYWxsaW5nIGhvb2tzDQoNCiAgICBJbiBwYXJ0aWN1bGFyIGFs bCB0aGUgcHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIFJQS0kgdmFsaWRhdGlvbiBzdGF0ZSANCiAg ICBzaWduYWxsaW5nIG92ZXIgZUJHUCBhbHNvIGFwcGx5IHRvIGJncHNlYyBzdGF0ZSBzaWduYWxs aW5nIG92ZXIgZUJHUC4NCg0KICAgIERlZmluaW5nIHRoaXMgYXMgbm9uLXRyYW5zaXRpdmUgaXMg YSBnb29kIHN0YXJ0LCBidXQgdGhlIGxhbmd1YWdlIG5lZWRzIA0KICAgIHRvIGNoYW5nZSB0byBl bnN1cmUgdGhhdCBpdCBjYW5ub3QgZXNjYXBlIGFuIEFTTi4gIENhbiBJIHN1Z2dlc3QgdGhlIA0K ICAgIGZvbGxvd2luZyB0ZXh0IGNoYW5nZXM6DQoNCiAgICBjaGFuZ2U6DQogICAgPiAgICBJZiB0 aGUgcm91dGVyIHN1cHBvcnRzIHRoZSBleHRlbnNpb24gYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3Vt ZW50LCBpdA0KICAgID4gICAgU0hPVUxEIGF0dGFjaCB0aGUgQkdQc2VjIHBhdGggdmFsaWRhdGlv biBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkgdG8NCiAgICA+ICAgIEJHUHNlYyBVUERBVEUgbWVz c2FnZXMgc2VudCB0byBCR1AgcGVlcnMgYnkgbWFwcGluZyB0aGUgbG9jYWxseQ0KICAgID4gICAg Y29tcHV0ZWQgdmFsaWRhdGlvbiBzdGF0ZSBpbnRvIHRoZSBsYXN0IG9jdGV0IG9mIHRoZSBleHRl bmRlZA0KICAgID4gICAgY29tbXVuaXR5LiAgVGhpcyBTSE9VTEQgYmUgZG9uZSBhdXRvbWF0aWNh bGx5IGZvciBpQkdQIHBlZXJzIGFuZA0KICAgID4gICAgY29uZmlndXJhYmxlIGZvciBlQkdQIHBl ZXJzIChzZWUgYmVsb3cpLg0KDQogICAgdG86DQogICAgPiAgICBJZiB0aGUgcm91dGVyIHN1cHBv cnRzIHRoZSBleHRlbnNpb24gYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LCBpdA0KICAgID4g ICAgU0hPVUxEIGF0dGFjaCB0aGUgQkdQc2VjIHBhdGggdmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRl ZCBjb21tdW5pdHkgdG8NCiAgICA+ICAgIEJHUHNlYyBVUERBVEUgbWVzc2FnZXMgc2VudCB0byBp QkdQIHBlZXJzIGJ5IG1hcHBpbmcgdGhlIGxvY2FsbHkNCiAgICA+ICAgIGNvbXB1dGVkIHZhbGlk YXRpb24gc3RhdGUgaW50byB0aGUgbGFzdCBvY3RldCBvZiB0aGUgZXh0ZW5kZWQNCiAgICA+ICAg IGNvbW11bml0eS4NCg0KICAgIGFuZCBjaGFuZ2U6DQogICAgPiAgICBCeSBkZWZhdWx0LCByb3V0 ZXJzIFNIT1VMRCBlbmFibGUgdXNlIG9mIHRoaXMNCiAgICA+ICAgIGNvbW11bml0eSBvbiBhbGwg aUJHUCBzZXNzaW9ucyBhbmQgcm91dGVycyBTSE9VTEQgZGlzYWJsZSB0aGUgdXNlIG9mDQogICAg PiAgICB0aGlzIGNvbW11bml0eSBvbiBhbGwgZUJHUCBzZXNzaW9ucy4gIEltcGxlbWVudGF0aW9u cyBNVVNUIE5PVCBzZW5kDQogICAgPiAgICBtb3JlIHRoYW4gb25lIGluc3RhbmNlIG9mIHRoZSBv cmlnaW4gdmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRlZA0KICAgID4gICAgY29tbXVuaXR5IGFuZCBN VVNUIGRyb3AgKHdpdGhvdXQgcHJvY2Vzc2luZykgdGhlIEJHUHNlYyBwYXRoDQogICAgPiAgICB2 YWxpZGF0aW9uIHN0YXRlIGV4dGVuZGVkIGNvbW11bml0eSBpZiByZWNlaXZlZCBvdmVyIGFuIEV4 dGVybmFsIEJHUA0KICAgID4gICAgKGVCR1ApIHBlZXJpbmcgc2Vzc2lvbiB0aGF0IGhhcyBub3Qg YmUgZXhwbGljaXRseSBjb25maWd1cmVkIHRvDQogICAgPiAgICBlbmFibGUgcHJvY2Vzc2luZy4N Cg0KICAgIHRvOg0KICAgID4gICAgQnkgZGVmYXVsdCwgcm91dGVycyBTSE9VTEQgZW5hYmxlIHVz ZSBvZiB0aGlzDQogICAgPiAgICBjb21tdW5pdHkgb24gYWxsIGlCR1Agc2Vzc2lvbnMuICBJbXBs ZW1lbnRhdGlvbnMgTVVTVCBOT1Qgc2VuZA0KICAgID4gICAgbW9yZSB0aGFuIG9uZSBpbnN0YW5j ZSBvZiB0aGUgb3JpZ2luIHZhbGlkYXRpb24gc3RhdGUgZXh0ZW5kZWQNCiAgICA+ICAgIGNvbW11 bml0eSwgTVVTVCBOT1QgYXR0YWNoIHRoZSBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uIHN0YXRlIGV4 dGVuZGVkDQogICAgPiAgICBjb21tdW5pdHkgdG8gQkdQc2VjIFVQREFURSBtZXNzYWdlcyBzZW50 IHRvIGVCR1AgcGVlcnMgYW5kIE1VU1QgZHJvcA0KICAgID4gICAgKHdpdGhvdXQgcHJvY2Vzc2lu ZykgdGhlIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24gc3RhdGUgZXh0ZW5kZWQgY29tbXVuaXR5DQog ICAgPiAgICBpZiByZWNlaXZlZCBvdmVyIGFuIGVCR1AgcGVlcmluZyBzZXNzaW9uLg0KICAgIE5p Y2sNCg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBTaWRyb3BzIG1haWxpbmcgbGlzdA0KICAgIFNpZHJvcHNAaWV0Zi5vcmcNCiAgICBo dHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzaWRyb3BzJmFtcDtk YXRhPTAyJTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3Q2YzNzEwNzkyMjQxZDRi YWUxNWJjMDhkODNlMzk3ZDhjJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0Mx JTdDMCU3QzYzNzMyNzc2MzkzNjI5ODI4MCZhbXA7c2RhdGE9YXVNMEl5dk1TUnB0cGtEMkxWRVdJ blFJSnFURWFuS3ljNGIlMkJFbHJURUhjJTNEJmFtcDtyZXNlcnZlZD0wDQoNCg== From nobody Tue Aug 25 19:17:59 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 5A42E3A0BA4; Tue, 25 Aug 2020 19:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lGuaMJi2F2e; Tue, 25 Aug 2020 19:17:57 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2095.outbound.protection.outlook.com [40.107.89.95]) (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 BB86B3A0BA0; Tue, 25 Aug 2020 19:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZAoqOOKSFxkVQR+c75ewou0ow3IL6Cc1f8GbAdWyz1uY0Je6go9PKRq8r5w5TQCDen81IMMeen8ID3L6ARkaWEVE12DI8/dQ077EkWVxk0wdqsxvddk6NKgQiCIm51lP+u0FB+BMQMACy6s4yau/evREL/AbKZxLSxJdz4WEJq1y/6b5lZBnVKFoY+pm9K4wGbkRT5aGYvs4mkElOh20EQPpBXdr8OcxO8Hu4w72MMPUvAnPJwrEG6PPC8fGE0NhPY2lf8XBlQh30gzsE7adbvoVRTefD54HnU97Q6BaiXuHJlTQjDBhBSwTyCe2VQLWiQPEEjsYQBfN+UmDMlyf4Q== 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=QQsC+S1tr4TtiyE/p7yBrFDi0Dsty3h7kg3pXEUvrC4=; b=RuRVgUCHXxj1hiBDtdLEHaoJvxqtKY+xVJv+8zYSKD6Vj2njOJA/Y11rrje5YJPHsNYpMGylYZoj5gwtNbx7Nq4ZWlCdrIWQVXdtxz/kVTqnkj2m2dnCIsPsjBggI38J1/ZJAjpdIxLvlO3kK8E5HpWNSGbFiZl/bw8UfiLheN5/9lP/+I5/lr2qGZVMlvBPlxgvVWoHsck2kB4fi6iQLS0HnzZytCOayrlb1fakxIDnHRAipv7icrIpW/XDDkvqZ2geObYiaj1GO4c9uaBiodQZ8tSJoc8n15LF1OUvibNsUAKj63Vgdw9vZKhY/wslBX/KmwVPhm2MIiGEbDg8FA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQsC+S1tr4TtiyE/p7yBrFDi0Dsty3h7kg3pXEUvrC4=; b=o9RmHM2MkCJf1/bZmhOh0JkYGk7fjQjz6DyIEauLVrnv+NkHGqpjhQO3lHp8tJ2tArnr7RjwXs580qs5pR86V6pquYF0iLj/RqroQ2zrtzsG8dWyabAnE749GfE/UqSVMgjCUkvys3r4U6ExjAtoKMgCKxnNyuNXqL0G5wZZrH8= Received: from BLAPR09MB6178.namprd09.prod.outlook.com (2603:10b6:208:2a4::20) by BLAPR09MB7011.namprd09.prod.outlook.com (2603:10b6:208:2af::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Wed, 26 Aug 2020 02:17:48 +0000 Received: from BLAPR09MB6178.namprd09.prod.outlook.com ([fe80::bc3d:e5e4:54db:5994]) by BLAPR09MB6178.namprd09.prod.outlook.com ([fe80::bc3d:e5e4:54db:5994%7]) with mapi id 15.20.3305.032; Wed, 26 Aug 2020 02:17:48 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "keyur@arrcus.com" CC: "sidrops@ietf.org" , "sidrops-chairs@ietf.org" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcA+HFL2ap5d5eEGUfZX0DE6/EKkzY/mAgBXSrACAAB4HAIAAAjuAgABhIKg= Date: Wed, 26 Aug 2020 02:17:47 +0000 Message-ID: References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> <94B06450-ED03-4AFD-B568-03AB60C8DF54@nist.gov>, <8C5D0A4F-0A3C-4678-ACD4-D2183660641D@nist.gov> In-Reply-To: <8C5D0A4F-0A3C-4678-ACD4-D2183660641D@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.219.117] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6c224683-a210-46ff-d603-08d8496639f8 x-ms-traffictypediagnostic: BLAPR09MB7011: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lXWy1gqe19ugW092vNM4eYzwxt8sAuBmTHiJppJazrCWV9LeWuzBJeTscW3TfsPCMN9jH4Ci5DhsifFXrPG2XfEHNukL1NMnTEBDblf/Yai558Ymr0jGWSRKGHL8oBD3Ag0lmrsDy10lM8xWTSzHZtUbANRsgXe4om4FVgGwToo7WfVGMKt8rsJh3LVbCpoxc7eKXMoMXmJ9ps9UllBGuD37l6l2kYcR09PaZX1N449TgqTa/Bd4CX2r+2np0qxR7nqoericbVQuuyZcSGlWVp3LPTzW9gWwSGGZgOxzcscooZdaukcGWn6Hf0T5LCxVnlzu2tbXKvgz1xf1e5sv6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6178.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(39850400004)(346002)(376002)(33656002)(478600001)(83380400001)(55016002)(8676002)(2906002)(52536014)(8936002)(9686003)(186003)(91956017)(76116006)(26005)(558084003)(66476007)(5660300002)(66446008)(66556008)(66946007)(64756008)(4326008)(7696005)(86362001)(316002)(6916009)(54906003)(6506007)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: svQ8nEtw7YanQOCWi9vt33PIJkBQ6RJzMTQNpYP82gZDM1wvQ98Y2e5dlKpPRPnRIi1Hxlg9Nlb68XKVINdgHLYhV0aHyO6fI8rKGmGMCuhnT2jltXnZcXuuEbE+TBqP2BVFjhYQHqgjzPvBniWcmV8aolnD92ceXot0nwBNhoNoyzHeb0g2OoJn2TpYISSEtchNgCty8Tgr2WZEryz+WspRfpuUd+8S/qb6LfdjYoVYDCWx1w1e8uFo9NcV+vxKni+OoK0LJhedcXFD/czC5rCT4WaKrTh+KrDFkAT3rA3QrCLYbjhZ53OlsTx8vNuFDAdrSmVMwVQlAYy38pXOCHzYwqfexF0n24K2CHSAUnUhOqIGR9I+FuRT2zNdBru8Pweq4HgkocGqPa4FBpYarRHeUaCT7zztEo9AqspfcFTSu9i5rhMp7jLHzsgynTM/T+A09msbzfTVMe4dP9CHx4/XdggNQu799I/GCEVWWnSUQ6NOomaD6vjVq7edq5nhDmOERwsmkzzJr24hJcfJr7NgqcCS2Swz2dLuJ4Z3nxNgitFiH++AmZQTmdZWzcN3eastwlrb+sh58YfprETvmhrtIR1/M8eZ7AqF3Pcy9UYgXE5ZIWlKfYpqqSh6ghNIHpaq7O5pg/pPkZjYrw+BMQ== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6178.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c224683-a210-46ff-d603-08d8496639f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 02:17:48.0050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OZR8qcJP19vMKx9l3ND7xoX81xIwx5V7nP+kKBj71w4fOCEzw3d/fl63A7kKSZ7Zg55f/pKJFvGo/ARzIW1koQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7011 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 02:17:58 -0000 I support the publication of this draft as an RFC.=0A= I've closely followed the draft's progress/revisions based on feedback/disc= ussions at sidrops wg meetings.=0A= I feel that the draft in its current version is well written and in good sh= ape to advance.=0A= =0A= Sriram = From nobody Tue Aug 25 20:37: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 2BA5C3A0C45 for ; Tue, 25 Aug 2020 20:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=yahoo.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 dSAD325W_-og for ; Tue, 25 Aug 2020 20:37:39 -0700 (PDT) Received: from sonic302-7.consmr.mail.bf2.yahoo.com (sonic302-7.consmr.mail.bf2.yahoo.com [74.6.135.46]) (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 C6D2E3A0C42 for ; Tue, 25 Aug 2020 20:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1598413058; bh=5JzY9i3NRh0EkeYeD+StUa9Otz1bTOx09iqYn5h7Sps=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=nmvHKyOQOdY5WBMXtB1VoU52BcH/xqrjvH5t2lEGxDvCwKkqCjaaLLL5wdC6uYXX/opWAOabcGysqokmKSQMg+SLrg/B7+1mjAvGiUOIZW3tat7Z7bJZ9XwZzZa3x6XOoIkDhbCsWGHobkOKJtyLvWvs6kFm0+5TAnb1WIK/Hv/bYIwJ/Z+/TwI1AF/RP2euu6HaEmx9iHnABHsLEN1LHG8dxmhjLrB5MFivUYrf2bXVm9+c+8rElcfAgL6mROSZmaKgq8UrFEeyJcMyf3Qj1KdxU0ZASuQ45W3smXepxreX/w56GC7J63HaNRCBDmzIsjHhytZbGVli3QXifKw91A== X-YMail-OSG: hpKEjc0VM1nxgWdXMRZa1vSV7rS3JRZvsnifMjYjVaridStQFnVlZhP08nYwVYA _efYUSJx7O.yXInDfk7ESCKwqluByjHSttQjgqEXWNf8RXRiPQ6qP3FHJeKIk48be1PCNhW3xbJu M1lr6H_mQALifhN7xuRJvEu88fXwFom_a47ZrpbRKcuJP0QnmjX9GnjrFb2m0DsMqWehdd5..uEr 4bQ9CjtGEEq4kDaBL.X8MWfhZnXLWIh9a8PdvsAMiMbL43MMqO8j1Wd6X81fUtDZdspVq9N8O_23 iOx7Pl1qs8Md_NRYD5VnG8a1TC6zTGVf6sTbpan5oa_.Wwy.SbdsQIZa25J2dcQLL0.Kzwk_uP4_ noxRzR6cy_IR8RczCCoKLGizv7xATv6_C9eZGyHct_IuW47TtIDAR23kptNIDyNeDdjiMUT0TX2Z PcV2kO4uumI1U1v0belYCs_FxZJL.Q.jFH9mcLR8rO2REqVZnDyPrPV_ep6v.1p2hCCieWcgo.EZ u_yEElp03J45._2oY4wmkNYM_8ezDgpgCNZCjvT2ADHDKkzl0befsjAJsI1CSKURMAPPTsz_ntFG LABJgQwppFyiGBRyrBL7t9Pb3rpOeTYTj0BQgGSxMEacOJG4R8KFH298HZxByOudtgOlBRYpfW2u iMtWEFBFoFQ3oengwksm6teu6m1M3s_HA3ZlL3WGE3UcT1q_D28iJLs6K1jEh9vec4WRvMSgexlx h6WZ1lyFBHuut2fVVOX.01qcogrwY5qo_stmgJCwi15fMunQLk50MGbkl_kyJzgW9jMejOa345DZ xmkLaj4_mXa3nwuIiEG8xnLv.JFZ2AhhtThZMvwjmY6dbxifJMvyuKL10AoHyMu36YItq1PvRLoU MS_5X2bSWGJgp16rRKavXEvhR8ExvtuQBvobacr03vrZosp3InJVPn_YZFg.HDvGEO.uvvaRKwBP zUnn6b3IM.VpIp_FezQKjUWql9JUnNSSkZuNQnqsHXFuvCE33dxyjrbO_evPbbKWWPHrrcqMIYE_ vMz8mHklponYWEje7DWRgEFz2q4e99408dtQmijML7ocDsgL6lOeIn1Gl429u5.knOAHB417if2. tAhaB8c8vm6qfNiPzrZd8GA567kNAW2PdqS83BJWUJ.3M4eDVIAWAa8HNZUQR_YiupXXlAEzRFKe U_XxLiVrwrjSH25b7JH9EKjbQRL787WMHM9dkVwt1CrVRzwGJssbnAkx34Hdt0_FG5C5cXOVBVue rGmxrI8T4jeTemsqEWDM.Gi08f3nbtZ.8jK5pnBy9Ov4jeAbTxAl2jn99xUO322v_p6TQyoMyYzP .G.TPCegcJMag8xqKB8Cw60hMO10rR3wesrNEXaFMhLKbHXdTDT0CiGA.4GPyw3lZ91WUAnL7nUv b6LSha8AQeVn08R6qECjPB5gfTsX8zpfiKqYMUntM_Mct6NseCef3skKW4KyNSJXIoy2x.WfYCt9 UDQpWJm7L.nv5xO_u8jWO_7.zbF45dyzQ.ETX6aOK5iWiz0MBka2UDEee7q2GgNv52TL0PLwyqQ2 wU.peIoM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Aug 2020 03:37:38 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 369af9724c103115e246e24cc4912a68; Wed, 26 Aug 2020 03:37:33 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Tue, 25 Aug 2020 20:37:28 -0700 From: Mehmet Adalier To: "Sriram, Kotikalapudi (Fed)" , "keyur@arrcus.com" CC: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" Message-ID: <818F3B55-A061-40AA-BB9B-5CFC43068C25@antarateknik.com> Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> <94B06450-ED03-4AFD-B568-03AB60C8DF54@nist.gov> <8C5D0A4F-0A3C-4678-ACD4-D2183660641D@nist.gov> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 03:37:41 -0000 >From an industry perspective, I support the publication of this draft as an= RFC.=20 I have reviewed the draft in detail. It is quite solid and I believe it wil= l add value. Mehmet Adalier Antara Teknik LLC =EF=BB=BFOn 8/25/20, 7:18 PM, "Sidrops on behalf of Sriram, Kotikalapudi (Fed)" <= sidrops-bounces@ietf.org on behalf of kotikalapudi.sriram=3D40nist.gov@dmarc.i= etf.org> wrote: I support the publication of this draft as an RFC. I've closely followed the draft's progress/revisions based on feedback/= discussions at sidrops wg meetings. I feel that the draft in its current version is well written and in goo= d shape to advance. =20 Sriram =20 _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops =20 From nobody Wed Aug 26 00:31:24 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 025B93A0E83; Wed, 26 Aug 2020 00:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=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 Yu5blx0cxNY6; Wed, 26 Aug 2020 00:31:20 -0700 (PDT) Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0E83A0ED7; Wed, 26 Aug 2020 00:31:18 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.5350639|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.146335-0.00875556-0.84491; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03293; MF=madi@rpstir.net; NM=1; PH=DS; RN=4; RT=4; SR=0; TI=SMTPD_---.IO5gsLt_1598427069; Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.IO5gsLt_1598427069) by smtp.aliyun-inc.com(10.147.43.230); Wed, 26 Aug 2020 15:31:10 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: <87tux9xgk6.wl-morrowc@ops-netman.net> Date: Wed, 26 Aug 2020 15:31:09 +0800 Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <98DB209F-7B10-447E-B531-D80B9B074604@rpstir.net> References: <87tux9xgk6.wl-morrowc@ops-netman.net> To: Chris Morrow X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] [WG ADOPTION] rfc-8211-bis - Ends 2020-28-08 (Aug 28 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, 26 Aug 2020 07:31:23 -0000 I am in support of adoption of this work as the co-author of RFC 8211. Manifest is the fundamental signed object used by RFC 8211 to analyze = adverse actions that could happen in the RPKI.=20 We have no reason of not updating RFC 8211, provided that Manifest is = being updated as WG item. I will once again take part in this effort on threat model for the RPKI. Di > 2020=E5=B9=B48=E6=9C=8812=E6=97=A5 01:01=EF=BC=8CChris Morrow = =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 > Howdy WG Folks! > The authors of RFC8211 have prepared an update to their document: > https://tools.ietf.org/id/draft-kent-sidrops-8211bis-00.txt >=20 > The abstract being: > " This document analyzes actions by or against a Certification > Authority (CA) or an independent repository manager in the RPKI that > can adversely affect the Internet Number Resources (INRs) associated > with that CA or its subordinate CAs. The analysis is done from the > perspective of an affected INR holder. The analysis is based on > examination of the data items in the RPKI repository, as controlled > by a CA (or an independent repository manager) and fetched by = Relying > Parties (RPs). The analysis does not purport to be comprehensive; = it > does represent an orderly way to analyze a number of ways that = errors > by or attacks against a CA or repository manager can affect the RPKI > and routing decisions based on RPKI data." >=20 > the updates are meant to take into account the updated language in the > pending RFC6486-bis document. Let's have a read, decide if this should > be adopted by the WG for work/cleanup/refresh and have a decision back > to the list/authors as of 28/8/2020 - August 28 this year (2020). >=20 > Thanks! > -chris > co-chair-persona >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Wed Aug 26 02:55: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 3EEE33A0E29; Wed, 26 Aug 2020 02:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSXeZCfWb9wn; Wed, 26 Aug 2020 02:55:01 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1E23A0E24; Wed, 26 Aug 2020 02:55:00 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 07Q9smkE068032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2020 10:54:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: "Borchert, Oliver (Fed)" Cc: Keyur Patel , "sidrops@ietf.org" , Daniel Kopp , "Borchert, Oliver (Fed)" , "Montgomery, Douglas C. (Fed)" References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> From: Nick Hilliard Message-ID: Date: Wed, 26 Aug 2020 10:54:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.27 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 09:55:04 -0000 Oliver, the difficulty here is not that operators might be using this, it's whether these signals cross administrative boundaries. It's one thing to use this on your own network, and even though it's not something that I'd view as being a very good idea, there are two mitigating factors: 1. your network, your rules and 2. it's ibgp only which means that your interior routing infrastructure will get a full view of all routes and will be able to make informed routing decisions, where bgpsec signaled routes can be evaluated in context alongside other candidate routes. The difficulty here is applying this to EBGP. If this draft ends up as a standards track document, this is giving the process the IETF stamp of approval that this is a good idea and recommended practice. This is a very poor idea for the reasons which I've detailed previously. Nick Borchert, Oliver (Fed) wrote on 26/08/2020 01:11: > Nick, > > This point has been made in the past (about origin validation signaling) and I think it is a bit of a red herring. > > Operators can and are signaling validation state today with ad-hoc use of communities. Operators do this for multiple reasons, including providing some resilience to the system should a router lose access to validating caches, to detect and diagnose RPKI state skew among routers in the same network etc. Not having a standardized encoding of this practice won't be the determining factor of how this kind of signaling is used. > > In the case of BGPsec, the need for diagnostics and resilience will be even higher. Remember there is no "not found" in BGPsec to fall back to loss of contact with RPKI data. If such signaling also facilitated performance optimizations or implementation of consistent policy decisions on routers that have deferred their own validation procedures, it actually might encourage more deployment than discourage it as you suggest. > > In short, I see such mechanisms as supporting and encouraging deployment of these technologies - or at worse being a non-factor to the adoption question - as those who want to do this in non-standard ways will just continue to do so. > > Oliver > > ----------------------------------------------- > Oliver Borchert, Computer Scientist > National Institute of Standards and Technology > (Office) +1.301.975.4856 > (GVoice) +1.240.668.4117 > > > On 8/11/20, 4:59 PM, "Sidrops on behalf of Nick Hilliard" wrote: > > Keyur Patel wrote on 11/08/2020 19:45: > > A working group last call has been requested for > > draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State > > signaling”. Please reply to the list with your comments. The WGLC will end > > on August 25, 2020. > > In general, replicating validation functionality using BGP communities > is a poor idea and from an ops point of view, it seems wiser as a long > term objective to push vendors to support bgpsec than to implement hacks > like this. For this reason I don't support publication of the draft as > an rfc. > > Major issues: > > 1. The draft lacks a problem statement and a sunset clause. > > 2. Previously there's been a good deal of discussion on sidrops about > RPKI validation state signalling. Several problems were listed here: > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fsidrops%2FYV1WfoxQNiwfOjtKIY1d6YJjRxM%2F&data=02%7C01%7Coliver.borchert%40nist.gov%7Cf3710792241d4bae15bc08d83e397d8c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637327763936298280&sdata=jfbGfpeLvSkbjjMYjIxzHtKA%2BmW3l%2B6Esky8QGrw1NQ%3D&reserved=0 > > Most of the problems associated with validation state signalling > identified in that email also apply to bgpsec validation state > signalling, namely: > > - crypto authentication is lost > - different and incompatible set of signalling hooks > > In particular all the problems associated with RPKI validation state > signalling over eBGP also apply to bgpsec state signalling over eBGP. > > Defining this as non-transitive is a good start, but the language needs > to change to ensure that it cannot escape an ASN. Can I suggest the > following text changes: > > change: > > If the router supports the extension as defined in this document, it > > SHOULD attach the BGPsec path validation state extended community to > > BGPsec UPDATE messages sent to BGP peers by mapping the locally > > computed validation state into the last octet of the extended > > community. This SHOULD be done automatically for iBGP peers and > > configurable for eBGP peers (see below). > > to: > > If the router supports the extension as defined in this document, it > > SHOULD attach the BGPsec path validation state extended community to > > BGPsec UPDATE messages sent to iBGP peers by mapping the locally > > computed validation state into the last octet of the extended > > community. > > and change: > > By default, routers SHOULD enable use of this > > community on all iBGP sessions and routers SHOULD disable the use of > > this community on all eBGP sessions. Implementations MUST NOT send > > more than one instance of the origin validation state extended > > community and MUST drop (without processing) the BGPsec path > > validation state extended community if received over an External BGP > > (eBGP) peering session that has not be explicitly configured to > > enable processing. > > to: > > By default, routers SHOULD enable use of this > > community on all iBGP sessions. Implementations MUST NOT send > > more than one instance of the origin validation state extended > > community, MUST NOT attach the BGPsec path validation state extended > > community to BGPsec UPDATE messages sent to eBGP peers and MUST drop > > (without processing) the BGPsec path validation state extended community > > if received over an eBGP peering session. > Nick > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=02%7C01%7Coliver.borchert%40nist.gov%7Cf3710792241d4bae15bc08d83e397d8c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637327763936298280&sdata=auM0IyvMSRptpkD2LVEWInQIJqTEanKyc4b%2BElrTEHc%3D&reserved=0 > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > From nobody Wed Aug 26 03:25:48 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 44CD63A0A40 for ; Wed, 26 Aug 2020 03:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7klUQsRtj7X for ; Wed, 26 Aug 2020 03:25:44 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0AA3A09A6 for ; Wed, 26 Aug 2020 03:25:43 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0024718A82; Wed, 26 Aug 2020 12:25:39 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Wed, 26 Aug 2020 12:25:39 +0200 From: Martin Hoffmann To: Stephen Kent , SIDR Operations WG Message-ID: <20200826122539.52493813@glaurung.nlnetlabs.nl> In-Reply-To: <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 10:25:46 -0000 Hi Steve, looks like you forgot to include the mailing list, so I=E2=80=99ll keep the quote in full. Stephen Kent wrote: > Martin, > > Stephen Kent wrote: =20 > >> =20 > >> Are you positing the case where the cache contains an expired ROA > >> for a CA instance, and a fetch that would have replaced the > >> expired ROA fails? =20 > > No, I am talking about a case where the ROA can be fetched > > successfully and matches the manifest hash, but its EE certificate > > is expired. Section 6.4 says that "if [files] fail the validity > > tests specified in [RFC6488]", the fetch has failed. Thus, the > > expired EE certificate in the ROA fails the complete fetch of all > > objects associated with the CA. =20 > Thanks for the clarification. > > So, not replacing an expired ROA in a publication point makes the > > entire CA not update anymore. I.e., any other objects that now > > expire cannot be replaced until that ROA is also replaced. =20 > "not update anymore" is not how I would state the result. This fetch=20 > will fail. Because a failed fetch will be reported to the RP > operations staff, hopefully they will contact the cognizant entity > for the pub point in question, causing the error to be fixed. Them a > subsequent fetch can succeed. That seems like an overly optimistic approach to the issue. Assume the problem is created by a bug or, worse, design oversight in the CA software. The turnaround from discovering the issue to deploying a fix can easily be weeks with some vendors. During all that time, not only can no ROAs be updated and may child CA certificates slowly expire, the entire CA=E2=80=99s data will not be available at all for any newly deployed relying parties. With containerised deployment, this is quite a serious issue. As a consequence, this approach will make the routing system less secure for, I=E2=80=99d like to argue, no actual gain. > > You could argue =E2=80=9CDon=E2=80=99t do that, then=E2=80=9D but this = approach doesn=E2=80=99t make > > the RPKI more robust but rather makes it break more easily on simple > > oversights. =20 > My sense of the WG discussion was that the majority of=C2=A0 folks chose > to prioritize correctness over robustness, and I made numerous > changes to the text to reflect that. I disagree with the blanket assessment that this approach makes RPKI more correct. To switch to the example I should have used in the first place: Ignoring a broken GBR object when producing a list of VRPs does not make the list less correct. In fact, the opposite is true: Ignoring the CA or updates to the CA because of a broken GBR makes this list less correct. > >> If a manifest points to objects that are not CRLs, certs, ROAs, > >> etc., then it is in error. =20 > > How do you introduce new object types in this case? There will > > always be relying parties that run old software that doesn=E2=80=99t kn= ow > > of them. You rather have to assume that objects of unknown types > > are signed objects with unknown content. If you do that, the > > current draft stipulates that you have to read, parse, and validate > > them -- and then throw away the content. > > > > This still means that all object types added to the RPKI must be > > signed objects. Whether that is okay or not, I don=E2=80=99t quite know= . =20 >=20 > Yes, all objects in the RPKI are always signed! >=20 > But, you first question raises a valid point, i.e., we do not have a=20 > generic description of how new objects types are to be introduced in > a graceful fashion (wrt RP processing). I am not sure that one > can/should amend 6486bis to address this topic. You absolutely have to deal with this issue in 6486bis in its current strict form. Any introduction of a new object type will permanently break CAs that use these objects when validated with a relying party software that is not aware of this type. I don=E2=80=99t think this is acceptable, as it effectively blocks the introduction of new types pretty much forever. > Instead I believe it > makes sense for any new object proposed for inclusion in the RPKI > repository system to address this question as part of its > documentation; it's not clear that a uniform approach is appropriate, > i.e., one size may not fit all. 6486 can be updated to reflect the > processing approach proposed for any new objects. It seems to me that the best approach is to simply ignore unknown objects. We could argue whether they can be ignored completely or whether one should at least check their manifest hash. Personally, I think completely ignoring is the better approach as I don=E2=80=99t see any benefit in rejecting a CA because someone swapped out an object I don=E2=80= =99t care about. Ultimately, I feel we=E2=80=99ve swung the pendulum way too far to the other side. The RPKI isn=E2=80=99t a single data set that needs to synchronized in full but it consists of multiple data sets that can be treated as independent: currently these are VRPs, router keys, and GBRs. If I use the RPKI for route origin validation, I don=E2=80=99t need to synchronize t= he router keys or GBRs. Why does it improve route origin validation if available and correctly signed data is skipped because of issues with irrelevant data? > >> But, your question seems to be what processing > >> has to be performed on the files contained in an apparently valid > >> manifest, right? Section 6.4 and RFC 6488 defines the tests to be > >> performed, and 6.4 explicitly cites 6488. What additional info do > >> you feel is needed here? =20 > > I would like the document to explicitly state how to deal with > > object types appearing on a manifest that a replying party does not > > know. If nothing else then to make the document more helpful for > > implementers. =20 > At this time the types of objects that may legitimately appear in a=20 > manifest is small and well-defined. Any other objects would result in > a fatch failure. > >>> But I=E2=80=99m not even sure it provides any benefit. I, say, I am > >>> validating a resource tagged association (RTA, [0]), I don=E2=80=99t = care > >>> about the ROAs at all. Does the RTA become invalid because a CA > >>> somewhere in the validation chain had an expired ROA? =20 > >> I have not examined the RTA ID, and it's an expired draft, so ... =20 > > RTA validates signed objects distributed via alternative means using > > the PKI published as part of the RPKI. I.e., one of the CA > > certificates published via the RPKI has issued the EE certificate > > used in that signed object. > > > > In order to validate that object, I do not need to look at any ROAs > > or GBRs, only certificates, CRLs, and manifests. =20 > According to George, the RTA carries it own, complete cert path, so=20 > certs and CRLs stored in the repository system are irrelevant, and,=20 > George noted that the RTA was designed to not require distribution > via the repository system, so it's not relevant example. > > Should validation of that object fail if there is an expired ROA > > published by one of the CAs along the validation chain? =20 >=20 > As I noted above, an RTA is not relevant to this discussion, based on=20 > George's description of its design and intent. >=20 > Steve Kind regards, Martin From nobody Wed Aug 26 05:25: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 47BFC3A1245 for ; Wed, 26 Aug 2020 05:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 lSi8-3G9FY0R for ; Wed, 26 Aug 2020 05:25:37 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FF53A1243 for ; Wed, 26 Aug 2020 05:25:36 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:a56f:53c5:813:7a44]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2BC7E18C97; Wed, 26 Aug 2020 14:25:34 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598444734; bh=ZnvPg+i6PW0wvgO8F5YG6Zry/+iOeXOFeSBg+bfvGf0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hPFUlU5ClDeJrZzuFj0N32k/2mqAgE8mVx6FJF+cKs/mqriwekWhr+RWgauORfkVo XiuF7Pjhi61LqAIJd2cCdmxpvu65+GlDljwpU9hEAJScArzTY1nYOiyBKn+3+0toNV yRQCgFUNxfIPhEQ8tTof60hBULN5ocgjaNVswwJw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: <20200826122539.52493813@glaurung.nlnetlabs.nl> Date: Wed, 26 Aug 2020 14:25:33 +0200 Cc: Stephen Kent , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <11EA0403-E4F3-45B0-9231-1CD4DFB0690E@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> To: Martin Hoffmann X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 12:25:38 -0000 > On 26 Aug 2020, at 12:25, Martin Hoffmann = wrote: >=20 > Hi Steve, >=20 > looks like you forgot to include the mailing list, so I=E2=80=99ll = keep the > quote in full. >=20 > Stephen Kent wrote: >> Martin, >>> Stephen Kent wrote: =20 >>>>=20 >>>> Are you positing the case where the cache contains an expired ROA >>>> for a CA instance, and a fetch that would have replaced the >>>> expired ROA fails? =20 >>> No, I am talking about a case where the ROA can be fetched >>> successfully and matches the manifest hash, but its EE certificate >>> is expired. Section 6.4 says that "if [files] fail the validity >>> tests specified in [RFC6488]", the fetch has failed. Thus, the >>> expired EE certificate in the ROA fails the complete fetch of all >>> objects associated with the CA. =20 >> Thanks for the clarification. >>> So, not replacing an expired ROA in a publication point makes the >>> entire CA not update anymore. I.e., any other objects that now >>> expire cannot be replaced until that ROA is also replaced. =20 >> "not update anymore" is not how I would state the result. This fetch=20= >> will fail. Because a failed fetch will be reported to the RP >> operations staff, hopefully they will contact the cognizant entity >> for the pub point in question, causing the error to be fixed. Them a >> subsequent fetch can succeed. >=20 > That seems like an overly optimistic approach to the issue. Assume the > problem is created by a bug or, worse, design oversight in the CA > software. The turnaround from discovering the issue to deploying a fix > can easily be weeks with some vendors. During all that time, not only > can no ROAs be updated and may child CA certificates slowly expire, = the > entire CA=E2=80=99s data will not be available at all for any newly = deployed > relying parties. With containerised deployment, this is quite a = serious > issue. >=20 > As a consequence, this approach will make the routing system less > secure for, I=E2=80=99d like to argue, no actual gain. I believe that manifest should tell me that I have *all* *latest* = objects. If there is stuff missing then rejecting the publication point = is fine by me. But I have a problem with doing the same if invalid = objects are found. In addition to what Martin said. This makes the system very brittle = w.r.t. changes in resources. Suppose that I had received 10.0.0.0/24 and = 192.168.0.0/24 on my certificate issued to me by my parent, and I = created ROAs for both. Now my parent pro-actively removes 10.0.0.0/24 = from my certificate but they have neglected to tell me in time. I see no = reason why my ROA for 192.168.0.0/24 should now be considered invalid. = And I remember that we had discussions in this WG advocating that = separate ROAs are created for each prefix, precisely to prevent this = kind of fate sharing. Tim From nobody Wed Aug 26 07:06: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 F40423A14A1 for ; Wed, 26 Aug 2020 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDALaKNoSe0C for ; Wed, 26 Aug 2020 07:06:31 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2113.outbound.protection.outlook.com [40.107.89.113]) (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 E1B453A149E for ; Wed, 26 Aug 2020 07:06:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ngm51JsNpkUGDYaCESuIWOx8SvGJUgr4hyDemcZTXoXh9xiMJ+AnCvCC0Z7P/aMxqWjb2+1dvI1m13DucG2PuKFqZDdeU4ogYerCg8bSE/YsR4B9ESJLRa4VMAxxG2wfxuGe3/pzOsWjLaUnTxPPmi8WDmECqSs9nyrxPELgThXzGmpc7IW+ICSMD76noyIuUBOKXBlkjQhvdhkf+pJTRdjPpRiMJS9xcqSnj0zOkUPm9XiScH8cdGoQaOAuYNPvMF24+spXi/ia27ZWldhuWa7bBsllxRXcN71kqCuOqfywSfjEvvR1ecBTwBvj9WLtunbUU+8uLhZXFCq6h1CuYQ== 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=n/NgWdBO+iAoz/mFKQsVHODBC0g+XL4RLdmzVAXv37c=; b=FV0JsSkyF6DtUlPniY8o3N1E145/NYwg/Qf3XNNu4kLN8Gs61BabTxxL9RuFuRMf1hydzNiG013szREf/KXEHvwxGZ0jRdEDQYGIiZzU3Og7DBLmP9utgNImr5Jfw0S8xnGT1scupP16wVrd4V+PAUFcIav/zdNVtdqzNADVY5eehviSJQZEra8b7hyG1YZoXhX2Zb4byvjwtBoibBYvE0IUESoU/mvxdX2WNMsLG0wKCz3UijKM9iI6QEnTrWNI7WnBOXBmc9s2fC2Kui8TRV8PLElvu+k+dMzzuUXQAbhaEgw2JOgxMgXb8l2rBRWYiqej+9sYMKKuz5EGWph4vA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n/NgWdBO+iAoz/mFKQsVHODBC0g+XL4RLdmzVAXv37c=; b=ZnoxdPWTi03SZ2KyYInUTTz2Kk1vjeRHgYMvqfv1+SdKtcte+TUhYiC1MyoluJ9sJwDD79gbUHIwIVaOh5oR7mK1VhmTQQrgjdAa61CaS5nubURDaNWkiEl86OmmhCNxalLHzZ0yHamWcScIZjkpzZJ4vH2leAQwod9sUjlcFYk= Received: from MN2PR09MB4860.namprd09.prod.outlook.com (2603:10b6:208:210::9) by MN2PR09MB5962.namprd09.prod.outlook.com (2603:10b6:208:21e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Wed, 26 Aug 2020 14:06:20 +0000 Received: from MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::ccb2:2b51:445e:77fe]) by MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::ccb2:2b51:445e:77fe%3]) with mapi id 15.20.3326.019; Wed, 26 Aug 2020 14:06:20 +0000 From: "Montgomery, Douglas C. (Fed)" To: Nick Hilliard , "Borchert, Oliver (Fed)" CC: Keyur Patel , "sidrops@ietf.org" , Daniel Kopp , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020 Thread-Index: AQHWcA+HFL2ap5d5eEGUfZX0DE6/EKkzY/mAgBXzwICAAOYEgIAAAzmA Date: Wed, 26 Aug 2020 14:06:20 +0000 Message-ID: <4546E616-2B93-4612-AC8E-F9039FEB7F60@nist.gov> References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20082300 authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:197::db] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 60960a0b-595b-41b4-e0f9-08d849c93570 x-ms-traffictypediagnostic: MN2PR09MB5962: x-ms-exchange-transport-forked: True 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: aF1aBBzIDagGtWzBEZZtrGx6sJN63AicFk0Ze/N5bOC8roDyBJvv9cu6dU7HDeLPKs/+T8PnmL6602n39BLrvY4uEbejSKnxgX3DLaeWRxq7IhF6fwAA2l28JwQjpRyslb80QkBmF6KOOxhiiQNYcfCOTesxIWXw/hDVug7MIr4S+0JyrvYsiKktWCZLihXGaxdTLLUrW97pfnfSn6rDCmPR/BpL/hZahbshuIThZPnm+igHxEakyxtx7p66J+F5urslQHdY/4oNSRBTA0jzkHJ7eZny6ei0GNwcx2PPchbeE9XZg5omTfaSHNnhR1Iqmwz25Vmr1eRJ4vbsKW1GBpZSIBS1L70LWD4Bj5rBrvj+qBJMhuayMUKbTphFVTFn+g3qdYhSE66eL/bNYw39gQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4860.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(39860400002)(346002)(376002)(86362001)(316002)(91956017)(66946007)(76116006)(54906003)(66476007)(66556008)(64756008)(66446008)(966005)(478600001)(110136005)(5660300002)(6512007)(4326008)(45080400002)(2616005)(107886003)(6506007)(36756003)(8676002)(53546011)(8936002)(33656002)(6486002)(71200400001)(186003)(83380400001)(2906002)(66574015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7rD2OsorvUBhXCFgP0kj7S3H7Dfw2EekFtrNmfmN65qM/yWI2iaZKKBqZALGCO8sUVCh2JwUeIupVuwOmwtF+SYVl1JqgVUJ/Gets33bS1qCyQDOX+BvLWUFCb2H7wwY4GDV9peu1Al803QN5pPo8Gv5+IG9N/gx9qIRqazHlSRwkhS83PjdkaTeJX0fxtckogp7DvgUZpsz1uZ8w00QIu0BYP9GfDInq1acRf6IIwduBV65PtMLYrc6F0yXMaM2tyGQU+ye8VoxxzHuXhpWpfqALTg7h/yYjSSJ4UMPDAIc9sKWuUN//rajjw4RRC7e5+EucpbBLxz0E5cTQRFhmiKRLvlMWK9PCtf4AsYk6WQ9ikEO2xPMMz4D9KSujzMTSmHWtz6WPBSCwnBSXlk7vDFKqm1rACZPBlXjVhgDcNILiy31IGnGgFKIN78O+OdZGxKCSj+H2J8zZjB7wi3MrNdXLAG930/gaJTFkheoYepyA1HNsFCYe/ifFmAlm6SylMytQJF09kWQ7MbUu5+h2fjHkggOM53UZsIsCdGRCyB1OWnKZPXcnfL8VxX+AEMZ+JP4FhYslCXnts7Di5YhKbhSTTmYjSF1wHbaLVMGM7KI155p2gS2UaHmGLOlB2Uj3pxu75wo+6czxBqh641Js1jDzS+YulGCpPoQSwkZ3DU= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4860.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60960a0b-595b-41b4-e0f9-08d849c93570 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 14:06:20.4499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5n2ia48o4C2CgHG8y9dlcXKV07VqJ9IOtTrZdgABJJciYbiIkZ7zLhgBQBEzKAeM X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5962 Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 14:06:33 -0000 TmljaywNCg0KSSB0aGluayB0aGF0IGNhbiBhbmQgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gIA0KDQpUaGUgc3BlYyBtYW5kYXRlcyB0 aGF0IHRoZSBzaWduYWwgYmUgbm9uLXRyYW5zaXRpdmUgLSBpdCBvbmx5IHByb3ZpZGVzIGluc2ln aHQgYXMgdG8gdGhlIHZhbGlkYXRpb24gcmVzdWx0IG9mIHlvdXIgaW1tZWRpYXRlIHBlZXIuDQoN CkhhdmluZyBzYWlkIHRoYXQsIGhlcmUgYXJlIHRob3NlIHRoYXQgZmVlbCB0aGlzIGZ1bmN0aW9u YWxpdHksIGVzcGVjaWFsbHkgaW4gdGhlIGNhc2Ugb2YgQkdQc2VjLCBwcm92aWRlcyB1c2VmdWwg ZnVuY3Rpb25hbGl0eSwgdGhhdCBpbmNyZWFzZXMgdGhlIHJlc2lsaWVuY2Ugb2YgdGhlIGVudGly ZSBzeXN0ZW0sIGFuZCBwcm92aWRlcyBhIG11Y2gtbmVlZGVkIGRpYWdub3N0aWMgY2FwYWJpbGl0 eSAoZm9yIG9wZXJhdGlvbnMgYW5kIG1vbml0b3JpbmcgaW5mcmFzdHJ1Y3R1cmVzKS4gIA0KDQpJ IHN1c3BlY3QgY29uY2VybnMgb2YgYnJpdHRsZW5lc3MgYW5kIGxhY2sgb2YgZGlhZ25vc3RpY3Mg YXJlIG1vcmUgb2YgYW4gaW1wZWRpbWVudCB0byBhZG9wdGlvbiB0aGFuIGNvbmNlcm5zIGFib3V0 IGRpc3RyaWJ1dGVkIHRydXN0IG1vZGVscy4NCg0KVGhlIG90aGVyIGNob2ljZSBpcyB0aGF0IG9w ZXJhdG9ycyB3aWxsIHN0aWxsIGRvIHRoaXMgaW4gbm9uLXN0YW5kYXJkIHdheXMgYW5kIHdlIHdp bGwgbG9zZSB0aGUgb3Bwb3J0dW5pdHkgdG8gbGV2ZXJhZ2UgdGhlIHBvdGVudGlhbCByb2J1c3Ru ZXNzIGFuZCBkaWFnbm9zdGljIGJlbmVmaXRzLg0KDQpJbiBnZW5lcmFsLCBJIHRoaW5rIHRoZSBz dXBwb3NpdGlvbiB0aGF0IHdlIHdpbGwgc29tZWhvdyBpbmZsdWVuY2UgLyBjb25zdHJhaW4gaW1w bGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgYXJjaGl0ZWN0dXJlcyBieSBub3Qgc3BlY2lmeWlu ZyBzaW1wbGUgbWVjaGFuaXNtcyBzdWNoIGFzIHRoaXMsIGlzIGFscmVhZHkgcHJvdmVuIHRvIGJl IGZhbHNlLg0KDQpkb3VnbQ0KLS0NCkRvdWdNIEAgTklTVA0KDQrvu79PbiA4LzI2LzIwLCA1OjU1 IEFNLCAiTmljayBIaWxsaWFyZCIgPG5pY2tAZm9vYmFyLm9yZz4gd3JvdGU6DQoNCiAgICBPbGl2 ZXIsDQoNCiAgICB0aGUgZGlmZmljdWx0eSBoZXJlIGlzIG5vdCB0aGF0IG9wZXJhdG9ycyBtaWdo dCBiZSB1c2luZyB0aGlzLCBpdCdzIA0KICAgIHdoZXRoZXIgdGhlc2Ugc2lnbmFscyBjcm9zcyBh ZG1pbmlzdHJhdGl2ZSBib3VuZGFyaWVzLiAgSXQncyBvbmUgdGhpbmcgDQogICAgdG8gdXNlIHRo aXMgb24geW91ciBvd24gbmV0d29yaywgYW5kIGV2ZW4gdGhvdWdoIGl0J3Mgbm90IHNvbWV0aGlu ZyB0aGF0IA0KICAgIEknZCB2aWV3IGFzIGJlaW5nIGEgdmVyeSBnb29kIGlkZWEsIHRoZXJlIGFy ZSB0d28gbWl0aWdhdGluZyBmYWN0b3JzOiAxLiANCiAgICB5b3VyIG5ldHdvcmssIHlvdXIgcnVs ZXMgYW5kIDIuIGl0J3MgaWJncCBvbmx5IHdoaWNoIG1lYW5zIHRoYXQgeW91ciANCiAgICBpbnRl cmlvciByb3V0aW5nIGluZnJhc3RydWN0dXJlIHdpbGwgZ2V0IGEgZnVsbCB2aWV3IG9mIGFsbCBy b3V0ZXMgYW5kIA0KICAgIHdpbGwgYmUgYWJsZSB0byBtYWtlIGluZm9ybWVkIHJvdXRpbmcgZGVj aXNpb25zLCB3aGVyZSBiZ3BzZWMgc2lnbmFsZWQgDQogICAgcm91dGVzIGNhbiBiZSBldmFsdWF0 ZWQgaW4gY29udGV4dCBhbG9uZ3NpZGUgb3RoZXIgY2FuZGlkYXRlIHJvdXRlcy4NCg0KICAgIFRo ZSBkaWZmaWN1bHR5IGhlcmUgaXMgYXBwbHlpbmcgdGhpcyB0byBFQkdQLiAgSWYgdGhpcyBkcmFm dCBlbmRzIHVwIGFzIA0KICAgIGEgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LCB0aGlzIGlzIGdp dmluZyB0aGUgcHJvY2VzcyB0aGUgSUVURiBzdGFtcCBvZiANCiAgICBhcHByb3ZhbCB0aGF0IHRo aXMgaXMgYSBnb29kIGlkZWEgYW5kIHJlY29tbWVuZGVkIHByYWN0aWNlLiAgVGhpcyBpcyBhIA0K ICAgIHZlcnkgcG9vciBpZGVhIGZvciB0aGUgcmVhc29ucyB3aGljaCBJJ3ZlIGRldGFpbGVkIHBy ZXZpb3VzbHkuDQoNCiAgICBOaWNrDQoNCiAgICBCb3JjaGVydCwgT2xpdmVyIChGZWQpIHdyb3Rl IG9uIDI2LzA4LzIwMjAgMDE6MTE6DQogICAgPiBOaWNrLA0KICAgID4gDQogICAgPiBUaGlzIHBv aW50IGhhcyBiZWVuIG1hZGUgaW4gdGhlIHBhc3QgKGFib3V0IG9yaWdpbiB2YWxpZGF0aW9uIHNp Z25hbGluZykgYW5kIEkgdGhpbmsgaXQgaXMgYSBiaXQgb2YgYSByZWQgaGVycmluZy4NCiAgICA+ IA0KICAgID4gT3BlcmF0b3JzIGNhbiBhbmQgYXJlIHNpZ25hbGluZyB2YWxpZGF0aW9uIHN0YXRl IHRvZGF5IHdpdGggYWQtaG9jIHVzZSBvZiBjb21tdW5pdGllcy4gIE9wZXJhdG9ycyBkbyB0aGlz IGZvciBtdWx0aXBsZSByZWFzb25zLCBpbmNsdWRpbmcgcHJvdmlkaW5nIHNvbWUgcmVzaWxpZW5j ZSB0byB0aGUgc3lzdGVtIHNob3VsZCBhIHJvdXRlciBsb3NlIGFjY2VzcyB0byB2YWxpZGF0aW5n IGNhY2hlcywgdG8gZGV0ZWN0IGFuZCBkaWFnbm9zZSBSUEtJIHN0YXRlIHNrZXcgYW1vbmcgcm91 dGVycyBpbiB0aGUgc2FtZSBuZXR3b3JrIGV0Yy4gICBOb3QgaGF2aW5nIGEgc3RhbmRhcmRpemVk IGVuY29kaW5nIG9mIHRoaXMgcHJhY3RpY2Ugd29uJ3QgYmUgdGhlIGRldGVybWluaW5nIGZhY3Rv ciBvZiBob3cgdGhpcyBraW5kIG9mIHNpZ25hbGluZyBpcyB1c2VkLg0KICAgID4gDQogICAgPiBJ biB0aGUgY2FzZSBvZiBCR1BzZWMsIHRoZSBuZWVkIGZvciBkaWFnbm9zdGljcyBhbmQgcmVzaWxp ZW5jZSB3aWxsIGJlIGV2ZW4gaGlnaGVyLiAgUmVtZW1iZXIgdGhlcmUgaXMgbm8gIm5vdCBmb3Vu ZCIgaW4gQkdQc2VjIHRvIGZhbGwgYmFjayB0byBsb3NzIG9mIGNvbnRhY3Qgd2l0aCBSUEtJIGRh dGEuICBJZiBzdWNoIHNpZ25hbGluZyBhbHNvIGZhY2lsaXRhdGVkIHBlcmZvcm1hbmNlIG9wdGlt aXphdGlvbnMgb3IgaW1wbGVtZW50YXRpb24gb2YgY29uc2lzdGVudCBwb2xpY3kgZGVjaXNpb25z IG9uIHJvdXRlcnMgdGhhdCBoYXZlIGRlZmVycmVkIHRoZWlyIG93biB2YWxpZGF0aW9uIHByb2Nl ZHVyZXMsIGl0IGFjdHVhbGx5IG1pZ2h0IGVuY291cmFnZSBtb3JlIGRlcGxveW1lbnQgdGhhbiBk aXNjb3VyYWdlIGl0IGFzIHlvdSBzdWdnZXN0Lg0KICAgID4gDQogICAgPiBJbiBzaG9ydCwgSSBz ZWUgc3VjaCBtZWNoYW5pc21zIGFzIHN1cHBvcnRpbmcgYW5kIGVuY291cmFnaW5nIGRlcGxveW1l bnQgb2YgdGhlc2UgdGVjaG5vbG9naWVzIC0gb3IgYXQgd29yc2UgYmVpbmcgYSBub24tZmFjdG9y IHRvIHRoZSBhZG9wdGlvbiBxdWVzdGlvbiAtIGFzIHRob3NlIHdobyB3YW50IHRvIGRvIHRoaXMg aW4gbm9uLXN0YW5kYXJkIHdheXMgd2lsbCBqdXN0IGNvbnRpbnVlIHRvIGRvIHNvLg0KICAgID4g DQogICAgPiBPbGl2ZXINCiAgICA+IA0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IE9saXZlciBCb3JjaGVydCwgQ29tcHV0ZXIgU2Np ZW50aXN0DQogICAgPiBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9s b2d5DQogICAgPiAoT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCiAgICA+IChHVm9pY2UpICsxLjI0 MC42NjguNDExNw0KICAgID4gICANCiAgICA+IA0KICAgID4gT24gOC8xMS8yMCwgNDo1OSBQTSwg IlNpZHJvcHMgb24gYmVoYWxmIG9mIE5pY2sgSGlsbGlhcmQiIDxzaWRyb3BzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIG5pY2tAZm9vYmFyLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+ ICAgICAgS2V5dXIgUGF0ZWwgd3JvdGUgb24gMTEvMDgvMjAyMCAxOTo0NToNCiAgICA+ICAgICAg PiBBIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3INCiAgICA+ ICAgICAgPiBkcmFmdC1zaWRyb3BzLWJncHNlYy12YWxpZGF0aW9uLXNpZ25hbGluZy0wMywg4oCc QkdQc2VjIFZhbGlkYXRpb24gU3RhdGUNCiAgICA+ICAgICAgPiBzaWduYWxpbmfigJ0uIFBsZWFz ZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5k DQogICAgPiAgICAgID4gb24gQXVndXN0IDI1LCAyMDIwLg0KICAgID4gDQogICAgPiAgICAgIElu IGdlbmVyYWwsIHJlcGxpY2F0aW5nIHZhbGlkYXRpb24gZnVuY3Rpb25hbGl0eSB1c2luZyBCR1Ag Y29tbXVuaXRpZXMNCiAgICA+ICAgICAgaXMgYSBwb29yIGlkZWEgYW5kIGZyb20gYW4gb3BzIHBv aW50IG9mIHZpZXcsIGl0IHNlZW1zIHdpc2VyIGFzIGEgbG9uZw0KICAgID4gICAgICB0ZXJtIG9i amVjdGl2ZSB0byBwdXNoIHZlbmRvcnMgdG8gc3VwcG9ydCBiZ3BzZWMgdGhhbiB0byBpbXBsZW1l bnQgaGFja3MNCiAgICA+ICAgICAgbGlrZSB0aGlzLiAgRm9yIHRoaXMgcmVhc29uIEkgZG9uJ3Qg c3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGUgZHJhZnQgYXMNCiAgICA+ICAgICAgYW4gcmZjLg0K ICAgID4gDQogICAgPiAgICAgIE1ham9yIGlzc3VlczoNCiAgICA+IA0KICAgID4gICAgICAxLiBU aGUgZHJhZnQgbGFja3MgYSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgYSBzdW5zZXQgY2xhdXNlLg0K ICAgID4gDQogICAgPiAgICAgIDIuIFByZXZpb3VzbHkgdGhlcmUncyBiZWVuIGEgZ29vZCBkZWFs IG9mIGRpc2N1c3Npb24gb24gc2lkcm9wcyBhYm91dA0KICAgID4gICAgICBSUEtJIHZhbGlkYXRp b24gc3RhdGUgc2lnbmFsbGluZy4gIFNldmVyYWwgcHJvYmxlbXMgd2VyZSBsaXN0ZWQgaGVyZToN CiAgICA+IA0KICAgID4gICAgICA+IGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJj aCUyRm1zZyUyRnNpZHJvcHMlMkZZVjFXZm94UU5pd2ZPanRLSVkxZDZZSmpSeE0lMkYmYW1wO2Rh dGE9MDIlN0MwMSU3Q2RvdWdtJTQwbmlzdC5nb3YlN0NjZGNjZDNlNGZlYWM0MTNlNWVkZDA4ZDg0 OWE2MWM5NSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzcz NDAzMjUxMTE0OTIwMzAmYW1wO3NkYXRhPUpINmc0NGhzMnVtbnptcklwVUV3SDBzTjRoJTJCcHZ0 dnFNRmclMkZpeUdrZmtnJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgPiANCiAgICA+ICAgICAgTW9z dCBvZiB0aGUgcHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIHZhbGlkYXRpb24gc3RhdGUgc2lnbmFs bGluZw0KICAgID4gICAgICBpZGVudGlmaWVkIGluIHRoYXQgZW1haWwgYWxzbyBhcHBseSB0byBi Z3BzZWMgdmFsaWRhdGlvbiBzdGF0ZQ0KICAgID4gICAgICBzaWduYWxsaW5nLCBuYW1lbHk6DQog ICAgPiANCiAgICA+ICAgICAgLSBjcnlwdG8gYXV0aGVudGljYXRpb24gaXMgbG9zdA0KICAgID4g ICAgICAtIGRpZmZlcmVudCBhbmQgaW5jb21wYXRpYmxlIHNldCBvZiBzaWduYWxsaW5nIGhvb2tz DQogICAgPiANCiAgICA+ICAgICAgSW4gcGFydGljdWxhciBhbGwgdGhlIHByb2JsZW1zIGFzc29j aWF0ZWQgd2l0aCBSUEtJIHZhbGlkYXRpb24gc3RhdGUNCiAgICA+ICAgICAgc2lnbmFsbGluZyBv dmVyIGVCR1AgYWxzbyBhcHBseSB0byBiZ3BzZWMgc3RhdGUgc2lnbmFsbGluZyBvdmVyIGVCR1Au DQogICAgPiANCiAgICA+ICAgICAgRGVmaW5pbmcgdGhpcyBhcyBub24tdHJhbnNpdGl2ZSBpcyBh IGdvb2Qgc3RhcnQsIGJ1dCB0aGUgbGFuZ3VhZ2UgbmVlZHMNCiAgICA+ICAgICAgdG8gY2hhbmdl IHRvIGVuc3VyZSB0aGF0IGl0IGNhbm5vdCBlc2NhcGUgYW4gQVNOLiAgQ2FuIEkgc3VnZ2VzdCB0 aGUNCiAgICA+ICAgICAgZm9sbG93aW5nIHRleHQgY2hhbmdlczoNCiAgICA+IA0KICAgID4gICAg ICBjaGFuZ2U6DQogICAgPiAgICAgID4gICAgSWYgdGhlIHJvdXRlciBzdXBwb3J0cyB0aGUgZXh0 ZW5zaW9uIGFzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgaXQNCiAgICA+ICAgICAgPiAgICBT SE9VTEQgYXR0YWNoIHRoZSBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uIHN0YXRlIGV4dGVuZGVkIGNv bW11bml0eSB0bw0KICAgID4gICAgICA+ICAgIEJHUHNlYyBVUERBVEUgbWVzc2FnZXMgc2VudCB0 byBCR1AgcGVlcnMgYnkgbWFwcGluZyB0aGUgbG9jYWxseQ0KICAgID4gICAgICA+ICAgIGNvbXB1 dGVkIHZhbGlkYXRpb24gc3RhdGUgaW50byB0aGUgbGFzdCBvY3RldCBvZiB0aGUgZXh0ZW5kZWQN CiAgICA+ICAgICAgPiAgICBjb21tdW5pdHkuICBUaGlzIFNIT1VMRCBiZSBkb25lIGF1dG9tYXRp Y2FsbHkgZm9yIGlCR1AgcGVlcnMgYW5kDQogICAgPiAgICAgID4gICAgY29uZmlndXJhYmxlIGZv ciBlQkdQIHBlZXJzIChzZWUgYmVsb3cpLg0KICAgID4gDQogICAgPiAgICAgIHRvOg0KICAgID4g ICAgICA+ICAgIElmIHRoZSByb3V0ZXIgc3VwcG9ydHMgdGhlIGV4dGVuc2lvbiBhcyBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQsIGl0DQogICAgPiAgICAgID4gICAgU0hPVUxEIGF0dGFjaCB0aGUg QkdQc2VjIHBhdGggdmFsaWRhdGlvbiBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkgdG8NCiAgICA+ ICAgICAgPiAgICBCR1BzZWMgVVBEQVRFIG1lc3NhZ2VzIHNlbnQgdG8gaUJHUCBwZWVycyBieSBt YXBwaW5nIHRoZSBsb2NhbGx5DQogICAgPiAgICAgID4gICAgY29tcHV0ZWQgdmFsaWRhdGlvbiBz dGF0ZSBpbnRvIHRoZSBsYXN0IG9jdGV0IG9mIHRoZSBleHRlbmRlZA0KICAgID4gICAgICA+ICAg IGNvbW11bml0eS4NCiAgICA+IA0KICAgID4gICAgICBhbmQgY2hhbmdlOg0KICAgID4gICAgICA+ ICAgIEJ5IGRlZmF1bHQsIHJvdXRlcnMgU0hPVUxEIGVuYWJsZSB1c2Ugb2YgdGhpcw0KICAgID4g ICAgICA+ICAgIGNvbW11bml0eSBvbiBhbGwgaUJHUCBzZXNzaW9ucyBhbmQgcm91dGVycyBTSE9V TEQgZGlzYWJsZSB0aGUgdXNlIG9mDQogICAgPiAgICAgID4gICAgdGhpcyBjb21tdW5pdHkgb24g YWxsIGVCR1Agc2Vzc2lvbnMuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBOT1Qgc2VuZA0KICAgID4g ICAgICA+ICAgIG1vcmUgdGhhbiBvbmUgaW5zdGFuY2Ugb2YgdGhlIG9yaWdpbiB2YWxpZGF0aW9u IHN0YXRlIGV4dGVuZGVkDQogICAgPiAgICAgID4gICAgY29tbXVuaXR5IGFuZCBNVVNUIGRyb3Ag KHdpdGhvdXQgcHJvY2Vzc2luZykgdGhlIEJHUHNlYyBwYXRoDQogICAgPiAgICAgID4gICAgdmFs aWRhdGlvbiBzdGF0ZSBleHRlbmRlZCBjb21tdW5pdHkgaWYgcmVjZWl2ZWQgb3ZlciBhbiBFeHRl cm5hbCBCR1ANCiAgICA+ICAgICAgPiAgICAoZUJHUCkgcGVlcmluZyBzZXNzaW9uIHRoYXQgaGFz IG5vdCBiZSBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8NCiAgICA+ICAgICAgPiAgICBlbmFibGUg cHJvY2Vzc2luZy4NCiAgICA+IA0KICAgID4gICAgICB0bzoNCiAgICA+ICAgICAgPiAgICBCeSBk ZWZhdWx0LCByb3V0ZXJzIFNIT1VMRCBlbmFibGUgdXNlIG9mIHRoaXMNCiAgICA+ICAgICAgPiAg ICBjb21tdW5pdHkgb24gYWxsIGlCR1Agc2Vzc2lvbnMuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBO T1Qgc2VuZA0KICAgID4gICAgICA+ICAgIG1vcmUgdGhhbiBvbmUgaW5zdGFuY2Ugb2YgdGhlIG9y aWdpbiB2YWxpZGF0aW9uIHN0YXRlIGV4dGVuZGVkDQogICAgPiAgICAgID4gICAgY29tbXVuaXR5 LCBNVVNUIE5PVCBhdHRhY2ggdGhlIEJHUHNlYyBwYXRoIHZhbGlkYXRpb24gc3RhdGUgZXh0ZW5k ZWQNCiAgICA+ICAgICAgPiAgICBjb21tdW5pdHkgdG8gQkdQc2VjIFVQREFURSBtZXNzYWdlcyBz ZW50IHRvIGVCR1AgcGVlcnMgYW5kIE1VU1QgZHJvcA0KICAgID4gICAgICA+ICAgICh3aXRob3V0 IHByb2Nlc3NpbmcpIHRoZSBCR1BzZWMgcGF0aCB2YWxpZGF0aW9uIHN0YXRlIGV4dGVuZGVkIGNv bW11bml0eQ0KICAgID4gICAgICA+ICAgIGlmIHJlY2VpdmVkIG92ZXIgYW4gZUJHUCBwZWVyaW5n IHNlc3Npb24uDQogICAgPiAgICAgIE5pY2sNCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAg IFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgPiAgICAgIFNpZHJvcHNAaWV0Zi5vcmcNCiAgICA+ ICAgICAgaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9w cyZhbXA7ZGF0YT0wMiU3QzAxJTdDZG91Z20lNDBuaXN0LmdvdiU3Q2NkY2NkM2U0ZmVhYzQxM2U1 ZWRkMDhkODQ5YTYxYzk1JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdD MCU3QzYzNzM0MDMyNTExMTQ5MjAzMCZhbXA7c2RhdGE9eFpoV2psT0NrN3JEWTNodUxab0lER2Rq bzNEMUppb25LNmRaJTJGcVlGNEVBJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgPiANCiAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBTaWRy b3BzIG1haWxpbmcgbGlzdA0KICAgID4gU2lkcm9wc0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly9n Y2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9wcyZhbXA7ZGF0YT0wMiU3 QzAxJTdDZG91Z20lNDBuaXN0LmdvdiU3Q2NkY2NkM2U0ZmVhYzQxM2U1ZWRkMDhkODQ5YTYxYzk1 JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNzM0MDMyNTEx MTQ5MjAzMCZhbXA7c2RhdGE9eFpoV2psT0NrN3JEWTNodUxab0lER2RqbzNEMUppb25LNmRaJTJG cVlGNEVBJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgPiANCg0K From nobody Wed Aug 26 07:54:37 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 117DF3A1551 for ; Wed, 26 Aug 2020 07:54:29 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sz0h0bq4uIy for ; Wed, 26 Aug 2020 07:54:25 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:110:201::51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAD83A1563 for ; Wed, 26 Aug 2020 07:54:24 -0700 (PDT) Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id C340910757B1 for ; Wed, 26 Aug 2020 10:54:23 -0400 (EDT) Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2020 10:54:18 -0400 Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Wed, 26 Aug 2020 10:54:18 -0400 From: John Curran To: "sidrops@ietf.org" Thread-Topic: Reason for Outage report (was: Re: [Sidrops] ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) Thread-Index: AQHWe7jFr1X00EMwDk+S8tTniWA6vw== Date: Wed, 26 Aug 2020 14:54:17 +0000 Message-ID: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.136.136.37] Content-Type: multipart/alternative; boundary="_000_727F6FBDF73C4F58AE2D0276B2A183A3arinnet_" MIME-Version: 1.0 Archived-At: Subject: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 14:54:36 -0000 --_000_727F6FBDF73C4F58AE2D0276B2A183A3arinnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMTMgQXVnIDIwMjAsIGF0IDE6NTMgUE0sIEpvaG4gQ3VycmFuIDxqY3VycmFuQGFyaW4ubmV0 PG1haWx0bzpqY3VycmFuQGFyaW4ubmV0Pj4gd3JvdGU6DQouLi4NCknigJlsbCBwcm92aWRlIGEg bW9yZSBkZXRhaWxlZCBwb3N0LW1vcnRlbSBoZXJlIG9uY2UgYXZhaWxhYmxlLg0KDQpSUEtJIEZv bGtzIC0NCg0KQXMgcHJvbWlzZWQsIHBsZWFzZSBmaW5kIHRoZSAicmVhc29uIGZvciBvdXRhZ2Ui IHJlcG9ydCBmb3IgQVJJTuKAmXMgMTIgQXVndXN0IFJQS0kgaW5jaWRlbnQgLQ0KaHR0cHM6Ly93 d3cuYXJpbi5uZXQvYW5ub3VuY2VtZW50cy8yMDIwMDgyNi8gIChhbmQgYXR0YWNoZWQgYmVsb3cg aW4gcGxhaW50ZXh0KQ0KDQpBcyBub3RlZCwgd2XigJlsbCBiZSBleHBhbmRpbmcgb3VyIGludGVy bmFsIFJQS0kgdGVzdGluZyBzdHJhdGVneSAtIHBsZWFzZSByZXZpZXcgYW5kIGxldCB1cyBrbm93 IGlmIHRoZXJl4oCZcyBhZGRpdGlvbmFsIHZhbGlkYXRvcnMvcGFja2FnZXMgd2Ugc2hvdWxkIGJl IHRlc3RpbmcgYWdhaW5zdC4NCg0KVGhhbmtzLA0KIC9Kb2huDQoNCkpvaG4gQ3VycmFuDQpQcmVz aWRlbnQgYW5kIENFTw0KQW1lcmljYW4gUmVnaXN0cnkgZm9yIEludGVybmV0IE51bWJlcnMNCg0K PT09DQoNCjEyLTEzIEF1Z3VzdCBSUEtJIE91dGFnZTogVXBkYXRlDQpQb3N0ZWQ6IFdlZG5lc2Rh eSwgMjYgQXVndXN0IDIwMjANClNlcnZpY2UgVXBkYXRlDQoNCjEyIEF1Z3VzdCAyMDIwIGF0IDEy OjIxIFBNIHRvIDEzIEF1Z3VzdCBhdCAxMTozNiBBTQ0KDQpPbiAxMiBBdWd1c3QgYXQgMTI6MjEg UE0sIEFSSU4gZGVwbG95ZWQgYSBuZXcgdmVyc2lvbiBvZiBpdHMgUlBLSSBzeXN0ZW0uIEFSSU7i gJlzIHJlcG9zaXRvcnkgc2hvd2VkIG5vIGVycm9ycyBpbiBib3RoIFJJUEXigJlzIFZhbGlkYXRv ciBhbmQgTkxOZXRMYWLigJlzIFJvdXRpbmF0b3Igc3lzdGVtcy4gQXQgMTI6NDYgUE0gb24gdGhh dCBzYW1lIGRheSB3ZSByZWNlaXZlZCBhIHNlcnZpY2UgaXNzdWUgbm90aWNlIHRoYXQgQVJJTuKA mXMgcmVwb3NpdG9yeSB3YXMgbm90IHdvcmtpbmcgd2l0aCBycGtpLWNsaWVudC4gQVJJTiBFbmdp bmVlcmluZyB3b3JrZWQgY2xvc2VseSB3aXRoIHRoZSBPcGVuQlNEIHNvZnR3YXJlIGRldmVsb3Bl cnMgdG8gcGlucG9pbnQgdGhlIGVycm9yIHdpdGhpbiB0aGUgUlBLSSBzeXN0ZW0uIEJvdGggQVJJ TiBlbmdpbmVlcmluZyBhbmQgdGhlIE9wZW5CU0QgZGV2ZWxvcGVycyBpbmRlcGVuZGVudGx5IGZv dW5kIHRoZSBlcnJvciB3aXRoaW4gQVJJTuKAmXMgcmVwb3NpdG9yeS4gVGhlIGZpeCB3YXMgZGV2 ZWxvcGVkIGFuZCBkZXBsb3llZCBvbiAxMyBBdWd1c3QgYXQgMTE6MzYgQU0uDQoNCkhlcmUgaXMg YSBkZXRhaWxlZCBhbmFseXNpcyBvZiB0aGUgZXJyb3I6DQoNCkR1cmluZyBSUEtJIHJlcG9zaXRv cnkgZ2VuZXJhdGlvbiwgQVJJTiBjcmVhdGVzIOKAnG1hbmlmZXN0cy7igJ0gQSBtYW5pZmVzdCBp cyBjcnlwdG9ncmFwaGljIG9iamVjdCBzcGVjaWZpYyB0byB0aGUgUlBLSSB3aGljaCBpcyB1c2Vk IHRvIGhlbHAgZ3VhcmFudGVlIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIHJlcG9zaXRvcnkuIE9uZSBt YW5pZmVzdCBpcyBhc3NvY2lhdGVkIHdpdGggZWFjaCByZXNvdXJjZSBjZXJ0aWZpY2F0ZSBpbiB0 aGUgcmVwb3NpdG9yeS4gVGhlIG1hbmlmZXN0LCBmbGFnZ2VkIGJ5IHRoZSBPcGVuU1NMLWJhc2Vk IHZhbGlkYXRvcnMsIGhhZCBhIHN1YnRsZSBlbmNvZGluZyBpc3N1ZS4gVGhlIG1hbmlmZXN0IGlu IHF1ZXN0aW9uIGVzc2VudGlhbGx5IGNvbnRhaW5zIHR3byBjb3BpZXMgb2YgYW4gQWxnb3JpdGht SWRlbnRpZmllciB2YXJpYWJsZSBpbiBkaWZmZXJlbnQgbG9jYXRpb25zIChhbmQgdXNlZCBmb3Ig ZGlmZmVyZW50IHB1cnBvc2VzKS4gUGVyIFJGQyA1MjgwLCBTZWN0aW9uIDQuMS4xLjIsIHRoZXNl IHR3byBpbnN0YW5jZXMgbXVzdCBtYXRjaCBjb21wbGV0ZWx5LiBJbiBBUklO4oCZcyBtYW5pZmVz dCwgb25lIGNvbnRhaW5lZCBhbiBlbXB0eSBzdHJpbmcgKOKAnOKAnSkgYXMgYSBwYXJhbWV0ZXIg YW5kIHRoZSBvdGhlciBjb250YWluZWQgYSBOVUxMIChwb2ludGVyIHRvIG5vdGhpbmcpLiBUaGUg ZW1wdHkgc3RyaW5nIHBhcmFtZXRlciB3YXMgaW5jb3JyZWN0IGFuZCB0aGUgT3BlblNTTC1iYXNl ZCB2YWxpZGF0b3JzIHdlcmUgZmxhZ2dpbmcgdGhpcyBiZWNhdXNlIHRoZSB0d28gZGVmaW5pdGlv bnMgb2YgQWxnb3JpdGhtSWRlbnRpZmllciBkaWQgbm90IG1hdGNoLg0KDQpQbGFubmVkIENvcnJl Y3RpdmUgYWN0aW9uczoNCg0KQXMgYSBjb3JyZWN0aXZlIGFjdGlvbiwgQVJJTiB3aWxsIGJlIGJy b2FkZW5pbmcgaXRzIHRlc3Rpbmcgc3RyYXRlZ3kuIEluIGZ1dHVyZSByZWxlYXNlcywgd2Ugd2ls bCBiZSB2YWxpZGF0aW5nIG5vdCBvbmx5IExpYnJlU1NMLWJhc2VkIHZhbGlkYXRvcnMgKFJJUEXi gJlzIFZhbGlkYXRvciBhbmQgTkxOZXRsYWLigJlzIFJvdXRpbmF0b3IpIGJ1dCBhbHNvIE9wZW5T U0wtYmFzZWQgdmFsaWRhdG9ycyBzdWNoIGFzIHJwa2ktY2xpZW50IGFuZCBGb3J0LiBUaGUgbGlz dCBvZiB2YWxpZGF0b3JzIHdlIGRvIHRlc3QgYWdhaW5zdCB0aGUgQVJJTiByZXBvc2l0b3J5IHdp bGwgYmUgbm90ZWQgd2l0aGluIHRoZSBSUEtJIHNlY3Rpb24gb2YgQVJJTuKAmXMgd2Vic2l0ZS4N Cg0KQVJJTiBhcG9sb2dpemVzIGZvciBhbnkgaW5jb252ZW5pZW5jZSB0aGF0IHRoaXMgbWF5IGhh dmUgY2F1c2UgdGhvc2Ugd2hvIHJ1biBPcGVuU1NMLWJhc2VkIHZhbGlkYXRvcnMuIFdlIHRha2Ug YW55IGluY29tcGF0aWJpbGl0eSBzZXJpb3VzbHkgYW5kIGFyZSB3b3JraW5nIHRvIGJldHRlciBz ZXJ2aWNlIHRoZSBjb21tdW5pdHkgb24gdGhpcyBlbWVyZ2luZyBidXQgeWV0IHZlcnkgaW1wb3J0 YW50IHNlcnZpY2UuIFdlIHdvdWxkIGxpa2UgdG8gdGhhbmsgSm9iIFNuaWpkZXJzIGFuZCB0aGUg T3BlbkJTRCBycGtpLWNsaWVudCB0ZWFtIGZvciBoZWxwaW5nIGFzc2lzdCB1cyBpbiBzb2x2aW5n IHRoaXMgaXNzdWUgcXVpY2tseS4NCg0KUmVnYXJkcywNCg0KTWFyayBLb3N0ZXJzDQpDaGllZiBU ZWNobm9sb2d5IE9mZmljZXINCkFtZXJpY2FuIFJlZ2lzdHJ5IGZvciBJbnRlcm5ldCBOdW1iZXJz IChBUklOKQ0KDQo9PT0NCg0KDQo= --_000_727F6FBDF73C4F58AE2D0276B2A183A3arinnet_ Content-Type: text/html; charset="utf-8" Content-ID: <9E2050C66149A34897EDE6F8C685F406@corp.arin.net> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk9uIDEzIEF1ZyAyMDIwLCBhdCAxOjUzIFBNLCBK b2huIEN1cnJhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpjdXJyYW5AYXJpbi5uZXQiIGNsYXNzPSIi PmpjdXJyYW5AYXJpbi5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Li4uPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IHByZTsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPknigJlsbA0KIHByb3ZpZGUgYSBtb3JlIGRldGFpbGVkIHBv c3QtbW9ydGVtIGhlcmUgb25jZSBhdmFpbGFibGUuPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClJQS0kgRm9sa3MgLSZuYnNwOzwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAg MCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2PkFz IHByb21pc2VkLCBwbGVhc2UgZmluZCB0aGUgJnF1b3Q7cmVhc29uIGZvciBvdXRhZ2UmcXVvdDsg cmVwb3J0IGZvciBBUklO4oCZcyAxMiBBdWd1c3QgUlBLSSBpbmNpZGVudCAtJm5ic3A7PC9kaXY+ DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmFyaW4ubmV0L2Fubm91bmNlbWVudHMvMjAyMDA4 MjYvIiBjbGFzcz0iIj5odHRwczovL3d3dy5hcmluLm5ldC9hbm5vdW5jZW1lbnRzLzIwMjAwODI2 LzwvYT4mbmJzcDsgKGFuZCBhdHRhY2hlZCBiZWxvdyBpbiBwbGFpbnRleHQpJm5ic3A7PC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BcyBub3RlZCwgd2XigJlsbCBiZSBl eHBhbmRpbmcgb3VyIGludGVybmFsIFJQS0kgdGVzdGluZyBzdHJhdGVneSAtIHBsZWFzZSByZXZp ZXcgYW5kIGxldCB1cyBrbm93IGlmIHRoZXJl4oCZcyBhZGRpdGlvbmFsIHZhbGlkYXRvcnMvcGFj a2FnZXMgd2Ugc2hvdWxkIGJlIHRlc3RpbmcgYWdhaW5zdC4mbmJzcDs8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxk aXY+Jm5ic3A7L0pvaG48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj5Kb2huIEN1cnJhbjwvZGl2Pg0KPGRpdj5QcmVzaWRlbnQgYW5kIENFTzwvZGl2Pg0KPGRp dj5BbWVyaWNhbiBSZWdpc3RyeSBmb3IgSW50ZXJuZXQgTnVtYmVyczwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj49PT08L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+MTIt MTMgQXVndXN0IFJQS0kgT3V0YWdlOiBVcGRhdGU8YnIgY2xhc3M9IiI+DQpQb3N0ZWQ6IFdlZG5l c2RheSwgMjYgQXVndXN0IDIwMjAmbmJzcDs8YnIgY2xhc3M9IiI+DQpTZXJ2aWNlIFVwZGF0ZSZu YnNwOzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjEyIEF1Z3VzdCAyMDIwIGF0IDEyOjIx IFBNIHRvIDEzIEF1Z3VzdCBhdCAxMTozNiBBTTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ck9uIDEyIEF1Z3VzdCBhdCAxMjoyMSBQTSwgQVJJTiBkZXBsb3llZCBhIG5ldyB2ZXJzaW9uIG9m IGl0cyBSUEtJIHN5c3RlbS4gQVJJTuKAmXMgcmVwb3NpdG9yeSBzaG93ZWQgbm8gZXJyb3JzIGlu Jm5ic3A7Ym90aCBSSVBF4oCZcyBWYWxpZGF0b3IgYW5kIE5MTmV0TGFi4oCZcyBSb3V0aW5hdG9y IHN5c3RlbXMuIEF0IDEyOjQ2IFBNIG9uIHRoYXQgc2FtZSBkYXkgd2UgcmVjZWl2ZWQgYSBzZXJ2 aWNlJm5ic3A7aXNzdWUgbm90aWNlIHRoYXQgQVJJTuKAmXMgcmVwb3NpdG9yeSB3YXMNCiBub3Qg d29ya2luZyB3aXRoIHJwa2ktY2xpZW50LiBBUklOIEVuZ2luZWVyaW5nIHdvcmtlZCBjbG9zZWx5 IHdpdGggdGhlJm5ic3A7T3BlbkJTRCBzb2Z0d2FyZSBkZXZlbG9wZXJzIHRvIHBpbnBvaW50IHRo ZSBlcnJvciB3aXRoaW4gdGhlIFJQS0kgc3lzdGVtLiBCb3RoIEFSSU4gZW5naW5lZXJpbmcgYW5k IHRoZSZuYnNwO09wZW5CU0QgZGV2ZWxvcGVycyBpbmRlcGVuZGVudGx5IGZvdW5kIHRoZSBlcnJv ciB3aXRoaW4gQVJJTuKAmXMgcmVwb3NpdG9yeS4gVGhlIGZpeA0KIHdhcyBkZXZlbG9wZWQgYW5k IGRlcGxveWVkJm5ic3A7b24gMTMgQXVndXN0IGF0IDExOjM2IEFNLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkhlcmUgaXMgYSBkZXRhaWxlZCBhbmFseXNpcyBvZiB0aGUgZXJyb3I6PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRHVyaW5nIFJQS0kgcmVwb3NpdG9yeSBnZW5lcmF0 aW9uLCBBUklOIGNyZWF0ZXMg4oCcbWFuaWZlc3RzLuKAnSBBIG1hbmlmZXN0IGlzIGNyeXB0b2dy YXBoaWMgb2JqZWN0IHNwZWNpZmljIHRvIHRoZSBSUEtJJm5ic3A7d2hpY2ggaXMgdXNlZCB0byBo ZWxwIGd1YXJhbnRlZSB0aGUgaW50ZWdyaXR5IG9mIHRoZSByZXBvc2l0b3J5LiBPbmUgbWFuaWZl c3QgaXMgYXNzb2NpYXRlZCB3aXRoIGVhY2ggcmVzb3VyY2UmbmJzcDtjZXJ0aWZpY2F0ZSBpbiB0 aGUgcmVwb3NpdG9yeS4NCiBUaGUgbWFuaWZlc3QsIGZsYWdnZWQgYnkgdGhlIE9wZW5TU0wtYmFz ZWQgdmFsaWRhdG9ycywgaGFkIGEgc3VidGxlIGVuY29kaW5nIGlzc3VlLiZuYnNwO1RoZSBtYW5p ZmVzdCBpbiBxdWVzdGlvbiBlc3NlbnRpYWxseSBjb250YWlucyB0d28gY29waWVzIG9mIGFuIEFs Z29yaXRobUlkZW50aWZpZXIgdmFyaWFibGUgaW4gZGlmZmVyZW50IGxvY2F0aW9ucyAoYW5kJm5i c3A7dXNlZCBmb3IgZGlmZmVyZW50IHB1cnBvc2VzKS4gUGVyIFJGQyA1MjgwLCBTZWN0aW9uDQog NC4xLjEuMiwgdGhlc2UgdHdvIGluc3RhbmNlcyBtdXN0IG1hdGNoIGNvbXBsZXRlbHkuIEluIEFS SU7igJlzJm5ic3A7bWFuaWZlc3QsIG9uZSBjb250YWluZWQgYW4gZW1wdHkgc3RyaW5nICjigJzi gJ0pIGFzIGEgcGFyYW1ldGVyIGFuZCB0aGUgb3RoZXIgY29udGFpbmVkIGEgTlVMTCAocG9pbnRl ciB0byBub3RoaW5nKS4mbmJzcDtUaGUgZW1wdHkgc3RyaW5nIHBhcmFtZXRlciB3YXMgaW5jb3Jy ZWN0IGFuZCB0aGUgT3BlblNTTC1iYXNlZCB2YWxpZGF0b3JzIHdlcmUgZmxhZ2dpbmcNCiB0aGlz IGJlY2F1c2UgdGhlIHR3byZuYnNwO2RlZmluaXRpb25zIG9mIEFsZ29yaXRobUlkZW50aWZpZXIg ZGlkIG5vdCBtYXRjaC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGFubmVkIENvcnJl Y3RpdmUgYWN0aW9uczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyBhIGNvcnJlY3Rp dmUgYWN0aW9uLCBBUklOIHdpbGwgYmUgYnJvYWRlbmluZyBpdHMgdGVzdGluZyBzdHJhdGVneS4g SW4gZnV0dXJlIHJlbGVhc2VzLCB3ZSB3aWxsIGJlIHZhbGlkYXRpbmcgbm90IG9ubHkmbmJzcDtM aWJyZVNTTC1iYXNlZCB2YWxpZGF0b3JzIChSSVBF4oCZcyBWYWxpZGF0b3IgYW5kIE5MTmV0bGFi 4oCZcyBSb3V0aW5hdG9yKSBidXQgYWxzbyBPcGVuU1NMLWJhc2VkIHZhbGlkYXRvcnMgc3VjaCBh cyZuYnNwO3Jwa2ktY2xpZW50IGFuZCBGb3J0LiBUaGUNCiBsaXN0IG9mIHZhbGlkYXRvcnMgd2Ug ZG8gdGVzdCBhZ2FpbnN0IHRoZSBBUklOIHJlcG9zaXRvcnkgd2lsbCBiZSBub3RlZCB3aXRoaW4g dGhlIFJQS0kgc2VjdGlvbiZuYnNwO29mIEFSSU7igJlzIHdlYnNpdGUuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQVJJTiBhcG9sb2dpemVzIGZvciBhbnkgaW5jb252ZW5pZW5jZSB0aGF0 IHRoaXMgbWF5IGhhdmUgY2F1c2UgdGhvc2Ugd2hvIHJ1biBPcGVuU1NMLWJhc2VkIHZhbGlkYXRv cnMuIFdlIHRha2UmbmJzcDthbnkgaW5jb21wYXRpYmlsaXR5IHNlcmlvdXNseSBhbmQgYXJlIHdv cmtpbmcgdG8gYmV0dGVyIHNlcnZpY2UgdGhlIGNvbW11bml0eSBvbiB0aGlzIGVtZXJnaW5nIGJ1 dCB5ZXQgdmVyeSZuYnNwO2ltcG9ydGFudCBzZXJ2aWNlLiBXZSB3b3VsZCBsaWtlIHRvIHRoYW5r DQogSm9iIFNuaWpkZXJzIGFuZCB0aGUgT3BlbkJTRCBycGtpLWNsaWVudCB0ZWFtIGZvciBoZWxw aW5nIGFzc2lzdCB1cyBpbiZuYnNwO3NvbHZpbmcgdGhpcyBpc3N1ZSBxdWlja2x5LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KTWFyayBLb3N0ZXJzPGJyIGNsYXNzPSIiPg0KQ2hpZWYgVGVjaG5vbG9neSBPZmZpY2VyPGJy IGNsYXNzPSIiPg0KQW1lcmljYW4gUmVnaXN0cnkgZm9yIEludGVybmV0IE51bWJlcnMgKEFSSU4p PC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pj09PTwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_727F6FBDF73C4F58AE2D0276B2A183A3arinnet_-- From nobody Wed Aug 26 08:32:43 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 EE61B3A159B; Wed, 26 Aug 2020 08:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAbrXU46NbRi; Wed, 26 Aug 2020 08:32:38 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBE83A0ECA; Wed, 26 Aug 2020 08:32:34 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 07QFWUu1009115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Aug 2020 16:32:31 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: "Montgomery, Douglas C. (Fed)" Cc: "sidrops@ietf.org" References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> <4546E616-2B93-4612-AC8E-F9039FEB7F60@nist.gov> From: Nick Hilliard Message-ID: Date: Wed, 26 Aug 2020 16:32:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.27 MIME-Version: 1.0 In-Reply-To: <4546E616-2B93-4612-AC8E-F9039FEB7F60@nist.gov> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 15:32:41 -0000 Montgomery, Douglas C. (Fed) wrote on 26/08/2020 15:06: > I think that can and should be addressed in the security > considerations section. > > The spec mandates that the signal be non-transitive - it only > provides insight as to the validation result of your immediate peer. This doesn't really work from an IETF standards track point of view because it's an actively harmful proposal at the point that tagged routes cross from one ASN to another, i.e. including immediate peers. It's not appropriate to publish an RFC which makes a recommendation about a security mechanism in the text and then makes a statement in the security section that effectively nullifies the recommendation. I get the other use cases that you're describing - these are all applicable to iBGP use, and I'm not arguing against them: just against ever seeing this mechanism on an EBGP session. Nick > Having said that, here are those that feel this functionality, > especially in the case of BGPsec, provides useful functionality, that > increases the resilience of the entire system, and provides a > much-needed diagnostic capability (for operations and monitoring > infrastructures). > > I suspect concerns of brittleness and lack of diagnostics are more of > an impediment to adoption than concerns about distributed trust > models. > > The other choice is that operators will still do this in non-standard > ways and we will lose the opportunity to leverage the potential > robustness and diagnostic benefits. > > In general, I think the supposition that we will somehow influence / > constrain implementation and deployment architectures by not > specifying simple mechanisms such as this, is already proven to be > false. > > dougm -- DougM @ NIST > > On 8/26/20, 5:55 AM, "Nick Hilliard" wrote: > > Oliver, > > the difficulty here is not that operators might be using this, it's > whether these signals cross administrative boundaries. It's one > thing to use this on your own network, and even though it's not > something that I'd view as being a very good idea, there are two > mitigating factors: 1. your network, your rules and 2. it's ibgp only > which means that your interior routing infrastructure will get a full > view of all routes and will be able to make informed routing > decisions, where bgpsec signaled routes can be evaluated in context > alongside other candidate routes. > > The difficulty here is applying this to EBGP. If this draft ends up > as a standards track document, this is giving the process the IETF > stamp of approval that this is a good idea and recommended practice. > This is a very poor idea for the reasons which I've detailed > previously. > > Nick > > Borchert, Oliver (Fed) wrote on 26/08/2020 01:11: >> Nick, >> >> This point has been made in the past (about origin validation >> signaling) and I think it is a bit of a red herring. >> >> Operators can and are signaling validation state today with ad-hoc >> use of communities. Operators do this for multiple reasons, >> including providing some resilience to the system should a router >> lose access to validating caches, to detect and diagnose RPKI state >> skew among routers in the same network etc. Not having a >> standardized encoding of this practice won't be the determining >> factor of how this kind of signaling is used. >> >> In the case of BGPsec, the need for diagnostics and resilience will >> be even higher. Remember there is no "not found" in BGPsec to fall >> back to loss of contact with RPKI data. If such signaling also >> facilitated performance optimizations or implementation of >> consistent policy decisions on routers that have deferred their own >> validation procedures, it actually might encourage more deployment >> than discourage it as you suggest. >> >> In short, I see such mechanisms as supporting and encouraging >> deployment of these technologies - or at worse being a non-factor >> to the adoption question - as those who want to do this in >> non-standard ways will just continue to do so. >> >> Oliver >> >> ----------------------------------------------- Oliver Borchert, >> Computer Scientist National Institute of Standards and Technology >> (Office) +1.301.975.4856 (GVoice) +1.240.668.4117 >> >> >> On 8/11/20, 4:59 PM, "Sidrops on behalf of Nick Hilliard" >> wrote: >> >> Keyur Patel wrote on 11/08/2020 19:45: >>> A working group last call has been requested for >>> draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation >>> State signaling”. Please reply to the list with your comments. >>> The WGLC will end on August 25, 2020. >> >> In general, replicating validation functionality using BGP >> communities is a poor idea and from an ops point of view, it seems >> wiser as a long term objective to push vendors to support bgpsec >> than to implement hacks like this. For this reason I don't support >> publication of the draft as an rfc. >> >> Major issues: >> >> 1. The draft lacks a problem statement and a sunset clause. >> >> 2. Previously there's been a good deal of discussion on sidrops >> about RPKI validation state signalling. Several problems were >> listed here: >> >>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fsidrops%2FYV1WfoxQNiwfOjtKIY1d6YJjRxM%2F&data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&sdata=JH6g44hs2umnzmrIpUEwH0sN4h%2BpvtvqMFg%2FiyGkfkg%3D&reserved=0 > >>> > >> Most of the problems associated with validation state signalling >> identified in that email also apply to bgpsec validation state >> signalling, namely: >> >> - crypto authentication is lost - different and incompatible set of >> signalling hooks >> >> In particular all the problems associated with RPKI validation >> state signalling over eBGP also apply to bgpsec state signalling >> over eBGP. >> >> Defining this as non-transitive is a good start, but the language >> needs to change to ensure that it cannot escape an ASN. Can I >> suggest the following text changes: >> >> change: >>> If the router supports the extension as defined in this document, >>> it SHOULD attach the BGPsec path validation state extended >>> community to BGPsec UPDATE messages sent to BGP peers by mapping >>> the locally computed validation state into the last octet of the >>> extended community. This SHOULD be done automatically for iBGP >>> peers and configurable for eBGP peers (see below). >> >> to: >>> If the router supports the extension as defined in this document, >>> it SHOULD attach the BGPsec path validation state extended >>> community to BGPsec UPDATE messages sent to iBGP peers by mapping >>> the locally computed validation state into the last octet of the >>> extended community. >> >> and change: >>> By default, routers SHOULD enable use of this community on all >>> iBGP sessions and routers SHOULD disable the use of this >>> community on all eBGP sessions. Implementations MUST NOT send >>> more than one instance of the origin validation state extended >>> community and MUST drop (without processing) the BGPsec path >>> validation state extended community if received over an External >>> BGP (eBGP) peering session that has not be explicitly configured >>> to enable processing. >> >> to: >>> By default, routers SHOULD enable use of this community on all >>> iBGP sessions. Implementations MUST NOT send more than one >>> instance of the origin validation state extended community, MUST >>> NOT attach the BGPsec path validation state extended community to >>> BGPsec UPDATE messages sent to eBGP peers and MUST drop (without >>> processing) the BGPsec path validation state extended community >>> if received over an eBGP peering session. >> Nick >> >> >> _______________________________________________ Sidrops mailing >> list Sidrops@ietf.org >> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&sdata=xZhWjlOCk7rDY3huLZoIDGdjo3D1JionK6dZ%2FqYF4EA%3D&reserved=0 > >> > >> _______________________________________________ Sidrops mailing >> list Sidrops@ietf.org >> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&sdata=xZhWjlOCk7rDY3huLZoIDGdjo3D1JionK6dZ%2FqYF4EA%3D&reserved=0 > >> > > > _______________________________________________ Sidrops mailing list > Sidrops@ietf.org https://www.ietf.org/mailman/listinfo/sidrops > From nobody Wed Aug 26 09:00: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 CAFBF3A163D for ; Wed, 26 Aug 2020 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 qZFwZnbWKz1Y for ; Wed, 26 Aug 2020 09:00:07 -0700 (PDT) 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 F19093A1639 for ; Wed, 26 Aug 2020 09:00:06 -0700 (PDT) Received: from bench.sobornost.net (sobornost.connected.by.freedominter.net [45.155.156.99]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 7EA5522019D; Wed, 26 Aug 2020 16:00:05 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 287521dd; Wed, 26 Aug 2020 16:00:02 +0000 (UTC) Date: Wed, 26 Aug 2020 16:00:01 +0000 From: Job Snijders To: John Curran Cc: "sidrops@ietf.org" Message-ID: <20200826160001.GF95612@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 16:00:09 -0000 Dear John, I'd like to offer some contributions to this document's outline of the background of some implementations. Mostly just nitpicking. On Wed, Aug 26, 2020 at 02:54:17PM +0000, John Curran wrote: > 12-13 August RPKI Outage: Update > Posted: Wednesday, 26 August 2020 > Service Update > > 12 August 2020 at 12:21 PM to 13 August at 11:36 AM > > On 12 August at 12:21 PM, ARIN deployed a new version of its RPKI > system. ARIN’s repository showed no errors in both RIPE’s Validator > and NLNetLab’s Routinator systems. The current versions of routinator and ripe ncc's validator have weak (lacking) support for manifest handling, there are other issues in both softwares that don't yield errors where they should yield errors related to manifest handling. Neither implementation handles manifests correctly at the moment, so neither software currently can be used to confirm the correct publication of manifest related data. :-( > At 12:46 PM on that same day we received a service issue notice that > ARIN’s repository was not working with rpki-client. ARIN Engineering > worked closely with the OpenBSD software developers to pinpoint the > error within the RPKI system. Both ARIN engineering and the OpenBSD > developers independently found the error within ARIN’s repository. The > fix was developed and deployed on 13 August at 11:36 AM. It was not just rpki-client (linked against LibreSSL), but the FORT validator (linked against OpenSSL) also flagged the same issue and emitted an error. LibreSSL and OpenSSL's RPKI extensions do share some public APIs, (and have some code in common), but they are distinct implementations from separate development communities. > Here is a detailed analysis of the error: > > During RPKI repository generation, ARIN creates “manifests.” A > manifest is cryptographic object specific to the RPKI which is used to > help guarantee the integrity of the repository. One manifest is > associated with each resource certificate in the repository. The > manifest, flagged by the OpenSSL-based validators, had a subtle > encoding issue. > > The manifest in question essentially contains two > copies of an AlgorithmIdentifier variable in different locations (and > used for different purposes). Per RFC 5280, Section 4.1.1.2, these two > instances must match completely. In ARIN’s manifest, one contained an > empty string (“”) as a parameter and the other contained a NULL > (pointer to nothing). The empty string parameter was incorrect and the > OpenSSL-based validators were flagging this because the two > definitions of AlgorithmIdentifier did not match. [ off topic note: from what I understand, the technical reason these identifiers MUST match is to make certain X.509 fingerprinting operations possible. If both identifiers had the (required) parameter field omitted the situation would've been different. ] > Planned Corrective actions: > > As a corrective action, ARIN will be broadening its testing strategy. > In future releases, we will be validating not only LibreSSL-based > validators (RIPE’s Validator and NLNetlab’s Routinator) but also > OpenSSL-based validators such as rpki-client and Fort. The list of > validators we do test against the ARIN repository will be noted within > the RPKI section of ARIN’s website. This is a good and sensible plan. Note: Neither RIPE's Validator and routinator are not based on LibreSSL or OpenSSL. RIPE uses a cryptographic library called "Bouncy Castle" and routinator appears (to in part?) rely on library bindings from the rust ecosystem (which under the hood may link LibreSSL or OpenSSL), but also in part seem to attempt to build their own crypto. LibreSSL and OpenSSL both reject X.509 data with this type of encoding issue, and consequently any RPKI validator implementations linked against these libraries will automatically consider the algorithmidentifier mismatch an error. It is key to ensure not only a diverse set of validator implementations is used for testing, but also care is taken to ensure a diverse set of cryptographic libraries are put through the test. It was not rpki-client or FORT rejecting the data, it was libressl and openssl rejecting the data. FORT and rpki-client have committed to a strict (safe) interpretation of how cryptographic data should be handled and what those design choices mean for internet operations in the global routing table. If either of these implementations are used to confirm the correct operating of the ARIN Trust Anchor (in cojunction with less strict implementations), one will not only find the lowest common denominator, but in doing also adhere to the highest standards. Kind regards, Job From nobody Wed Aug 26 10:07:26 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 93CCA3A1785 for ; Wed, 26 Aug 2020 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yttcXi50t30H for ; Wed, 26 Aug 2020 10:07:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E443A1783 for ; Wed, 26 Aug 2020 10:07:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kAytJ-0003DK-Sw; Wed, 26 Aug 2020 17:07:18 +0000 Date: Wed, 26 Aug 2020 10:07:15 -0700 Message-ID: From: Randy Bush To: Keyur Patel Cc: "sidrops@ietf.org" In-Reply-To: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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, 26 Aug 2020 17:07:25 -0000 > A working group last call has been requested for > draft-sidrops-bgpsec-validation-signaling-03, $B!H(BBGPsec Validation State > Signaling$B!I(B. Please reply to the list with your comments. The WGLC will > end on August 25, 2020. i think this is as good as we will do in this area. sad to say, among other things, we are going to have rov incapable devices in our networks for some years. but yes nick, perhaps sec cons could be sterner about filtering the community. as you know, i am not fond of communities and leakage thereof. but we're not going over to idr and creating an attribute. randy From nobody Wed Aug 26 11:24:49 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 963CC3A003F for ; Wed, 26 Aug 2020 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo-GAclgsOAO for ; Wed, 26 Aug 2020 11:24:46 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55633A0044 for ; Wed, 26 Aug 2020 11:24:45 -0700 (PDT) Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 17CA01933F; Wed, 26 Aug 2020 20:24:43 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Wed, 26 Aug 2020 20:24:42 +0200 From: Martin Hoffmann To: Job Snijders Cc: John Curran , "sidrops@ietf.org" Message-ID: <20200826202442.232829fc@grisu.home.partim.org> In-Reply-To: <20200826160001.GF95612@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 18:24:48 -0000 Job Snijders wrote: >=20 > The current versions of routinator and ripe ncc's validator have weak > (lacking) support for manifest handling, there are other issues in > both softwares that don't yield errors where they should yield errors > related to manifest handling. Neither implementation handles > manifests correctly at the moment, so neither software currently can > be used to confirm the correct publication of manifest related > data. :-( To the best of my knowledge, Routinator and the RIPE NCC RPKI Validator handle manifests according to the specifications laid out in the relevant standards track IETF documents. I assume that you are referring to your assessment that all objects published by a CA should be discarded if any inconsistencies are discovered. While such behaviour is certainly acceptable under the current specification, not doing so does not constitute incorrect handling of manifests. Given that this topic is currently discussed in this very working group and there wasn=E2=80=99t outright consensus on how software should be= have in these cases, it seems only prudent to delay modifications until after such consensus has been achieved. If you have information about other issues these software packages have with regards to manifest handling -- as you seem to imply there are multiple issues --, I am sure the maintainers would like to hear about them. Regards, Martin From nobody Thu Aug 27 05:30:21 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 85FBF3A0C8E for ; Thu, 27 Aug 2020 05:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=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 (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAZ_iTjtfNeF for ; Thu, 27 Aug 2020 05:30:18 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 58CFF3A0C90 for ; Thu, 27 Aug 2020 05:30:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E75EAB1; Thu, 27 Aug 2020 14:30:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1598531413; bh=7CDR93SmCAUx6MZBS5WVXFAYahMCkbvSttO/gz6z39Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0AKimR1tvA8RHPAYTkIEg0721aNIfJVk64+3zxEfuNty0IzGeIVFx4fwS/vipnGaT ra52IxqMPkOCIXEBzfEgfpRzwwUCCHXol1+N9JM76GRDJQxfQ8dOKLbiu6KPu6QcaX 33NI33FtN/qsKd+7McoOIoib8T12LRwbGzmkPpM0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E3625B0; Thu, 27 Aug 2020 14:30:13 +0200 (CEST) Date: Thu, 27 Aug 2020 14:30:13 +0200 (CEST) From: Mikael Abrahamsson To: Martin Hoffmann cc: Job Snijders , John Curran , "sidrops@ietf.org" In-Reply-To: <20200826202442.232829fc@grisu.home.partim.org> Message-ID: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 12:30:21 -0000 On Wed, 26 Aug 2020, Martin Hoffmann wrote: > To the best of my knowledge, Routinator and the RIPE NCC RPKI Validator > handle manifests according to the specifications laid out in the > relevant standards track IETF documents. I assume that you are referring > to your assessment that all objects published by a CA should be > discarded if any inconsistencies are discovered. While such behaviour is > certainly acceptable under the current specification, not doing so does > not constitute incorrect handling of manifests. At this point in time, everybody I am aware of who are implementing RPKI in the routing system are doing invalid=drop, and nothing else. The overall goal right now is to make sure the ROA is correctly validated, all the way. If a ROA is gone, it doesn't cause an outage. It causes lack of protection. It's not a competition which validator can validate the most ROAs, the competition should be to get things *right*. If something doesn't validate correctly, drop it. Drop all it depends on. If all ROAs from a RIR are gone for an hour or a day, it's not the end of the world. It's not an outage. We need to make sure the entire ecosystem gets things right, correct, and have procedures in place to do things right, all the time. Other parts of the Internet ecosystem had teething problems in the beginning, but they worked it out. RPKI ecosystem needs to do the same. The goal of the validator should be to validate. It should be picky. It should throw things away that doesn't look right. You're advocating for something else, and I don't understand why. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 27 05:42:43 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 BC16A3A0CAF for ; Thu, 27 Aug 2020 05:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJWr7o3uABUU for ; Thu, 27 Aug 2020 05:42:40 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:110:201::52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852703A0CAB for ; Thu, 27 Aug 2020 05:42:40 -0700 (PDT) Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTPS id A7EE61075831; Thu, 27 Aug 2020 08:42:39 -0400 (EDT) Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2020 08:42:33 -0400 Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Thu, 27 Aug 2020 08:42:33 -0400 From: John Curran To: Mikael Abrahamsson CC: Martin Hoffmann , Job Snijders , "sidrops@ietf.org" Thread-Topic: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) Thread-Index: AQHWe8H1lyby13eRVkOYMJjWzO6cXKlK998AgAEvSoCAAAN4AA== Date: Thu, 27 Aug 2020 12:42:33 +0000 Message-ID: <7329ECB9-6622-4C0B-8E73-2BC2297A3703@arin.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.136.136.37] Content-Type: text/plain; charset="utf-8" Content-ID: <16CBECF66743144FA1A3220089094FA2@corp.arin.net> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 12:42:42 -0000 T24gMjcgQXVnIDIwMjAsIGF0IDg6MzAgQU0sIE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3 bS5wcC5zZT4gd3JvdGU6DQo+IA0KPiBPbiBXZWQsIDI2IEF1ZyAyMDIwLCBNYXJ0aW4gSG9mZm1h bm4gd3JvdGU6DQo+IA0KPj4gVG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCBSb3V0aW5hdG9y IGFuZCB0aGUgUklQRSBOQ0MgUlBLSSBWYWxpZGF0b3IgaGFuZGxlIG1hbmlmZXN0cyBhY2NvcmRp bmcgdG8gdGhlIHNwZWNpZmljYXRpb25zIGxhaWQgb3V0IGluIHRoZSByZWxldmFudCBzdGFuZGFy ZHMgdHJhY2sgSUVURiBkb2N1bWVudHMuIEkgYXNzdW1lIHRoYXQgeW91IGFyZSByZWZlcnJpbmcg dG8geW91ciBhc3Nlc3NtZW50IHRoYXQgYWxsIG9iamVjdHMgcHVibGlzaGVkIGJ5IGEgQ0Egc2hv dWxkIGJlIGRpc2NhcmRlZCBpZiBhbnkgaW5jb25zaXN0ZW5jaWVzIGFyZSBkaXNjb3ZlcmVkLiBX aGlsZSBzdWNoIGJlaGF2aW91ciBpcyBjZXJ0YWlubHkgYWNjZXB0YWJsZSB1bmRlciB0aGUgY3Vy cmVudCBzcGVjaWZpY2F0aW9uLCBub3QgZG9pbmcgc28gZG9lcyBub3QgY29uc3RpdHV0ZSBpbmNv cnJlY3QgaGFuZGxpbmcgb2YgbWFuaWZlc3RzLg0KPiANCj4gQXQgdGhpcyBwb2ludCBpbiB0aW1l LCBldmVyeWJvZHkgSSBhbSBhd2FyZSBvZiB3aG8gYXJlIGltcGxlbWVudGluZyBSUEtJIGluIHRo ZSByb3V0aW5nIHN5c3RlbSBhcmUgZG9pbmcgaW52YWxpZD1kcm9wLCBhbmQgbm90aGluZyBlbHNl Lg0KPiANCj4gVGhlIG92ZXJhbGwgZ29hbCByaWdodCBub3cgaXMgdG8gbWFrZSBzdXJlIHRoZSBS T0EgaXMgY29ycmVjdGx5IHZhbGlkYXRlZCwgYWxsIHRoZSB3YXkuIElmIGEgUk9BIGlzIGdvbmUs IGl0IGRvZXNuJ3QgY2F1c2UgYW4gb3V0YWdlLiBJdCBjYXVzZXMgbGFjayBvZiBwcm90ZWN0aW9u LiBJdCdzIG5vdCBhIGNvbXBldGl0aW9uIHdoaWNoIHZhbGlkYXRvciBjYW4gdmFsaWRhdGUgdGhl IG1vc3QgUk9BcywgdGhlIGNvbXBldGl0aW9uIHNob3VsZCBiZSB0byBnZXQgdGhpbmdzICpyaWdo dCouDQo+IA0KPiBJZiBzb21ldGhpbmcgZG9lc24ndCB2YWxpZGF0ZSBjb3JyZWN0bHksIGRyb3Ag aXQuIERyb3AgYWxsIGl0IGRlcGVuZHMgb24uIElmIGFsbCBST0FzIGZyb20gYSBSSVIgYXJlIGdv bmUgZm9yIGFuIGhvdXIgb3IgYSBkYXksIGl0J3Mgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxkLiBJ dCdzIG5vdCBhbiBvdXRhZ2UuDQo+IA0KPiBXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgZW50aXJl IGVjb3N5c3RlbSBnZXRzIHRoaW5ncyByaWdodCwgY29ycmVjdCwgYW5kIGhhdmUgcHJvY2VkdXJl cyBpbiBwbGFjZSB0byBkbyB0aGluZ3MgcmlnaHQsIGFsbCB0aGUgdGltZS4gT3RoZXIgcGFydHMg b2YgdGhlIEludGVybmV0IGVjb3N5c3RlbSBoYWQgdGVldGhpbmcgcHJvYmxlbXMgaW4gdGhlIGJl Z2lubmluZywgYnV0IHRoZXkgd29ya2VkIGl0IG91dC4gUlBLSSBlY29zeXN0ZW0gbmVlZHMgdG8g ZG8gdGhlIHNhbWUuDQo+IA0KPiBUaGUgZ29hbCBvZiB0aGUgdmFsaWRhdG9yIHNob3VsZCBiZSB0 byB2YWxpZGF0ZS4gSXQgc2hvdWxkIGJlIHBpY2t5LiBJdCBzaG91bGQgdGhyb3cgdGhpbmdzIGF3 YXkgdGhhdCBkb2Vzbid0IGxvb2sgcmlnaHQuIFlvdSdyZSBhZHZvY2F0aW5nIGZvciBzb21ldGhp bmcgZWxzZSwgYW5kIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkuDQoNCk1pa2FlbCAtIA0KDQoJRGlk IHlvdSBtZWFuIGEpIOKAnGRyb3AgaXTigJ0gb3IgYikg4oCcZHJvcCBpdCB3aXRoIHZlcnkgY2xl YXIgYW5kIHNwZWNpZmljIG1lc3NhZ2VzIHRoYXQgYWxsb3cgZm9yIHJlYWR5IGlkZW50aWZpY2F0 aW9uIG9mIHRoZSBpc3N1ZeKAnSA/DQoNCgkoSeKAmW0gdW5hd2FyZSBob3cgd2UgZ2V0IHRvICd3 b3JrIG91dCB0aGUgdGVldGhpbmcgaXNzdWVz4oCZLCBhcyB5b3Ugc3VnZ2VzdCwgdW5sZXNzIHlv dSBtZWFudCB0aGUgbGF0dGVyIGFuZCBpdHMgZGV0YWlsZWQgbWVzc2FnZXPigKYpIA0KDQovSm9o bg0KDQpKb2huIEN1cnJhbg0KUHJlc2lkZW50IGFuZCBDRU8NCkFtZXJpY2FuIFJlZ2lzdHJ5IGZv ciBJbnRlcm5ldCBOdW1iZXJzDQoNCg0KDQoNCg== From nobody Thu Aug 27 06:40:54 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 6401D3A097E for ; Thu, 27 Aug 2020 06:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTGOG4q6jodZ for ; Thu, 27 Aug 2020 06:40:50 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330093A097C for ; Thu, 27 Aug 2020 06:40:49 -0700 (PDT) Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8C9DF1A645; Thu, 27 Aug 2020 15:40:45 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com Date: Thu, 27 Aug 2020 15:40:45 +0200 From: Martin Hoffmann To: Mikael Abrahamsson Cc: "sidrops@ietf.org" Message-ID: <20200827154045.52498a15@glaurung.nlnetlabs.nl> In-Reply-To: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> Organization: Open Netlabs X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Reason for Outage report 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, 27 Aug 2020 13:40:52 -0000 Mikael Abrahamsson wrote: >=20 > At this point in time, everybody I am aware of who are implementing > RPKI in the routing system are doing invalid=3Ddrop, and nothing else. >=20 > The overall goal right now is to make sure the ROA is correctly > validated, all the way. If a ROA is gone, it doesn't cause an outage. > It causes lack of protection. It's not a competition which validator > can validate the most ROAs, the competition should be to get things > *right*. >=20 > If something doesn't validate correctly, drop it. Drop all it depends > on. If all ROAs from a RIR are gone for an hour or a day, it's not > the end of the world. It's not an outage. >=20 > We need to make sure the entire ecosystem gets things right, correct, > and have procedures in place to do things right, all the time. Other > parts of the Internet ecosystem had teething problems in the > beginning, but they worked it out. RPKI ecosystem needs to do the > same. >=20 > The goal of the validator should be to validate. It should be picky. > It should throw things away that doesn't look right. You're > advocating for something else, and I don't understand why. Two separate things. First, you will notice that I talked about delaying modifications, not refusing modifications. I strongly believe that a change in invalidation strategy should be discussed in the community and the best possible strategy found. We are talking about security here which is never easy and the obvious answers are frequently wrong. For instance: If a ROA is found to be invalid, should all the ROAs published by the issuing CA and its child CAs be dropped or should not in fact all statements made for resources owned by the CA be filtered completely, even those made by unrelated CAs? Only the latter covers for cases where a route might accidentally become invalid because its prefix was authorized to two or more CAs. Further, the current proposal suggests to reuse non-expired cached data instead. Routinator, for example, does not in fact do that and needs significant changes to its architecture to make that possible. Do I want to make those changes before the community agrees that using old objects is a good idea? Doing so may make it easier to block object revocation. Do we prefer that over just not having certain objects at all? I don=E2=80=99t think there is consensus yet. Second and entirely independent of the first, the matter of the validity of that ARIN manifest. Some of us have concluded that it didn=E2=80=99t need rejecting because it was not in fact invalid. While it = was indeed encoded in a way that is not allowed by the respective specs for encoders, the specs instruct decoders to be more forgiving. Such forgiveness is a decision an implementer makes. The particular mistake did not alter the meaning of these fields or endangered the cryptographic integrity of the certificate as an RPKI resource certificate, hence the decision to accept such certificates. This assessment might be different were the certificate used in another context and thus it may indeed need to be rejected by a general purpose library, but a library that only and exclusively deals in RPKI resource certificates does not. Should it be picky nonetheless and drop anything that looks vaguely suspicious? Would you be surprised to hear that if we indeed did that, out of the currently 175,330 VRPs, a mere 3,571 would be left. Even if we interpreted unclear RFCs in favour of implementers, we still would be down to 54,258 or about a third. Would dropping all these VRPs out of caution make the Internet more secure? It is kind of hard to argue for that. I believe that whether a security system in itself is more or less secure is an entirely irrelevant question. It needs to be assessed in terms of whether it makes the thing it serves more secure. And so need concrete implementations and all the decisions made along the way. Kind regards, Martin From nobody Thu Aug 27 06:48:21 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 111ED3A0AE7 for ; Thu, 27 Aug 2020 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=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 (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uESF488GMPX6 for ; Thu, 27 Aug 2020 06:48:18 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 25E343A0ABB for ; Thu, 27 Aug 2020 06:47:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1209BB1; Thu, 27 Aug 2020 15:47:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1598536067; bh=j++igncls6ihgFyW2mXnNhxF9FdD9itTyEjwwNs/2sE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lQmaLFWo+4YvTZ8z8G3MaclJQDlqs5E3K1MbKyOxkjz590m9YLrn07XrCXlzgil02 +hvwpL9B/EmpORMwTgAAUwN/D4HAjB7TxZbJ8fAhQk8YbNIhI7hmreGL3bIQZD77lS u3AKRyvURyspOZbl/MNHPyX0nSzL835fs/wHelUI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0ECA4B0; Thu, 27 Aug 2020 15:47:47 +0200 (CEST) Date: Thu, 27 Aug 2020 15:47:47 +0200 (CEST) From: Mikael Abrahamsson To: John Curran cc: Martin Hoffmann , Job Snijders , "sidrops@ietf.org" In-Reply-To: <7329ECB9-6622-4C0B-8E73-2BC2297A3703@arin.net> Message-ID: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <7329ECB9-6622-4C0B-8E73-2BC2297A3703@arin.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-409383974-1598536067=:11025" Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 13:48:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-409383974-1598536067=:11025 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 27 Aug 2020, John Curran wrote: > Did you mean a) “drop it” or b) “drop it with very clear and specific messages that allow for ready identification of the issue” ? I just take for granted that if something is dropped because it was incorrect, there is a diagnostic message generated so it can be fault found. so "b)". > (I’m unaware how we get to 'work out the teething issues’, as you > suggest, unless you meant the latter and its detailed messages…) Of course. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-409383974-1598536067=:11025-- From nobody Thu Aug 27 06:50: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 C23A93A0B2C for ; Thu, 27 Aug 2020 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvhdCGU2-vVj for ; Thu, 27 Aug 2020 06:50:20 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 0B6883A0AE7 for ; Thu, 27 Aug 2020 06:50:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CE2AAB1; Thu, 27 Aug 2020 15:50:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1598536214; bh=bP+Qpdipe6KI9m9Sl9jyqbC0+83WCokJumJSwnqfUbo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=h5vAUsjQMsuy5TKxHd+vqZ0MjiqGpmO14zqQkYcIIQ4kFCFzlvn06fFFPHd5hDVyk 6cqqRcP6/nHQni7oQDO3WTBD3sx9z5bfU5+Crh1DycNhkSvC7daN7KbEjgxQPiUn4r zu0y9YQEPILvmNKqhPH5VFgWrwit1ttN4wMD2zSI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CC725B0; Thu, 27 Aug 2020 15:50:14 +0200 (CEST) Date: Thu, 27 Aug 2020 15:50:14 +0200 (CEST) From: Mikael Abrahamsson To: Martin Hoffmann cc: "sidrops@ietf.org" In-Reply-To: <20200827154045.52498a15@glaurung.nlnetlabs.nl> Message-ID: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827154045.52498a15@glaurung.nlnetlabs.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Sidrops] Reason for Outage report 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, 27 Aug 2020 13:50:22 -0000 On Thu, 27 Aug 2020, Martin Hoffmann wrote: > Should it be picky nonetheless and drop anything that looks vaguely > suspicious? Would you be surprised to hear that if we indeed did that, > out of the currently 175,330 VRPs, a mere 3,571 would be left. Even if > we interpreted unclear RFCs in favour of implementers, we still would be > down to 54,258 or about a third. That's fine, let's then fix those. What's wrong with them? Has this been fed back to the people responsible for them? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Aug 27 07:28: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 E96D23A0C17 for ; Thu, 27 Aug 2020 07:28:32 -0700 (PDT) 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 n9kxsZufpJ5S for ; Thu, 27 Aug 2020 07:28:31 -0700 (PDT) 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 330DF3A0C16 for ; Thu, 27 Aug 2020 07:28:31 -0700 (PDT) Received: from bench.sobornost.net (233-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.233]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id CDED2220136; Thu, 27 Aug 2020 14:28:29 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id ff14e15e; Thu, 27 Aug 2020 14:28:28 +0000 (UTC) Date: Thu, 27 Aug 2020 14:28:27 +0000 From: Job Snijders To: sidrops@ietf.org Message-ID: <20200827142827.GC88356@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200826202442.232829fc@grisu.home.partim.org> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 27 Aug 2020 14:28:33 -0000 Dear all, It pains me to write this email. It appears there is an increasingly acrimonious situation in which RIPE NCC, Cloudflare, and NLNetLabs representatives not only produce and publish insecure software, but also argue towards erosion of the robustness of the object security RPKI depends on. I'm drawing harsh conclusions: the reality is that we are now 6 months into /what should've been/ a simple bug report, but turned into a trench war. Folks are digging in their heels deeper. Attempts in this group to bridge the knowledge gap have failed so far. On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: > Job Snijders wrote: > > The current versions of routinator and ripe ncc's validator have weak > > (lacking) support for manifest handling, there are other issues in > > both softwares that don't yield errors where they should yield errors > > related to manifest handling. Neither implementation handles > > manifests correctly at the moment, so neither software currently can > > be used to confirm the correct publication of manifest related > > data. :-( > > To the best of my knowledge, Routinator and the RIPE NCC RPKI > Validator handle manifests according to the specifications laid out in > the relevant standards track IETF documents. The implementers of RIPE NCC's validator, Routinator, and OctoRPKI entirely missed the point of WHY RPKI Manifests exist at all. The bigger picture is ignored, one can't look at normative terms in a vacuum. I quote from the INTRODUCTION of RFC6486: "A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point." A Manifest makes it possible for a validator software to react sanely when data tampering is detected. Manifests exist to *protect* both the issuing CA and the RP, failure to acknowledge the purpose of manifests is akin to the famous quote "the operation was successful - but the patient died". Did any CA ever wish for an incomplete view of their routing intentions to be transformed into routing decisions? Zero CAs want this. One has to look further than the normative terms, one has to realize what the implications are to routing in the global system and inevitably the conclusion is to err on the side of caution. To be cynical about what data is provided via an untrusted network input channel. Why implement a virus scanner, which can detect virus files, but subsequently doesn't do anything about it? Manifests are the *only* mechanism to verify a publication point's completeness and integrity. Neither Routinator nor RIPE NCC's software attach any consequence to integrity issues at a publication point. Both continue to emit as many VRPs as possible, regardless of whether the publication point is complete to begin with! The datastructure of Route Origin Authorizations (ROAs) allows only a single origin ASN per .roa file, this means network operators who wish to grant permission to multiple ASNs (a common example: their own and their customers' ASNs) to originate parts of their IP space, they *have* the create multiple .roa files. The IP Block owner's routing intentions can only be considered when the full bundle of .roa files is available. Logically, when some .roa files are missing (which according to a valid current manifest must be present), the remaining .roa files at the publication point become useless as they represent an *incomplete* overview of routing intentions; even worse those files flip from 'useless' to 'dangerous' when they are injected as VRPs into the operator's routing system. Manifests are analogous to to Debian's "Release + Release.gpg" APT archive concepts. APT (or yum/dnf) do *not* proceed to install packages when critical dependencies are missing, or when the SIGNED checksums do not match the checksum of the downloaded .deb file. An administrator has to *explicitly* override (-y --force) to install such packages when dependencies or checksums don't match. Let me demonstrate what happens when I cherry-pick just a few words you wrote, and withhold some of your other words. You wrote this email: https://mailarchive.ietf.org/arch/msg/sidrops/7JxOCNBvYbwDHL7hcPHsfvxto0Q/ *** start of modified email *** On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: > Routinator and the RIPE NCC RPKI Validator have issues. *** end of modified email *** Do you see the issue now? I didn't even change the order of your words, I merely withheld some of the text you wrote, and the resulting text is entirely contradictory to what you intended to write! Let's be honest, neither RIPE NCC nor NLNetLabs have real experience using RPKI ROV 'invalid == reject' in their own networks. RIPE NCC so far has refused to implement ROV in AS 3333 out of fear, and NLNetLab's own ASN is a simple single-homed stub network. Why are both organisations ignoring the community's pleas to fix a security issue? Why the hubris? Do you really think you know better? Why does Alexander Band say that fixing this is "not a priority", why is RIPE NCC refusing to commit a one-line patch to fix their validator? Is loss of face the issue? The longer the delay to provide a fix, the longer NLNetLabs and RIPE NCC keep hurting their users (and dependents). Is this what one calls 'good for the Internet'? The issue was brought to attention MONTHS [1] ago, it should've been a few days to get it patched. > Given that this topic is currently discussed in this very working > group and there wasn’t outright consensus on how software should behave > in these cases, it seems only prudent to delay modifications until > after such consensus has been achieved. The only ones arguing against the consensus are RIPE NCC and NLNetLabs employees. Go figure. Staff and knowledge were exchanged between the two software houses, a path is visible how the misconceptions continued to proliferate. It is not too late to change course, but catch-up is needed. Believe it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an existential crisis: your credibility is on the line. Are you going to produce routing security software which actually improves security, or not? Will you attempt to absorb decades of PKI and X.509 experience, or throw it all in the wind? Currently routinator + ripe ncc's validator + octorpki set their users up for failure. Operators using these softwares ARE AT NEEDLESS RISK. Regards, Job [1]: https://github.com/NLnetLabs/routinator/issues/319 https://github.com/RIPE-NCC/rpki-validator-3/issues/232 https://github.com/RIPE-NCC/rpki-validator-3/issues/158 https://github.com/cloudflare/cfrpki/issues/38 From nobody Thu Aug 27 07:32: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 1A7153A0C6C for ; Thu, 27 Aug 2020 07:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 1foKB3oeD0jC for ; Thu, 27 Aug 2020 07:32:50 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE833A0D17 for ; Thu, 27 Aug 2020 07:32:43 -0700 (PDT) Received: from [172.20.10.4] (unknown [109.37.137.176]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A5E041A706; Thu, 27 Aug 2020 16:32:41 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598538761; bh=jZJmrpygDAFXWP5jAmCKcC5JHnjCZSQok9fZzrYCiIg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lMFrNFm0HrwoRogIMz+KSd6pwT9TmoWOZIXrej4w/ZngOvV4bNFMZFQtpqa/O0jg5 DuFpmQ+K9XY78+hYmhJ9/ZzzlCTemIMppQzz1gnvU6M+pFSIN4XI+wYV8LDBPtprLm s7IJXhq4yOt4oaR32M31CwvNMqSKVVZW2eeXkMZw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> Date: Thu, 27 Aug 2020 16:32:40 +0200 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> To: John Curran X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 14:32:52 -0000 Hi John, all, > On 26 Aug 2020, at 16:54, John Curran wrote: >=20 >> As a corrective action, ARIN will be broadening its testing strategy. = In future releases, we will be validating not only LibreSSL-based = validators (RIPE=E2=80=99s Validator and NLNetlab=E2=80=99s Routinator) = but also OpenSSL-based validators such as rpki-client and Fort. The list = of validators we do test against the ARIN repository will be noted = within the RPKI section of ARIN=E2=80=99s website. fwiw, we have automated tests for Krill where we set it up with an = embedded TA and a CA which produces a bunch of ROAs. We then expect the = same set of VRPs to come out on the other end of: - fort 1.1.3 - octorpki v1.1.4 - rcynic buildbot-1.0.1544679302 - routinator 0.7.0-pre - rpkiclient VERSION_0_3_0 - RIPE NCC RPKI Validator 3.1-2020.07.06.14.28 We try to use 'strict' modes where available. The set up is based on GitHub actions, Terraform and docker. The details = are probably not interesting to this mailing list, but if CA or RP = implementors want to have more details please feel free to contact me = directly. Tim =20= From nobody Thu Aug 27 08:07: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 C03AD3A0D69 for ; Thu, 27 Aug 2020 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 0HoRNtHvtm7S for ; Thu, 27 Aug 2020 08:07:55 -0700 (PDT) Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.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 4210F3A0D55 for ; Thu, 27 Aug 2020 08:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598540874; bh=psrHXBF9aFDTiLVy6oBvG5NQYeOOkbqx8TWihTlRcKU=; h=Subject:From:To:References:Date:In-Reply-To:From:Subject; b=CjRk3MvLN8ipW+Fs8Go9V7Qra7KUcL+xVMzXhS22VI5knufYNFK1DKsWoDaKQeIRahoEG/Q0X8OTNXUti0I9+01xPX/VzJeLnmZG5kNvLaVdvjFw6yTnyI+ukqa75jEzMfO/iq0+HQ2acxLHBqejJITBIlMXOWWskgWwBj4QZH9kl8bZozXdpC9kC9D9bgb7YtbQU+xkpknppBi5WZ2zu3mKz6x1DUAtZNt09c58z7NGSAPdnQtYvCybnqHPhNotC6zLO8tY/lt0XPRTAhFygON1fMCkZtWXCIsMPdgxT3w2K3o+hwDFHuEMW00OsEiV0Ir5xGuwk60JopEhlPlX6w== X-YMail-OSG: _ZOdvU0VM1kNOEJmc1z3dEiOKXSw4yWcUt9qr.tQt0ByN9THawh.XA8Sj9PeLnK fLW8RIoP3kURq2HniMddLrVxDCtMeigd.TojHGlJlKfjFiJ5yxiiglhu.lbjm7KJMMpVF2414qKa VhhoYq1Ywl.D9nbJjYPEGV9YqX5OnrsXxEFaOp9McPrmdOXkZfd0tx2CUyiV_zwRKgf_rzQQW1Wc DCt6KKUmcy0tNlwdb0vj5DhcS0z.fbhVCJjQodWbDhRQ0jJULH1yxwAvVQBk.kXH.bYhVonIguAg .EszNrTqHs8I7U4gcgr.vXC9grqyJu_OSvB81NbqI8qHm2_o7O2ydDQhXLLWz9JcXopzHB0nPBD2 G2oPNxGoifBm_FQNHX82kDmQd_v79y2iXiQvOOMctmxA7NZD1ozeQlpzqYExeREg.9p6DbvSs9aK M6U2VT8.5V7XeZOBhfiZxosMEx500xtRRrs_XJrJF9BW8qeMsyZ0Yd9xWloWpS1fA6yFYCesUgvj 6nIOZbhjiysLbvMtI_JrZTjBEU_QqbEwD4J5lpb11SnV9UF9Kr6EWYKzuUBmmrV4iF64C8AVtW1p WgQtBr624ZWLlFkKAFKUF3WHPn5yGRlt4GF6iz11MuSgDKDTQdeu2nWUdDyUt_7PhRP12ltS0sAt HSxt3BkJ7cIPMDaWr63DayXJCwm1aAdFSPJSNjroGnLcr_BW3ep3c5Gec1mO37mH6sjYzsKPpZ5K xzy7rGbOpBXNltz7LlvRzdZALzMpWTeNViY3otMJtgu43eE9BPecn8SFYAVyn47JMINSpUbntjWs ZJLJUcCQzPuYRuHvMk7Yr06GnolV0ecIkbVq6xNDFVcsj6ENQzUfBkNwhbJ6IBvICJdDTsIbGx3g 61MszWZZGC2M65BKJwzKLBL8OVoL1Tv36..h7r7_gvenNfZCYC_jbpWidjwUkgrQe0ipuHbJlY5o L3cApy7wcBWuBvceWU24ILiTANlztw.SGECmv9U98QeyJc58vZMJEgX.Ozvuw9rxBHtHR5hY6LcV 1CDrneRBL8WS_9RFETLuFXo7ZgNhOe2LgtjZ8pwvfp78NN5sQZR26RebRiI6v8tGN_RepgFQDYy2 uwj6JIaPftIjxfpLsP24bgh6Bg1oDHyV8sXl1gmTtVGfA1ek3NhOts0tV0Z4Lxs_x4VfAYr5Ch02 tC5a5dcjcPpYUaBVNClvEeBR3ktCxEKykLraJ6Dr599OAcsPW2g0iavtSKh7R9loL7omvq.1J.P0 exOI1MiA8BTkMMqLBA9UT0AGhCogJkZWan85g5xQ6dLDsAs.ssQu.mw8S.qpDjlpXpC5GkRCDlAA gP1fDV7NDwfO7lvQgAmxwzTGEDh3XmUGr2ZCjKDDb8E0TrejqBPyNmwAJtI7vLYIvj3MByaS_vk9 1oDGHw2l675ey6vxgLRUsffeBJxCKhH6JOmvIweQlhWaQIQl0T8yyn59eh2pgmYZyd3Ty4F.B1Hl B8WYIOvZukezZvgZm.ujSLyGBzAOmW4an273Ww04D4_mw5mHR65ztvi.GLol385gh8w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 27 Aug 2020 15:07:54 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ec463013e9f0de4b2ed1942291634c15; Thu, 27 Aug 2020 15:07:51 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> Message-ID: Date: Thu, 27 Aug 2020 11:07:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 27 Aug 2020 15:07:57 -0000 Martin, > ... >>> "not update anymore" is not how I would state the result. This fetch >>> will fail. Because a failed fetch will be reported to the RP >>> operations staff, hopefully they will contact the cognizant entity >>> for the pub point in question, causing the error to be fixed. Them a >>> subsequent fetch can succeed. >> That seems like an overly optimistic approach to the issue. Assume the >> problem is created by a bug or, worse, design oversight in the CA >> software. The turnaround from discovering the issue to deploying a fix >> can easily be weeks with some vendors. During all that time, not only >> can no ROAs be updated and may child CA certificates slowly expire, the >> entire CA’s data will not be available at all for any newly deployed >> relying parties. With containerised deployment, this is quite a serious >> issue. >> >> As a consequence, this approach will make the routing system less >> secure for, I’d like to argue, no actual gain. When I the WG chairs tell me that I misunderstood the WG consensus re strict correctness then I will revisit this topic. However, the recent messages from Mikael and Job suggest that your perception of WG consensus is not accurate. This issue is one that needs to be decided by network operators, not by developers of RP software. I agree with the observations made by Mikael and Job, i.e., that requiring strict conformance with manifest rules is the preferred approach. >>>> You could argue “Don’t do that, then” but this approach doesn’t make >>>> the RPKI more robust but rather makes it break more easily on simple >>>> oversights. >>> My sense of the WG discussion was that the majority of  folks chose >>> to prioritize correctness over robustness, and I made numerous >>> changes to the text to reflect that. >> I disagree with the blanket assessment that this approach makes RPKI more >> correct. To switch to the example I should have used in the first place: >> Ignoring a broken GBR object when producing a list of VRPs does not >> make the list less correct. In fact, the opposite is true: Ignoring the >> CA or updates to the CA because of a broken GBR makes this list less >> correct. I suspect we disagree on what constitutes "correct." A correctly functioning CA does not publish objects with bad signatures or format errors, use certs that have expired, does not fail to replace expired or stale objects, does not include objects at pub points that are not on the manifest, etc. > >>> ... >> You absolutely have to deal with this issue in 6486bis in its current >> strict form. Any introduction of a new object type will permanently >> break CAs that use these objects when validated with a relying party >> software that is not aware of this type. I don’t think this is >> acceptable, as it effectively blocks the introduction of new types >> pretty much forever. No, it does not. What I suggested is that when a new object is proposed, it is the responsibility of the those proposing the new object to explain how it will be incrementally deployed. That explanation belongs in the RFC defining the new object, and in an updated version of 6486 will need to be generated. We have no good examples of new objects that provide a basis for describing how to accommodate incremental deployment, and thus no basis for defining such mechanisms at this time. It might be the case that a new object will be defined that requires the CA to maintain a separate pub point using some newly-defined SIA pointer, indicting that the new pub point contains the new object and thus RPs that don't know how to process the object MUST NOT follow that pointer. There will need to be agreement on how long a CA MUST maintain the old pub point, etc. But, absent a concrete example of a new object type that warrants this sort of effort it is premature to write a spec. >>> Instead I believe it >>> makes sense for any new object proposed for inclusion in the RPKI >>> repository system to address this question as part of its >>> documentation; it's not clear that a uniform approach is appropriate, >>> i.e., one size may not fit all. 6486 can be updated to reflect the >>> processing approach proposed for any new objects. >> It seems to me that the best approach is to simply ignore unknown >> objects. We could argue whether they can be ignored completely or >> whether one should at least check their manifest hash. Personally, I >> think completely ignoring is the better approach as I don’t see any >> benefit in rejecting a CA because someone swapped out an object I don’t >> care about. > > In X.509 certs we mark extensions as critical, or not. An extension marked as critical will cause a cert to be rejected by an RP that does not know how to process that extension. One might revise the generic signed object definition (RFC 6488)  introduce a similar flag. But, first, we would have to figure out how to incrementally deploy the new signed object format, with a new version number, etc. I hope you see why this approach to incremental deployment of new object types probably would entail more that a revision of 6486. >> Ultimately, I feel we’ve swung the pendulum way too far to the other >> side. The RPKI isn’t a single data set that needs to synchronized in >> full but it consists of multiple data sets that can be treated as >> independent: currently these are VRPs, router keys, and GBRs. If I use >> the RPKI for route origin validation, I don’t need to synchronize the >> router keys or GBRs. Why does it improve route origin validation if >> available and correctly signed data is skipped because of issues with >> irrelevant data? The RPKI was designed to support origin validation first, and BGPsec second. The set of objects that were defined are intended to support these two functions. If the WG decides to extend the set of supported functions it needs to take a hard look at a wide range of RFCs that will be affected, not just 6486. Steve From nobody Thu Aug 27 08:16: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 4FD583A0DA6; Thu, 27 Aug 2020 08:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 ZdwZjyGnu79Q; Thu, 27 Aug 2020 08:16:35 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CA13A0DCC; Thu, 27 Aug 2020 08:16:34 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 07RFGW3o090024 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Aug 2020 16:16:32 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Stephen Kent Cc: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> From: Nick Hilliard Message-ID: <915de042-af0f-e518-c841-5a10402c1868@foobar.org> Date: Thu, 27 Aug 2020 16:16:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.27 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 27 Aug 2020 15:16:37 -0000 Stephen Kent wrote on 27/08/2020 16:07: > When I the WG chairs tell me that I misunderstood the WG consensus re > strict correctness then I will revisit this topic. However, the recent > messages from Mikael and Job suggest that your perception of WG > consensus is not accurate. This issue is one that needs to be decided by > network operators, not by developers of RP software. I agree with the > observations made by Mikael and Job, i.e., that requiring strict > conformance with manifest rules is the preferred approach. I concur - strictness is generally desirable when dealing with data integrity. In this case, the manifest problem was harmless and the data integrity was unaffected. Speaking as an operator and rpki consumer, what I don't have good handle on is whether the manifest checks that would be required to detect the problem that happened at ARIN would also detect actual manifest integrity problems. If the answer to this is yes, then there is no question about whether these checks should be added to the code bases that currently lack them. Otherwise they are a nice-to-have, and I'd very much like to see them added. Nick From nobody Thu Aug 27 08:40: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 E1E093A0F02; Thu, 27 Aug 2020 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVTzI3C71eRo; Thu, 27 Aug 2020 08:40:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334BE3A0ECA; Thu, 27 Aug 2020 08:40:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kBK1C-0006jQ-FX; Thu, 27 Aug 2020 15:40:50 +0000 Date: Thu, 27 Aug 2020 08:40:50 -0700 Message-ID: From: Randy Bush To: Stephen Kent Cc: sidrops@ietf.org In-Reply-To: <20200827142827.GC88356@bench.sobornost.net> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 27 Aug 2020 15:40:55 -0000 > I agree with the observations made by Mikael and Job, i.e., that > requiring strict conformance with manifest rules is the preferred > approach. otherwise, why the heck would we make them. this non-compliance is destructive. i try to save civil disobedience for BLM etc. > I suspect we disagree on what constitutes "correct." A correctly > functioning CA does not publish objects with bad signatures or format > errors, use certs that have expired, does not fail to replace expired > or stale objects, does not include objects at pub points that are not > on the manifest, etc. this would seem to be pretty obvious, CA 101. > No, it does not. What I suggested is that when a new object is > proposed, it is the responsibility of the those proposing the new > object to explain how it will be incrementally deployed. cf router keys, ASPA Job Snijders wrote: > It pains me to write this email. It appears there is an increasingly > acrimonious situation in which RIPE NCC, Cloudflare, and NLNetLabs > representatives not only produce and publish insecure software, but > also argue towards erosion of the robustness of the object security > RPKI depends on. you are too polite. it is destructive of the internet and therefore quite dangerous. > I quote from the INTRODUCTION of RFC6486: > > "A manifest is intended to allow an RP to detect unauthorized object > removal or the substitution of stale versions of objects at a > publication point." seemed pretty simple at the time so we have 6486-bis in progress. but if some vendors have the arrogance to continue these same games, why should we bother? > Did any CA ever wish for an incomplete view of their routing > intentions to be transformed into routing decisions? Zero CAs want > this. sad to say, given the "we can do whatever the hell we want" dogma, i have my suspicions otherwise. or is it just lack of ops clue? > *** start of modified email *** > On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: > > Routinator and the RIPE NCC RPKI Validator have issues. > *** end of modified email *** > > Do you see the issue now? I didn't even change the order of your words, > I merely withheld some of the text you wrote, and the resulting text is > entirely contradictory to what you intended to write! yes. but it is correct! :) > Believe it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an > existential crisis: your credibility is on the line. no, for some of us, it's gone. randy From nobody Thu Aug 27 10:31:00 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 CEE8E3A111F for ; Thu, 27 Aug 2020 10:30:58 -0700 (PDT) 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=VZP3k4R7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u7xQk3AL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pabJVlpr6muM for ; Thu, 27 Aug 2020 10:30:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8076C3A111E for ; Thu, 27 Aug 2020 10:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=583; q=dns/txt; s=iport; t=1598549457; x=1599759057; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CYwsJuPE/2EYc4DD1R8HCr7OvR152UYOBEsB6okrAVs=; b=VZP3k4R7FJHnRmvRz5EPuLuIkMdDuwDl0sHYirjhscU21cbAYSO5NhjP a8rtlqLcSJsMtUItHxwFGnGDkCJqFfcTZb7LYwLltoNujRzXdO03NHEcK keWrchyRwUkkfG3agR33Jh3+uTaJ+xSd5bCD9Sw0/9taiHj3bpGaOEoOD M=; IronPort-PHdr: =?us-ascii?q?9a23=3A9j9ITR+ij44w1P9uRHGN82YQeigqvan1NQcJ65?= =?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-Anti-Spam-Result: =?us-ascii?q?A0BUAQBm7Udf/40NJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYFRUQeBSC8sh30DjXKYcYJTA1ULAQEBDAEBLQI?= =?us-ascii?q?EAQGETAKCSQIkNwYOAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAwESKAYBATc?= =?us-ascii?q?BBAcEAgEIFQEgBQsyJQIEAQ0NGoMEgkwDDiABqDYCgTmIYXSBNIMBAQEFhTg?= =?us-ascii?q?YghAJgTgBgnCKNBuBQT+BVIIfLj5pG4M7g0iCLY96pmIKgmOaToJ1nVCFYIx?= =?us-ascii?q?sn0sCBAIEBQIOAQEFgWokgVdwFYMkUBcCDY4fN4M6ilZ0NwIGCgEBAwl8j3U?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.76,360,1592870400"; d="scan'208";a="726998268" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 17:30:56 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RHUuDb032270 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2020 17:30:56 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 12:30:56 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 Aug 2020 12:30:55 -0500 Received: from NAM11-BN8-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; Thu, 27 Aug 2020 13:30:55 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQyAzZyKH50JFVpKwZeTPNjJ/1m+IRZYNiC4eXVLy7gXPVPOHVBJHEtma8MCw8Alo/9V0PZcnvBe1c5M4cPD8O6W+MK2JBPPYuSXQcnHsrrusu1gpA9cuCaf51jfu36+jyGEZFTvqfiqrPRfZUU5c07YNxx1dy9es2zddXOL+RW21dNEhOVi76rw8nPJuUBkXKUFd69me1r/mEpVY+7RYZAHvZzhhaEPYqE5lgjZyjyANHW0+g23b4ca0ULADazfFayNebQwzjwGleC+DCx68rvZu/lneFQkpzpNE8nUkEPsgIdQEvhR3eMN+cKwiXisnypoiaysQrwPmS/qq9ncYw== 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=CYwsJuPE/2EYc4DD1R8HCr7OvR152UYOBEsB6okrAVs=; b=kgD26KypaAk8aXrPxU+BgoAzFbFujY5vP9jXH4VL2fWPoCpmNDV4jmqqc/kVySOvKMcFGq9nd6BV9QCW+kqQ7aBCiEnQCqqkkGfDQ0nGTGWCCQyYReH7BfPL/TUzXpUaDdUi7KCn6gNWvwDvNrMdAKHh45XM+KIK+HFBr5BPWlx/Fe7VIOGgWkYGBAZiWnu46dh5hZryUivtm1bj5fw28EueU2vhvrpY2ntipWuF2JEYTxgf94IJfiyArfDzDWb+IiswFdVzwebZgeRDlVzHCk1ka0lLA1wDe3b8ox61stUGdgKVvlBmlpXe8gGKiLVMglVK+PKO0XhqOuZmujKvpg== 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=CYwsJuPE/2EYc4DD1R8HCr7OvR152UYOBEsB6okrAVs=; b=u7xQk3ALnM8O8ebY8YQq5M5APavzIGA7jTRgnnmAjZ49Ixgfd6Rl9HhT70OWTGnYphOYq/b+j0YRfcfRoJCzmj0GAbQAlRAYp4YYDmLRxTyxSdD0HfSBsPyEsXt0mMd4AtUlUAC2jQtFYotqTlCIuJ3OJnbqTdlmlw8lBcrhs1M= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3638.namprd11.prod.outlook.com (2603:10b6:a03:f8::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Thu, 27 Aug 2020 17:30:54 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff%2]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 17:30:54 +0000 From: "Jakob Heitz (jheitz)" To: Mikael Abrahamsson , Martin Hoffmann CC: John Curran , "sidrops@ietf.org" , Job Snijders Thread-Topic: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) Thread-Index: AQHWe7jpH81/uUT4x0Sz5/cY5XwZRKlKjHaAgAAobQCAAS9KgIAAUfJQ Date: Thu, 27 Aug 2020 17:30:54 +0000 Message-ID: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> In-Reply-To: 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:29c8:c183:7a95:c6a8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51503958-2b03-4091-d048-08d84aaef3a5 x-ms-traffictypediagnostic: BYAPR11MB3638: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2201; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2HR5iLH2WA2lEZfTuDv41ae5XHBzdw978mym/20LxtqVzGlSnXoXGtn6XbR2C1YCzqiMBhujxvxUl900ClQHo2NAzBqvQ1SEyQmEcs8SDTjZHzqrzHrcnH1j5SHRcvOUI6yajmxYya8piSj0SANlYf+QKs2ralXcHpQqD4/Clzs2GOF8WDqrQsAh++0Y7kPDywFvF+MtPH63QWaAieWlEXfi5VCkTObKbfo+1t3oY2j401jUctEiI0MA06DWc2cMVn4yBaKbBnrvV3rjZab1ufrH45L+29413yeeo51LN+ydaffcypECQdaIBIIbGhLhNDvekx2E70hZKpm9DsoMtg== 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:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(2906002)(86362001)(186003)(54906003)(110136005)(66556008)(66946007)(4326008)(64756008)(66476007)(76116006)(66446008)(6506007)(316002)(83380400001)(8676002)(52536014)(7696005)(33656002)(8936002)(4744005)(478600001)(71200400001)(5660300002)(9686003)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +4WgStHs1ktmA1JxE+rnISM92noPmcF2QI3eKsVHSBOkVaKicfs17LfCFrgoYqVgjQW3/uxUm0LPdBXwe5QzypYa6MEW8qVXGdGeenfy7+tIsH/F38cvqM8Ce2jC7fEiRjz8Bf0dg4vvvVBTzTNpw8aK+S0bg1INqE6ZDMvj+tVLToOOALHVpmfNSG+8osj3mGJJkSEYslTLLmk9Ia8XULfiFjxb5R9cWcoJ3eIvu50BYRhmgwvu4uZEOdCixbQcw/tqXuHb85loJHVoRxmoxG5Nhxr9FslwLbxw0DbHwdQ5FSTZqe0a7lfIHEG+bcgxw55EzbM3k4PbL89l45Qf6xSDA+nmoIME4CjXE6VGBzRG4rd+EXariZGF/sTfASV1VVvyz5/8WjYUPKfs8jhsQVj8DLUiU6I8C/8S4rC8IXp/8wD9ZOXNkah/v/2jFTCYOL00v6fE3FSe0We4dHXAc48igi+hiQKxkYP8zLf13wMTAltMUZMA2mo3Zhotvr/xgt1JwdSav2DMfzvid7ZzM4/l7CjAf6fhV+CCQWRdw+1kKd//dmobpPmhcLoUcSMRmp8ushFoI+1ObqWPL7mxbWkVRBv9OtioobUkPP4SMVE85xXHojDavJZPeHLQykIvb0haoTYdXKDp76s00U+JWFdExMdsgf4+PQ3CILnClsOId1+HdsduU6xfD2C3KJV8mNkS3nJrcY9FQXRyOR41WQ== 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: 51503958-2b03-4091-d048-08d84aaef3a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 17:30:54.3461 (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: yBJEcF8qUBPG1GOjOZL0dtP/Qh9XIH1qqBm4atG+twjr3ivEswo9qQPABBumEvZd8Hgwmbl+a/FNJ2VWDVcgLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3638 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 17:30:59 -0000 -----Original Message----- From: Mikael Abrahamsson Sent: Thursday, August 27, 2020 5:30 AM > If a ROA is gone, it doesn't cause an outage. It causes lack of protectio= n. Suppose a provider has a ROA for a large prefix and subdivides it into more= specifics. It allocates these more specifics to other ASes and those ASes publish ROAs= for those more specifics. If the ROAs for the more specifics are gone, then the less specific ROA for the larger prefix will invalidate announcements for the more specific p= refixes. That's an outage. Regards, Jakob. From nobody Thu Aug 27 10:49: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 005F33A11B2; Thu, 27 Aug 2020 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRsfOVJj80oY; Thu, 27 Aug 2020 10:49:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19913A11B7; Thu, 27 Aug 2020 10:49:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kBM1u-0007mK-QJ; Thu, 27 Aug 2020 17:49:42 +0000 Date: Thu, 27 Aug 2020 10:49:42 -0700 Message-ID: From: Randy Bush To: Jakob Heitz Cc: SIDR Operations WG In-Reply-To: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 27 Aug 2020 17:49:55 -0000 > If the ROAs for the more specifics are gone, then the less specific > ROA for the larger prefix will invalidate announcements for the more > specific prefixes. yep; simply stated. and perhaps the more likely common case. a less common case could be if i am doing a provider switch where my upstreams do my announcements. for "make before break" i would have roas for both providers. if the roa for the one which is currently announcing is dropped, kaboom. similarly a transfer of ip space from one AS to another. the correctness of CA publication point data and the rigor and reliability of RP collection and propagation to routers is critical. and the threat of half-assed vendor software is a far bigger and more real threat to operations than the dutch court attack boogeyperson. randy From nobody Thu Aug 27 13:39:33 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 518E03A12DA for ; Thu, 27 Aug 2020 13:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 64-mUjWZQH3S for ; Thu, 27 Aug 2020 13:39:31 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5B43A12C1 for ; Thu, 27 Aug 2020 13:39:31 -0700 (PDT) Received: from hydrogen.localdomain (217-122-250-127.cable.dynamic.v4.ziggo.nl [217.122.250.127]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id EEE5A1ABFE for ; Thu, 27 Aug 2020 22:39:28 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=NLnetLabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=benno@NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598560769; bh=3GcR6jZcvIE/lGoA1LFYUCjUGaf37mLezidv/zEgEDU=; h=Subject:To:References:From:Date:In-Reply-To; b=VGniWxuZjWdeZx6YSYq5C7MEy0RT99z3gyDOt8k1B5maje6ZbzJqTT3RcCmwbeSk9 18dvOB3YE8JGU1EMCYpM9H42pmlbYjZDc/B+TbFNjr6Th9w0W2dQE/yUh4DbJIziqq Rj3obiC/OHAiNkNkxuW6Sqe+/HNdq800qz+CJ+qA= To: sidrops@ietf.org References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> From: Benno Overeinder Message-ID: Date: Thu, 27 Aug 2020 22:39:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200827142827.GC88356@bench.sobornost.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 27 Aug 2020 20:39:32 -0000 On 27/08/2020 16:28, Job Snijders wrote: > The only ones arguing against the consensus are RIPE NCC and NLNetLabs > employees. Go figure. Staff and knowledge were exchanged between the two > software houses, a path is visible how the misconceptions continued to > proliferate. It is not too late to change course, but catch-up is > needed. Please stick to technical arguments in the discussion on the mailing list, and omit insinuations and false extrapolations. Thank you. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From nobody Thu Aug 27 23:33:13 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 05A213A15A4 for ; Thu, 27 Aug 2020 23:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OCFJkOGurVmW for ; Thu, 27 Aug 2020 23:33:09 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141563A159B for ; Thu, 27 Aug 2020 23:33:08 -0700 (PDT) Received: from yoda.fritz.box (62-251-31-8.ip.xs4all.nl [62.251.31.8]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 22D331B270; Fri, 28 Aug 2020 08:33:06 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598596386; bh=8fVX3kf50AQ5rJgD4UZcMFfdfFLmtBTV1NMZpJt4Aq0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=n356CPhhi2ZCdImJ1c47bJztsuBQU9gngzmtWaShWKv4heUlZiTuTnkQsJwrBuHsC o381yIFUj0i7DEVBrZe7IUt+Z2in0nUl5gST2fCXMba5vy2PNSectAGkTaXBbNS00D 6x1d74FqyDKp55TOPm/MwoA+euxS2WqtpbKopIok= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: <20200827142827.GC88356@bench.sobornost.net> Date: Fri, 28 Aug 2020 08:33:04 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 06:33:11 -0000 Dear WG, Please allow me to zoom out a bit.. Much of this discussion is caused by: a) different interpretations of a spec b) differing views on Postel's Law and how it should (not) be applied in = a security context @a: the spec While I write RPKI CA code, I was not intimately involved in writing = validation code related to the particular issue in ARIN's manifest. The = discussion however was painful. Bug reports were created. They were not = blindly followed. People double checked. People argued that it should be = discussed in the IETF, and not on GitHub. People had differing = interpretations on what encodings are okay. Painful as it was I believe = that in the end a discussion based on the content of this particular = issue did take place in this group. ARIN fixed their manifest and the RP = implementers planned fixes for inclusion in upcoming releases. @b: the robustness principle and security Should any and all violations of spec lead to the rejection of objects? Arguments can be made, are being made, that in the context of security = the answer this question is 'yes'. It makes for a simpler world, and = simple is good when it comes to security. There is no slippery slope = anymore. Taking this even further one can argue (in the context of = manifests) that if an RP knows that it has *all current products* of a = CA, and the CA clearly messed up even one object - they should no longer = be trusted to know what they are doing. The counterarguments are that we have existing deployments, and that = there are shades of gray in this world. The bug in ARIN's manifest seemed to me to be a violation of spec, but = not necessarily a critical security issue. The algorithms are all = specified in the relevant RPKI RFCs - hashes and signatures providing = proof of possession worked out. The dialect may have been funny, but the = intent was clear. This is not the only existing encoding issue. The bouncy castle library = used by both the RIPE NCC and Lacnic code bases produces CMS that is = BER, not DER, encoded. The specs say that DER MUST be used. While this = is is the case OpenSSL and other implementations will happily decode BER = encoded CMS objects - most other CMS implementations use BER after all. = This is a violation of spec, but is this a critical security issue? Other examples were found over the years. And I have no doubt that other = deviations from the specs exist today. Some went unnoticed for years (9 years of deployment) - and are only = being found now that more independent RP tools are being built. This is a good thing. But does this mean that we should reject all = objects that do not conform to spec today? That would leave alarmingly = few VRPs. Should we apply 'shades of gray' - and allow certain = deviations from spec if we feel they are not harmful, indefinitely? Or = should we aim for full compliance in years to come, but give CAs time to = fix existing issues? I would like to believe that it's okay to have different viewpoints on = this during the discussion phase. And while I may have my own opinions = of what I feel is right, I am quite willing to change my mind if we can = discuss these matters openly and constructively. Kind regards, Tim > On 27 Aug 2020, at 16:28, Job Snijders wrote: >=20 > Dear all, >=20 > It pains me to write this email. It appears there is an increasingly > acrimonious situation in which RIPE NCC, Cloudflare, and NLNetLabs > representatives not only produce and publish insecure software, but = also > argue towards erosion of the robustness of the object security RPKI > depends on. >=20 > I'm drawing harsh conclusions: the reality is that we are now 6 months > into /what should've been/ a simple bug report, but turned into a = trench > war. Folks are digging in their heels deeper. Attempts in this group = to > bridge the knowledge gap have failed so far. >=20 > On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: >> Job Snijders wrote: >>> The current versions of routinator and ripe ncc's validator have = weak >>> (lacking) support for manifest handling, there are other issues in >>> both softwares that don't yield errors where they should yield = errors >>> related to manifest handling. Neither implementation handles >>> manifests correctly at the moment, so neither software currently can >>> be used to confirm the correct publication of manifest related >>> data. :-( >>=20 >> To the best of my knowledge, Routinator and the RIPE NCC RPKI >> Validator handle manifests according to the specifications laid out = in >> the relevant standards track IETF documents.=20 >=20 > The implementers of RIPE NCC's validator, Routinator, and OctoRPKI > entirely missed the point of WHY RPKI Manifests exist at all. The = bigger > picture is ignored, one can't look at normative terms in a vacuum. >=20 > I quote from the INTRODUCTION of RFC6486: >=20 > "A manifest is intended to allow an RP to detect unauthorized = object > removal or the substitution of stale versions of objects at a > publication point." >=20 > A Manifest makes it possible for a validator software to react sanely > when data tampering is detected. Manifests exist to *protect* both the > issuing CA and the RP, failure to acknowledge the purpose of manifests > is akin to the famous quote "the operation was successful - but the > patient died". Did any CA ever wish for an incomplete view of their > routing intentions to be transformed into routing decisions? Zero CAs > want this. >=20 > One has to look further than the normative terms, one has to realize > what the implications are to routing in the global system and = inevitably > the conclusion is to err on the side of caution. To be cynical about > what data is provided via an untrusted network input channel. Why > implement a virus scanner, which can detect virus files, but > subsequently doesn't do anything about it? >=20 > Manifests are the *only* mechanism to verify a publication point's > completeness and integrity. Neither Routinator nor RIPE NCC's software > attach any consequence to integrity issues at a publication point. = Both > continue to emit as many VRPs as possible, regardless of whether the > publication point is complete to begin with!=20 >=20 > The datastructure of Route Origin Authorizations (ROAs) allows only a > single origin ASN per .roa file, this means network operators who wish > to grant permission to multiple ASNs (a common example: their own and > their customers' ASNs) to originate parts of their IP space, they = *have* > the create multiple .roa files. The IP Block owner's routing = intentions > can only be considered when the full bundle of .roa files is = available. >=20 > Logically, when some .roa files are missing (which according to a = valid > current manifest must be present), the remaining .roa files at the > publication point become useless as they represent an *incomplete* > overview of routing intentions; even worse those files flip from > 'useless' to 'dangerous' when they are injected as VRPs into the > operator's routing system. >=20 > Manifests are analogous to to Debian's "Release + Release.gpg" APT > archive concepts. APT (or yum/dnf) do *not* proceed to install = packages > when critical dependencies are missing, or when the SIGNED checksums = do > not match the checksum of the downloaded .deb file. An administrator > has to *explicitly* override (-y --force) to install such packages = when > dependencies or checksums don't match. >=20 > Let me demonstrate what happens when I cherry-pick just a few words = you > wrote, and withhold some of your other words. You wrote this email: > = https://mailarchive.ietf.org/arch/msg/sidrops/7JxOCNBvYbwDHL7hcPHsfvxto0Q/= >=20 > *** start of modified email *** > On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: >> Routinator and the RIPE NCC RPKI Validator have issues. > *** end of modified email *** >=20 > Do you see the issue now? I didn't even change the order of your = words, > I merely withheld some of the text you wrote, and the resulting text = is > entirely contradictory to what you intended to write! >=20 > Let's be honest, neither RIPE NCC nor NLNetLabs have real experience > using RPKI ROV 'invalid =3D=3D reject' in their own networks. RIPE NCC = so > far has refused to implement ROV in AS 3333 out of fear, and = NLNetLab's > own ASN is a simple single-homed stub network. Why are both > organisations ignoring the community's pleas to fix a security issue? > Why the hubris? Do you really think you know better? Why does = Alexander > Band say that fixing this is "not a priority", why is RIPE NCC = refusing > to commit a one-line patch to fix their validator? >=20 > Is loss of face the issue? The longer the delay to provide a fix, the > longer NLNetLabs and RIPE NCC keep hurting their users (and = dependents). > Is this what one calls 'good for the Internet'? The issue was brought = to > attention MONTHS [1] ago, it should've been a few days to get it = patched. >=20 >> Given that this topic is currently discussed in this very working >> group and there wasn=E2=80=99t outright consensus on how software = should behave >> in these cases, it seems only prudent to delay modifications until >> after such consensus has been achieved. >=20 > The only ones arguing against the consensus are RIPE NCC and NLNetLabs > employees. Go figure. Staff and knowledge were exchanged between the = two > software houses, a path is visible how the misconceptions continued to > proliferate. It is not too late to change course, but catch-up is > needed. >=20 > Believe it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an > existential crisis: your credibility is on the line. Are you going to > produce routing security software which actually improves security, or > not? Will you attempt to absorb decades of PKI and X.509 experience, = or > throw it all in the wind?=20 >=20 > Currently routinator + ripe ncc's validator + octorpki set their users > up for failure. Operators using these softwares ARE AT NEEDLESS RISK.=20= >=20 > Regards, >=20 > Job >=20 > [1]: https://github.com/NLnetLabs/routinator/issues/319 > https://github.com/RIPE-NCC/rpki-validator-3/issues/232 > https://github.com/RIPE-NCC/rpki-validator-3/issues/158 > https://github.com/cloudflare/cfrpki/issues/38 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Aug 27 23:40:49 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 5314C3A159B for ; Thu, 27 Aug 2020 23:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kSoFK09D4JdS for ; Thu, 27 Aug 2020 23:40:47 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9613A0D45 for ; Thu, 27 Aug 2020 23:40:47 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 88CF51B2B8; Fri, 28 Aug 2020 08:40:45 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598596845; bh=JIsMsS3JgDZYTT4fprsiZ/sfpOqSPFMAy811GAavHK0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lb5J3GbEiWvXxzI8DzrgNmRvlU4Nm+AUJ2VbYZv4/5/wkTWG81JrNq3Ah9sJIOekp ngniPg11IeoXGO4jgJ8spm16iqQxZwT2CzPlUniMzPFyP1++cwjc+vxcxW9RY5Kz1X iwTVcXWkPyzhH9dnsc6hV+R+bYqkxMbHFiaQoYbU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 28 Aug 2020 08:40:45 +0200 Cc: Jakob Heitz , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 06:40:48 -0000 Hi, > On 27 Aug 2020, at 19:49, Randy Bush wrote: >=20 >> If the ROAs for the more specifics are gone, then the less specific >> ROA for the larger prefix will invalidate announcements for the more >> specific prefixes. >=20 > yep; simply stated. and perhaps the more likely common case. >=20 > a less common case could be if i am doing a provider switch where my > upstreams do my announcements. for "make before break" i would have > roas for both providers. if the roa for the one which is currently > announcing is dropped, kaboom. >=20 > similarly a transfer of ip space from one AS to another. Indeed, I believe that, if the publication point for a Certification = Authority in the RPKI is rejected for whatever reason, then all VRPS for = prefixes overlapping the resources issued to them in their CA = certificate for said publication point should be filtered out. Note that most RP software already implements SLURM - and this kind of = post-validation filtering can be done in a very similar way. It is important to only do this for VALID CA certificates with invalid = publication points. This is what I said above, but I just want to be = overly clear here.. because if one would start doing this for invalid = over-claiming CA certificates then this would of course open a wide = vector for people to DoS legitimate statements about other people's = address space. Tim From nobody Fri Aug 28 00:45: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 D1A1A3A14A4 for ; Fri, 28 Aug 2020 00:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAHVY1rWBVxK for ; Fri, 28 Aug 2020 00:45:41 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D8A3A15AC for ; Fri, 28 Aug 2020 00:45:41 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4AED71B382; Fri, 28 Aug 2020 09:45:39 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598600739; bh=QKM2Ke8ZGMfnEktitYqvXcvUOxfUDUoxX6zq7IcFy1w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SMiGAp+xw965SVOhIDVFuwZ+tTdEOLVztGyrlMfx6AXfQXZF99CFCCljY/9cpR86V etN7wtGJSkvBOdaSdE03j+tPIjnUQx2DnKKLuz0hnfvv3CARBMjvfUOpfLU2UGCgCC o7szTpSrSWzhomKsoQhOwXDv1St7gbys3mqbbTL4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 28 Aug 2020 09:45:39 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> To: Stephen Kent X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 28 Aug 2020 07:45:44 -0000 Hi, > On 27 Aug 2020, at 17:07, Stephen Kent = wrote: >=20 > Martin, >> ... >>>> "not update anymore" is not how I would state the result. This = fetch >>>> will fail. Because a failed fetch will be reported to the RP >>>> operations staff, hopefully they will contact the cognizant entity >>>> for the pub point in question, causing the error to be fixed. Them = a >>>> subsequent fetch can succeed. >>> That seems like an overly optimistic approach to the issue. Assume = the >>> problem is created by a bug or, worse, design oversight in the CA >>> software. The turnaround from discovering the issue to deploying a = fix >>> can easily be weeks with some vendors. During all that time, not = only >>> can no ROAs be updated and may child CA certificates slowly expire, = the >>> entire CA=E2=80=99s data will not be available at all for any newly = deployed >>> relying parties. With containerised deployment, this is quite a = serious >>> issue. >>>=20 >>> As a consequence, this approach will make the routing system less >>> secure for, I=E2=80=99d like to argue, no actual gain. >=20 > When I the WG chairs tell me that I misunderstood the WG consensus re = strict correctness then I will revisit this topic. However, the recent = messages from Mikael and Job suggest that your perception of WG = consensus is not accurate. This issue is one that needs to be decided by = network operators, not by developers of RP software. I agree with the = observations made by Mikael and Job, i.e., that requiring strict = conformance with manifest rules is the preferred approach. >=20 >=20 >>>>> You could argue =E2=80=9CDon=E2=80=99t do that, then=E2=80=9D but = this approach doesn=E2=80=99t make >>>>> the RPKI more robust but rather makes it break more easily on = simple >>>>> oversights. >>>> My sense of the WG discussion was that the majority of folks chose >>>> to prioritize correctness over robustness, and I made numerous >>>> changes to the text to reflect that. >>> I disagree with the blanket assessment that this approach makes RPKI = more >>> correct. To switch to the example I should have used in the first = place: >>> Ignoring a broken GBR object when producing a list of VRPs does not >>> make the list less correct. In fact, the opposite is true: Ignoring = the >>> CA or updates to the CA because of a broken GBR makes this list less >>> correct. >=20 > I suspect we disagree on what constitutes "correct." A correctly = functioning CA does not publish objects with bad signatures or format = errors, use certs that have expired, does not fail to replace expired or = stale objects, does not include objects at pub points that are not on = the manifest, etc. I agree that a correctly functioning CA will produce a sound set of = objects. Also it is highly unlikely that a CA will just publish an = expired ROA. The much more likely scenario is that a CA is unable to = make or publish updates and the MFT and CRL go stale, and the MFT EE = expires, way before any ROA or issued cert would. That being said there are scenarios beyond the control of a CA that can = lead to invalid objects: 1) rsync If the RP does rsync only, they may get an inconsistent data set. = Transactions are not supported here. They just get an old MFT and new = CRL or vice versa, or they may get a new MFT but not the new object, = etc. This is a race condition that happens infrequently when RPs fetch = during publication. It is rare, but it does happen. I remember that many years ago I wrote code in the, then, RIPE NCC = validator 2 to catch this issue. And only process publication points if = the set was consistent. This was an allowed, but not mandated, = interpretation of 6486. Note that with RRDP we have deltas. Solving this issues was one of its = design goals. So, phasing out rsync could mitigate this. (yes, I realise now that the co-chairs asked me to re-submit the I-D for = this, and I still need to do it) 2) resource changes If the parent removes any resources from the child before the child has = had a chance to clean up objects then this will lead to invalid objects. = Being strict that *all* objects must be valid will then lead to = rejection of the CA's products. Even if it is only for a few hours. I believe that this issue could be greatly mitigated if RFC6492 would be = extended with a notion to give children a warning about planned resource = removals. The length of this warning time being a function of the = contact frequency of child CAs and the depth of the CA hierarchy. But, = if this frequency could also be stipulated - say SHOULD every 10 = minutes? Then a warning time of just a few hours would already be = plenty. However, this is a separate discussion. I do not suggest that we block = progress on 6486bis for this. I am just saying that if strict checking = for *all* objects is where the consensus goes then the WG must be aware = of these consequences and accept them. >=20 >>=20 >>>> ... >>> You absolutely have to deal with this issue in 6486bis in its = current >>> strict form. Any introduction of a new object type will permanently >>> break CAs that use these objects when validated with a relying party >>> software that is not aware of this type. I don=E2=80=99t think this = is >>> acceptable, as it effectively blocks the introduction of new types >>> pretty much forever. >=20 > No, it does not. What I suggested is that when a new object is = proposed, it is the responsibility of the those proposing the new object = to explain how it will be incrementally deployed. That explanation = belongs in the RFC defining the new object, and in an updated version of = 6486 will need to be generated. We have no good examples of new objects = that provide a basis for describing how to accommodate incremental = deployment, and thus no basis for defining such mechanisms at this time. = It might be the case that a new object will be defined that requires the = CA to maintain a separate pub point using some newly-defined SIA = pointer, indicting that the new pub point contains the new object and = thus RPs that don't know how to process the object MUST NOT follow that = pointer. There will need to be agreement on how long a CA MUST maintain = the old pub point, etc. But, absent a concrete example of a new object = type that warrants this sort of effort it is premature to write a spec. >=20 >=20 >>>> Instead I believe it >>>> makes sense for any new object proposed for inclusion in the RPKI >>>> repository system to address this question as part of its >>>> documentation; it's not clear that a uniform approach is = appropriate, >>>> i.e., one size may not fit all. 6486 can be updated to reflect the >>>> processing approach proposed for any new objects. >>> It seems to me that the best approach is to simply ignore unknown >>> objects. We could argue whether they can be ignored completely or >>> whether one should at least check their manifest hash. Personally, I >>> think completely ignoring is the better approach as I don=E2=80=99t = see any >>> benefit in rejecting a CA because someone swapped out an object I = don=E2=80=99t >>> care about. >>=20 >>=20 > In X.509 certs we mark extensions as critical, or not. An extension = marked as critical will cause a cert to be rejected by an RP that does = not know how to process that extension. One might revise the generic = signed object definition (RFC 6488) introduce a similar flag. But, = first, we would have to figure out how to incrementally deploy the new = signed object format, with a new version number, etc. I hope you see why = this approach to incremental deployment of new object types probably = would entail more that a revision of 6486. The current version of 6486 allows RPs to treat individual objects as = invalid. -bis is trying to change that to say that the whole set of = objects must be valid. This changes the consequences for the deployment = of new object types, so it is right to consider this now. The most likely next object type would be the ASPA objects. I don't = think that RPs should reject all ROAs because they do not yet understand = ASPA. Given that object types in the RPKI get distinct file names, and = RPKI signed objects get distinct OIDs I think it would be reasonable to = say that RP software can ignore object *types* that it does not = understand. I would still advocate then that the RPs do check for the = presence and hashes of these objects as stipulated by the signed MFT, = but not consider their content. If we don't then the consequence will be that new object types only = become deployable after a significant percentage of RP has been upgraded = to version that understand the new type. Now, if all operators say that they are fine with this: let things go = unknown for everyone who did not upgrade, and force them to do so.. = sure. But it is right to consider this now and make a conscious choice. = Oh and BTW.. for RPKI use cases where we only have VALID/INVALID but no = NOT FOUND, such as BGPSec, this would be problematic. >>> Ultimately, I feel we=E2=80=99ve swung the pendulum way too far to = the other >>> side. The RPKI isn=E2=80=99t a single data set that needs to = synchronized in >>> full but it consists of multiple data sets that can be treated as >>> independent: currently these are VRPs, router keys, and GBRs. If I = use >>> the RPKI for route origin validation, I don=E2=80=99t need to = synchronize the >>> router keys or GBRs. Why does it improve route origin validation if >>> available and correctly signed data is skipped because of issues = with >>> irrelevant data? >=20 > The RPKI was designed to support origin validation first, and BGPsec = second. The set of objects that were defined are intended to support = these two functions. If the WG decides to extend the set of supported = functions it needs to take a hard look at a wide range of RFCs that will = be affected, not just 6486. >=20 > Steve >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Aug 28 05:00:40 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 583B03A0934; Fri, 28 Aug 2020 05:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID8AzIl2WSYB; Fri, 28 Aug 2020 05:00:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1546F3A0928; Fri, 28 Aug 2020 05:00:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kBd3a-0007KU-Ou; Fri, 28 Aug 2020 12:00:35 +0000 Date: Fri, 28 Aug 2020 05:00:34 -0700 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: Jakob Heitz , SIDR Operations WG In-Reply-To: References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 12:00:38 -0000 excuse, but a bit pre caffeine here > I believe that, if the publication point for a Certification Authority > in the RPKI is rejected for whatever reason, then all VRPS for > prefixes overlapping the resources issued to them in their CA > certificate for said publication point should be filtered out. complexity and cleverness produce fragility. first, you may not know the prefix from the failed pp; it failed. second, getting you to think that you do could be a nice attack. > It is important to only do this for VALID CA certificates with invalid > publication points. i am not sure what an invalid pp is. one where none of the referring object(s) are cryptographically validatable to a TA? > if one would start doing this for invalid over-claiming CA > certificates then this would of course open a wide vector for people > to DoS legitimate statements about other people's address space. good reasone not to do it at all. randy From nobody Fri Aug 28 05:10: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 2C6F23A0978 for ; Fri, 28 Aug 2020 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6padwmW49qL for ; Fri, 28 Aug 2020 05:10:44 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C463A0930 for ; Fri, 28 Aug 2020 05:10:44 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 5A0421B716; Fri, 28 Aug 2020 14:10:42 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598616642; bh=XxN+FdOVyLkS0KnKzPO+B9MT5d3ryfAN4cKuxgwYPEQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MaphoM/xaWeW60EJgJjhhQ92nlasEgxY+TvLxtqtow71irTm9YsdZBfZOc+3WWeWR e9qIgvYmLMw94/tPPkltPeGDBlc/PPZzI2UljTVOb10Oc1ZqKgLZhB7tXfwbhJxqg+ EZe08Tq86wLfswCwJoqw5IhPwhHLjsSgcsettCq0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 28 Aug 2020 14:10:42 +0200 Cc: Jakob Heitz , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 12:10:46 -0000 Hi, > On 28 Aug 2020, at 14:00, Randy Bush wrote: >=20 > excuse, but a bit pre caffeine here >=20 >> I believe that, if the publication point for a Certification = Authority >> in the RPKI is rejected for whatever reason, then all VRPS for >> prefixes overlapping the resources issued to them in their CA >> certificate for said publication point should be filtered out. >=20 > complexity and cleverness produce fragility. Sure, but: 1) it may not be that complicated (SLURM does the same) 2) as you said, if you only reject the objects under one CA and the same = resources exist elsewhere this can lead to invalids >=20 > first, you may not know the prefix from the failed pp; it failed. > second, getting you to think that you do could be a nice attack. You were looking at all the objects listed on a manifest you found for a = valid CA certificate. You know which resources the valid CA certificate = holds. >> It is important to only do this for VALID CA certificates with = invalid >> publication points. >=20 > i am not sure what an invalid pp is. one where none of the referring > object(s) are cryptographically validatable to a TA? I thought the discussion here was that if any of the objects for a mft = is invalid, then all objects should be treated as invalid. By = publication point I mean the MFT and all objects listed on it, >> if one would start doing this for invalid over-claiming CA >> certificates then this would of course open a wide vector for people >> to DoS legitimate statements about other people's address space. >=20 > good reasone not to do it at all. As above.. I just wanted to make it abundantly clear.. you start off = with a validated CA certificate. >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Aug 28 05:14: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 3CC053A09DF for ; Fri, 28 Aug 2020 05:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cX2p1BhTRdWK for ; Fri, 28 Aug 2020 05:14:33 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CB83A0917 for ; Fri, 28 Aug 2020 05:14:33 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id B802E1B722; Fri, 28 Aug 2020 14:14:31 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598616871; bh=npvt2tf5OeUSvRqPWo4Degt8u0vJJQdDh+I4HgJpOno=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Wb+lt3gQLxfZbDc6jb3nYYa5dARZNzip7QzYW4GxbfBdfuq0xZAaaqoJTgCAe30rW XqvdE3ZMFi3msRB84i/Gb5i41RjNmXoSJfXZv/gR63nFwQDib3+x85c/nWh5lX5mgd VQdPnIZa8ND/+iPVoQFKmKQzfMZH0zSzW+eXgUnc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> Date: Fri, 28 Aug 2020 14:14:31 +0200 Cc: Jakob Heitz , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <54D0DBD9-4E4C-425C-B08A-6C42ADC7733D@nlnetlabs.nl> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 12:14:34 -0000 > On 28 Aug 2020, at 14:10, Tim Bruijnzeels wrote: >=20 > Hi, >=20 >> On 28 Aug 2020, at 14:00, Randy Bush wrote: >>=20 >> excuse, but a bit pre caffeine here >>=20 >>> I believe that, if the publication point for a Certification = Authority >>> in the RPKI is rejected for whatever reason, then all VRPS for >>> prefixes overlapping the resources issued to them in their CA >>> certificate for said publication point should be filtered out. >>=20 >> complexity and cleverness produce fragility. >=20 > Sure, but: > 1) it may not be that complicated (SLURM does the same) > 2) as you said, if you only reject the objects under one CA and the = same resources exist elsewhere this can lead to invalids @2: Announcements with state RPKI Invalid w.r.t. ROV (not other invalid = objects)= From nobody Fri Aug 28 07:00: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 4E4A23A0658 for ; Fri, 28 Aug 2020 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 Vhk5AxDO7V4S for ; Fri, 28 Aug 2020 07:00:20 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.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 DDB373A08B0 for ; Fri, 28 Aug 2020 07:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598623219; bh=ua3x9Ywt3AQ4IPMT+Kuevv9ogfPBsoxx8YTEazoZO9U=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=VP/EhdpqZgFSnS/Lez+lMIIpWMpJ3RpCf9zO9mmF+eXdNljhcDmpjG6EycSRgE979sA+XlvBFxFqjzYuON5xNNDKaoYBGur5uesMnqUUUaY128lbFzVxk6QnnCPoRt3FqBtvmGbEq0QpAIOjGpptXBVConY/cE1j/7v318+WwGDgV6BwY/ACc52M8JO0QbuLr3mWmZPT43DOTqM1oCAC+ZCCUVbWdeHi4bMMa23MSjNsQR30ZumSX+h7BvSIxFfttyhtOZsnj4BTirKZ38MAQzxd3eJrXDmPn36bb6VIbv33oLxbv5EkJj091jt6mYqnisSk8wFu5BqEGOT2/hTLsQ== X-YMail-OSG: LC9lo2oVM1kOYC4_lrQE43ycWWjQeKre0lVYyFSei.HWuCvN_Dfn434AHYbi0lB 1d6jxorWJSHvY1HXNsv98g97PSFlVus5WIMpWdkxLyYt2l0oXJ1.woEaqXaYKRb8_LNf.TpQvjhb 3pIc9IroOOSEk3xyrFM5fWOLij_xnEVyiLsUwNb15.hDqJnVjE.TRGYS6bqWUp8SOdIiSZEosmJu tUhwE9vuR1hyrMLEZAfwfE1g7C3oQ979gheH.LgNF8cDo45zU9fZ28yf1uxPYXK0_.BT8OyGncA5 PEVWqHW_saALtYqJvRvlRNW51a1BgIFi9z2IX4Mhil5mRwcE7jpcNCyOSBZ26k_3JFKTG5DFBt8X eyOtxHYjNMW3mAbrpTq7GR5iGTQccCfF6l8eg6wvIuhF6bry7I498s_5beIOTuVnUMofGFmyM2Tc OJc1DydRaPvlbpsOAVs0CEPrRj9falrw8DRa_EbdjD75WRhlZUMlDlGvJPHW8kgxlnGwpHASoSmt Bs.jfygr1ctUMSXUsKMA0eKxWKx.FzcFOW62kNIYc7EU7QWfpW8b29fQCa3KgYJiUBMCfw6fYPRJ 8fwndq1zxsVMiH9eqsEeOcT1R7qeH2.x9BrDzNo4H9ddkrPBEVPWvGFVLQCtWl._1uhnDrThOwXL ZzTKKKkJxVtmcuCdlR4aGJc7wjRuVT7_Wms13.YSwLUH8TQDOH1kccVLzwQRpHaGp4lxEAZgB_0H yO4PCg.kR9P52E5ZFDy..gB48xxYMzG9SzPCIERPHy6rs3aUAQYnYiI1iuX77QIti1PiPiOUzAY4 pChfrU__5tXJwdBj.1n4XuPfDrE62rdKrVkbvgDNOSlqqbgvi9FDfpLuWW0oYOSY9H4L.b2k3x.c FH_h7qz9Yx2mjKrQnwBepqiNX07WSSVGOchBp4t512yQ9WHHft_bvg2r8Purxb8sa3fIEDX6bJ53 gzu1ND8FDpGtjdznLnoVlx1BfbfaUwKCdTuUM4gaLX.21JstOyn5BC538L_WTNrL9sunyyP61GVE EXNq0dSytB3l85ryQxA_kKaSG041J6uVZ0jeeBun9p39LSGZegERF67qlD4XGDLai9Qyb1b5hKKP s5RGbhoJjl66CKe47pUEnrPYDdu9SLgeh7n7j_njlaLRcOr0Qo0j4l67_BanRulCMgvl96o2lRei D89fYdhNR8B1tNjflGrJj3v6ro6L5aSOFGuXzPylFVdsJKZ3S0RcMZDkLPk7.d1LtTY0XrV7KAex g2i0Q536xrOvFM525BpTSBOKXDYWYwVPDWr9oRVnT.hhoayPJA8e9Uf495wDAyQ5Godtz1kBc9nM Hu_o0Bso89zPOeI4VP3YUOGt7fjh6xk0ZOs2d9f.QssW3KxFX3nR0gXyL5sxkmOMiN.QnOlv5i6A 6OSrNTNXIIqOnX4VEuE7xY55LXueEcmJDE3Atim.liIOGRMgSPxFYRqTlIIOk9skHrEjdPwRVtrx qJ8IE75dWlYZswNQTD_Ud3IxdZw7qjSwO6iQ9TLJUrRyQtri8X62ztXK_EfYE45S0ubTTTk04Fgm N0RR5vBSEO5mDktoFw5eSzPQbzJV6PQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 28 Aug 2020 14:00:19 +0000 Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a9a21888e6c0310dd3f8df5d9a1b739b; Fri, 28 Aug 2020 14:00:15 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> Message-ID: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> Date: Fri, 28 Aug 2020 10:00:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 14:00:22 -0000 Tim, > ... > > @b: the robustness principle and security Jon Postel's robustness principle is appropriate for promoting interoperability, but it is not a good principle for security. Security requires discipline. In my experience, people are not very disciplined, and thus we have recurring security problems. Experience shows that without feedback, people are not motivated to become more disciplined, and security problems become worse. Thus I feel is is critical for the community to reject RPKI repository data that does not conform to the RFCs, as a way of providing feedback and improving discipline. The revisions we have made to the manifest RFC are intended to remove ambiguity and to impose strict standards for how CAs manage the data at a pub point. We all seemed to agree that removing ambiguity is desirable and necessary, but not everyone seems to believe that strict standards are desirable. I defer to the WG chairs to decide what the consensus position is in this respect. However, at this time, suggesting that the manifest RFC needs to specify how new objects can be incrementally be introduced into the repository system is a distraction. I can envision one way to do that, as noted in a prior message, but that would entail changes to several other RFCs, and will delay, substantially, progress on revisions to the manifest RFC. I am very bothered by the observation that, if were were to strictly enforce the requirements imposed by the RPKI RFCs, then the number of verified routes would substantially decrease. This seems to suggest that it is more important to be able to cite big numbers of verified routes, to convey a sense of RPKI deployment success,  than to "encourage" CAs to get their act together and follow the standards. That, I believe, is a mistake. Steve From nobody Fri Aug 28 07:25: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 3AAC93A0C1F for ; Fri, 28 Aug 2020 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 lXgkDTKhpfLX for ; Fri, 28 Aug 2020 07:25:44 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 D17B43A0C22 for ; Fri, 28 Aug 2020 07:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598624742; bh=gpisv9Ly/AdJ62zGHFHOx4InnBLRStFml8qn8uE6jkg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Hr7T3gtM5LEJMN8KBHqZCnMsG4fYv34uy3f3caLUGne+Tfe2on1Jr2f0pp/CJKyW8ziTsjVlYlVeUSRPt2i8coXodFSN5TeY4H/x98mUU2AhmDpDsKg1zt3wyChu7BQf1RuIRiXgbim5VQ3xulSbt8J941eOWE+GaZYXhTbDMSXz6/QwfxYH1U0kvL1iWkavN57kzBTMhV1oXWIc56WNspfuscdzQOg9U0bu9FaY50c2PlMEHOIIEgnZLCwJVXT37r89R37MFJaNXoCh/yJWjTc0Ewl4r3J6/Y334vrQyw565o5zAMKd0HIYblb05+TiG2eUCCClDXFx+N+lYC3OHg== X-YMail-OSG: _BlQw_gVM1kM4Nk95QGpB8R09fikdkVcSPQ3790zFFpRwVqsZ62JUvc.oD6j8oA LI2L6opL_tK9WSRp0Vhq8ZrvzciZOlXzWARxen6spPlVUmm9lvw7v0I4FKncBjBfS6BwiVIJs6Lf IPyMskTLPY4UYOZ_flPPzdTsksiAczV9yOjqeBibQf2iDVlDamLVxOr_Cu02jqqV.kpWJJZfNpbM qWMaAO23zSr3ldzocQ3P2_VhT5pAoe22GDX1kbJSbTN.oy6QsGxPSA_rMWUeLJ3_nQY40Zwp3dLf BOa6U4OMZ2DEws9ubqLmpfwffkDSL346fyBPeAo5idMZ0LTB0q_AElpXST22Flr55K_fm5hMvhEo mIrqmX2qydSsMAUrpR9cvdmU.QRIyr0gJetvS5vTES0B0jIOVJoRab5SlIhG2km5YEVcyHwrw0Ph RwHvUxwXGTwTqxJJF_4E4DSfEXoBkJ8p6.uUlL0duSmXAY12dY7LZH_GRFnMJTTLACmtZIqPwrlh Z6Aby5OsTqprwae3wI24etm2hT2HuvOKz.2aJo1dpNcW202uXcDJnzxFc0qmW4_xn.IdrqX9xmAm 98C_vQ5JysZip9HFjYM.i016jW4bXqfUcQ4Qj_Nz4OIcNEIf0If7u.KUDD3kXGLYZxWVRUpVmz8g 6WF5.Sg7X0CubCdrjWKYRVJXAfGuaOx05bsV9jSdH5pKEkJHv3JLzFi7ayW3ZvsVtNYxVs4ZtCRv rkE3GZbmmVxXRV9GGzfEk9du50YYfnhYongBJEq4dfQAe72DVJzwFDWU.8GlCI0J6HdjGy2yREO2 gVsbE9.ZJHi.RXwWNMPG1B.8JnKMKcmFkYhbLUWRkWS1uycY0XSr15oXrWwK8mmj0KH4CKfrkHw. YPanrJWqVjlDKdOvsGHS7ujKFahuPLTpmbTSZx1b_06EgxvHo5ttac1ZsEos7uOhZCcxSInEWKmF Yd3gOWDLfc7N2TjqXkq7dN7RTMIhdDQbbqBPeqwxQniBna2ygOXZNDe7rb38K1J8iuG3uQaWfPwB XrsXfDnPm1ZLhggYpNs9IVAHecdZdfhwN6hUfUZUCBrYYWBTV7cXG_iPVURBhDCUT1DFAfp.BKq3 DqL03hpd57r155aPqwaQkaB1UP9pq9P9m2cESWvPixl8e7dHLRimJqYssc0hzZ7.jgJu7Xhq_aB5 wcRVsGpUC_lIFAUbYxpWSzuGNce8rNNB49Z6Kbp26P12I9Gaurf3B0fYhkk26bF2fg.8j6L2QdHk ehXNxcYuvHMrA0rZjv3xg0On_VVFExvEfFl8wjdZ5w25koTmleoDGGY7GlAU.mWFU1GNHAG.x.Uo yzIdcQRF9YLvumkkAnfYute9u4EuI2zddSK8zgoTSPfRjDSOEJMZ4MXYLZagK7nXS5wNR9a5IR0I 7wx28gIGz.icV3JvcHry6NOFzowEA.L562SBUup18WXPwasGP2uRt4A6B4suFdZCBQHZ_5EC0HPL hzszA_wCXpx0GvszGrSKAxDZdepzK2BkHOxuaJuK_OOXsOjhEjWtZmZ4iR55EBdLqBw.tPN5y7jQ dW.vStBYWACeGs2WWH.z0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 28 Aug 2020 14:25:42 +0000 Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b4e13331f9e36cb503d78fd2be8ebbbe; Fri, 28 Aug 2020 14:25:41 +0000 (UTC) To: sidrops@ietf.org References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> From: Stephen Kent Message-ID: Date: Fri, 28 Aug 2020 10:25:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.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.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 14:25:45 -0000 Tim, > Should any and all violations of spec lead to the rejection of objects? > > Arguments can be made, are being made, that in the context of security the answer this question is 'yes'. It makes for a simpler world, and simple is good when it comes to security. There is no slippery slope anymore. Taking this even further one can argue (in the context of manifests) that if an RP knows that it has *all current products* of a CA, and the CA clearly messed up even one object - they should no longer be trusted to know what they are doing. The issue is not whether a CA that makes some types of errors cannot be trusted to know what they are doing. Rather, the issue is that, absent feedback, a CA that persistently makes such errors will do so forever, forcing all RPs to accommodate these errors. This IS a slippery slope; it paves the way to more serious errors to be tolerated, based on an established pattern of accommodating sloppy behavior. Steve From nobody Fri Aug 28 07:40: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 93C003A0C49 for ; Fri, 28 Aug 2020 07:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 WH2S1QouIoEG for ; Fri, 28 Aug 2020 07:40:21 -0700 (PDT) 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 053153A0BAA for ; Fri, 28 Aug 2020 07:40:20 -0700 (PDT) Received: from bench.sobornost.net (129-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.129]) by mail4.dllstx09.us.to.gin.ntt.net (Postfix) with ESMTPSA id 2C942EE0189; Fri, 28 Aug 2020 14:40:19 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id c2b655fe; Fri, 28 Aug 2020 14:40:17 +0000 (UTC) Date: Fri, 28 Aug 2020 14:40:17 +0000 From: Job Snijders To: Tim Bruijnzeels Cc: Randy Bush , Jakob Heitz , SIDR Operations WG Message-ID: <20200828144017.GF88356@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 14:40:23 -0000 On Fri, Aug 28, 2020 at 02:10:42PM +0200, Tim Bruijnzeels wrote: > > first, you may not know the prefix from the failed pp; it failed. > > second, getting you to think that you do could be a nice attack. > > You were looking at all the objects listed on a manifest you found for > a valid CA certificate. You know which resources the valid CA > certificate holds. Suggested text, feedback welcome: ================ If a CA's publication point's RPKI data is invalid, a Relying Party MUST add all IP address resources listed on the certificate's issuer to a Prefix Filter. The Relying party MUST consider any VRPs derived from any Trust Anchor to match with this Prefix Filter if the VRP prefix is equal to or covered by any of the Prefix Filter prefix. The following prefixes MUST NOT be added to the Prefix Filter: 0.0.0.0 and ::/0 ================ In other words, if a valid current manifest at a publication point demonstrates files are missing, the resources listed in the AIA's sbgp-ipAddrBlock extension become an output filter. If under RIPE's TA a CA delegates authority for 85.xx.0.0/16 to a publication point, and a ROA file is missing, and 85.xx.0.0/16 also exists somewhere under ARIN's TA, the RP should omit to produce VRPs covering 85.xx.0.0/16 or more specific. This is the safest approach. By excluding 0.0.0.0/0 and ::/0 we prevent one TA from taking down another TA, and encourage a (hopefully) healthy approach to operational intermediate certificates which exist to narrow the TA's blast radius. Kind regards, Job From nobody Fri Aug 28 07:55: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 3A20D3A0C50 for ; Fri, 28 Aug 2020 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGINiFcvoGcE for ; Fri, 28 Aug 2020 07:54:59 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD503A0BC8 for ; Fri, 28 Aug 2020 07:54:59 -0700 (PDT) Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8BC2C1B92A; Fri, 28 Aug 2020 16:54:56 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598626496; bh=lEYGeWYB2M9XWOuJvd9FQpN9BnhgxPBxZ5OelEH3J1U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OV4O4D5AdFeSqa0gJaac7DwumNtG8x7Q9Gg/9qTw2nrYc6IMEFljqfFwus6Suf/h+ TCdcgbbFB5bgDovsIRPYjvgLjN+xbqIjS59C9ylypsLecTKwg6SP/UFjWRTJyvZtKL Mynhl/YAnljxAgUhtQsBNo6tcALNE+EOgrmgG5eU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tim Bruijnzeels In-Reply-To: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> Date: Fri, 28 Aug 2020 16:54:56 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <10CF100D-9B71-4FA8-A3D2-2A9933B6D9E5@nlnetlabs.nl> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 14:55:02 -0000 Steve, > On 28 Aug 2020, at 16:00, Stephen Kent = wrote: >=20 > Tim, >> ... >>=20 >> @b: the robustness principle and security >=20 > Jon Postel's robustness principle is appropriate for promoting = interoperability, but it is not a good principle for security. Security = requires discipline. In my experience, people are not very disciplined, = and thus we have recurring security problems. Experience shows that = without feedback, people are not motivated to become more disciplined, = and security problems become worse. Thus I feel is is critical for the = community to reject RPKI repository data that does not conform to the = RFCs, as a way of providing feedback and improving discipline. I believe that strict conformance is a laudable goal, but I also think = that given that none of the RP software has been doing this until today = CAs should be given time to fix things. If we ask all CA implementors to test their repositories with strict = compliance validation options, then I believe that setting a flag day = for strict compliance in future can get us there without impacting = current operations. Yes, it implies that we accept that things like using the wrong type of = 'String' for a Subject, and even BER vs DER encoding, are not critical = security errors. > The revisions we have made to the manifest RFC are intended to remove = ambiguity and to impose strict standards for how CAs manage the data at = a pub point. We all seemed to agree that removing ambiguity is desirable = and necessary, but not everyone seems to believe that strict standards = are desirable. I defer to the WG chairs to decide what the consensus = position is in this respect. No, I do believe that strict standards are desirable. What I was advocating is that MFT are treated strictly by RPs to = determine that they have the full set of statements made by a CA. This = protects against issues between the CA and Publication Server, and = between a Publication Server and RP. Going beyond this by saying that if a CA makes any mistake we should = disregard everything they say has implications that I outlined in my = other email. I think there are scenarios where security is not impacted = (e.g. GBR vs ROA). But I can live with it as long as the WG understands = and accepts that there are at least two (temporary) failure scenarios = where the issuing CA is not to 'blame': inconsistent (rsync) fetches and = resource removal timing issues. > However, at this time, suggesting that the manifest RFC needs to = specify how new objects can be incrementally be introduced into the = repository system is a distraction. I can envision one way to do that, = as noted in a prior message, but that would entail changes to several = other RFCs, and will delay, substantially, progress on revisions to the = manifest RFC. As I said in my other email, the suggested change that all listed = objects in a MFT are valid makes incremental much harder than before. = Therefore it is something that needs to be considered. I am not going to repeat what I said there, but maybe you can reply to = the specific points I raised there, and suggestion I made that = incidentally would not cause any delay on this revision. > I am very bothered by the observation that, if were were to strictly = enforce the requirements imposed by the RPKI RFCs, then the number of = verified routes would substantially decrease. This seems to suggest that = it is more important to be able to cite big numbers of verified routes, = to convey a sense of RPKI deployment success, than to "encourage" CAs = to get their act together and follow the standards. That, I believe, is = a mistake. See above, I think we should aim for a flag day Tim >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Aug 28 07:56: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 D4F0E3A0C54; Fri, 28 Aug 2020 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn3nDIlljput; Fri, 28 Aug 2020 07:56:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A575E3A0C52; Fri, 28 Aug 2020 07:56:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kBfna-0008MU-9A; Fri, 28 Aug 2020 14:56:14 +0000 Date: Fri, 28 Aug 2020 07:56:13 -0700 Message-ID: From: Randy Bush To: Job Snijders Cc: Tim Bruijnzeels , Jakob Heitz , SIDR Operations WG In-Reply-To: <20200828144017.GF88356@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl> <20200828144017.GF88356@bench.sobornost.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved) 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, 28 Aug 2020 14:56:23 -0000 > If a CA's publication point's RPKI data is invalid "invalid" is already an overloaded magic word in this space; not cryptographically validatable up to a TA, and bgp announcement not finding a matching roa. can we come up with another term for a failed (for many reasons) fetch of a PP's data? > a Relying Party MUST add all IP address resources listed on the > certificate's issuer what certificate? > to a Prefix Filter what is a prefix filter? > The Relying party MUST consider any VRPs an RP cache knows if a PP was not fetchable, but does not have any VRPs (yet), just ROAs. a router has VRPs, but has no idea what happened between the RP cache and the PPs it tried to fetch. i suspect this whole thing is a capybara hole we just do not want to explore, especially when we have software out there which is . though i would not mind looking at a concise and simple statement of what it is you're trying to do here. but do consider the PPs of a CA whose INRs are delegated from multiple parents, and which, in turn, delegates to other CA(s). randy From nobody Fri Aug 28 08:25: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 DCBA33A0C8F for ; Fri, 28 Aug 2020 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 tk0k4uZt6KIb for ; Fri, 28 Aug 2020 08:25:10 -0700 (PDT) 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 F40403A0C37 for ; Fri, 28 Aug 2020 08:25:09 -0700 (PDT) Received: from bench.sobornost.net (129-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.129]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 6C0E5220136; Fri, 28 Aug 2020 15:25:07 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id fda80495; Fri, 28 Aug 2020 15:25:05 +0000 (UTC) Date: Fri, 28 Aug 2020 15:25:05 +0000 From: Job Snijders To: Stephen Kent Cc: sidrops@ietf.org Message-ID: <20200828152505.GH88356@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 15:25:11 -0000 Dear Stephen, On Fri, Aug 28, 2020 at 10:00:14AM -0400, Stephen Kent wrote: > I am very bothered by the observation that, if were were to strictly > enforce the requirements imposed by the RPKI RFCs, then the number of > verified routes would substantially decrease. >From my observations, OpenBSD rpki-client produces 514 VRPs fewer than some of the other validators, but still totals at 171,643 VRPs related to the global routing system (currently 895,143 routing table entries, ipv4 and ipv6 combined). In the grand scheme of things those 500 VRPs to me are not 'substantial' but rather "just out of luck", knowing that any attempts to 'repair' or 'salvage' those 500 VRPs puts the remaining 171,643 route origin authorizations at risk. This is a good noise level, and if we come up with additional ideas to improve strictness that krank it from 500 to the low thousands, we are still in great shape. Also knowing that whatever triggers further decreases can probably easily be remedied by the relevant TA or CA. Kind regards, Job From nobody Fri Aug 28 10:36:59 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 57D633A0EDD for ; Fri, 28 Aug 2020 10:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 NgP9DsCV5cFo for ; Fri, 28 Aug 2020 10:36:55 -0700 (PDT) Received: from mail5.web-server.biz (www5.web-server.biz [185.181.105.105]) (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 971A03A0EDB for ; Fri, 28 Aug 2020 10:36:55 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail5.web-server.biz (Postfix) with ESMTPSA id DABD447C79 for ; Fri, 28 Aug 2020 17:36:48 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id g13so2189058ioo.9 for ; Fri, 28 Aug 2020 10:36:48 -0700 (PDT) X-Gm-Message-State: AOAM530vehVBTq8KfOgU72SgOZAR/UPIuGpfwSWWrlN40B0lPFnSU/CD H2jVabQkvJ20dELh/fjhAhltUKdqW2SUojxNSsU= X-Google-Smtp-Source: ABdhPJw14UONBHxoE9lmkkue3Kap+xLj9qdOLFv5dziZNC/xoIBHSENI1aTxVCfPExyGovXxZTn5mXE8mFr0l5CmJaI= X-Received: by 2002:a6b:fb0c:: with SMTP id h12mr1809887iog.98.1598636207279; Fri, 28 Aug 2020 10:36:47 -0700 (PDT) MIME-Version: 1.0 References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> In-Reply-To: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> From: Lukas Tribus Date: Fri, 28 Aug 2020 19:36:33 +0200 X-Gmail-Original-Message-ID: Message-ID: To: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 28 Aug 2020 17:36:57 -0000 Hello, On Fri, 28 Aug 2020 at 16:00, Stephen Kent wrote: > I am very bothered by the observation that, if were were to strictly > enforce the requirements imposed by the RPKI RFCs, then the number of > verified routes would substantially decrease. This I believe is at the core of the disagreement. There is a faction that argues with points that sound a lot like "if in doubt, consider the ROA valid, because we NEED to emit a VRP", "CA's are too big to fail" and equivalents of "but if HTTPS fails, people will just use HTTP so we end up being less secure" (as in "better have a stale VRP than no VRP at all"). This is a mindset thing and goes beyond the specific issue about manifest invalidation. For example some RP's accept stale objects by default. Err'ing on the side of caution seems to mean "consider the ROA valid, so we emit the VRP" for some, which as a network operator I find deeply troubling. Let's be honest: there are not a lot of incentives for the CA's to fix underlying issues if the 3 major RP's accept those ROA's. Yes, sure, all of this is an oversimplification and the devil is in the details, which do need clarification. But we cannot be guided by a fear of decreasing VRP numbers when improving validation. Immaggine if browsers would do that with WebPKI (and that is actually causing direct outages for users, as opposed to ROV where outages are more likely caused by the *presence* of VRPs than by its absence). -- lukas From nobody Fri Aug 28 13:00: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 760963A0B5F for ; Fri, 28 Aug 2020 13:00:39 -0700 (PDT) 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 5bi3OGRkYIMv for ; Fri, 28 Aug 2020 13:00:38 -0700 (PDT) Received: from hrabosky.cbbtier3.att.net (braeburn.org [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 276E03A091F for ; Fri, 28 Aug 2020 13:00:38 -0700 (PDT) Received: from oz.mt.att.com (zoe.cbbtier3.att.net [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id BED722B6AD; Fri, 28 Aug 2020 20:00:35 +0000 (UTC) Received: by oz.mt.att.com (Postfix, from userid 1000) id 9B8FE5640A9A; Fri, 28 Aug 2020 16:00:35 -0400 (EDT) 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) Message-ID: <24393.25181.84151.476185@oz.mt.att.com> Date: Fri, 28 Aug 2020 16:00:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Borkenhagen To: Stephen Kent Cc: sidrops@ietf.org In-Reply-To: References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> Reply-To: Jay Borkenhagen X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 28 Aug 2020 20:00:40 -0000 Steve, I would like to comment on two things you recently wrote to this list:=20= Stephen Kent writes: > When I the WG chairs tell me that I misunderstood the WG consensus re: > strict correctness then I will revisit this topic. However, the recent > messages from Mikael and Job suggest that your perception of WG > consensus is not accurate. This issue is one that needs to be decided by > network operators, not by developers of RP software. I agree with the > observations made by Mikael and Job, i.e., that requiring strict > conformance with manifest rules is the preferred approach. I don't think viewing this as "network operators" vs "developers of RP software" is a productive approach. I am a professional network operator -- somebody pays me to do that. I also happen to have some opinions on how a successful PKI should operate, but so far no one has offered to pay me for those opinions. If asked to use only the network operator part of my brain to say whether strict conformance is the best approach here, I would answer "Honestly, I don't care. As a network operator I care only that the VRPs I use in my network are as trustable and reliable as possible." I certainly have opinions how =5Fhow=5F to make the system as trustable= and reliable as possible, but I know others have thought about such aspects far more than I have -- in particular folks who have implemented RP software. At the risk of making my comments here too personal (they are not intended that way), my friend Job wears both of these hats: he is a network operator, and he is involved in developing an RP implementation. That's great! I value his opinions, and I am happy to hear that you do, too. But it would be fruitless to attempt to determine which parts of Job's psyche most inform his opinions voiced in this WG. So rather than attempting to do so, I would like to ask you to also value the opinions and contributions of other RP implementors, particularly those who have been active in this discussion. Many network operators do not participate here in SIDROPS, but presumably all RP implementors do. > >> You absolutely have to deal with this issue in 6486bis in its current > >> strict form. Any introduction of a new object type will permanently > >> break CAs that use these objects when validated with a relying party > >> software that is not aware of this type. I don=E2=80=99t think this is > >> acceptable, as it effectively blocks the introduction of new types > >> pretty much forever. > No, it does not. What I suggested is that when a new object is proposed, > it is the responsibility of the those proposing the new object to > explain how it will be incrementally deployed. That explanation belongs > in the RFC defining the new object, and in an updated version of 6486 > will need to be generated. We have no good examples of new objects that > provide a basis for describing how to accommodate incremental > deployment, and thus no basis for defining such mechanisms at this time. > It might be the case that a new object will be defined that requires the > CA to maintain a separate pub point using some newly-defined SIA > pointer, indicting that the new pub point contains the new object and > thus RPs that don't know how to process the object MUST NOT follow that > pointer. There will need to be agreement on how long a CA MUST maintain > the old pub point, etc. But, absent a concrete example of a new object > type that warrants this sort of effort it is premature to write a spec. The situation you describe here sounds horrible, trying to keep older RPs from seeing newer objects they're not equipped to fully understand. A much more robust system would be one where RPs are not thrown off by unknown object types retrieved from known publication points and listed in manifests. Clearly older RPs would not know what use to make of newer objects, and thus would ignore them. Network operators interested in taking advantage of the new objects would first need to upgrade their RPs in order to do so, but that's BAU. Thank you. =09=09=09=09=09=09Jay B. From nobody Sat Aug 29 03:23: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 B3B873A12CF for ; Sat, 29 Aug 2020 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 scGQk6tsTShv for ; Sat, 29 Aug 2020 03:22:57 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6723A12CE for ; Sat, 29 Aug 2020 03:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id: From; bh=t7NCcX5eG8EcpXdxZiGhKakpK04E3i+Zn00UBImjKjU=; b=HtWucMMyh5Jj6IKvfyNh f+rFO/6JPzKpriARwtU5b1X4r4zWDveXEanG8laflIj6/hM6Cnv9xRR6ZS/wKgbIfud+FA2GvwCzm WiKKuQGir5BU6N0tTmjbPRDy5Ro0uSMMidF7+bVLSS4hRA28dEsr3CHx0shLYJmSmfxriA0Aum6iA 7J99AMnLwTcb5uTNCevM7ZseNefZXprJSK8PXp7+QkE64/i8ccHX7SuPs1NVqgyxLCXwr2aK+IStq 1n5rAiMimfMdBzkOqZommC8jPaitVcgyGGwpaD8sTnJpfg8i1/QdsiG+ooVctHCuCavUZogzCETcZ ELWDh9A2M/slqA==; Received: from allealle.ripe.net ([193.0.23.12]) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kBy0d-0005xw-Fw; Sat, 29 Aug 2020 12:22:55 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::3ec]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kBy0d-0005OF-An; Sat, 29 Aug 2020 12:22:55 +0200 From: Nathalie Trenaman Message-Id: <60849B88-EC02-4B86-8FF4-2AD7401567B0@ripe.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9496009B-383C-43CA-AD04-D557A9925626" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 29 Aug 2020 12:22:54 +0200 In-Reply-To: <20200827142827.GC88356@bench.sobornost.net> Cc: sidrops@ietf.org To: Job Snijders References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a6d61947082153b9bc04ce371fdf8724e Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 29 Aug 2020 10:23:00 -0000 --Apple-Mail=_9496009B-383C-43CA-AD04-D557A9925626 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Last month, we released a =E2=80=9Cstrict mode=E2=80=9D for our = validator. It takes into account 6486bis except the use of cached data, = which I did not see consensus on yet (correct me if I=E2=80=99m wrong = please).=20 The reason why we did not release strict mode as default is because we = first needed to have a clear picture what it was we were actually losing = in terms of objects and the impact this would cause. Let me put it very clear that none of us at RIPE NCC are objecting = against any consensus.=20 Where Job sees around 400 objects missing, we do see a lot more. Here = you can see an instance of our validator in the default mode: https://rpki-validator.ripe.net/trust-anchors = While here you can see an instance running in strict mode: http://alias.student.utwente.nl:9177/trust-anchors = We have been monitoring the amount of missing objects and we see a = difference of around 4500 objects. Mainly from the APNIC region.=20 This is why I believe Tim=E2=80=99s suggestion for a flag day sounds = reasonable to me. We have to inform CAs about the impact changing the = behaviour of RPs has on them.=20 Furthermore, I would really appreciate it if we can keep the discussion = constructive.=20 Regards, Nathalie Trenaman RIPE NCC > Op 27 aug. 2020, om 16:28 heeft Job Snijders het = volgende geschreven: >=20 > Dear all, >=20 > It pains me to write this email. It appears there is an increasingly > acrimonious situation in which RIPE NCC, Cloudflare, and NLNetLabs > representatives not only produce and publish insecure software, but = also > argue towards erosion of the robustness of the object security RPKI > depends on. >=20 > I'm drawing harsh conclusions: the reality is that we are now 6 months > into /what should've been/ a simple bug report, but turned into a = trench > war. Folks are digging in their heels deeper. Attempts in this group = to > bridge the knowledge gap have failed so far. >=20 > On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: >> Job Snijders wrote: >>> The current versions of routinator and ripe ncc's validator have = weak >>> (lacking) support for manifest handling, there are other issues in >>> both softwares that don't yield errors where they should yield = errors >>> related to manifest handling. Neither implementation handles >>> manifests correctly at the moment, so neither software currently can >>> be used to confirm the correct publication of manifest related >>> data. :-( >>=20 >> To the best of my knowledge, Routinator and the RIPE NCC RPKI >> Validator handle manifests according to the specifications laid out = in >> the relevant standards track IETF documents.=20 >=20 > The implementers of RIPE NCC's validator, Routinator, and OctoRPKI > entirely missed the point of WHY RPKI Manifests exist at all. The = bigger > picture is ignored, one can't look at normative terms in a vacuum. >=20 > I quote from the INTRODUCTION of RFC6486: >=20 > "A manifest is intended to allow an RP to detect unauthorized = object > removal or the substitution of stale versions of objects at a > publication point." >=20 > A Manifest makes it possible for a validator software to react sanely > when data tampering is detected. Manifests exist to *protect* both the > issuing CA and the RP, failure to acknowledge the purpose of manifests > is akin to the famous quote "the operation was successful - but the > patient died". Did any CA ever wish for an incomplete view of their > routing intentions to be transformed into routing decisions? Zero CAs > want this. >=20 > One has to look further than the normative terms, one has to realize > what the implications are to routing in the global system and = inevitably > the conclusion is to err on the side of caution. To be cynical about > what data is provided via an untrusted network input channel. Why > implement a virus scanner, which can detect virus files, but > subsequently doesn't do anything about it? >=20 > Manifests are the *only* mechanism to verify a publication point's > completeness and integrity. Neither Routinator nor RIPE NCC's software > attach any consequence to integrity issues at a publication point. = Both > continue to emit as many VRPs as possible, regardless of whether the > publication point is complete to begin with!=20 >=20 > The datastructure of Route Origin Authorizations (ROAs) allows only a > single origin ASN per .roa file, this means network operators who wish > to grant permission to multiple ASNs (a common example: their own and > their customers' ASNs) to originate parts of their IP space, they = *have* > the create multiple .roa files. The IP Block owner's routing = intentions > can only be considered when the full bundle of .roa files is = available. >=20 > Logically, when some .roa files are missing (which according to a = valid > current manifest must be present), the remaining .roa files at the > publication point become useless as they represent an *incomplete* > overview of routing intentions; even worse those files flip from > 'useless' to 'dangerous' when they are injected as VRPs into the > operator's routing system. >=20 > Manifests are analogous to to Debian's "Release + Release.gpg" APT > archive concepts. APT (or yum/dnf) do *not* proceed to install = packages > when critical dependencies are missing, or when the SIGNED checksums = do > not match the checksum of the downloaded .deb file. An administrator > has to *explicitly* override (-y --force) to install such packages = when > dependencies or checksums don't match. >=20 > Let me demonstrate what happens when I cherry-pick just a few words = you > wrote, and withhold some of your other words. You wrote this email: > = https://mailarchive.ietf.org/arch/msg/sidrops/7JxOCNBvYbwDHL7hcPHsfvxto0Q/= >=20 > *** start of modified email *** > On Wed, Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote: >> Routinator and the RIPE NCC RPKI Validator have issues. > *** end of modified email *** >=20 > Do you see the issue now? I didn't even change the order of your = words, > I merely withheld some of the text you wrote, and the resulting text = is > entirely contradictory to what you intended to write! >=20 > Let's be honest, neither RIPE NCC nor NLNetLabs have real experience > using RPKI ROV 'invalid =3D=3D reject' in their own networks. RIPE NCC = so > far has refused to implement ROV in AS 3333 out of fear, and = NLNetLab's > own ASN is a simple single-homed stub network. Why are both > organisations ignoring the community's pleas to fix a security issue? > Why the hubris? Do you really think you know better? Why does = Alexander > Band say that fixing this is "not a priority", why is RIPE NCC = refusing > to commit a one-line patch to fix their validator? >=20 > Is loss of face the issue? The longer the delay to provide a fix, the > longer NLNetLabs and RIPE NCC keep hurting their users (and = dependents). > Is this what one calls 'good for the Internet'? The issue was brought = to > attention MONTHS [1] ago, it should've been a few days to get it = patched. >=20 >> Given that this topic is currently discussed in this very working >> group and there wasn=E2=80=99t outright consensus on how software = should behave >> in these cases, it seems only prudent to delay modifications until >> after such consensus has been achieved. >=20 > The only ones arguing against the consensus are RIPE NCC and NLNetLabs > employees. Go figure. Staff and knowledge were exchanged between the = two > software houses, a path is visible how the misconceptions continued to > proliferate. It is not too late to change course, but catch-up is > needed. >=20 > Believe it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an > existential crisis: your credibility is on the line. Are you going to > produce routing security software which actually improves security, or > not? Will you attempt to absorb decades of PKI and X.509 experience, = or > throw it all in the wind?=20 >=20 > Currently routinator + ripe ncc's validator + octorpki set their users > up for failure. Operators using these softwares ARE AT NEEDLESS RISK.=20= >=20 > Regards, >=20 > Job >=20 > [1]: https://github.com/NLnetLabs/routinator/issues/319 > https://github.com/RIPE-NCC/rpki-validator-3/issues/232 > https://github.com/RIPE-NCC/rpki-validator-3/issues/158 > https://github.com/cloudflare/cfrpki/issues/38 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_9496009B-383C-43CA-AD04-D557A9925626 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = all,

Last month, we = released a =E2=80=9Cstrict mode=E2=80=9D for our validator. It takes = into account 6486bis except the use = of cached data, which I did not see consensus on yet (correct me if = I=E2=80=99m wrong please). 
The reason why we did not release strict mode as default is = because we first needed to have a clear picture what it was we were = actually losing in terms of objects and the impact this would = cause.
Let me put it very clear that none of = us at RIPE NCC are objecting against any = consensus. 

Where Job sees around 400 objects = missing, we do see a lot more. Here you can see an instance of our = validator in the default mode:
https://rpki-validator.ripe.net/trust-anchors
While here you can see an instance running in strict = mode:
http://alias.student.utwente.nl:9177/trust-anchors

We have been = monitoring the amount of missing objects and we see a difference of = around 4500 objects. Mainly from the APNIC region. 
This is why I believe Tim=E2=80=99s suggestion for a flag day = sounds reasonable to me. We have to inform CAs about the impact changing = the behaviour of RPs has on them. 

Furthermore, I would really appreciate = it if we can keep the discussion constructive. 

Regards,
Nathalie Trenaman
RIPE NCC


Op 27 aug. 2020, om 16:28 heeft = Job Snijders <job@ntt.net> het volgende geschreven:

Dear = all,

It pains me to write this email. It = appears there is an increasingly
acrimonious situation in = which RIPE NCC, Cloudflare, and NLNetLabs
representatives = not only produce and publish insecure software, but also
argue towards erosion of the robustness of the object = security RPKI
depends on.

I'm = drawing harsh conclusions: the reality is that we are now 6 months
into /what should've been/ a simple bug report, but turned = into a trench
war. Folks are digging in their heels = deeper.  Attempts in this group to
bridge the = knowledge gap have failed so far.

On Wed, = Aug 26, 2020 at 08:24:42PM +0200, Martin Hoffmann wrote:
Job Snijders wrote:
The current versions of = routinator and ripe ncc's validator have weak
(lacking) = support for manifest handling, there are other issues in
both softwares that don't yield errors where they should = yield errors
related to manifest handling. Neither = implementation handles
manifests correctly at the moment, = so neither software currently can
be used to confirm the = correct publication of manifest related
data. :-(

To the best of my knowledge, = Routinator and the RIPE NCC RPKI
Validator handle = manifests according to the specifications laid out in
the = relevant standards track IETF documents.

The implementers of RIPE NCC's validator, Routinator, and = OctoRPKI
entirely missed the point of WHY RPKI Manifests = exist at all. The bigger
picture is ignored, one can't = look at normative terms in a vacuum.

I = quote from the INTRODUCTION of RFC6486:

=    "A manifest is intended to allow an RP to detect = unauthorized object
   removal or the = substitution of stale versions of objects at a
=    publication point."

A = Manifest makes it possible for a validator software to react sanely
when data tampering is detected. Manifests exist to *protect* = both the
issuing CA and the RP, failure to acknowledge the = purpose of manifests
is akin to the famous quote "the = operation was successful - but the
patient died". Did any = CA ever wish for an incomplete view of their
routing = intentions to be transformed into routing decisions? Zero CAs
want this.

One has to look = further than the normative terms, one has to realize
what = the implications are to routing in the global system and inevitably
the conclusion is to err on the side of caution. To be = cynical about
what data is provided via an untrusted = network input channel. Why
implement a virus scanner, = which can detect virus files, but
subsequently doesn't do = anything about it?

Manifests are the *only* = mechanism to verify a publication point's
completeness and = integrity. Neither Routinator nor RIPE NCC's software
attach= any consequence to integrity issues at a publication point. Both
continue to emit as many VRPs as possible, regardless of = whether the
publication point is complete to begin with! =

The datastructure of Route Origin = Authorizations (ROAs) allows only a
single origin ASN per = .roa file, this means network operators who wish
to grant = permission to multiple ASNs (a common example: their own and
their customers' ASNs) to originate parts of their IP space, = they *have*
the create multiple .roa files. The IP Block = owner's routing intentions
can only be considered when the = full bundle of .roa files is available.

Logically, when some .roa files are missing (which according = to a valid
current manifest must be present), the = remaining .roa files at the
publication point become = useless as they represent an *incomplete*
overview of = routing intentions; even worse those files flip from
'useless' to 'dangerous' when they are injected as VRPs into = the
operator's routing system.

Manifests are analogous to to Debian's "Release + = Release.gpg" APT
archive concepts. APT (or yum/dnf) do = *not* proceed to install packages
when critical = dependencies are missing, or when the SIGNED checksums do
not match the checksum of the downloaded .deb file.  An = administrator
has to *explicitly* override (-y --force) to = install such packages when
dependencies or checksums don't = match.

Let me demonstrate what happens when = I cherry-pick just a few words you
wrote, and withhold = some of your other words. You wrote this email:
https://mailarchive.ietf.org/arch/msg/sidrops/7JxOCNBvYbwDHL7hc= PHsfvxto0Q/

*** start of modified email = ***
   On Wed, Aug 26, 2020 at 08:24:42PM = +0200, Martin Hoffmann wrote:
Routinator and the RIPE NCC RPKI Validator have issues.
*** end of modified email ***

Do you see the issue now? I didn't even change the order of = your words,
I merely withheld some of the text you wrote, = and the resulting text is
entirely contradictory to what = you intended to write!

Let's be honest, = neither RIPE NCC nor NLNetLabs have real experience
using = RPKI ROV 'invalid =3D=3D reject' in their own networks. RIPE NCC so
far has refused to implement ROV in AS 3333 out of fear, and = NLNetLab's
own ASN is a simple single-homed stub network. = Why are both
organisations ignoring the community's pleas = to fix a security issue?
Why the hubris? Do you really = think you know better? Why does Alexander
Band say that = fixing this is "not a priority", why is RIPE NCC refusing
to= commit a one-line patch to fix their validator?

Is loss of face the issue? The longer the delay to provide a = fix, the
longer NLNetLabs and RIPE NCC keep hurting their = users (and dependents).
Is this what one calls 'good for = the Internet'? The issue was brought to
attention MONTHS = [1] ago, it should've been a few days to get it patched.
Given that this topic = is currently discussed in this very working
group and = there wasn=E2=80=99t outright consensus on how software should behave
in these cases, it seems only prudent to delay modifications = until
after such consensus has been achieved.

The only ones arguing against the = consensus are RIPE NCC and NLNetLabs
employees. Go figure. = Staff and knowledge were exchanged between the two
software = houses, a path is visible how the misconceptions continued to
proliferate. It is not too late to change course, but = catch-up is
needed.

Believe = it not, RIPE NCC, Cloudflare, and NLNetLabs are now at an
existential crisis: your credibility is on the line. Are you = going to
produce routing security software which actually = improves security, or
not? Will you attempt to absorb = decades of PKI and X.509 experience, or
throw it all in = the wind?

Currently routinator + ripe = ncc's validator + octorpki set their users
up for failure. = Operators using these softwares ARE AT NEEDLESS RISK.

Regards,

Job

[1]: https://github.com/NLnetLabs/routinator/issues/319
https://github.com/RIPE-NCC/rpki-validator-3/issues/232
https://github.com/RIPE-NCC/rpki-validator-3/issues/158
https://github.com/cloudflare/cfrpki/issues/38

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

= --Apple-Mail=_9496009B-383C-43CA-AD04-D557A9925626-- From nobody Sat Aug 29 03:26: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 0EAFD3A12D8; Sat, 29 Aug 2020 03:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7NERApEE1rN1; Sat, 29 Aug 2020 03:26:50 -0700 (PDT) Received: from out20-61.mail.aliyun.com (out20-61.mail.aliyun.com [115.124.20.61]) (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 1F2033A12D5; Sat, 29 Aug 2020 03:26:48 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1597086|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0843744-0.0114148-0.904211; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03306; MF=madi@rpstir.net; NM=1; PH=DS; RN=5; RT=5; SR=0; TI=SMTPD_---.IPgo1HO_1598696798; Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.IPgo1HO_1598696798) by smtp.aliyun-inc.com(10.147.40.26); Sat, 29 Aug 2020 18:26:39 +0800 From: Di Ma Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Sat, 29 Aug 2020 18:26:37 +0800 Cc: Chris Morrow , Keyur Patel , Nathalie Trenaman , SIDR Operations WG To: SIDROps Chairs X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Sidrops] Adoption request of draft-madi-sidrops-rush-02 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 10:26:52 -0000 Chairs, We authors just update draft-madi-sidrops-rush into v2 re Randy and = Job=E2=80=99s concern raised in last IETF SIDROPS meeting. This version articulates in Security Consideration that : "RUSH is designed to carry out RPKI cache data update from one to = another, with out-of-band trust established between those cache servers. = That is, the scope of RUSH usage is convergent. Cache subscription = management might be employed to implement cache identification and = verification. " Please consider this mail as the formal request of adoption of = draft-madi-sidrops-rush-02 as WG item. Thanks. Di= From nobody Sat Aug 29 10:14:28 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 4E0F63A0CF0 for ; Sat, 29 Aug 2020 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu59oB5TdcHF for ; Sat, 29 Aug 2020 10:14:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413083A0CE8 for ; Sat, 29 Aug 2020 10:14:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kC4Qr-0001qn-1L for sidrops@ietf.org; Sat, 29 Aug 2020 17:14:25 +0000 Date: Sat, 29 Aug 2020 10:14:24 -0700 Message-ID: From: Randy Bush To: SIDR Operations WG User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] draft-ietf-sidrops-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 17:14:27 -0000 draft-ietf-sidrops-8210bis has 1.2. Changes from RFC 8210 This section summarizes the significant changes between [RFC6810] and the protocol described in this document. o New ASPA PDU type (Section 5.12) added to support [I-D.ietf-sidrops-aspa-profile]. o A small section, Section 11, has been added to handle two ROA PDU race conditions, Break Before Make and Shorter Prefix First. it is not clear there is a rush on ASPA. as ROA PDU Race Minimization has serious effect on cache behavior, 11. ROA PDU Race Minimization When a cache is sending ROA PDUs to the router, especially during an initial full load, two undesirable race conditions are possible: Break Before Make: For some prefix P, an AS may announce two (or more) ROAs because they are in the process of changing what provider AS is announcing P. This is is a case of "make before break." If a cache is feeding a router and sends the one not yet in service a significant time before sending the one currently in service, then BGP data could be marked invalid during the interval. To minimize that interval, the cache SHOULD announce all ROAs for the same prefix as close to sequentially as possible. Shorter Prefix First: If an AS has issued a ROA for P0, and another AS (likely their customer) has issued a ROA for P1 which is a sub- prefix of P0, a router which receives the ROA for P0 before that for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the cache SHOULD announce the sub-prefix P1 before the covering prefix P0. this has overlap with a discussion Job was having. i would like to close on this and get it out the door. but it would be good if folk, reread, thought, and commented. randy From nobody Sat Aug 29 11:52: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 F0C463A0F13 for ; Sat, 29 Aug 2020 11:52:30 -0700 (PDT) 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 AH2CdzKOL7ef for ; Sat, 29 Aug 2020 11:52:28 -0700 (PDT) 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 D0FFC3A0F10 for ; Sat, 29 Aug 2020 11:52:28 -0700 (PDT) Received: from bench.sobornost.net (129-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.129]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 587E7220161; Sat, 29 Aug 2020 18:52:22 +0000 (UTC) Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 6261e9e5; Sat, 29 Aug 2020 18:48:19 +0000 (UTC) Date: Sat, 29 Aug 2020 18:48:19 +0000 From: Job Snijders To: Nathalie Trenaman Cc: sidrops@ietf.org Message-ID: <20200829184819.GL88356@bench.sobornost.net> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <60849B88-EC02-4B86-8FF4-2AD7401567B0@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <60849B88-EC02-4B86-8FF4-2AD7401567B0@ripe.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 29 Aug 2020 18:52:31 -0000 On Sat, Aug 29, 2020 at 12:22:54PM +0200, Nathalie Trenaman wrote: > Last month, we released a “strict mode” for our validator. It takes > into account 6486bis except the use of cached data, which I did not > see consensus on yet (correct me if I’m wrong please). I think you are wrong on the cached data consensus, but it doesn't matter, it is a small implementation detail. If an implementer doesn't want to take advantage of their local file cache, they don't need to. RPs are expected to be able to function with empty caches as well. > Where Job sees around 400 objects missing, we do see a lot more. > > We have been monitoring the amount of missing objects and we see a > difference of around 4500 objects. Mainly from the APNIC region. The difference between rpki-client and ripe ncc validator 'insecure-mode=off / rsync-only' seems to be about 2,500 VRPs. However, the ripe ncc validator logs 5 only errors: https://rpki.meerval.net/trust-anchors/monitor/2 One of the errors appears to be logged at "2020-08-29 18:08:48" and indicates: "CRL next update was expected on or before 2020-08-29T22:46:19.000Z" It is not clear why it errors on things still in the future. The 2,500 VRP difference might be caused by a software issue rather than a specifications issue? For example, I can't find a reason why a VRP for Prefix: 203.163.202.0/23 Maxlength: 24, Origin: AS10085, TA: APNIC is not emitted by the ripe ncc validator. It is also curious to see RRDP fetches are performed while 'rpki.validator.rsync-only=true' is set. Are you sure the current version implemented things correctly? > This is why I believe Tim’s suggestion for a flag day sounds > reasonable to me. We have to inform CAs about the impact changing the > behaviour of RPs has on them. A flag day to release a security update? Flag day's generally are used for other types of events. Regards, Job From nobody Sat Aug 29 11:58: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 962413A0F21 for ; Sat, 29 Aug 2020 11:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 e1VlzX328kji for ; Sat, 29 Aug 2020 11:58:25 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.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 182533A0F1E for ; Sat, 29 Aug 2020 11:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598727503; bh=l0Ba2wp0yVrT3Z1pwiyDSPFZtNYjzz5lQCoLgLIA+hc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=LebJobmdBinjqpcHGubC1/4mtwF1DjhwSVmsFX5PE3pOVEF7L5wlqYNFNQzkV5YLhhWF6YBkqMWm1+athopIqjI5WM6I+1YzxHzZ4Pn4qt1/zbvLMCBTEEr0S9Nb1wys+GFDTPJg/250eI+1TkFv+CCfZjHI2ZfzAknuqf5IyhcJmjN50HLvN5x7EFGM9Frn5hWMkgs+wN8ozIy6BdsZxrttEa3BH682cQLDA6wdInCA0k+KtXMpMVJw0A5tVjdps9W45OqmtvHU1on52K2Qi3nGSZhYyLrOrge8PfB+0TZFE5oHFvkP9+40lwOx2ymprsslBOTCqNSlVZEFxOx1fw== X-YMail-OSG: a9fWxIMVM1kdDpKCS.144IH.WS3gfVfBlyJ_SfnSyC.TbcOusHxNYj1ED7apLMS gK73Eram31_Vc1_PcxCctsqmLgMN5hLqfHz9hs.gOBVxiqrn4ijyEs0bVB54FTWbmXtyzWa4DYqH WVbkmWhJ6Od_leT8xuK7L8aj0mYTiHSZzFQyEG6IGKxuPlfVey2t0kfQNOmFkgxCHu3_mcxCP5Z7 bpdhMKNwyH33ghgDa.Fb4UhuQ.F1xQoVBqTU7WEVlpq2.QAdKmAaSh3js3UleNQNB4JqDSMloiN3 Hl_uUf90EUK6sv53pdYQowAz5OQFluMWqS7t1T_xJFt4ZZfnk8znlYfQd7rB5wkNbOGiKcfwCuqc wOGLd_ZmgWXPeoEenLfEmiETrGahfnhzDr8sRY.LP2RG7q4Cr2V_fSW7HQbnqMe4nW6kvxFOSgZo 2uAizVbsTc1HE1Sqki2_nd4z9MSGl1efAsVV7MBs.xAfeDTvpEaUNXKAC5cDpm4hJ7JF.Vp5H23Q kcjQiyVI8I7QXTV.fxghO_vYk7y2A5HkzKsFY.Bg3f0SGLNIEfjeA_rENU_0KxbzC02YU5mC8JQM mzfq0HZ8aUA_axwOfUQow.yqz1LE7sAoAdiyrKmDAIBztqNHN2K1UEcfDyZcCnzg2L35OGqKXEk9 wJ6ti0l.xJRCLFPR6EkI5eBL_.0AI8kJhN.l5JXEC2kBW9VENDlCn99jQAwklnDD27cjSZJwpVG5 M6eSdVhOc7x1iQOzlK.k5LCCDQzMpHNet2d9sJOZ_Dt9hHmAFrv2W9mDoWaEYtQtRt0lVpxjet5Q 0t0ormg7PCUddh0U28fy5RhJHnQKKsPbMlhU.n.Co6gjaUMBFSxJZH1AzEA6ymT.EDVocfAQCuwF fcJc.IVaFUdQn9seQoXDWTi2d_U9Wh1DjHcjdkuOfuVtVcY4K.Qm7JYeZKnI.XzU91eyL2K9_wcg FAiUSe1udoYgWXfhxdv6.VGhqyhrms9YRscXy1.9wI3O_hrHVWdLKemdHk5b2OcFbcDu7ECG06Yl sbDoWcyk_1tcWaudp_3IEKMDiTa3_D17kv.wknK3qVt1aYONi5_WGZwj2aGdSgIqdfVzxylJHB4B 2WyI5b.J4Beqh7id.fv39MI1H09kjl4BF7iyX3BEDdPWI2WE0i6kwLmSbXHUwcxxiUjRjwpFKEUm QuAJc.OZlU7zAimbZa8UWQ66oPY9YOtNcH09vkV7FJYaSjTaNlpRgxKyev8lPowBsLTmJN.cdieh 9aCuuTUFi_k6szhdJlbFxk6ikkVKaWTuJRp5R9JbzV1Rol5NOO3id2l1h3OoXQSkNHS8et2vNZW0 12RXvqq0VTHS9qp91lRamaT82jviT_sPEiTm0CWHEoeb5K46pqrOgj.1FedV0zkxuNUJpuMUs6Cd zhaed0ZivCnS5PLPL_W20lmijjijYtHcOsGgZhxV0wnL6NV7iavCnbWI_CTv6UOqHmYjwjwKF_PE JeePPaSexRFv3ce4.Uq2gAmTYehW7lkW3EDogf9oY1r6pXxs36AATdscr8iPUx_1q3VGZvrRjG7G S.geO Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sat, 29 Aug 2020 18:58:23 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dbee226bae5a6fb06ec76084f40e19ea; Sat, 29 Aug 2020 18:58:18 +0000 (UTC) To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> From: Stephen Kent Message-ID: <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> Date: Sat, 29 Aug 2020 14:58:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 29 Aug 2020 18:58:27 -0000 Tim, > Hi, > I agree that a correctly functioning CA will produce a sound set of objects. Also it is highly unlikely that a CA will just publish an expired ROA. The much more likely scenario is that a CA is unable to make or publish updates and the MFT and CRL go stale, and the MFT EE expires, way before any ROA or issued cert would. I agree that these seem to be the more likely error modes, but there also was a discussion of encountering more than one CRL, for example. > That being said there are scenarios beyond the control of a CA that can lead to invalid objects: > > 1) rsync > > If the RP does rsync only, they may get an inconsistent data set. Transactions are not supported here. They just get an old MFT and new CRL or vice versa, or they may get a new MFT but not the new object, etc. This is a race condition that happens infrequently when RPs fetch during publication. It is rare, but it does happen. I agree that this may happen, even if one publishes all of the objects in a new directory and the  switches the pointer. But, in that case, the RP should consider this a failed fetch and retry. I believe that's what the RPSTIR software did (does?), so it's not a fatal error. > I remember that many years ago I wrote code in the, then, RIPE NCC validator 2 to catch this issue. And only process publication points if the set was consistent. This was an allowed, but not mandated, interpretation of 6486. > > Note that with RRDP we have deltas. Solving this issues was one of its design goals. So, phasing out rsync could mitigate this. > (yes, I realise now that the co-chairs asked me to re-submit the I-D for this, and I still need to do it) I'm still waiting to see a clear, and hopefully concise, description of how an RP verifies that the pub point data acquired via RRDP is constrained in the hierarchic fashion imposed by the rsync directory model, but that's a separate issue. > 2) resource changes > > If the parent removes any resources from the child before the child has had a chance to clean up objects then this will lead to invalid objects. Being strict that *all* objects must be valid will then lead to rejection of the CA's products. Even if it is only for a few hours. > > I believe that this issue could be greatly mitigated if RFC6492 would be extended with a notion to give children a warning about planned resource removals. The length of this warning time being a function of the contact frequency of child CAs and the depth of the CA hierarchy. But, if this frequency could also be stipulated - say SHOULD every 10 minutes? Then a warning time of just a few hours would already be plenty. > > However, this is a separate discussion. I do not suggest that we block progress on 6486bis for this. I am just saying that if strict checking for *all* objects is where the consensus goes then the WG must be aware of these consequences and accept them. yes, this is a separate discussion. > The current version of 6486 allows RPs to treat individual objects as > invalid. -bis is trying to change that to say that the whole set of > objects must be valid. This changes the consequences for the > deployment of new object types, so it is right to consider this now. 6486 allows an RP to behave either way, e.g., to accept some but not all inconsistencies to to reject them. So, it's not quite accurate to suggest that RP software that operates in accordance with 6486 will treat individual objects as invalid- it might, or it might not. > The most likely next object type would be the ASPA objects. I don't think that RPs should reject all ROAs because they do not yet understand ASPA. Given that object types in the RPKI get distinct file names, and RPKI signed objects get distinct OIDs I think it would be reasonable to say that RP software can ignore object *types* that it does not understand. I would still advocate then that the RPs do check for the presence and hashes of these objects as stipulated by the signed MFT, but not consider their content. Allowing RPs to ignore object types they don't understand prevents a CA from being able to convey the notion that a new object type is important (to that CA). I don't think this is a good strategy. It means that RP behavior will be ambiguous relative to new object types. > If we don't then the consequence will be that new object types only become deployable after a significant percentage of RP has been upgraded to version that understand the new type. > > Now, if all operators say that they are fine with this: let things go unknown for everyone who did not upgrade, and force them to do so.. sure. But it is right to consider this now and make a conscious choice. Oh and BTW.. for RPKI use cases where we only have VALID/INVALID but no NOT FOUND, such as BGPSec, this would be problematic. If we want to have a consistent and flexible approach to accommodating new objects I suggest the strategy I mentioned earlier. Define an additional SIA URI that points to a pub point (and manifest) where we can introduce the next version of the signed object format, one that includes a critical flag, analogous to X.509v3 extensions. This allows each CA to decide which object types have to be processed  by an RP in order for the whole pub point to be accepted vs. rejected. Note that this will require modifying a lot of RFCs, but it is a flexible, extensible approach to this issue. I agree that even if we adopt the current 6486bis , for now, that a flag day is appropriate, and it shoudk be part of the document. Steve From nobody Sat Aug 29 12:11:28 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 ED80D3A0140 for ; Sat, 29 Aug 2020 12:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 q3TnFzSMXkdB for ; Sat, 29 Aug 2020 12:11:25 -0700 (PDT) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 D1B963A0E55 for ; Sat, 29 Aug 2020 12:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598728283; bh=riBTl2uF1bybgFVWFEZFWD2r5iHoKBEXhdW6YCv8y5E=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=LpkuFyofDQ6C8cM6hss3JokgY0NdPgJHVyoSHsXuniIBXkiCZoUMzlCFAhzKyU0o+6dFpGVQzU1BAHfcqK8eYq48vXaykMGU6xN8YQJXmjvBMFpsfitc73VtO19sb2Yhu1mpURveog5MNMpYqBjETszJkbLNsiRykNPaJk0GmzgR7g6zWtITpT72iz3ZFeRdgeTu9Yc5YfGcVMieclum+o+5W+Oh8NmtiPXy4QoBeyRSA1GhcjRJ5Vexomm0WPukjOcbyyZskojPj9KTUi0YDptsunbK57gYzmZo3XP6YIkqWRN0t9ZsYrHWmnOu0vcAgwgqhIcFsu4nuRiaP/ADWw== X-YMail-OSG: Dome6EkVM1kHUT1tUGv5EW2fOhp9TQ5sdP.jzn_19hp5LUCdrbAq4ijUIkT3QE1 QurU18jAI3oNqbNWHMwPaKSmDf05ZkqhB96AGZYV.WeO6mfCaEZqMYGcAxQ9x59ft2gQ55q1JPCc .XX84sDQXx.O9yEjTJzUvaOGMrhsHuuGdmT2EaiznDC.QSNO7TYsLXx4Zu6qXg7ZhLX7RErMd4s9 3CppghDBKj.QdrR1vICkVQYVwjlFz8KhQirkI1hVEmSBHz1nnNLiCxtU7G8rEnkBAGYkV_PiMfqi boO_QsKqtRB6xnX54WZNTMCe0YCdEZms7B11BmgSOg2sh39D90ZW5gIc5L1vjnejRzTjqa1xMR3W DwgZsHc7FTcuro_miU3zBrlbvPk7UoEgjAWL2JZe2C.K8N3h8.APqSr2NYg05Rdgxq8v_sYE_J63 dtd8GVDjp8ySgCMz.R6X_AnqwbRja24pTCf7re1X2reZiq8vDimqN_FN.rM3EBDevOLAYqX3m0bI k_EFmg47a4Q.8KDiuoSsnOXX5gmIdR.lcgr.6ThHiHjX1zvuy8cVkqEuhlFMNrwADeyxJx_cBdyj gVVRCjxzeuUAs2D.PHSthecB7Xf6FpAKLozcDtb0rK8wVmyqxwGL9LG3rKm_XbqFAmIUlRtl2MpP ZqcqOjtN3tFGdPWxSaJlFXNwEzT74mUax9k9xvLk2OePhmfwmHgNcpvJczfLeIAsBbYEg6pXGRMx 9Lbl4UfJeIEQlyWDpV6RwXkaX35j4I6ipkC6JII1v5balhYn5bp_iV3B0vCABSkeS_RkwOeJ48I0 Mxg1z0rM_9QBgg.Gtx6HiQhVcbgPVGygHc7l8wfdCEbiufeaLK_x8nQeQA8Ph1rzWBlFZ8SdqwKo X7ENs63xi78O6XXDidV6jlFHtEy5qo7FvfUptnpeHX03GEILkuTLWh2Zgd_OlSXghYxF2ZhnF9xR 6e3U.pDyCw4ShyBGcKMLgeZoFrwAz.oTIbXoWm_xP58Ohhl6sQePNgN9dC.Vdaann6bJ4FYgazZk zNculmLAOd17ZRSn3g6qvWnNtdl4gcZSYOCiziczsXDC6nXOTjt7klNawH8ioSHcCsyCv2_qu9Sx cVo3Xvj4iVEbZIpRCUb.DWN1XE3KsSsSCFf4z8vVcnIaJfKBaDuUTKKcQx6WeKJgh6SxW3a8BsqE 4zOqasSfqAN6D5mLTgcQGqNlMMR3I60cf4qkxqSQLdphzRZeG78aPXiT8bQEFB3fK6FIoJLmMhgn q13DPEoSXBO7.A5vkr4Na40774tEkwtnn_vhwLj4o3WSy.EAvdk4pQ2BBTsHUHtaFgfzkWOX7bM7 IyyyVD3zQATpBMM9Iaxc66ugGC.om.4Nv8JInJa0gYdngr2oFTVZqbjVIyb_R5Mjswjd8ft6TLTX .GePPzG_pxqR4Vs8ZC3jHagIjOnZM2bx.nj8QjoyfUL2.yF41OvmsENOb5FugDExutRsUeq5yt29 YvAXbaD8V4hG4g0lqN9i5xIvOUDSeh_pcbZfHCu_zNlG1ctBTkKvI_GRkSSWDrR1TivxiRs2BBWY u05VtxJsw5L6Z_UelZ6Wg67cTVTc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sat, 29 Aug 2020 19:11:23 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2d5fcd44c63216ac76794313453f4cfe; Sat, 29 Aug 2020 19:11:19 +0000 (UTC) To: sidrops@ietf.org References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <24393.25181.84151.476185@oz.mt.att.com> From: Stephen Kent Message-ID: <4d77e33d-25bb-03a7-7a7e-1535bb2e1f18@verizon.net> Date: Sat, 29 Aug 2020 15:11:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <24393.25181.84151.476185@oz.mt.att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 29 Aug 2020 19:11:27 -0000 Jay, > Steve, > > I would like to comment on two things you recently wrote to this list: > > Stephen Kent writes: > > When I the WG chairs tell me that I misunderstood the WG consensus re: > > strict correctness then I will revisit this topic. However, the recent > > messages from Mikael and Job suggest that your perception of WG > > consensus is not accurate. This issue is one that needs to be decided by > > network operators, not by developers of RP software. I agree with the > > observations made by Mikael and Job, i.e., that requiring strict > > conformance with manifest rules is the preferred approach. > > I don't think viewing this as "network operators" vs "developers of RP > software" is a productive approach. > > I am a professional network operator -- somebody pays me to do that. > I also happen to have some opinions on how a successful PKI should > operate, but so far no one has offered to pay me for those opinions. > If asked to use only the network operator part of my brain to say > whether strict conformance is the best approach here, I would answer > "Honestly, I don't care. As a network operator I care only that the > VRPs I use in my network are as trustable and reliable as possible." > I certainly have opinions how _how_ to make the system as trustable > and reliable as possible, but I know others have thought about such > aspects far more than I have -- in particular folks who have > implemented RP software. > > At the risk of making my comments here too personal (they are not > intended that way), my friend Job wears both of these hats: he is a > network operator, and he is involved in developing an RP > implementation. That's great! I value his opinions, and I am happy > to hear that you do, too. But it would be fruitless to attempt to > determine which parts of Job's psyche most inform his opinions voiced > in this WG. So rather than attempting to do so, I would like to ask > you to also value the opinions and contributions of other RP > implementors, particularly those who have been active in this > discussion. Many network operators do not participate here in > SIDROPS, but presumably all RP implementors do. The crux of the issue is whether it is preferable to reject all objects at a pub point if an error is detected (until the error is rectified), and thus potentially treat many more routes as having an unknown verification status, or to accept bits and pieces of data from a pub point with the potential that some routes will be treated as valid, even if they are invalid. To me, that is a value judgement to be made by network operators, not by developers of RP software. Job can pick whatever hat fits him best. > > >> You absolutely have to deal with this issue in 6486bis in its current > > >> strict form. Any introduction of a new object type will permanently > > >> break CAs that use these objects when validated with a relying party > > >> software that is not aware of this type. I don’t think this is > > >> acceptable, as it effectively blocks the introduction of new types > > >> pretty much forever. > > > No, it does not. What I suggested is that when a new object is proposed, > > it is the responsibility of the those proposing the new object to > > explain how it will be incrementally deployed. That explanation belongs > > in the RFC defining the new object, and in an updated version of 6486 > > will need to be generated. We have no good examples of new objects that > > provide a basis for describing how to accommodate incremental > > deployment, and thus no basis for defining such mechanisms at this time. > > It might be the case that a new object will be defined that requires the > > CA to maintain a separate pub point using some newly-defined SIA > > pointer, indicting that the new pub point contains the new object and > > thus RPs that don't know how to process the object MUST NOT follow that > > pointer. There will need to be agreement on how long a CA MUST maintain > > the old pub point, etc. But, absent a concrete example of a new object > > type that warrants this sort of effort it is premature to write a spec. > > > The situation you describe here sounds horrible, trying to keep older > RPs from seeing newer objects they're not equipped to fully > understand. A much more robust system would be one where RPs are not > thrown off by unknown object types retrieved from known publication > points and listed in manifests. Clearly older RPs would not know what > use to make of newer objects, and thus would ignore them. Network > operators interested in taking advantage of the new objects would > first need to upgrade their RPs in order to do so, but that's BAU. Experience with X.509 cert extensions suggests that the approach I noted is preferable. Saying that older RPs can ignore objects they don't understand introduces ambiguity in RP behavior, which is precisely the concern that motivated the effort to generate 6486bis. Steve From nobody Sat Aug 29 21:49: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 787F03A1430 for ; Sat, 29 Aug 2020 21:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 mITx4swEedfF for ; Sat, 29 Aug 2020 21:49:05 -0700 (PDT) Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 217643A142E for ; Sat, 29 Aug 2020 21:49:02 -0700 (PDT) X-QQ-mid: bizesmtp11t1598762935t2mvfpuq Received: from [192.168.3.24] (unknown [223.21.254.18]) by esmtp6.qq.com (ESMTP) with id ; Sun, 30 Aug 2020 12:48:52 +0800 (CST) X-QQ-SSF: 00400000002000X0Z000000A0000000 X-QQ-FEAT: 2Jv068wAOjb5VLoLeohB/axnXO9hfTwstcp3S19/IsIYO6lrIzumsA0MrbZFi MSG0y4IHvEbLm4692fRC0q1p8zKX/DpTSfGIsArMUVQt9BVVxfO0CgcCxmeqzHY3XcFCaCB IrqCtDqECN+ZNKJ/SwlquDWdK4pCVGSCKFF2eHcJrOPSSdgtylXQQuwRYcLMSFa/0icRnpg 51tYDWNokEnhAQ4Qha9FEtmhGLk0Z6V1ihhL3XVN9cBgtceSoMW2fz7XsvUlTFgrpjgczdX B4azb0cPTbhALpU/Hye3VNg/VycRk/pX8G3Ital2jwIh2SgDKKKse/CsGqKa+UmEnxR/mXj DNvn+EvR2VHRI7dsS6IKQS4soCju63R5jAUikwu X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> Date: Sun, 30 Aug 2020 12:48:51 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> To: Stephen Kent , Tim Bruijnzeels X-Mailer: Apple Mail (2.3608.120.23.2.1) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign7 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 04:49:09 -0000 > 2020=E5=B9=B48=E6=9C=8830=E6=97=A5 02:58=EF=BC=8CStephen Kent = =E5=86=99=E9=81=93=EF=BC=9A >=20 > Tim, >> Hi, >> I agree that a correctly functioning CA will produce a sound set of = objects. Also it is highly unlikely that a CA will just publish an = expired ROA. The much more likely scenario is that a CA is unable to = make or publish updates and the MFT and CRL go stale, and the MFT EE = expires, way before any ROA or issued cert would. > I agree that these seem to be the more likely error modes, but there = also was a discussion of encountering more than one CRL, for example. >> That being said there are scenarios beyond the control of a CA that = can lead to invalid objects: >>=20 >> 1) rsync >>=20 >> If the RP does rsync only, they may get an inconsistent data set. = Transactions are not supported here. They just get an old MFT and new = CRL or vice versa, or they may get a new MFT but not the new object, = etc. This is a race condition that happens infrequently when RPs fetch = during publication. It is rare, but it does happen. > I agree that this may happen, even if one publishes all of the objects = in a new directory and the switches the pointer. But, in that case, the = RP should consider this a failed fetch and retry. I believe that's what = the RPSTIR software did (does?), so it's not a fatal error. Yes. RPSTIR2 does do so, retrying. It is difficult for an RP to determine if it is a rollover or a mistake = when it sees new MFT and old signed objects coexist in the repository in = question. If it is a mistake, RP is supposed to consider those old objects invalid = as per 6486bis. But if it is during rollover, RPSTIR2 now has to keep retrying until = things are seems ok.=20 IMHO, I suggest it is the CA that does make-before-break by setting up a = new publication point with new MFT and new objects, keeping old ones = still valid. Once the new publication is all ready to service, CA = replaces old SIA with new one. This is what I can see by far a = compromise to solve this issue. Di= From nobody Sun Aug 30 12:59:59 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 739743A040F for ; Sun, 30 Aug 2020 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.948, 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 D0TmhH8yU2ru for ; Sun, 30 Aug 2020 12:59:57 -0700 (PDT) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (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 4F06E3A043E for ; Sun, 30 Aug 2020 12:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598817596; bh=Kn8P3DizRAUhoMn9d6RNl8RxX29SH66+iwZyBlMTqQc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=tAyoMvoMpLimFvBXg1vRPcLC7YYEfoM9NR3Q/0gIAWwpdoBFMS4vl5qp1TCsWQhj2AZK2n7+ZCDOZhSFdBlw0WwciOVLuiPP15rycU/d1+Rnlk8pMi2J4am+WILIPwolTaWdm9GivPY3ku3OdRlksJ1kEr2PW0iB3VNC2PdNhEaovLHB1zdxq5fFMatCHxirwIilDUkqdsXcaQCMUPeE0HE0PEMmwzBsLIbHiQXX5OnAgrO26jmsSiu3ftHql6OUfrW+UUNsBgjrfwaULMzm3vgF1EzjJ0wAI7MHo1tWyyNGcVnjZ/MaX+Uvs8653XckH45shf3iACkt/I1kMEIHSw== X-YMail-OSG: cl7fxEcVM1mFdhu6Ds6bwEZ_5CzSan8apNHBxqIJiUDd_TJScn8eWTYgVcHeeWo ARVGYsTRJDNgduUadCAKtpWXl9GUwutJmK9Pmza6jLItDpCzyz2xnMenNBfui4w6pKGSFyCC5A6H 7_njak42oZTZQwq74W.jdfbFPma91PJWFgWLy4fz3o4YzqWx37o6AnN7XFAqNtW9dSToEYAgXYQJ HoQ58rVM0H69SWt5eac4I8LsTLEzXGFP1ONSRmzgf6FeXK1L_VbIGyGYy9jhoUMR6fwMfrlqKN00 nZDcT712TW1PJMoVj1iHQZ11Tqr5C4TTIMNdpXeS8Kd_xCe_odqS_VI8xZyLPvyPXCzXu_5ZqKzT 8JyiUc382YdiV4jHZQUkyGkylkh8CeSNf5YP0oiEaZm5e8KT9utKhL3zVXFko55siXJiL7ntPpEB w.KEGg.SQNkbMHxNcMNs4jVB3z2IJiSJkrtmz.viH_yQpbHOwa_AmytieM.jBgWgT9n3o6WAxSeM trUOYz1AcJzdhjLf5LKqeDnwnbj7NzdH4LXE5_e8GmWgwrrRUU6ao7A1mGgVps3QJ2g0FeEk.UWm j6FBcLs3NU_nGt4Ue3cJbOzczGSL9f66OgvyhKaCOAItKXTxTFNzxLMm7Pa0DaSAjf8J_vApzqNI Qs7BSqVQW7lJSoYLMiqy0WXElk6OXyBURAS1aC8BcSnjjYUZ2bv_oHrjAxVilacK5BIntwdGiRAT DOr54iHFEAxo9DiGY8WwOlE4T3Qgc8eZovcls1BFp0CELGEZ5hwSsY1OtmhgDKZsQRume2C82FbM 5P3_LNwEfGNBrKz04jEy0Srl9sYZ55K_fjntZvyKWCvoC7wQMlD9E8JB3krjFA1d7wE_fuNFS8PB 0_W9mcVolljQCEJsOkL2p3PxE5MzyxIRUxbgOC4J5sJXSQTiIIg9qFh7qzd3OYj9AK60CmGdlkem VQiPWbPqxzwkDX_0iVLD8ZmAZuTt9ZNgjupS6JOLzhm3qXKq7FQgzwxSrX77uFiZAv3.D1fkbb9e UpJWrDjTnoucGUAb6tbL33ShDuouSVb6IRbV4N5prV2I6l7p7MtMRzlKRx4XyFouzEOyiTf1RX7Q Dl71yRUqkHKEitURX3_h3BtnN_QMvwuWtnpVLDE5kk4U37OEtzst6wxrt0WFj.Rt8iT_h2wPj12k zyeBrXAtPDRU.LTzcvlvN3BywPhJXCuxdvxVe1RDrwhIJxgWAkHd_rzNlrbKs.NXoSuFEL1SQW_R B65oMKcGCuvE6GCKI5hV4tIyHIPhBSjeTias1zhSZEAfb7S8Opunikv62lu4wj7b4SxZeTlWoIlx JHBJCfRlatU03.xEoMn_Rtg4BAwcGHVmKsZtjzhF.1gcvtgvvKqFydm3NYBorJeQW9vZ8rb61BcY wlsDb6nUthFivq0yYALEA_dslwxDm7cfGhc8YBpbatt1C0TA3bTCjsJgbV5iV91_jiGJkRpZgNDH 5aUA.bSFfIOm6Pn3vRmdtfc3DRK_DpAl6Tm5QUj8kgi7Sq5FVJASOyA0xP.3FlIsHIJCzeqr1TX5 FG4yudX2UPOnG4oBgiVgXYyzbGFi9ypIOVJuThulzZXY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sun, 30 Aug 2020 19:59:56 +0000 Received: by smtp408.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0ec9151097a9704ff53048fe3338c05a; Sun, 30 Aug 2020 19:59:55 +0000 (UTC) To: Job Snijders Cc: sidrops@ietf.org References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net> <20200828152505.GH88356@bench.sobornost.net> From: Stephen Kent Message-ID: <08223d90-ee7f-7505-60c7-fab626e5fe19@verizon.net> Date: Sun, 30 Aug 2020 15:59:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200828152505.GH88356@bench.sobornost.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.16565 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 19:59:58 -0000 Job, > Dear Stephen, > > On Fri, Aug 28, 2020 at 10:00:14AM -0400, Stephen Kent wrote: >> I am very bothered by the observation that, if were were to strictly >> enforce the requirements imposed by the RPKI RFCs, then the number of >> verified routes would substantially decrease. You didn't copy the rest of my message, in which I indicated that I felt we were worrying too much about the bad PR associated with having fewer routes verified, as a side effect of adopting stricter rules wrt manifest processing. > >From my observations, OpenBSD rpki-client produces 514 VRPs fewer than > some of the other validators, but still totals at 171,643 VRPs related > to the global routing system (currently 895,143 routing table entries, > ipv4 and ipv6 combined). > > In the grand scheme of things those 500 VRPs to me are not 'substantial' > but rather "just out of luck", knowing that any attempts to 'repair' or > 'salvage' those 500 VRPs puts the remaining 171,643 route origin > authorizations at risk. > > This is a good noise level, and if we come up with additional ideas > to improve strictness that krank it from 500 to the low thousands, we > are still in great shape. Also knowing that whatever triggers further > decreases can probably easily be remedied by the relevant TA or CA. I agree with your point. Steve From nobody Sun Aug 30 18:59:45 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 AE8903A0C97 for ; Sun, 30 Aug 2020 18:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 uOIl4F1cBHJc for ; Sun, 30 Aug 2020 18:59:38 -0700 (PDT) Received: from smtpproxy21.qq.com (smtpbg704.qq.com [203.205.195.105]) (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 3B3733A0C96 for ; Sun, 30 Aug 2020 18:59:35 -0700 (PDT) X-QQ-mid: bizesmtp13t1598839169tnucmnpc Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Mon, 31 Aug 2020 09:59:28 +0800 (CST) X-QQ-SSF: 00400000002000X0Z000B00A0000000 X-QQ-FEAT: tvOgVvG7QYDx4jvxRmRm64ZdV5kmdFiHM4VZLwsW9CncYRD9vJbmviHi0lOAf 5ue3H4afNbUQIc3VfuH4n4FbhZe5mXIhjpNncPkAHnpUhxOyQO1YZNxsf/V7JW7WYJ2oCLA BkAv1uBu6sOcFZOzIw6QPg73Sa+5Gm2pbs+kTCo8z3UtaV6uu4Zlmz7hao4/PRm7oxPzedm WrkwHIhPGWKSy9HPycv6VCn0H/QGUCL4EtgtpNMqjX/Pc07WM+HjrmQYedaQX5pacIdfnFh mJ1j+CQp117tXUc7t+1Dy0E+wAwkX8B5hAfkKI0YkzoU3JmuotDzNEfliEioyGEYmZk5tYd 9Lrxvp6nzNtwe6LFLJVv10w5S91ZA== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: Date: Mon, 31 Aug 2020 09:59:25 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.3608.120.23.2.1) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 01:59:43 -0000 Randy, As far as I observe, two measures can be taken to avoid ROA PDU race. One could be done by RP software by sorting PDU as per prefix and its = length, before sending to routers. The other one could be done by routers by establishing a transaction of = RTR session before effecting those in routing table. I think the first one can only mitigate the issue but the second one can = really resolve the problem which calls for router software update. Di > 2020=E5=B9=B48=E6=9C=8830=E6=97=A5 01:14=EF=BC=8CRandy Bush = =E5=86=99=E9=81=93=EF=BC=9A >=20 > draft-ietf-sidrops-8210bis has >=20 > 1.2. Changes from RFC 8210 >=20 > This section summarizes the significant changes between [RFC6810] = and > the protocol described in this document. >=20 > o New ASPA PDU type (Section 5.12) added to support > [I-D.ietf-sidrops-aspa-profile]. >=20 > o A small section, Section 11, has been added to handle two ROA PDU > race conditions, Break Before Make and Shorter Prefix First. >=20 > it is not clear there is a rush on ASPA. as ROA PDU Race Minimization > has serious effect on cache behavior, >=20 > 11. ROA PDU Race Minimization >=20 > When a cache is sending ROA PDUs to the router, especially during an > initial full load, two undesirable race conditions are possible: >=20 > Break Before Make: For some prefix P, an AS may announce two (or > more) ROAs because they are in the process of changing what > provider AS is announcing P. This is is a case of "make before > break." If a cache is feeding a router and sends the one not yet > in service a significant time before sending the one currently in > service, then BGP data could be marked invalid during the > interval. To minimize that interval, the cache SHOULD announce > all ROAs for the same prefix as close to sequentially as = possible. >=20 > Shorter Prefix First: If an AS has issued a ROA for P0, and another > AS (likely their customer) has issued a ROA for P1 which is a = sub- > prefix of P0, a router which receives the ROA for P0 before that > for P1 is likely to mark a BGP prefix P1 invalid. Therefore, the > cache SHOULD announce the sub-prefix P1 before the covering = prefix > P0. >=20 > this has overlap with a discussion Job was having. i would like to > close on this and get it out the door. but it would be good if folk, > reread, thought, and commented. >=20 > randy >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Sun Aug 30 20:18:45 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 5C88A3A0D77 for ; Sun, 30 Aug 2020 20:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 rylAu_UGblx5 for ; Sun, 30 Aug 2020 20:18:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F113A0D76 for ; Sun, 30 Aug 2020 20:18:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kCaL8-0007aX-Oq; Mon, 31 Aug 2020 03:18:38 +0000 Date: Sun, 30 Aug 2020 20:18:38 -0700 Message-ID: From: Randy Bush To: Di Ma Cc: SIDR Operations WG In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 03:18:44 -0000 > The other one could be done by routers by establishing a transaction > of RTR session before effecting those in routing table. you might have a small discussion with a router implementor about where they would like to store the uncommited transaction. consider two things, many current routers still have a 32-bit memory model, and a transaction could be a full dump cold start from a cache. randy From nobody Sun Aug 30 20:33: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 D28BE3A0DEB for ; Sun, 30 Aug 2020 20:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 SqSbmJgn-EX1 for ; Sun, 30 Aug 2020 20:33:13 -0700 (PDT) Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786413A0DEE for ; Sun, 30 Aug 2020 20:33:11 -0700 (PDT) X-QQ-mid: bizesmtp7t1598844784tbg0rir8q Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Mon, 31 Aug 2020 11:33:03 +0800 (CST) X-QQ-SSF: 00400000002000X0Z000B00A0000000 X-QQ-FEAT: AomiL+cBEBPOx2nujMUqfFTOh6ZIh3a4lCXMTtqPT+r/H9e7mvcXu1apcdeo6 bjlskga42cS0+L+nVFiY7EPRThyZiiT1q92VvBRvkOykpKbF/j5sOPncCj2V6oZc7mxTzhB u0fWq/SnJVN6PqTw5n40DoaMv99Me1FFqbwGQ68HB1NdSuXBfn8fGxuW1X4kY9BL2NDE+5k 2glDrfyYIpoN5xdJ7BoVLrp7tAFXch3pONLOVzZEgSNNJdDazc3e/OTzFBY+At205PXP0Tv n3QWnhQSQSyqAYYBf5woHnMacDTsQZbJa3nRC0xP1a4HfSr3LBUAdyYUYxS730tgQpU2jZI 5J5U3HkzLmV2B2ozyxWiv9rqHc3NQ== X-QQ-GoodBg: 2 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Di Ma In-Reply-To: Date: Mon, 31 Aug 2020 11:33:01 +0800 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <1EDB2EB6-A7F0-481C-909D-56DCE4B8FB76@zdns.cn> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.120.23.2.1) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 03:33:19 -0000 Exactly. I am exchanging notes with friends working for vendors on the issue you = raised. It would be better to hear from router implementors in the list. Di > 2020=E5=B9=B48=E6=9C=8831=E6=97=A5 11:18=EF=BC=8CRandy Bush = =E5=86=99=E9=81=93=EF=BC=9A >=20 >> The other one could be done by routers by establishing a transaction >> of RTR session before effecting those in routing table. >=20 > you might have a small discussion with a router implementor about = where > they would like to store the uncommited transaction. consider two > things, many current routers still have a 32-bit memory model, and a > transaction could be a full dump cold start from a cache. >=20 > randy >=20 From nobody Sun Aug 30 21:34:51 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 C10A43A0E7D for ; Sun, 30 Aug 2020 21:34:48 -0700 (PDT) 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=beCRdnlJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v7SxFN/f Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X08j4WQ0LX68 for ; Sun, 30 Aug 2020 21:34:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3928B3A0E7C for ; Sun, 30 Aug 2020 21:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1598848487; x=1600058087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hXong+/qj2XtY6Dx6zgSpDxGP9sFN+QbxT7r5EtX0PE=; b=beCRdnlJTGKLHBUW0u3lQtHGqOnMuBKUCAy2/X3C7EO7h7WSaxuo2eVO lmBtmAgBPSfY5MmIRHSy/jDadSzj+QEXcc40Bd0AdhGjCvwKdZCSZx0kl 3iyRIWHuapjVeYfELe8jSlepTkkgmeOw7V+UvuWZozLKqJqigGym9Euzi M=; IronPort-PHdr: =?us-ascii?q?9a23=3ArWkdPBPUWA2akwNrfzol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13k3FW56d4PQXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoI0RTA4D1YQ6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJBQDkfExf/5JdJa1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHcFgvLAqELoNGA410mHGCUwNVCwEBAQwBARgLCgI?= =?us-ascii?q?EAQGECEQCF4IyAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQMBAQEQERE?= =?us-ascii?q?MAQEsCwEEBwQCAQYCEQQBAQMCJgICAiULFQgIAgQBDQUIGoMFgksDDiABDpQ?= =?us-ascii?q?3kGgCgTmIYXaBMoMBAQEFhToYghADBoEOKoJxg2WCPoQRG4FBP4ERQ4JNPoJ?= =?us-ascii?q?cAQGBYYMVM4ItkxuSV490gQgKgmWaU6BWklGfVwIEAgQFAg4BAQWBayOBV3A?= =?us-ascii?q?VO4JpUBcCDY4fg3GFFIVCdDcCBgEJAQEDCXyPMAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,374,1592870400"; d="scan'208";a="797646762" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2020 04:34:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 07V4YjX9028428 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 04:34:45 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 30 Aug 2020 23:34:45 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 00:34:44 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 30 Aug 2020 23:34:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YghBa0i1J3xkjJhMa5/mgQrB15tJsQ36xtGE9XEZBNbk4oDVaoArQlJAdzVLlIuJHpMznbkG5Tv9Gh1HIeJvpmPILJyeMCYahysz4EEhKNDNiFMhdqY93zEKU4rFmDwbdr0p94X2/EVtlu6y8f6HSU9E5xKxb0TxI5KPUvBMxNlxzUnTbfbfHqS8fb+27+F5ZPXM2J/P9BCjC1QOxgWzbArms3Lc5K6MaATJKMnXldywixDzIxsDMo1+fO4/1cqIVN0x0UhzXnLA3lwrD54pzCi9dCNtpoJO4CHMtrzUxaoQnKBQzTp0I8KmkC9GMtCoY8LP3kc4yigOofNrZqvOrA== 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=hXong+/qj2XtY6Dx6zgSpDxGP9sFN+QbxT7r5EtX0PE=; b=XtjGIq/XZBY/ACm9m1IuE4lkmOzJk9pzEWzfrNZdf7dYf71TEu88ArmhwHD5RqISCGEN61AEUEwNQIuSYkebG/ad5OFAupQzglzCbL1LMkZxUJTndctbh2aAEyITs7Qogfx9SfAH891cbouL+IkPBZ6uo/Nd6QeDBXNzi0Z96MwELxVimwfcfdVMTIeRRMF6FhC01a8WJBb2Tu9NLhhR9MRfV3cVusToo+PVuFU8bUnXCXO2wKNyUHP/j1vpz2OItfUA9IPiG50nLxbxh3B6Qhw9C7uElGZC6aLLNU7MVCpW3T5doS+D1cgJwQ/ZVGIEUYK++5zGqsPZyqZjsGVrbg== 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=hXong+/qj2XtY6Dx6zgSpDxGP9sFN+QbxT7r5EtX0PE=; b=v7SxFN/fPrVX33wv8uSkwCl6Spc5XjGaHMcStqWOjfaRSFa7Ul2Q+lVr9vMSb0JPoOczDdhVhYnZbwskABiSUzAqMvrINd+nkFtvcMWvOSozsB6XYw2aMZRyLcK3C04EASTyTTPjn6Y/IlAkuzjrG61cn3/4Ps5lfDfYWMm/Zm4= Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3080.namprd11.prod.outlook.com (2603:10b6:a03:8c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Mon, 31 Aug 2020 04:34:42 +0000 Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e857:a3fb:11ad:faff%2]) with mapi id 15.20.3326.023; Mon, 31 Aug 2020 04:34:42 +0000 From: "Jakob Heitz (jheitz)" To: Di Ma , Randy Bush CC: SIDR Operations WG Thread-Topic: [Sidrops] draft-ietf-sidrops-8210bis Thread-Index: AQHWfiflJ0fvCtYePUSAK86WYpoS4alReGSAgAAWIgCAAAQFgIAADU/g Date: Mon, 31 Aug 2020 04:34:42 +0000 Message-ID: References: <1EDB2EB6-A7F0-481C-909D-56DCE4B8FB76@zdns.cn> In-Reply-To: <1EDB2EB6-A7F0-481C-909D-56DCE4B8FB76@zdns.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: zdns.cn; dkim=none (message not signed) header.d=none;zdns.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [76.102.46.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 341b1d2f-b023-4b96-3daa-08d84d672e55 x-ms-traffictypediagnostic: BYAPR11MB3080: 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: yqSfC6v54ox3I0qk00FTq31nsTTyeaSBxLu8wFI9SEe41yAQfYhagtSNyiEsOZOKgdd/sz9IeasrrqfYABtLkuhBwGd0j6xUSZ5jjOSx2Yr5xNyMOImHRT5yZress6jPSUxaKQ+fSsyyHkt6ojmFq/RF9Xmgkbv8cw+XLoyGjNiQ47LM/u1XnFSeCITqEVekls4Ar5BgGYlcQA0SYQZuYMS68qryvkd1jj7Iqint07uCcMxLyRUKmZSxMKS0pcPLrLs605bajhPkWFffdT4Tlt19Hvm0x0Z1OMcFK/DNOL8noawa0bCzUY+dDpGStOqfPEhgnJM9uaU34fYMnQQmxtliCOvv5esu3vzSf2eAo9vJY/3kHpj0uJcoAxExjykqUCi7whJ0oNKE1PFoZg2Gsw== 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:(4636009)(376002)(39860400002)(346002)(366004)(396003)(136003)(26005)(186003)(71200400001)(7696005)(2906002)(6506007)(53546011)(52536014)(110136005)(5660300002)(66556008)(64756008)(4326008)(66946007)(66476007)(8936002)(8676002)(66574015)(316002)(478600001)(966005)(86362001)(83380400001)(33656002)(9686003)(55016002)(76116006)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: L4N6qZBMsfba/4FaqbY/yd3uc/B94zSYlophRnRiOZb6jKCVC7k9VZDnx/MGKa1tG1TTHC20a0UZ1X9cjB9R3fMnzunGePPS2s1oaJwd9JPgPodPjmIUGNVylKtZw5rxRwxkGPUlzcZo5KoLe7pNYc4F0d6oEpTLOybYWp2XnLQfBkeLcqhKOcOL6BP7dxNjhGUHSucuEG2LfFSZTFPM2B/pVx31lusnun9JyrMxzLA7O5C8roV2trMRT4bmUxphwlKTeR3C0FT7QbzZDerl0+eD+V5TgKDu3SJM0IqbvrVsXmiPPD3x8vseaPBlAsrbxD47TReVdXq6J5i6stWE2maHNssog1hjbpdfwkGQlq+flVDYCe/1N5ODnUfOrNC7N2BrHUm0ERFOlpAxh25w9FTZgSzaIT99bI/TnU4dX2PqLIrKNxFQ4rMgUo/XOFYxCiFQkCOIj5qVnSe+YI7pHdxtityyhYsvJ7m9XCwJ8ZYz9lACBfEG4pX9z9FQviemZAo6897BIoqtRmqmR2Ht7zaFmBnejETTxAQpl2oVkbtjyWBk7ffGJKtwkVqN5AaCdzB/lq17fjQ2rzHYGsjHAGE8JTVZQMUu4tvV8kliH/ghr0icXOu8Ghu4KkNTSELYFdM7CJrxdLmmXpzDv52uwQ== 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: 341b1d2f-b023-4b96-3daa-08d84d672e55 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 04:34:42.6174 (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: cQWxhSWy19nWSTzKNlW/IISCHb3FYYhjZW7ksyH5uC4KIwV5IazibrwHhMfTrrM9HZF/jpY32Xh52XPYzGLiKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3080 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-8210bis X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 04:34:49 -0000 SSB3YXMgZ29pbmcgdG8gc3VnZ2VzdCB0aGUgc2FtZSB0aGluZy4NClNpbmNlIHRoZXJlIGNhbiBv bmx5IGJlIG9uZSB0cmFuc2FjdGlvbiBvdXRzdGFuZGluZyBmcm9tIGFueSBvbmUNCmNhY2hlLCB0 aGUgc3RhdGUgY2FuIGJlIHN0b3JlZCBhcyBmbGFncyBvbiB0aGUgcmVjb3Jkcy4NCllvdSB3b3Vs ZCBuZWVkIHRvIGFkZCB0aGF0IGFueSBQRFUgZm9sbG93aW5nIHRoZSBkYXRhIFBEVXMNCm90aGVy IHRoYW4gYW4gRW5kIE9mIERhdGEgd2lsbCBpbnZhbGlkYXRlIHRoZSBwcmV2aW91cyBkYXRhIFBE VXMuDQpGb3IgZXhhbXBsZSwgYSBTZXJpYWwgTm90aWZ5IG9yIGEgQ2FjaGUgUmVzcG9uc2UuDQoN ClJlZ2FyZHMsDQpKYWtvYi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNp ZHJvcHMgPHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERpIE1hDQpTZW50 OiBTdW5kYXksIEF1Z3VzdCAzMCwgMjAyMCA4OjMzIFBNDQpUbzogUmFuZHkgQnVzaCA8cmFuZHlA cHNnLmNvbT4NCkNjOiBTSURSIE9wZXJhdGlvbnMgV0cgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW1NpZHJvcHNdIGRyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzDQoNCkV4YWN0bHku DQoNCkkgYW0gZXhjaGFuZ2luZyBub3RlcyB3aXRoIGZyaWVuZHMgd29ya2luZyBmb3IgdmVuZG9y cyBvbiB0aGUgaXNzdWUgeW91IHJhaXNlZC4NCg0KSXQgd291bGQgYmUgYmV0dGVyIHRvIGhlYXIg ZnJvbSByb3V0ZXIgaW1wbGVtZW50b3JzIGluIHRoZSBsaXN0Lg0KDQpEaQ0KDQo+IDIwMjDlubQ4 5pyIMzHml6UgMTE6MTjvvIxSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiDlhpnpgZPvvJoNCj4g DQo+PiBUaGUgb3RoZXIgb25lIGNvdWxkIGJlIGRvbmUgYnkgcm91dGVycyBieSBlc3RhYmxpc2hp bmcgYSB0cmFuc2FjdGlvbg0KPj4gb2YgUlRSIHNlc3Npb24gYmVmb3JlIGVmZmVjdGluZyB0aG9z ZSBpbiByb3V0aW5nIHRhYmxlLg0KPiANCj4geW91IG1pZ2h0IGhhdmUgYSBzbWFsbCBkaXNjdXNz aW9uIHdpdGggYSByb3V0ZXIgaW1wbGVtZW50b3IgYWJvdXQgd2hlcmUNCj4gdGhleSB3b3VsZCBs aWtlIHRvIHN0b3JlIHRoZSB1bmNvbW1pdGVkIHRyYW5zYWN0aW9uLiAgY29uc2lkZXIgdHdvDQo+ IHRoaW5ncywgbWFueSBjdXJyZW50IHJvdXRlcnMgc3RpbGwgaGF2ZSBhIDMyLWJpdCBtZW1vcnkg bW9kZWwsIGFuZCBhDQo+IHRyYW5zYWN0aW9uIGNvdWxkIGJlIGEgZnVsbCBkdW1wIGNvbGQgc3Rh cnQgZnJvbSBhIGNhY2hlLg0KPiANCj4gcmFuZHkNCj4gDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNp ZHJvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lk cm9wcw0K From nobody Mon Aug 31 01:47:54 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 27BCC3A1142 for ; Mon, 31 Aug 2020 01:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6FURNtAr5CW3 for ; Mon, 31 Aug 2020 01:47:43 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C0B3A115D for ; Mon, 31 Aug 2020 01:47:43 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:3078:6343:6a85:9a0d] (unknown [IPv6:2001:981:4b52:1:3078:6343:6a85:9a0d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 90FAE1E289; Mon, 31 Aug 2020 10:47:39 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598863659; bh=MdXQ5KlaWaKdM11tcBnYEsFKXvAoUWaTJbvCWUJ9I2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=h9ESeoYvXbwrua+7dJspIdkQX5gpNxNK+WEuIIRFUbHZGmLsLfqDbUnZdX979tzva IEuPP0YniYeiAk5pI5bnbcsGAJmMKyB+8mju9Fxr5pySM37LXKcSSa9+1mjUhVQegX +LZirL8YhDdBEDqI9t500AdUVu8CG77eVSu9I17k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <20200829184819.GL88356@bench.sobornost.net> Date: Mon, 31 Aug 2020 10:47:39 +0200 Cc: Nathalie Trenaman , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5CDFEEF2-C16A-47B7-B520-36A13318BC1A@nlnetlabs.nl> References: <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <60849B88-EC02-4B86-8FF4-2AD7401567B0@ripe.net> <20200829184819.GL88356@bench.sobornost.net> To: Job Snijders X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report) 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, 31 Aug 2020 08:47:53 -0000 Hi, > On 29 Aug 2020, at 20:48, Job Snijders wrote: >=20 >> This is why I believe Tim=E2=80=99s suggestion for a flag day sounds >> reasonable to me. We have to inform CAs about the impact changing the >> behaviour of RPs has on them.=20 >=20 > A flag day to release a security update? Flag day's generally are used > for other types of events. To be clear: I suggested a flag day for encoding issues which are not = *critical*. No CA is big enough to fail if there is a critical issue. Fact is that if you take the position that any object which is not 100% = specification compliant MUST be considered invalid, then NONE of the = current validators are secure. The ARIN issue was related to wrong encoding. The relevant RFC is pretty = easy to misinterpret. But while there is a mandated encoding here, the = error did not change the semantics. Furthermore the signature algorithm = is defined by the RPKI RFCs - and the object has a whole could be = validated. There never was a chance of different interpretations. There = never was a chance of the signature being valid over modified content. = So, wrong as this may have been, qualifying this as a critical issue is = somewhat questionable. And given that the RFC was not very clear, it was = right that RP implementers questioned the issue raised before = implementing. I could make equally bold statements on how routinator with the --strict = option is in fact the only secure validator, because all others accept = BER (not DER) encoded MFT and ROA objects. BER encoding is more = complicated to decode - one issue in particular is that you do not = necessarily know the size of compound values up front, and this has led = to security issues in other applications. Surely, this is at least as = bad, quite possibly worse. In practice, of course, we downloaded the = objects and we can check their size before ending up here. So, while it = is wrong, I would actually claim that this is not *critical*. This should not stop us from improving. On the contrary. We can all = learn from each other here. It is a very good goal to aim for 100% = compliance, but it's going to require work from everyone to get there. = This is why I suggested a flag day. Let's just focus our energy on = working with each other, shall we? - RP compliance checking It is not easy to get to 100% checking in RPs. You can only test for = things that you can think of - or things your library developers = (openssl, bouncy castle etc) have thought of.. In days long past Rob Austein and Andrew Chi (then BBN) and I (then RIPE = NCC) met to discuss validation corner cases. Andrew was able to generate = all kinds of broken objects that our library simply could not generate = (we could generate objects that we believe to be valid only). So, I was = very grateful that he could do this and we could test our validation = software. These objects are still used for regression testing in the = RIPE NCC validator today. You can find them (100s of corner cases) here: = https://github.com/RIPE-NCC/rpki-commons/tree/master/src/test/resources/co= nformance The ARIN encoding issue is not in there. Still, maybe this kind of set = up can be useful for RP implementors again. It could be revived, = extended, and hopefully be of use for all. - CA compliance Most implementations have code bases going back to 2011 or earlier. Most = have automated tests in place using rcynic and/or the ripe ncc = validator. Nowadays there are many more options available. My advice = would be that all CA developers start testing with all RP = implementations they can get their hands on, and use 'strict mode' where = available. As for processes.. if we can get RP and CA developers to agree, I think = we can move forward on this without the need for an RFC even. It's a = matter of organising things for sure. But I believe that other flag days = (e.g. DNS) were just co-ordinated between all parties involved. Kind regards, Tim From nobody Mon Aug 31 08:06: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 84C583A14B5 for ; Mon, 31 Aug 2020 08:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TaYdkqm73ms6 for ; Mon, 31 Aug 2020 08:06:07 -0700 (PDT) Received: from mail5.web-server.biz (www5.web-server.biz [185.181.105.105]) (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 28AC73A14B2 for ; Mon, 31 Aug 2020 08:06:06 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail5.web-server.biz (Postfix) with ESMTPSA id BD1D247C7E for ; Mon, 31 Aug 2020 15:05:59 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id m23so6241072iol.8 for ; Mon, 31 Aug 2020 08:05:59 -0700 (PDT) X-Gm-Message-State: AOAM531jQsq6cjbxKRUN4a92XIrVc2DoMaroDVVcCF/6hWyexsr79OOf SxHvvU3zSyV/yT8vaC6FEg6oqDkv3U2KMJ4fd9U= X-Google-Smtp-Source: ABdhPJz4br/+Bss/IGW4FTiGmCr+jK9J096AbI3IXMTZ2BSYlvWYvj9a9yvQZwcuMIL0+BUwMiTHg+EOfhHeeHXcI4Y= X-Received: by 2002:a6b:fb0c:: with SMTP id h12mr1498958iog.98.1598886358135; Mon, 31 Aug 2020 08:05:58 -0700 (PDT) MIME-Version: 1.0 From: Lukas Tribus Date: Mon, 31 Aug 2020 17:05:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] stale VRP's in production networks 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, 31 Aug 2020 15:06:09 -0000 Dear all, I'm concerned about stale VRP's in production networks with ROV enabled. It is my understanding that RPKI/RTR was developed with the intention to fail-open, so when the data is non-existent, obsolete or the validator is broken, we would not trust that data and either failover to a different RTR server or fail-open completely if there are none. Stale VRPs on production routers are a bad thing, especially because it could remain undetected for a long time. It is unrealistic to expect perfect monitoring and immediate manual intervention on subtle errors from all those operators out there. We need to fail hard and early in my opinion. To my surprise, multiple RTR implementations (see below) actually prefer serving stale data *by design* as opposed to closing RTR connections or withdrawing VRP's, for the sake of availability. I think a software stack where a single bug or honest error (human or otherwise, like a memory allocation failure, a validator crash due to a bug, or admin disabling the validator erroneously) will easily cause VRP's to become stale on production networks *for a long time* is very dangerous. Failing and not serving VRP's while broken would be expected behavior in my opinion. Regarding the availability of RPKI validator/RTR server setup I think this is something that the operator needs to address based on the individual situation/network, not something that RTR software should care about. I believe RTR software needs to be able to fail early, without hiding issues and subsequently serving stale VRP's. RPKI-validator-3 [1]: > The RPKI-RTR server is a separate daemon, that allows routers to connect > using the RPKI-RTR protocol. It's set up as a separate instance because > not everyone needs to run this, but more importantly, if you do need to > run this then a separate daemon allows one to run more than one instance > for redundancy > *(it keeps state even when the validator is down)*. gortr [2]: > Yes this behavior was implemented on purpose to provide resilience in > case of a temporary validator issue. > [...] > The choice was made to ensure continuity in Origin Validation rather > than bouncing routes/VRPs (+ added complexity on RTR serial management > in some cases). Any inputs and opinions on this would be greatly appreciated, -- lukas [1] https://github.com/RIPE-NCC/rpki-validator-3/wiki [2] https://github.com/cloudflare/gortr/issues/81#issuecomment-676247412 From nobody Mon Aug 31 11:03:59 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 3BDF33A189C for ; Mon, 31 Aug 2020 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QRnN92FEDxlp for ; Mon, 31 Aug 2020 11:03:48 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ABE3A18A8 for ; Mon, 31 Aug 2020 11:03:43 -0700 (PDT) Received: from [IPv6:2001:981:4b52:1:46d:f759:87b6:c673] (unknown [IPv6:2001:981:4b52:1:46d:f759:87b6:c673]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E40001ECF7; Mon, 31 Aug 2020 20:03:40 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598897020; bh=En7B5ieMONVtdTDGeoUy5z7lGHrjBFxYQ/lR4oQ9qo0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CQ7dv7GQox8oZT/u2jrIQXYbmaYOdky9uUeTOYADKJoOZk6v0hRT6l2zk+EfGcFKo DxIi+ofU56gLIoJoBDI3+poxE8IgEKYJVTMePv2nUXR2kZZBEqC2M7PJgSozca6NJY KkLcy1x7cXhOOowbih6dNeBHY5IDcJopKnslEtZg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Tim Bruijnzeels In-Reply-To: <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> Date: Mon, 31 Aug 2020 20:03:40 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <291655EE-2255-441B-B425-59BEE6DBE39F@nlnetlabs.nl> References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl> <10b9622d-90b0-63e8-288e-858f88835284@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Sidrops] 6486bis: Failed Fetches 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, 31 Aug 2020 18:03:58 -0000 Hi, > On 29 Aug 2020, at 20:58, Stephen Kent wrote: >=20 > Tim, >> Hi, >> I agree that a correctly functioning CA will produce a sound set of = objects. Also it is highly unlikely that a CA will just publish an = expired ROA. The much more likely scenario is that a CA is unable to = make or publish updates and the MFT and CRL go stale, and the MFT EE = expires, way before any ROA or issued cert would. > I agree that these seem to be the more likely error modes, but there = also was a discussion of encountering more than one CRL, for example. >> That being said there are scenarios beyond the control of a CA that = can lead to invalid objects: >>=20 >> 1) rsync >>=20 >> If the RP does rsync only, they may get an inconsistent data set. = Transactions are not supported here. They just get an old MFT and new = CRL or vice versa, or they may get a new MFT but not the new object, = etc. This is a race condition that happens infrequently when RPs fetch = during publication. It is rare, but it does happen. > I agree that this may happen, even if one publishes all of the objects = in a new directory and the switches the pointer. But, in that case, the = RP should consider this a failed fetch and retry. I believe that's what = the RPSTIR software did (does?), so it's not a fatal error. >> I remember that many years ago I wrote code in the, then, RIPE NCC = validator 2 to catch this issue. And only process publication points if = the set was consistent. This was an allowed, but not mandated, = interpretation of 6486. >>=20 >> Note that with RRDP we have deltas. Solving this issues was one of = its design goals. So, phasing out rsync could mitigate this. >> (yes, I realise now that the co-chairs asked me to re-submit the I-D = for this, and I still need to do it) > I'm still waiting to see a clear, and hopefully concise, description = of how an RP verifies that the pub point data acquired via RRDP is = constrained in the hierarchic fashion imposed by the rsync directory = model, but that's a separate issue. Coming up, I just submitted 'draft-ietf-sidrops-deprecate-rsync-00' as = requested by the co-chairs on 16 July. Sorry, for the delay. Let's have = the discussion there. >> 2) resource changes >>=20 >> If the parent removes any resources from the child before the child = has had a chance to clean up objects then this will lead to invalid = objects. Being strict that *all* objects must be valid will then lead to = rejection of the CA's products. Even if it is only for a few hours. >>=20 >> I believe that this issue could be greatly mitigated if RFC6492 would = be extended with a notion to give children a warning about planned = resource removals. The length of this warning time being a function of = the contact frequency of child CAs and the depth of the CA hierarchy. = But, if this frequency could also be stipulated - say SHOULD every 10 = minutes? Then a warning time of just a few hours would already be = plenty. >>=20 >> However, this is a separate discussion. I do not suggest that we = block progress on 6486bis for this. I am just saying that if strict = checking for *all* objects is where the consensus goes then the WG must = be aware of these consequences and accept them. > yes, this is a separate discussion. Possible extension of RFC6492 is a separate discussion. For 6486bis the WG should be aware that intermittent failure cases can = come up, and assume that they will. If this happens high enough in the = tree - e.g. RIR shrinks NIR, while NIR still issues affected resources = to its members - then this will invalidate a big branch, resulting in = not founds. This may be a soft landing, but it is a landing. In short: Given that I expect that we are never come to a consensus = other than the total reject-all-if-one-fails - I can live with this if = we must, but don't let it come as a surprise. >> The current version of 6486 allows RPs to treat individual objects as = invalid. -bis is trying to change that to say that the whole set of = objects must be valid. This changes the consequences for the deployment = of new object types, so it is right to consider this now.=20 > 6486 allows an RP to behave either way, e.g., to accept some but not = all inconsistencies to to reject them. So, it's not quite accurate to = suggest that RP software that operates in accordance with 6486 will = treat individual objects as invalid- it might, or it might not. >> The most likely next object type would be the ASPA objects. I don't = think that RPs should reject all ROAs because they do not yet understand = ASPA. Given that object types in the RPKI get distinct file names, and = RPKI signed objects get distinct OIDs I think it would be reasonable to = say that RP software can ignore object *types* that it does not = understand. I would still advocate then that the RPs do check for the = presence and hashes of these objects as stipulated by the signed MFT, = but not consider their content. > Allowing RPs to ignore object types they don't understand prevents a = CA from being able to convey the notion that a new object type is = important (to that CA). I don't think this is a good strategy. It means = that RP behavior will be ambiguous relative to new object types. So far none of the objects have seemed to need this flag. >> If we don't then the consequence will be that new object types only = become deployable after a significant percentage of RP has been upgraded = to version that understand the new type. >>=20 >> Now, if all operators say that they are fine with this: let things go = unknown for everyone who did not upgrade, and force them to do so.. = sure. But it is right to consider this now and make a conscious choice. = Oh and BTW.. for RPKI use cases where we only have VALID/INVALID but no = NOT FOUND, such as BGPSec, this would be problematic. >=20 > If we want to have a consistent and flexible approach to accommodating = new objects I suggest the strategy I mentioned earlier. Define an = additional SIA URI that points to a pub point (and manifest) where we = can introduce the next version of the signed object format, one that = includes a critical flag, analogous to X.509v3 extensions. This allows = each CA to decide which object types have to be processed by an RP in = order for the whole pub point to be accepted vs. rejected. Note that = this will require modifying a lot of RFCs, but it is a flexible, = extensible approach to this issue. I agree that it's flexible and extensible. I had not thought of this = approach. But it is a lot of work, not just in RFCs, also in code. It also raises = questions about how and when old PPs without the new objects can be = deprecated. You can give operators more time to upgrade, but at some = point plugs will probably be pulled? Maintaining multiple PPs = indefinitely seems rather wasteful. I would like to hear what others have to say.. I have the feeling that = ASPA is getting close, and I would really not like to see it delayed = because of this. If we do go down this road then I think that we should also look at the = manifest object itself, and let it convey which object (types) are = critical (and while we are at it, we can specify types instead of using = filename extensions). That way future object types could introduced more = easily perhaps - this obviously needs more discussion but it could even = allow for semantics like: 1) new object please test, don't use, 2) new = objects, use if you can, 3) new objects, critical - fail if you don't = understand. Tim >=20 > I agree that even if we adopt the current 6486bis , for now, that a = flag day is appropriate, and it shoudk be part of the document. >=20 > Steve >=20 >=20 From nobody Mon Aug 31 12:05:31 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 9A02D3A18C5; Mon, 31 Aug 2020 12:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <159890072559.31155.191532586512778700@ietfa.amsl.com> Date: Mon, 31 Aug 2020 12:05:25 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 19:05:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Resource Public Key Infrastructure (RPKI) Repository Requirements Authors : Tim Bruijnzeels Randy Bush George Michaelson Filename : draft-ietf-sidrops-deprecate-rsync-00.txt Pages : 10 Date : 2020-08-31 Abstract: This document formulates a plan of a phased transition to a state where RPKI repositories and Relying Party software performing RPKI Validation will use the RPKI Repository Delta Protocol (RRDP) [RFC8182] as the only mandatory to implement access protocol. In short this plan consists of the following phases. In phase 0, today's deployment, RRDP is supported by most, but not all Repositories, and most but not all RP software. In the proposed phase 1 RRDP will become mandatory to implement for Repositories, in addition to rsync. This phase can start as soon as this document is published. Once the proposed updates are implemented by all Repositories phase 2 will start. In this phase RRDP will become mandatory to implement for all RP software, and rsync must no longer be used. Measurements will need to be done to help determine when it will be safe to transition to the final phase of this plan. During this phase Repositories will no longer be required to provide rsync access for RPKI validation purposes. However, they may still provide rsync access for direct access to files for other purposes, if desired, at a best effort basis. Although this document currently includes descriptions and updates to RFCs for each of these phases, we may find that it will be beneficial to have separate documents for the plan, and each phase, so that it might be more clear to all when the updates to RFCs take effect. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/