Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-evaluate the RPKI state when new routing advertisements come in #618

Open
racompton opened this issue Nov 29, 2021 · 2 comments
Open
Assignees

Comments

@racompton
Copy link

Have Artemis re-evaluate the RPKI state when new routing advertisements come in and potentially clear the RPKI INVALID status in the alerts. Similar to how Artemis can change the status of an alert from Ongoing to Withdrawn.

One example of this is where we had the prefix 76.178.98.0/23 advertised but Artemis had the config to monitor for 76.178.64.0/18. This generated an alert and was RPKI invalid. A ROA was then created and 76.178.98.0/23 was added to the Artemis config. It would have been nice if the alert would have cleared and shown RPKI valid
image

@vkotronis vkotronis self-assigned this Dec 6, 2021
@vkotronis
Copy link
Member

Will work on it this week, we should probably remove the redis caching logic

redis_rpki_asn_prefix_key = "rpki_as{}_p{}".format(
so that it always gets the most recent info from the validator itself.

@vkotronis
Copy link
Member

vkotronis commented Dec 6, 2021

hmmm currently we clear the cache every one hour. We cannot state events as innocent based on RPKI only, we clear them when the configuration which is the SoT does not consider them hijacks any more. We can remove the caching logic for RPKI statuses, but this will probably have a performance impact on detection. Will need to think on this before implementing sth related.
@racompton in the event you mention, after the RPKI cache is expired (1 hour by default) you will see a VD state. Have you checked that this holds? If the configuration is also correctly updated the alert will become deprecated. Note that we do not act on RPKI information to declare sth as hijack or non-hijack, we simply augment the available hijack info. Thus, the configuration should also be updated after you get the ROA in place. I can elaborate more on this if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants