On 12-March-2019, Steve Meuse writes:
ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll happily share development notes with you, you can even look at pmacct's source code for inspiration. :-)
Thanks Job, I just wanted to reach back out to you and the NANOG community that we've implemented this feature. Currently Kentik can match flow data with the following validation state:
- VALID = Prefix fits in ROA, and ROA ASN and Prefix Origin Match - UNKNOWN = we haven't found any matching ROA - INVALID - ASN mismatch = BGP prefix fits in the ROA prefix's length BUT the ROA ASN differs from the Prefix Origin ASN - INVALID - Prefix length out of bounds = the BGP prefix doesn't have an ROA with large enough Max-Length to refer to - INVALID - ASN 0 specified = there is a matching ROA w/ the right max-length but the ASN associated w/ it is 0 (explicit invalid)
Hi Steve, Thanks for the update, but based on that description I'm not certain that you implemented the same thing that pmacct built, which IMO is what is needed by those considering deploying a drop-invalids policy. (Perhaps you omitted mentioning that ability in your description but included it in your implementation.) Citing from Job's description:
Pmacct implemented Origin Validation in a cute way: it separates out RPKI invalid BGP announcements into two categories:
a) "invalid with no overlapping or alternative route" (aka will be blackholed if 'invalid == reject')
b) "invalid but an overlapping unknown/valid announcement also exists" (end-to-end connectivity can still work).
Networks contemplating Origin Validation need to be able to predict how their traffic with the rest of the Internet would change after deploying a drop-invalid-routes policy. When we (as7018) were preparing to begin dropping invalid routes received from peers earlier this year, that is exactly the kind of analysis we did. In our case we rolled our own with a two-pass process: we first found all the traffic to/from invalid routes by a bgp community we gave them, then outside of our flow analysis tool we further filtered the traffic for invalid routes which were covered by less-specific not-invalid routes. What remained was the traffic we would lose once invalid routes were dropped. Had the pmacct capability existed at that time, we would have used it. Regarding the ability to further partition invalid traffic into the three sub-categories you mentioned: that would not have been of interest to us at the time we did our analysis, and it's not clear to me how it would be useful to a network as it contemplates adopting a drop-invalids policy. In this context, the reason a route is invalid is not important; what is important is whether it is covered by a non-invalid route or not. Thanks. Jay B.