Re: [sidr] Injecting idea of "freshness of repository data" into BGP

[Eric Osterweil <[e-mail]>]

On Mar 29, 2012, at 1:16 AM, Jeffrey Haas wrote:

> Jakob,
> 
> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>> Could we not put a freshness indication into the BGP update?
>> Then everyone that receives the new update would know to invalidate the less fresh paths.
> 
> Just to be clear, this is not a route freshness mechanism I am
> recommending.  What I am recommending is a signal that a repository has
> newer data that may be needed for validation.
> 
> Given such a mechanism, we may be able to reduce the work upon the
> repository mirroring system (distributed or not) by not having to regularly
> poll for new objects frequently unless the repository indicates there is new
> data present.


The RPKI and BGP have orthogonal data and distribution models though.  The RPKI is disseminating certs and ROAs that reflect the _policy_ of resource allocations and holders.  BGP is disseminating reachability and routing information.  While the former is being used to semantically inform the latter, they do not have a tight coupling.  In fact, the loose coupling between them is currently only oneway (cache to router if I'm not mistaken).  IIRC, once the RPKI data has been cached, it is an unsigned, unverifiable tuple that gets pushed to a router.  How can we start from there and get secure information flowing the other way, exactly?

The idea of adding freshness to the RPKI does not have anything to do with the reachability of BGP[SEC].  I think this is actually hitting on a new requirement that needs to be documented: the _resource certification system (RPKI)_ must provide a freshness model.  I would suggest that this stay as far from BGP as we can get it.  BGP is a great soft-state protocol (where some may define ``great'' differently), but I don't currently tweet or update my fb status over it.

Eric