Re: [ncc-services-wg] RPKI Resource Certification: building features

[mkarir <mkarir () merit edu>]

Hi Alex,

We are trying to tackle a similar problem with the RADB.  The approach  
we have
taken is to build into the object management web portal an alerting  
system that
provides alerts to a user when there is a mismatch between what is in  
the IRR
and what is observed in BGP.  Right next to the alert will be a button  
that
they can click on to "fix" their own IRR information or to flag an  
object
as "conflict - needs review" to allow Merit to manually review and  
resolve
conflicting IRR information.  If it indeed is a hijack then they can  
take other
steps.

A second piece of this is a historical origin database we have built  
where we
attempt to learn from history what a valid origin might be for a given  
prefix.
Lots of complications here with moas and newly announced prefixes but  
some
heuristics can help here.  Once again this db becomes a source of  
validation
information like the IRR database.  Not for use in rejecting/accepting
routes but for generating alerts that allow a user to fix/monitor their
routing assets.

So in both these cases we take what is reported in BGP and compare it  
with
sources of possible validation and generates alerts for users on  
mismatches.

The final piece of the puzzle which is a link with roa is something that
we are still working on integrating into the RADB.  The piece that is
currently in place add roa-uri tag to irrd which allows a user to
specify in the IRR a URI pointer to a roa for that prefix.  Currently
we dont use it in any validation.  However we have a modified
rpki-whois that at the end of the whois query will perform roa  
validation
and tell the user whether the roa was valid or in in addition to the
usual whois reponse.

-manish


On Oct 4, 2010, at 6:00 AM, routing-wg-request () ripe net wrote:

> Message: 1
> From: Alex Band <alexb () ripe net>
> Date: Sun, 3 Oct 2010 19:08:33 +0200
> To: ncc-services-wg () ripe net,
> routing-wg () ripe net
> Subject: [routing-wg] RPKI Resource Certification: building features
>
> Most of the discussions around RPKI Resource Certification that have =
> been held up to now have largely revolved around infrastructure and =
> policy topics. I would like to move away from that here and discuss  
> what =
> kind of value and which features can be offered with Certification  
> for =
> network administrators around the world. Because in the end, the  
> goal is =
> to make Internet routing more robust and create a more reliable  
> method =
> for network operators to make routing decisions.
>
> We all know about the shortcomings of the IRR system and that just  
> half =
> of all prefixes on the Internet have a route object associated with  
> them =
> (http://bgpmon.net/blog/?p=3D140). However, it does mean that there  
> is =
> ton of valuable information in the IRRs, whereas the Certification =
> system needs to start from scratch. Based on many discussion I've  
> had =
> with members and the Community, here is my idea for a Route Origin =
> Authorisation** (ROA) wizard that retrieves IRR information,  
> compares it =
> to real world routing and uses that for the creation of ROA =
> Specifications. This has a number of benefits:
>
> - Network operators don't have to create their routing policy in the =
> Certification system from scratch
> - Because a comparison between is done the IRR and RIS =
> (http://ripe.net/ris/), only accurate up-to-date information is  
> added to =
> the Certification system
> - The accuracy of the IRR is increased as a bonus, and is achieved =
> without leaving the wizard
>
> Ideally, a network operator should be able to manage and publish  
> their =
> routing policy =96 both for the IRR and Certification =96 from one =
> single interface.=20
>
> Here are the basic steps for the wizard after a certificate is =
> generated:
>
> 1. Start ROA Wizard
>
> 2. Detect IRR information using the AS numbers in the Certificate,  
> like =
> for example:
> =
> http://www.db.ripe.net/whois?searchtext=3DAS286&inverse_attributes=3Dorigi=
> n&form_type=3Dsimple
>
> 3: Compare results with RIS using RRCC/Netsense, like for example:
> http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=3DAS286
>
> 4: Allow user to flag which ROA specifications they would actually  
> like =
> to create, based on the IRR and RRCC/Netsense results.
>
> 5: Allow user to create additional ROA Specifications
>
> 6: Detect which maintainer is used for the route objects in the IRR
>
> 7: Allow user to specify maintainer password/pgp key, so all route =
> objects are updated/removed/added based on the ROAs that were  
> created. =
> This makes sure the data in the IRR and the Certification system is =
> consistent.=20
>
> 8: Save and publish ROAs and route objects
>
> Do you think there is value in creating a system like this? Are  
> there =
> any glaring holes that I missed, or something that could be added?  
> I'm =
> looking forward to your feedback.
>
> Alex Band
> RIPE NCC
> http://ripe.net/certification
>
>
> ** The certification system largely revolves around three main  
> elements: =
> (1) the Certificate, that offers validated proof of holdership of an =
> Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a =
> standardised document that states that the holder of a certain  
> prefix =
> authorises a particular AS to announce that prefix and (3) the =
> Validator, which relying parties, i.e. your peers, can use to  
> validate =
> certificates and ROAs.=