Subject: [sidr] RPKI-RTR implementation clues

From: Denis Fondras <[email-masked]>
Date: Wed, 27 Sep 2017 11:18:05 +0200

Hi,

I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am
wondering about how others have implemented it.

- 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 another
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 ?

- 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.

Thank you in advance,
Denis

---

From: Denis Fondras <[email-masked]>
Date: Wed, 27 Sep 2017 11:23:55 +0200

> for a refresh timer ? In the former, a prefix could stay in the wrong state for
                               ^^^ latter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Sep 2017 11:40:28 +0200

On Wed, Sep 27, 2017 at 11:18:05AM +0200,
 Denis Fondras <[email-masked]> wrote 
 a message of 28 lines which said:

> I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd

This is not directly related to your question, but note that the new
RFC, standardizing the new version of RTR (version 1, RFC 6810 was
version 0) is in AUTH48-DONE and can be published any time now
<https://www.rfc-editor.org/auth48/C306>

---

From: Ruediger Volk <[email-masked]>
Date: Wed, 27 Sep 2017 11:54:16 +0200

Hi Denis,
  > wondering about how others have implemented it.
great to hear about implementation efforts for another (nice)
BGP implementation.

  > 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
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.

  > 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
  > [email-masked]
  > https://www.ietf.org/mailman/listinfo/sidr

Ruediger Volk

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 27 Sep 2017 16:09:12 +0000

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:[email-masked]] On Behalf Of Ruediger Volk
Sent: Wednesday, September 27, 2017 5:54 AM
To: Denis Fondras <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [sidr] RPKI-RTR implementation clues

Hi Denis,
  > wondering about how others have implemented it.
great to hear about implementation efforts for another (nice) BGP implementation.

  > validated while the VRP list is not complete. The solution is to make anoth er
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.

  > 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.

Ruediger Volk

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Sep 2017 14:11:34 -0700

> <https://www.rfc-editor.org/auth48/C306>

you may also find draft-ymbk-sidrops-ov-clarify-01.txt useful

randy

---

From: Denis Fondras <[email-masked]>
Date: Thu, 28 Sep 2017 10:50:59 +0200

Thank you very much for the insight !

Denis