To address the risk of somebody exhausting your memory by dumping a ton of routes on you,
we added two new options to "soft-reconfiguration inbound" in IOS-XR.
RPKI-dropped-only
Saves a copy of only the routes dropped by an RPKI validation-state test in neighbor-in route-policy.
RPKI-tested-only
Saves a copy of only the routes tested in an RPKI validation-state test in neighbor-in route-policy.
This was released in 7.3.1 in Feb 2021.
The bug CSCwb17937 was fixed in 7.5.2, just released. Fixed a few other things in 7.5.2 also.
Tomoya, apologies that you had a terrible time with it.
Regards,
Jakob.
What does this mean? If any term refers to validation-state, the route
gets stored?
Eg.
if validation-state is valid then
pass
else
drop
a) Would 'RPKI-dropped-only' store everything or nothing?
b) Would 'RPKI-tested-only' store everything?
'RPKI-tested-only' will store all routes that encounter a 'validation-state' test
in the inbound route policy. In that case, when an RPKI server updates a VRP to the
router, it can re-run the inbound policy from the stored route and not require a
refresh request to be sent.
This option saves memory if you use a coarse filter in the route-policy before
the validation test. For example, you use a peer-locking filter to drop peer
routes from your customers before they hit the validation-state test. Then
a massive route leak won't chew up soft-reconfiguration memory.
If a validation-state test drops a route and that route is not stored by
soft-reconfiguration, then when the RPKI server updates any VRP, the router
needs to send a route-refresh request.
'RPKI-dropped-only' causes the dropped routes to be stored. This will prevent
the unnecessary route-refreshes described above. It does not prevent all
route-refreshes, but uses significantly less memory than 'RPKI-tested-only'
Regards,
Jakob.
Jakob, thank you and your team for quickly implementing this. It is most appreciated.
I hope someone from the IOS XE team is working on it, too :-).
Mark.
Hey Jakob,
'RPKI-tested-only' will store all routes that encounter a 'validation-state' test
in the inbound route policy. In that case, when an RPKI server updates a VRP to the
router, it can re-run the inbound policy from the stored route and not require a
refresh request to be sent.
'RPKI-dropped-only' causes the dropped routes to be stored. This will prevent
the unnecessary route-refreshes described above. It does not prevent all
route-refreshes, but uses significantly less memory than 'RPKI-tested-only'
I'm sorry, but I am unable to reason what these answers mean in
context of question that was:
In the end, the reason for all this RPKI-thingy is to prevent route spoofing by malicious actors. It sure would be nice if someone from the top 20: https://asrank.caida.org/ would be able to have an auto-updated site that showed all RPKI dropped from their end.
This would complement https://bgpstream.crosswork.cisco.com/ for those of us who want to know who is trying to hijack our routes at the core.
Regards,
Hank
a malicious actor will spoof the origin AS. The aim of RPKI to help stop mis-origination of prefixes, and the root cause of most of this is accidental.
Nick
In the end, the reason for all this RPKI-thingy is to prevent route
spoofing by malicious actors.
sigh. for my quarterly posting of the same many year old text
To be clear, as people keep calling BGP security 'RPKI',
RPKI
The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent
with the internet IP address allocation administration, the IANA,
RIRs, ISPs, ... It is just a database, but is the substrate on
which the next two mechanisms are based. It is currently deployed
in all five administrative regions.
RPKI-based Origin Validation (ROV)
RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data
to allow a router to verify that the autonomous system originating
an IP address prefix is in fact authorized to do so. This is not
crypto checked so can be violated. But it should prevent the vast
majority of accidental 'hijackings' on the internet today, e.g. the
famous Pakistani accidental announcement of YouTube's address space.
RPKI-based origin validation is in shipping code from AlcaLu, Cisco,
Juniper, and possibly others.
BGPsec
RPKI-based Path Validation, AKA BGPsec, a future technology still
being designed [draft-ietf-sidr-bgpsec-overview], uses the full
crypto information of the RPKI to make up for the embarrassing
mistake that, like much of the internet BGP was designed with no
thought to securing the BGP protocol itself from being
gamed/violated. It allows a receiver of a BGP announcement to
cryptographically validate that the autonomous systems through which
the announcement passed were indeed those which the sender/forwarder
at each hop intended.
Sorry to drone on, but these three really need to be differentiated.
Saku,
You have two questions. I'll address the second one first.
Beginning in IOS-XR 7.3.1, there is a new O(log n) scalable way to test for autonomous system numbers (ASN) in route-policy. ASNs can be grouped into an as-set as follows:
as-set foo
64496,
64497
end-set
!
route-policy bar
if not as-path originates-from foo then
drop
endif
pass
end-policy
The first question:
If you use several tests in your route-policy and put the validation-state
test last, then any route that gets dropped before the validation-state
test is reached will not be saved with
"soft-reconfiguration inbound RPKI-tested-only".
For example:
route-policy bar
if not as-path originates-from foo then
drop
endif
if validation-state is invalid then
drop
endif
pass
end-policy
Regards,
Jakob.
15.05.22 00:19, Nick Hilliard пише:
a malicious actor will spoof the origin AS. The aim of RPKI to help stop mis-origination of prefixes, and the root cause of most of this is accidental.
To make a working hijack of the routed prefix (for sniffing traffic, DDoS or something similar), you have to announce a more specific prefix(es). It can be denied by RPKI.
If you signed RPKI prefix is still unannounced - yes, somebody can hijack it by forging the origin ASN - that's quite easy.
This axiomatically assumes first come, first serve, which is obviously
not complete understanding of BGP best path algorithm.