This discussion is very interesting, I didn't know about this problem, it has implications to our work on routing security, thanks!
If you learn, let's say, up to /22 (v4), and someone hijacks one /21
you will learn the legitimate prefix and the hijacked prefix. Now, the
owner of the legitimate prefix wants to defends their routes announcing
/23 or /24, of course those prefixes won't be learnt if they are filtered.
I wonder if this really is a consideration to avoid filtering small prefixes (e.g. /24):
- attackers are quite likely to do sub-prefix hijacks (or say a specific /24), so I'm not sure this `hits' defenders more than it `hits' attackers
- I think we're talking only/mostly about small providers here, right? as larger providers probably will not have such problems of tables exceeding router resources.I expect such small providers normally connect thru several tier-2 or so providers... if these upper-tier providers get hijacked, the fact you've prevented this at the stub/multihome ISP may not help much - we showed how this happens with ROV in our NDSS paper on it:
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut