[ca-tf] Topic 4 at CA-TF meeting in Amsterdam - Thursday 20 March 2008

[Daniel Karrenberg <daniel.karrenberg@localhost]

Here is v1.0 of the white paper for topic 4. Thanks to Ruediger for the idea 
and for insightful comments. We tried to be concise (just 88 lines). Details
are for later, this is about the general idea.

See you all an Thursday.

Daniel


Publishing ROAs as RPSL Route Objects

Ruediger Volk
Daniel Karrenberg

version: 1.0

Tue Mar 18 09:49:33 CET 2008


Abstract

This white paper describes how ROAs, one of the signed data objects in
resource certification, could be published in a form that is immediately
usable by current BGP configuration tools.  We will list some pro-s and
con-s, and point out some open questions. 


Problem Statement

A number of ISPs use data encoded in RPSL [1] as input to generate their
BGP routing policies.  These ISPs typically use data from multiple
sources and assign each source a different level of trust and relevance
for processing.  It is unlikely that ISPs already using such tools will
abandon them immediately in favor of new tools based on number resource
certificates and ROAs.  This will aggravate the typical "chicken and
egg" dilemma in this area: there is no incentive to obtain certificates
and generate ROAs if they are little used; there is little incentive to
use this information if coverage is very low. 


The Proposal

On the other hand it is quite likely that certificate based data will
quickly be used, if it is made available in RPSL encoded form.  Since
ISPs are already used to using RPSL information from various sources,
this will just represent another source to use with existing tools. 
Uptake is likely because this data will be of an inherently high
quality.  Uptake is also likely because it can be gradual because
the information generated from ROAs can be assigned increasing levels of
trust and relevance as uptake and experience with it increases. 


Cons

As any transition tool this may slow down adoption of native tools.  The
inherent authentication and verification properties of CERTs and ROAs
will not be there.  Users will have to trust the publisher of the RPSL
version, but that is not different from today's RPSL environment where
users do trust the maintainers of routing registries. 
However making the software package for verifying and mapping the ROAs
available to ISPs would enable them to avoid even this "leap of faith".


Implementation

The RIPE NCC will periodically convert all ROAs in its repository to
equivalent RPSL route objects and publish them in the RIPE routing registry
with a unique source attribute value. The RIPE NCC should also do this with ROAs
from other repositories.

Details to be worked out

- detail of transcoding from ROA to route object
	- how to encode eactMatch=FALSE, multiple route objects, route-set
          (note that the ROA format is again under discussion on this point)

- details of the data model for the database server 

- presentation options for response to clients

- what verification to do on the ROAs and CERTs

- how to deal with validity times

- frequency of updates

- best practises for using the information 
  (largely a reflection of ROA best practises that are not written up yet either)

- values of the source attributes


References

[1] RFC2622 RFC4012