Increase maximum PDU length that is decoded

[ties]

Limit the maximum PDU length that is decoded to a size that is both safe for the software as well as unrealistic in the DFZ. This path is only hit when using rtrdump, rtrmon, or when using starter as a library.

It is very feasible to create a ASPA PDU > 2k.

@cjeker this is more relevant in real BGP speakers.

[cjeker]

I think your new limit is far to big. In no sensible world one AS would have every other AS of the DFZ as a provider.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size. I will bump OpenBGPD's max PDU size to 64k which should be enough for 10'000 SPAS in one PDU.

I dislike that the ASPA profile did not limit the number of SPAS. This idea that computers run with infinite resources is very dumb especially for a security critical application. We should prevent random operators to generate ASPA PDUs that will inflict high resource usage on every boarder router.

[ties]

I agree that the limit is big, but given the protocol, I do not think there is any sane value that would prevent the denial-of-service-by-disconnect gap.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size.

64kb definitely is an improved value.

But unfortunately that limit is per ASPA, which allows multiple objects to be combined for a larger number of SPAS for an AS. This would require active "experiments"/attacks in the public RPKI, but that is the status quo.

1MB is manageable for systems and a large enough number to definitely cover what is realistic in the DFZ.

I think this may need RPs to limit the total number of SPAS for an AS (over all ASPAs), or alternatively, a protocol change.

On Sat, Apr 6, 2024, 09:08 Claudio Jeker @.***> wrote:

I think your new limit is far to big. In no sensible world one AS would have every other AS of the DFZ as a provider.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size. I will bump OpenBGPD's max PDU size to 64k which should be enough for 10'000 SPAS in one PDU.

I dislike that the ASPA profile did not limit the number of SPAS. This idea that computers run without infinite resources is very dumb for a security critical application. We should prevent random operators to generate ASPA PDUs that will inflict very big loads on BGP routers.

— Reply to this email directly, view it on GitHub https://github.com/bgp/stayrtr/pull/121#issuecomment-2040998444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQTEWUGIQAPM2WYT4F4TTY36NP3AVCNFSM6AAAAABFYZSNZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQHE4TQNBUGQ . You are receiving this because you authored the thread.Message ID: @.***>

[benjojo]

Outside of the general conversation of this PDU size, I suspect there is value in having a massive ASPA entry shoved into the system early on so that systems are forced to deal with this

On Sat, Apr 6, 2024, 09:00 Ties de Kock @.***> wrote:

I agree that the limit is big, but given the protocol, I do not think there is any sane value that would prevent the denial-of-service-by-disconnect gap.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size.

64kb definitely is an improved value.

But unfortunately that limit is per ASPA, which allows multiple objects to be combined for a larger number of SPAS for an AS. This would require active "experiments"/attacks in the public RPKI, but that is the status quo.

1MB is manageable for systems and a large enough number to definitely cover what is realistic in the DFZ.

I think this may need RPs to limit the total number of SPAS for an AS (over all ASPAs), or alternatively, a protocol change.

On Sat, Apr 6, 2024, 09:08 Claudio Jeker @.***> wrote:

I think your new limit is far to big. In no sensible world one AS would have every other AS of the DFZ as a provider.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size. I will bump OpenBGPD's max PDU size to 64k which should be enough for 10'000 SPAS in one PDU.

I dislike that the ASPA profile did not limit the number of SPAS. This idea that computers run without infinite resources is very dumb for a security critical application. We should prevent random operators to generate ASPA PDUs that will inflict very big loads on BGP routers.

— Reply to this email directly, view it on GitHub https://github.com/bgp/stayrtr/pull/121#issuecomment-2040998444, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABQTEWUGIQAPM2WYT4F4TTY36NP3AVCNFSM6AAAAABFYZSNZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQHE4TQNBUGQ>

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/bgp/stayrtr/pull/121#issuecomment-2041009668, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPK4RLD2OBCAGMSNMRHBDY36TSHAVCNFSM6AAAAABFYZSNZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGAYDSNRWHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ties]

Outside of the general conversation of this PDU size, I suspect there is value in having a massive ASPA entry shoved into the system early on so that systems are forced to deal with this

I agree. There is value in having non-abusive edge cases in the system early on to ensure safe behaviour.

[cjeker]

I agree that the limit is big, but given the protocol, I do not think there is any sane value that would prevent the denial-of-service-by-disconnect gap.

I think the RTR caches should prevent the generation of huge PDUs. Up until now all RTR PDU were minimal in size but the unfinished darft-8210bis code introduces a PDU with a much much bigger possible payload. Right now I stopped caring about darft-8210bis. That draft in its current form is not making it through WGLC.

So maybe it is time to add some sensible limits to the RFC so implementations don't diverge too much.

rpki-client will limit the ASPA SPAS to 10'000 elements so there is no need for a 1MB PDU size.

64kb definitely is an improved value. But unfortunately that limit is per ASPA, which allows multiple objects to be combined for a larger number of SPAS for an AS. This would require active "experiments"/attacks in the public RPKI, but that is the status quo. 1MB is manageable for systems and a large enough number to definitely cover what is realistic in the DFZ. I think this may need RPs to limit the total number of SPAS for an AS (over all ASPAs), or alternatively, a protocol change.

rpki-client added a per VAP limit of 10'000 elements as well. We see no point in pushing more SPAS down the pipeline and to be honest 10'000 is already more than a magnitude more than what is sensible. It seems the biggest AS need maybe a few hundred SPAS and that's for probably a handful of very special ASes.

[ties]

I've adjusted it to the upper bound discussed in a mail thread. This is big, but I don't want rtrmon/rtrdump to break when they are monitoring/debugging aids.

[ties]

@benjojo what do you think?

I've skipped a metric (series, { _sum, _count, _max}) on the PDU size of now, I see limited value there.