Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator

Tim Bruijnzeels <tim@ripe.net> Tue, 25 July 2017 13:49 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7557127869 for <sidrops@ietfa.amsl.com>; Tue, 25 Jul 2017 06:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 HS4Zi5n559Zv for <sidrops@ietfa.amsl.com>; Tue, 25 Jul 2017 06:49:32 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC8E129A96 for <sidrops@ietf.org>; Tue, 25 Jul 2017 06:49:32 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1da0DJ-0001r6-6k; Tue, 25 Jul 2017 15:49:30 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-196.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1da0DJ-0006F2-2X; Tue, 25 Jul 2017 15:49:29 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com>
Date: Tue, 25 Jul 2017 15:49:28 +0200
Cc: "Carlos M. Martinez" <carlosm3011@gmail.com>, Matthias Waehlisch <m.waehlisch@fu-berlin.de>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net>
References: <alpine.WNT.2.00.1707171628150.10844@mw-x1> <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198d73f28c16dfee394677c38a82454f31
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CUsoZWMeEKQjgVlLcfvjcs6y6cI>
Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2017 13:49:35 -0000

Hi,

Jakob, not picking on you - but your statement gave me a good angle for what I wanted to say on this.

> On 20 Jul 2017, at 19:01, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> If it causes legitimate traffic to fail, then it's wrong.

Sure, but knowing what constitutes legitimate is the trick then. If an announcement has status “invalid”, then this means that the holder of the prefix made one or more authorisation(s) for other announcement(s) for this space, but not for *this* announcement.

Whether this is:
 a) a bug, because the holder wants the announcement but neglected to authorise; or
 b) a feature, because the holder does not want this announcement

That is impossible to tell based only on the observation that there is a disagreement. And I fear that any smart heuristics, e.g. based on announcement history, are in the end only estimated guesswork. It may be smart and it may be right more often than wrong, but it’s still guesswork.

Now, I see value in exposing such differences and helping operators anywhere to understand and debug them and take action, but I have to say that I disagree quite fundamentally on automating decisions on the validator side. I believe that it will inevitably result in announcements that are supposed to be “invalid” (by choice of the holder) to become authorised. This will degrade the benefit of using RPKI Origin Validation for networks that do maintain their ROAs properly. Secondly I believe that ‘fixing’ this on the RP side will remove the incentive for networks to fix their ROAs so that they match their intended announcements. If it hurts, people will fix it. This has been happening in Europe for decades w.r.t. route objects.

Let me provide a further datapoint. We have 4880 organisations that activated their hosted RPKI service. Some organisations only switched on the system, but a total of 2874 organisations actively maintain ROAs. We provide an opt-in service whereby organisations can receive alerts in case we see announcements that are inconsistent with their ROAs. Although this is not mandatory, the majority of organisations (2020) have opted in to this service. The alerts will inform the organisation of any “invalid” or “unknown” announcements. On receiving this organisations can choose to authorise these announcements - but ONLY if they are supposed to be correct (their choice). If they do not authorise the announcement, and it keeps happening, they will receive an email every day. For this reason users can also choose to suppress the warnings on announcements they do not wish to authorise. We have 219 organisations that have at lease one announcement suppressed.

So, in short: I believe that this in itself proves that a lot of our users are actively managing their ROAs, and that quite a few of the “invalids” out there are really supposed to be considered just that: “invalid”

Thanks
Tim





>  
> Thanks,
> Jakob.
>  
> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Carlos M. Martinez
> Sent: Thursday, July 20, 2017 8:41 AM
> To: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
> Cc: sidrops@ietf.org
> Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator
>  
> I was about to ask a question on the mic but was late to the line. Maybe it’s worth sharing it here:
> 
> 	• How we define a ROA to be “wrong” ? One that invalidates routes or one that causes legitimate traffic to be dropped ?
> Why? because we’ve seen in many cases ROAs that create lots of invalids but validate a less-specific route that covers those invalids
> 
> In a way, this even a positive side-effect, sort of vacuum-cleaning your routing tables.
> 
> I believe analyzing what ROAs are wrong is quite important, but i’d believe this particular case should not count as wrong.
> 
> thanks!
> 
> /Carlos
> 
> On 17 Jul 2017, at 16:36, Matthias Waehlisch wrote:
> 
> two comments via the list because we run out of time:
> 
> (1) I'm wondering about the statement that the quality of ROAs decreases
> over time. My impression is that the quality improved because of
> excellent training by RIRs and others.
> 
> Slide 4 shows absolute values, which is not helpful in this context.
> 
> 
> (2) Regarding ROV measurements: "Similar results apparently from
> measurements by Randy Bush and others (didn't yet see details)"
> 
> Details are available, easy to find using Google:
> 
> * "Towards a Rigorous Methodology for Measuring Adoption of RPKI Route
> Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of
> this work was also presented at the last RIPE meeting:
> https://ripe74.ripe.net/archives/video/46/
> 
> 
> 
> 
> Cheers
> matthias
> 
> -- 
> Matthias Waehlisch
> . Freie Universitaet Berlin, Computer Science
> .. http://www.cs.fu-berlin.de/~waehl
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops