ROV++: Improved Deployable Defense against BGP Hijacking

Wed Dec 9 11:40:13 UTC 2020

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

On 09.12.20 09:04, Amir Herzberg wrote:
> Hi, the paper:
>             ROV++: Improved Deployable Defense against BGP Hijacking
> will be presented in the NDSS'21 conference.
>
> The paper is available in:
> https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking 
> <https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking>
>
> 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
>
> Homepage: https://sites.google.com/site/amirherzberg/home 
> <https://sites.google.com/site/amirherzberg/home>
>
> Foundations of Cyber-Security (part I: applied crypto, part II: 
> network-security):
> https://www.researchgate.net/project/Foundations-of-Cyber-Security 
> <https://www.researchgate.net/project/Foundations-of-Cyber-Security>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201209/9f91c8d2/attachment.html>