Re: [sidr] Another potential DOS attack on RP software?

[Tim Bruijnzeels <[e-mail]>]

Hi Demian,

On Jan 23, 2014, at 1:46 PM, Demian Rosenkranz <[e-mail]> wrote:

> Hi,
> 
> I'm thinking about another potential DoS attack. An entity which owns a CA certificate has the possibility to generate a huge hierarchy of further CA certificates without any limitation (as far as I know).
> 

As far as I remember there are no formal restrictions regarding either the number of child CA certificates issued by a CA, or the length of the chain.  

> In contrast to the generation of a huge amount of ROAs, this attack isn't limited regarding the number of objects/certificates.
> 
> I.e. a compromised/bad entity owns a /16 prefix and generates 10000 CA certificates and hand down this prefix until the lowest CA certificate and generates 2^8 ROAs, a relying party software would be forced to check this hierarchy 2^8 times.

Some say that the same resource 'should' not appear on multiple child CA certificates, however in practice this can happen in case of a child key roll, and a make-before-break resource transfer. There is no notification about the reason, so RPs have a hard time guessing. In short: our RP doesn't care about resources appearing on multiple child CA certs. If the certificates are valid, the duplicate resource is valid for both branches.. if the parent disagrees, they should revoke / re-issue as needed.

That said, if one wants avoid duplicating resources in an attack like this there is always IPv6.. And then it's of course possible that it wasn't intended as an attack at all, but some over zealous CA goes granular way beyond present day BGP --- eg. giving ghostbusters to all their v6 end users ;)

> Of course, this is kind of a blunt attack but without making any provisions, this "local cache flooding" could lead to a disturbance of all (worst case) local caches for a certain time. Some smaller RP could be slower in remedying this.

While I don't think we have formal restrictions, I can imagine certain mitigations if this would become a serious threat:
= Parent of the offending CA could revoke the certificate (if abuse is defined in terms of use, talking doesn't help, etc.., reactive by nature though)

= RPs could limit the maximum length of the cert chain, or even number of CA certs issued by CA certs they are willing to accept
      - e.g. pro-actively quarantine 'spam-CAs' like this, and allow the end-user to override
      - or re-actively.. proceed, but warn and allow user to disregard
      - or a mix of both of course with some thresholds, prob. allowing the RIRs to issue a bit more 
= RPs should probably employ strategies to ensure that a lot of work in one part of the tree does not block validation of the remaining tree (if resources don't overlap).

> Are there any restriction to this attack I've missed? Any feedback is very welcome!

I would say that been though it's entirely possible to attack the rpki by producing many objects, it's not feasible to do this *covertly*. This will get get you noticed, quickly.

So while I see the value of thinking about these scenarios and possible ways to mitigate them - thank you :) - I am not convinced that we should go overboard in terms of best practices for RPs, or general restrictions for CAs, at this time. I would consider possible *covert* attack vectors on the rpki infrastructure to be much more serious though.

Cheers
Tim