[Sidrops] Re: ASPA Provider List size limit (draft-ietf-sidrops-8210bis-16.txt)

[Claudio Jeker <[e-mail]>]

On Tue, Dec 03, 2024 at 10:48:15AM +0100, Tim Bruijnzeels wrote:
> Hi,
> 
> > On 2 Dec 2024, at 22:44, Borchert, Oliver (Fed) <[e-mail]> wrote:
> > 
> > I do not believe we should restrict the number of providers in 8210-bis. The proper location is the ASPA profile draft. It is easier to in the future update the ASPA profile than modifying 8210bis. A modification of whatever RFC the current RFC 8210-bis becomes will require a new protocol version.
> >  The proper way going forward is to modify section 6 of the ASPA Profile draft to require that an upper boundary MUST not exceeded 10,000 provider ASes. (Or 4,000 if this is more reasonable). This can easily be updated later to a higher number.
> >  As of now it is already possible to generate PDU’s that allow to exceed many GB.
> >  As example:
> > * The Router Key PDU (8) allows to have a key that is multiple GB of size.
> > * The Error Report PDU (10) can become multiple GB of size.
> 
> I am not opposed to limiting the size of ASPA objects by including an upper boundary in the ASPA profile.
> 
> >  Hence the ASPA PDU (11) is not really a special case.
> 
> I think the ASPA PDU also needs an upper boundary.
> 
> There is no way to prevent that multiple ASPA objects are created for
> the same customer ASN, possibly under different CAs, even if we say
> “don’t do it". Additionally, SLURM…
> 
> So, while it would be good to ‘fail early and clearly’ and limit the
> ASPA object itself, I think we need an additional limit and check in
> 8210-bis.

The rtr protocol took many shortcuts to be simple with the result that
properly implementing it is hard. I fully agree that this protocol needs a
PDU size limit not only for ASPA PDU but also for all other not fixed
sized PDUs. It also requires proper error handling.

All of this was already discussed on this list and it will come up again
and again since progress on 8210bis stalled long time ago.
-- 
:wq Claudio