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

From: Eric Osterweil <[email-masked]>
Date: Sun, 1 Apr 2012 12:56:38 -0700

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 01 Apr 2012 22:57:05 +0200

Hi Eric,

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

While I agree with 99% of what you said today on the list (especially 
pointing out need for solid requirements to document what sidr is trying 
to achieve) I am not sure why you call BGP soft-state.

For me soft-state protocol is RSVP which requires refresh otherwise 
state invalidates. BGP does not require refresh.

If that would not be enough BGP is soon to become completely "hard 
state" if one would implement 
http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01

Best,
R.

---

From: Eric Osterweil <[email-masked]>
Date: Sun, 1 Apr 2012 14:12:42 -0700

On Apr 1, 2012, at 1:57 PM, Robert Raszuk wrote:

> While I agree with 99% of what you said today on the list (especially pointing out need for solid requirements to document what sidr is trying to achieve)

Great, thanks!  I don't want to lose that high order bit!  But, I don't want to ignore ya either.  I'll send an off-list response for the below. :)

Eric

> I am not sure why you call BGP soft-state.
> 
> For me soft-state protocol is RSVP which requires refresh otherwise state invalidates. BGP does not require refresh.
> 
> If that would not be enough BGP is soon to become completely "hard state" if one would implement http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01
> 
> Best,
> R.
>