RIS dumps, 0.0.0.0/0 routes and RPKI validator 3
Hello, I've got some really strange results when talking to rpki-validator 3's API and after some up and downgrading I concluded that it has to be in the RIS dumps (that was the only static data regardless of the validator version) and then I found the likely cause: AS15576 announcing 0.0.0.0/0 As of writing this email the first entry on this page: https://rpki-validator.ripe.net/bgp-preview but when we look at: https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS15576 it is not there. I assumed RIPEstat uses the same data source (RIS) just with some less delay. Are 0.0.0.0/0 routes filtered by RIPEstat but included in RIS dumps? Should rpki-validator filter them out? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Are 0.0.0.0/0 routes filtered by RIPEstat but included in RIS dumps? Should rpki-validator filter them out?
as the rirs each have a cert for 0/0, shouldn't the validator should be prepared to evaluate 0/0? randy
Randy Bush:
Are 0.0.0.0/0 routes filtered by RIPEstat but included in RIS dumps? Should rpki-validator filter them out?
as the rirs each have a cert for 0/0, shouldn't the validator should be prepared to evaluate 0/0?
just to clarify: I didn't mean to say that validtor 3 isn't prepared to evaluate 0/0. The strange results originated from my tools that did not expect 0/0 routes in validator's BGP preview - but I will fix my side. And to clarify "strange results": I'm regularly looking at how we are doing with RPKI misconfigurations (RPKI Observatory) and the last output suggested that we are down to 0 unreachable RPKI IP address space because _every_ INVALID announcement had an alternative path via 0/0 from AS15576 which is obviously not correct. kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Hi nusenu,
Op 17 mrt. 2019, om 09:23 heeft nusenu <nusenu-lists@riseup.net> het volgende geschreven:
Randy Bush:
Are 0.0.0.0/0 routes filtered by RIPEstat but included in RIS dumps? Should rpki-validator filter them out?
as the rirs each have a cert for 0/0, shouldn't the validator should be prepared to evaluate 0/0?
just to clarify: I didn't mean to say that validtor 3 isn't prepared to evaluate 0/0. The strange results originated from my tools that did not expect 0/0 routes in validator's BGP preview - but I will fix my side.
And to clarify "strange results": I'm regularly looking at how we are doing with RPKI misconfigurations (RPKI Observatory) and the last output suggested that we are down to 0 unreachable RPKI IP address space because _every_ INVALID announcement had an alternative path via 0/0 from AS15576 which is obviously not correct.
The data in the validator is consistent with the data in RIS: https://stat.ripe.net/widget/announced-prefixes#w.resource=15576 <https://stat.ripe.net/widget/announced-prefixes#w.resource=15576> You can see 0.0.0.0/0 (and ::/0 by the way) there. Out of curiosity, did you ping them about these mis-announcements already? Nathalie
Hi Nathalie, Nathalie Trenaman:
The data in the validator is consistent with the data in RIS: https://stat.ripe.net/widget/announced-prefixes#w.resource=15576 <https://stat.ripe.net/widget/announced-prefixes#w.resource=15576> You can see 0.0.0.0/0 (and ::/0 by the way) there.
then I'm wondering what the difference between the two RIPEstat widgets is since the other one does not include 0.0.0.0/0 as mentioned in the first email https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS15576 https://stat.ripe.net/docs/data_api#as-routing-consistency in_bgp "True" if the route has been seen by RIS, "False" otherwise - AS Routing Consistency "This data call shows the difference between routing and registration state of a ASN." - Announced Prefixes "This data call returns all announced prefixes for a given ASN. The results can be restricted to a specific time period."
Out of curiosity, did you ping them about these mis-announcements already? I did not.
thanks for your reply, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
Hi nusenu, Let me clarify, the AS Routing Consistency data call [0] is an API endpoint that was primarily developed to service the widget as it combines multiple data sources into a new functionality, the routing consistency. In order to fulfil this functionality RIPEstat applies a prefix filter to remove "unintended" routes so that the user can focus on consistency. The filter threshold is set so that routes that have not been seen by at least 10 full-table peers are removed. The Announced Prefixes data call is more raw and is used as input for various other applications and provides more control over the output. This data call has a parameter which controls the filter threshold, "min_peers_seeing", which currently defaults to 3, as described in the documentation [1]. I understand why this can cause confusion and as an result I will change the default threshold for the Announced Prefixes to 10 and update the documentation for the AS Routing Consistency to reflect the route filter. Plus the typo "..registration state of aN ASN..". Best regards, Christian PS: For a more in-depth explanation of the filter threshold please read [2]. [0] https://stat.ripe.net/docs/data_api#as-routing-consistency [1] https://stat.ripe.net/docs/data_api#announced-prefixes [2] https://labs.ripe.net/Members/wilhelm/content-how-define-address-space-route... On 18/03/2019 02:48, nusenu wrote:
Hi Nathalie,
Nathalie Trenaman:
The data in the validator is consistent with the data in RIS: https://stat.ripe.net/widget/announced-prefixes#w.resource=15576 <https://stat.ripe.net/widget/announced-prefixes#w.resource=15576> You can see 0.0.0.0/0 (and ::/0 by the way) there.
then I'm wondering what the difference between the two RIPEstat widgets is since the other one does not include 0.0.0.0/0 as mentioned in the first email https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS15576
https://stat.ripe.net/docs/data_api#as-routing-consistency in_bgp "True" if the route has been seen by RIS, "False" otherwise
- AS Routing Consistency "This data call shows the difference between routing and registration state of a ASN."
- Announced Prefixes "This data call returns all announced prefixes for a given ASN. The results can be restricted to a specific time period."
Out of curiosity, did you ping them about these mis-announcements already? I did not.
thanks for your reply, nusenu
-- Christian Teuschel | Human behind RIPEstat Follow me on Twitter: @NCC_RIPEstat
Christian Teuschel:
Let me clarify, the AS Routing Consistency data call [0] is an API endpoint that was primarily developed to service the widget as it combines multiple data sources into a new functionality, the routing consistency. In order to fulfil this functionality RIPEstat applies a prefix filter to remove "unintended" routes so that the user can focus on consistency. The filter threshold is set so that routes that have not been seen by at least 10 full-table peers are removed.
The Announced Prefixes data call is more raw and is used as input for various other applications and provides more control over the output. This data call has a parameter which controls the filter threshold, "min_peers_seeing", which currently defaults to 3, as described in the documentation [1].
I understand why this can cause confusion and as an result I will change the default threshold for the Announced Prefixes to 10 and update the documentation for the AS Routing Consistency to reflect the route filter. Plus the typo "..registration state of aN ASN..".
thanks for your comprehensive answer, maybe you want to add the information about these filters that apply but can not be changed to the AS Routing Consistency data call to the documentation since you already typed it. thank you, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu
On 3/16/19 11:57 PM, nusenu wrote: [...]
Are 0.0.0.0/0 routes filtered by RIPEstat but included in RIS dumps? Should rpki-validator filter them out?
In the bgp-preview? Probably. Although the route is in RIS, provided by some peers, 0.0.0.0/0 does more harm than good in tools like RIPEstat and the rpki-validator's preview. Alternatively, developers could raise the lower limit of number of RIS peers which must see a route before it is included in the preview. Currently, that limit is set to 5. The 0.0.0.0/0 routes typically have very low visibility. The latest dump at http://ris.ripe.net/dumps/riswhoisdump.IPv4.gz sees 0/0 announced by 24 different ASes. But where most of them are seen by just 1, 2 or 3 out of 222 full feed RIS peers, the announcement by AS15576 is seen by 5 peers and thus makes it to the preview. -- Rene
participants (5)
-
Christian Teuschel -
Nathalie Trenaman -
nusenu -
Randy Bush -
Rene Wilhelm