Re: [sidr] RPKI-RTR implementation clues

Ruediger Volk <rv@NIC.DTAG.DE> Wed, 27 September 2017 09:54 UTC

Return-Path: <rv@NIC.DTAG.DE>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03EDB134940 for <>; Wed, 27 Sep 2017 02:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5akOIPjdtBUT for <>; Wed, 27 Sep 2017 02:54:30 -0700 (PDT)
Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE []) by (Postfix) with ESMTP id 5DBAB13493E for <>; Wed, 27 Sep 2017 02:54:30 -0700 (PDT)
Received: from x59.NIC.DTAG.DE (x59.NIC.DTAG.DE []) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id LAA20926; Wed, 27 Sep 2017 11:54:16 +0200 (MEST)
To: Denis Fondras <>
cc:, rv@limes.NIC.DTAG.DE
From: Ruediger Volk <rv@NIC.DTAG.DE>
In-Reply-To: Your message of "Wed, 27 Sep 2017 11:18:05 +0200." <>
Date: Wed, 27 Sep 2017 11:54:16 +0200
Message-ID: <2061.1506506056@x59.NIC.DTAG.DE>
Archived-At: <>
Subject: Re: [sidr] RPKI-RTR implementation clues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Sep 2017 09:54:33 -0000

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
  > 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 
  > for a refresh timer ? In the former, a prefix could stay in the wrong state
  > 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

Ruediger Volk