Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022

[Tim Bruijnzeels <[e-mail]>]

Hi,

I agree with the general sentiment that one VRP per ROA should be used.

But I think this text is not correct:

>    The potential influence of operations of ROAs containing multiple IP
>    prefixes on BGP routers must be considered.  For the ROA containing
>    multiple prefixes, once increase or delete one <AS, ip_prefix> pair
>    in it, this whole ROA must be withdrawn and reissued.  Through
>    sychronization with repository, Relying Party (RP) fetches a new ROA
>    object and then notify and send all the <AS, ip_prefix> pairs in this
>    ROA to BGP routers.  That is to say, the update of the ROA containing
>    multiple IP address prefixes will lead to redundant transmission
>    between RP and BGP routers.  So frequent update of these ROAs will
>    increase the convergency time of BGP routers and reduce their
>    performance obviously.

This is an issue if, per Randy's example, the entire ROA is withdrawn first,
the RPs fetches and revalidates and sends withdraws for VRPs to the router,
and then the new ROA is published later, validated, etc

Taking the RIPE NCC system, and krill, as examples operators don't get to
do this. They get to specify which *VRPs* they want and the system then
takes care of republishing.. It will publish a new ROA in the same delta
where the previous ROA is either withdrawn or replaced by name. The added
language on failed fetches in the manifest bis further ensures that RPs
will see the complete delta.

RPs will work out what the diff in *VRPs* is. And it's this diff that is
sent to routers. So replacing a ROA with 319 prefixes with one that has
those 319 + 1 new prefix results in a 1 VRP diff.

Similarly if an RP encounter multiple ROAs with the same VRP, then it
will exclude duplicates when talking to the routers.

Another example here.. key rolls.. When a key roll happens all ROAs are
re-issued under a new key. But the VRP set is unchanged.

Re-issuance of a ROA object before it would expire, essentially replacing
it with a new object of the same semantic content: no VRP change.

That said, the following *is* an issue, and in my opinion reason enough:

>    In addition, the validity period of ROA is a long time in default,
>    the prefix ownership change is more possible during this period, this
>    will cause the withdraw or re-issurance of the whole set of prefixes
>    containing within the same ROA

Indeed, resource shrink is troublesome.

(I don't think validity period matters here, as the shrink can happen
at any time)

If VRPS are combined then this could result in the following scenario:
a ROA for 319 is suddenly invalid because of 1 overclaiming VRP - leading
to a drop in 319 VRPs and router churn. Later the child discovers the
shrink and issues a ROA for the remaining 318 VRPs. Resulting in router
churn again.

This is also why krill prefers one VRP per ROA.

So, with single VRP ROAs, a shrink by the parent may cause a child to
temporarily have one, or a couple of single VRP ROAs which are overclaiming,
and then clean them up as soon as it finds out.

Still - this is not the same for the RIPE NCC system. Their hosted system
contains both the parent *and* the child. Context matters. In their case
the child can re-issue ROAs before the parent changes the CA certificate
issued to them - preventing overclaims. They also publish in the same
repository so both changes would be seen together.

Regarding:
>    The extreme case (a single ROA can only contain one IP address
>    prefix) may lead to too many ROA objects globally, which may in turn
>    become a burden for RPs to synchronize and validate all these ROA
>    objects with the fully deployment of RPKI.  So it seems that a
>    tradeoff between the number of ROAs and the number of IP prefixes in
>    a single ROA should be considered.  However, considering the
>    stability and security of RPKI and BGP routing system is the most
>    important target, containing one IP address prefix in a single ROA is
>    recommended if the CA wants to avoids the potential instability and
>    risks.

An example to consider where multi-VRP ROAs may be applicable are the AS0
ROAs for unallocated space that some RIRs publish. There is almost no
risk wrt overclaim - while publishing separate objects would result in
excessive numbers.

Currently krill has a strategy for this trade-off. By default it will
start aggregating when a CA has more than 100 VRPs defined. And it will
start de-aggregating (i.e. start using one ROA per VRP again) when this
number drops below 90. The defaults can be changed in future releases
based on feedback and research.. users can also override them.

If we are to stop using multi-VRP ROAs altogether then this could also
be done, but in my opinion there are contexts where they are not an issue
but a useful optimisation.

To conclude:
- I think the text on router churn needs to be changed.
- I interpret the trade-off discussion to mean that implementers
  can make a decision that in their context multi-VRP ROAs are not
  an issue.
- I am happy to change the default strategy in krill if RP implementers
  are fine with potentially more objects.



Tim





> On 24 Feb 2022, at 23:47, Keyur Patel <[e-mail]> wrote:
> 
> Hi Folks:
>  
> A working group last call has been issued for draft-ietf-sidrops-roa- considerations-01, “Problem Statement and Considerations for ROA containing Multiple Prefixes”. Please reply to the list with your comments. The WGLC will end on March 10th, 2022.
>  
> The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/.
>  
> Regards,
> Nathalie, Chris & Keyur
>  
>  
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops