Hi Amir,
Neither providing an abstract nor the high-level takeaways of
your work is a rather blunt way to promote your paper. I have a
bunch of comments and questions, but I'm only a student so take
them with a grain of salt.
Regarding ROV++ v1: Let's modify your example in Figure 2a
slightly such that AS 666 announces 1.2.3/24 also via AS 86.
Further, let's say AS 88 also uses ROV++ v1. Now, let's replay
your example from the paper. AS 78 still sees the same
announcements you describe, and you recommend using a different,
previously less-preferred route for 1.2/16. Yet, all routes
available to AS 78 ultimately run into the same hijack behavior
(which is not visible from AS 78's routing table alone). In a
nutshell, your recommendation did not affect the outcome for
1.2.3/24---the traffic still goes towards the hijacker---but you
effectively moved all the remaining traffic inside 1.2/16 from an
optimal route to a sub-optimal one. Your approach not only may
have no effects on the fate of the attacked traffic, but it may
also mess with previously unaffected traffic.
Regarding ROV++ v2: A simple sub-prefix hijack would still not
yield a "valid" during your ROV. The moment you propagate such a
route, you reject the entire idea of ROV. I understand that you
drop the traffic, but your proposal still feels like a step
backward. However, I'm not an expert on this---I might just be
wrong.
Regarding goals: I think that you only meet your first design goal
since your definition of 'harm' is very restricted. The moment you
add more dimensions, e.g., QoS degradation for previously
unaffected traffic, this goal is no longer met.
Regarding your evaluation: Which of CAIDA's serials do you use?
Serial-1 is known to miss a significant fraction of peering links,
while Serial-2 contains potentially non-existing links (as they
are inferred using heuristics). Since coverage and validity of
links varies drastically between serials (and for serial-2 even
between snapshots), it is unclear to which degree your topology
reflects reality. I like that you assumed the basic Gao-Rexford
Model for the best-path decision process. Yet, you ignored that
various networks deploy things like prefix-aggregation,
peer-locking, or more-specifics (referring to /25 .. /30 IPv4
prefixes) filters. Further, I do not get why you randomly picked
ROV-deploying networks. I am sure people like Job Snijders or
Cecilia Testart could have provided you an up-to-date list of ASes
that currently deploy ROV. It is not clear to me why it is useful
to look at scenarios in which those networks potentially no longer
deploy ROV.
Those are at least my thoughts. I hope they initiate some
discussion.
Best regards,
Lars
Hi, the paper:ROV++: Improved Deployable Defense against BGP Hijackingwill be presented in the NDSS'21 conference.
The paper is available in:
Feedback, by discussion here or by direct email to me, is welcome, thanks.
btw, I keep most publications there (researchgate), incl. the drafts of `foundations of cybersecurity' ; the 1st part (mostly applied crypto) is in pretty advanced stage, feedback is also very welcome. URL in sig.--Amir Herzberg
Comcast professor of Security Innovations, University of Connecticut
Foundations of Cyber-Security (part I: applied crypto, part II: network-security):