Hi,
On Dec 8, 2011, at 11:58 PM, Arturo Servin wrote:
> I imagine then that it just warns that the roa does not match the routing
> table and it is up to roa-creator to figure out what the error is (the roa or
> the route).
Speaking for the implementation in the RIPE NCC hosted pilot service (managed
CA hosted by us, UI in member portal), and validator....
On the portal page where members can manage their ROAs we also check the
announcements that we see(*) for their certified address space, against their
ROAs. Yes, this is a warning only. It is up to the member to make the judgement
what is right and configure things accordingly. Note that our members can not,
at this time, certify their own clients for part of their address space. So if
a client of a member uses a prefix then it's up the member to ensure that the
ROAs for this prefix are set up correctly.
Members can also subscribe to 'roa-alerts'. If they do they get a daily email
about unknown and invalid announcements that we see for them. This is not
real-time alerting of course. We're actually also thinking about that, but it
would require a very different technical solution and we're focusing on other
stuff first... at this stage I think this is mainly useful for members to make
sure that their ROAs actually keep matching their announcements. Although if
some rogue announcement is happening continuously it will show up. We have also
received some feedback where someone mentioned: "oh... I forgot that we were
doing that announcement there.. I'd better fix it..". I am not sure if that was
based on the UI or the mailing though..
All this was added fairly recently so we actually have quite a lot of ROAs that
were created before this functionality was there. We are planning to do a
one-time mailing soon where we alert members to announcements invalidated by
their ROAs. I am not keen on spamming people, but with thousands of
announcements being invalidated, presumably largely because the ROAs are wrong
-- not the announcements... I don't see operators trusting this. So, data
quality and fixing this is important.
We also compare validated ROAs to the announcements we see in the new version
of our validator. And yes, it's showing a *lot* of invalids. This is the RP
side of course, so changing those ROAs is not really an option ;) We do provide
knobs in the validator though to ignore ROAs for certain prefixes and add your
own ASN, prefix, maxLength entries as though ROAs existed for them, but
managing this doesn't scale to thousands...
An official release announcement is scheduled for Tuesday, but it's already
available for download, and your feedback is appreciated:
https://certification.ripe.net/content/public-repo/releases/net/ripe/rpki-validator/rpki-validator-app/2.0.0/rpki-validator-app-2.0.0-bin.zip
Regards,
Tim
*: We use the 8-hourly aggregate of routes seen by RIS Route Collectors.
Published here: http://www.ris.ripe.net/dumps/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
