[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[safnog] RPKI discussions
On 13/Apr/15 08:56, Ben Maddison wrote:
> At Workonline, we're still at the point of evaluating validation server code (and I'd be keen to hear any experience on that), although we have all our ROAs registered (and hopefully correct).
We are using the RPKI Toolset at http://rpki.net/. We run this on FreeBSD.
It supports both RP and CA tools. As AFRINIC do not currently support CA
delegation, we are just using the RP tools.
> We run a fair few XE boxes too, so would love that Bug ID if you have it Mark?
Bug ID is CSCus34757.
Fixed in 15.5(1.18)S0.12, 15.5(2)S, 15.5(2.13)S, 15.5(2.6)T and 16.1(0.174).
It's a nasty bug.
We are running 15.3(3)S4 / 3.10(4)S, which is the long-term maintenance
release for the ASR1000 at this time. So quite a long way away from
re-enabling RPKI on our ASR1000's for production, but will do in a
controlled environment for now.
If you are interested in seeing our view of the global RPKI state, our
looking glasses do support RPKI, including some RPKI BGP commands:
http://lg.seacomnet.com/
You can also log into the looking glasses via Telnet.
> Our short term plan is to de-PREF invalids and to mark prefixes with a validation status community for export. The community gives our customers the option of filtering without needing to re-validate. The lower LOCAL_PREF is of pretty limited value as you've both pointed out, but does give a highjacked remote network a means of fighting back reactively (even if that requires them to temporarily loose a bunch of more specifics).
It is an interesting idea, and would like to hear how you fare with your
customers as you run your tests.
> All of this of course protects only from the very least sophisticated attacks/accidents, but it is a start. Anything that doesn't provide for path validation is less than half a solution anyway.
You're right, it's a start.
Path validation, while key to completing the chain, has various
implementation hurdles that need to be fixed in the spec., let alone
code and hardware.
Mark.