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

I could understand if there are providers that would rather accept
the "maybe invalid" than drop them. Dropping prefixes breaks connectivity.
If they can't tell the difference between "matched with wrong AS"
and covered, then they'll just accept them all.

Thanks,
Jakob.

> -----Original Message-----
> From: Tim Bruijnzeels [mailto:tim@ripe.net]
> Sent: Tuesday, July 25, 2017 6:49 AM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: Carlos M. Martinez <carlosm3011@gmail.com>; Matthias Waehlisch <m.waehlisch@fu-berlin.de>; sidrops@ietf.org
> Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator
> 
> 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