Hi Dennis, The issue is not only with new BGP updates you receive during the cache update, the issue is also how to treat already received updates. The safest is to operate with the RPKI state known prior the start of a cache update. Once the cache is updated, re-evaluate all BGP updates you know already using the new RPKI information.
Oliver -----Original Message----- From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Ruediger Volk Sent: Wednesday, September 27, 2017 5:54 AM To: Denis Fondras <i...@ledeuns.net> Cc: r...@limes.nic.dtag.de; sidr@ietf.org Subject: Re: [sidr] RPKI-RTR implementation clues Hi Denis, > Hi, > > I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am > wondering about how others have implemented it. great to hear about implementation efforts for another (nice) BGP implementation. > - How is the process started ? > Currently, when I start bgpd, it will fetch a list of VRP from the cache > and at the same time get prefixes from its peers. As soon as it gets > a VRP, it will > try to validate prefixes in the RIB. The goal is to get a state as sooner as > possible to apply filters if needed. > The problem is I can have an unknown state in the case a prefix tries to get > validated while the VRP list is not complete. The solution is to make anoth er > round of validation when I get a complete VRP list. > Do you wait until you get a complete VRP list (ENDOFDATA message) before > starting the validation process ? it is a bad idea to do origin validation based on incomplete cache state. For example consider that a more specific (e.g. beef:dead::/32) will be classified INVALID if there is a matching ROA but only a covering but NOT matching aggregate ROA (e.g. beef::/16-16) is available before the more specific VRP. > - How are subsequent validation handled ? > Do you start the validation process as soon as you get a new VRP or do you wait > for a refresh timer ? In the former, a prefix could stay in the wrong state for > some time. I am assuming that every new prefix is validated as it arrives. Lazy origin validation classification is allowed (but it implies that besides unknown/valid/invalid you should support a 4th class of "unclassified" is needed). It's great if recceived announcements are immediately classified - but that can only be done correctly against a complete cache state. > Thank you in advance, > Denis > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr Ruediger Volk _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
