IETF Logo Mail Archive

Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved)

John Curran <jcurran@arin.net> Thu, 27 August 2020 12:42 UTC

Return-Path: <jcurran@arin.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC16A3A0CAF for <sidrops@ietfa.amsl.com>; 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 <sidrops@ietfa.amsl.com>; 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 <sidrops@ietf.org>; 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 <jcurran@arin.net>
To: Mikael Abrahamsson <swmike@swm.pp.se>
CC: Martin Hoffmann <martin@opennetlabs.com>, Job Snijders <job@ntt.net>, "sidrops@ietf.org" <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: <DE33EFAE-FBD2-478F-92A9-1FBD81CCC43F@arin.net> <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <alpine.DEB.2.20.2008271422560.11025@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.2008271422560.11025@uplift.swm.pp.se>
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: <https://mailarchive.ietf.org/arch/msg/sidrops/3iUlAetBdHeh8WhcNQZWRhl-K-A>
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 <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2020 12:42:42 -0000

On 27 Aug 2020, at 8:30 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> 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 - 

	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’m unaware how we get to 'work out the teething issues’, as you suggest, unless you meant the latter and its detailed messages…) 

/John

John Curran
President and CEO
American Registry for Internet Numbers

v2.23.0 | Report a Bug | By Email