Hello Amir,
On 5/18/19 1:08 PM, Amir Herzberg wrote:
This discussion is very interesting, I didn't know about this problem,
it has implications to our work on routing security, thanks!
Your welcome..., since long time ago I wanted to expose our findings in
English.
On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta
<alejandroacostaal...@gmail.com
<mailto:alejandroacostaal...@gmail.com>> wrote:
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):
My position is exactly the opposite.
- 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
Yes, you are right, but anyhow -IMHO- this still better than not
learning small prefixes at all.
- 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:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/
You are right here.
Thanks for the link, I will take a look.
Alejandro,
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut
Foundations of Cybersecurity:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security
Homepage: https://sites.google.com/site/amirherzberg/home
