[Sidrops] Re: Fwd: [GROW] I-D Action: draft-ietf-grow-yang-bgp-communities-08.txt

[Job Snijders <[e-mail]>]

On Fri, Apr 17, 2026 at 12:10:49PM +0200, Martin Hoffmann wrote:
> Martin Pels wrote:
> > For the below draft Job is proposing a mechanism for discovery of BGP 
> > community definition locations through the RPKI. Feedback from this 
> > group is very welcome.
> 
> I am starting to get a bit worried about the amount of new objects that
> people want to stick into the RPKI. We already have a large number of
> objects with a terrible signal-to-noise ration (payload of a couple of
> bytes wrapped in hundreds of bytes of certificate). Adding new types
> for all sorts of things isn’t going to improve this situation.
> 
> For this particular proposal, currently all objects in the RPKI result
> in data that is being sent directly to the routers. If I understand
> the draft correctly, this data isn’t really relevant for routers but
> more for the provisioning system to create policies.

You meant to say 'before this proposal'? If so, I'm not sure that would
be a correct characterization of the current situation: Manifests,
CRLs, CA certificates, Trust Anchor Keys, and GhostBuster records (now
deprecated) are all not send to routers via RTR. To me it seems fine to
have signed information in repositories that doesn't need to exist in
routers.

> My sense is that we should limit data stored directly in the RPKI to
> data where a complete view is relevant for all routers.

I disagree the scope of published objects should be limited in this way.

> E.g., in order to do route origin validation, you do need the full set
> of data derived from all ROAs in a table in your router, so the ROAs
> should be in the RPKI directly.
> 
> For data where only a subset of the all the data is needed by a given
> network or where data is only queried occasionally on request, perhaps
> we can find a better place to store it and link it to the RPKI via some
> mechanism.
> 
> For instance, we could provide a new Subject Information Access type
> for CA certificates which provides a URL to the location of a document
> containing all such information which is then signed by the RPKI CA.

I did consider this option, but then you'd be left with a 'dangling'
SPKI: the EE cert containing the SIA would also contain a purpose-less
public key. Having a separate purpose-specific signed object type to me
seems a cleaner approach.

And, with either approach you'd need an 'instance of a thing', size-wise
there isn't much difference between a bare EE cert and a CMS signed
object.

> This specific scheme may not be good enough, but I think the basic idea
> -- keep information elsewhere but make it discoverable and verifiable
> --, would help with keeping the global RPKI repository manageable in
> the long run while providing an extensible means to provide information
> in a changing world.
> 
>   -- Martin
> 
> 
> PS: Apologies for hijacking your draft in this way. I’ve been pondering
>     this dilemma for quite some time and this just seemed too good an
>     opportunity to bring it up.

Fair enough.

I'd like to note that a nice property of the Erik synchronisation
protocol is that the RP knows the type of object ahead of fetching time
(through the filename extensions visible in the Manifest) and can simply
skip over objects it is not interested in (such as CDR, or TAK, or GBR,
or whatever).

Kind regards,

Job