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

> On 25 Jul 2017, at 19:55, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> 
> I could understand if there are providers that would rather accept
> the "maybe invalid" than drop them. Dropping prefixes breaks connectivity.

True, but they are really “invalid” in the validation sense. You can choose to ignore this, or the holder can authorise them so they will be valid - which would be the better solution.

I believe a lot of this comes down to a burden of proof kind of concept - if the connectivity breaks because the holder only partially authorised their announcements - then they are to ‘blame’ and they have the power to fix.

> If they can't tell the difference between "matched with wrong AS"
> and covered, then they'll just accept them all.

I believe it would be better then to make this difference available to operators, rather than artificially marking things as valid.

Accepting more specific announcements leaves one vulnerable though to more specific announcements done with a spoofed AS. Therefore, if the path cannot be trusted, e.g. by use of BGPSec, doing blanket acceptance policy to accept “invalid length” introduces a major vulnerability.

That said, if you as an operator have other ways of determining whether you can trust the path, e.g. because it’s a leaf customer of yours and its path length is 1, or because the path is short and you know and trust all the ASNs on it, then I think there is something to be said for a pragmatic policy of accepting more specifics here. It doesn’t give the full RPKI+Origin Validation+BGPSec certainty, but it’s probably a big step up from today without causing too many issues.

I am quite sure that talking about this will also generate quite some discussion between more purist and more pragmatic world views on security, but I think it’s probably a good discussion to have.

> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops