Dear Lars (and NANOG), sorry for the late reply. We looked carefully at your feedback, and made few relevant fixes in the paper, e.g., mentioned that we use serial-2 - definitely should have done it , so thanks for pointing it out.
You're most welcome to take a look at the revised (camera-ready) version; we plan to have a `full version' later on so if you'll have any more feedback we'll be happy to consider it and modify that version accordingly. You can download from : https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking Let me respond to all your comments/questions; 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). Lars, this is incorrect: in your example AS88 uses ROV++ so it would ignore the hijack from 666 and route correctly to 99. But let me clarify: there are scenarios where ROV++ (all versions) fail to prevent hijack for different reasons, including some which you may consider `disappointing'; we never claimed otherwise (and present the results). Clearly, further improving would be interesting! btw, we are also not claiming our results `prove' anything. This is not something we can prove just by simulations, we know that, and we continue now with pilot deployment. Although, frankly, I'm _quite_ sure, that ROV++v1 helps a lot - esp for edge ASes. > > 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. > We definitely don't reject ROV! it does improve security considerably - although, our results do show there seem to be room to improve. ROV++V2 doesn't just propagate the hijack, it turns it into `backhole announcement'. But, based on our results, we don't recommend to deploy it for announced prefixes; but it does provide significant value for unannounced prefixes - which are often abused, e.g., for DDoS, spam, etc. > > 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. > Well, we definitely cannot claim that we meet all intuitive interpretations of `do no harm'; maybe our text was a bit misleading here so we tried to make it more clear. > > 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). Serial 2 - I think, most works in the area use this. > 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. We _definitely_ agree that it _should_ be possible to do better simulations/evaluations by taking such aspects in consideration. But : (1) what we did is the same as what was done afaik in all previous works (except it seems our implementation is better optimized), and (2) we _are_ working toward better simulation/evaluation mechanism; in fact we believe we already have a first version working. But we couldn't use this for this evaluation since this is absolutely non-trivial change of evaluation method, and we have quite a lot of work to complete this and evaluate this very well. Clarifying: I refer to evaluating the correctness of our improved evaluation/simulation mechanism... So that's why we didn't use it yet. We are the first to agree current methodology is not the best! > 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. > Excellent point, this may indeed be a more interesting/realistic measurement. I must admit - just didn't think of it. Stupid... Cecilia sent us a list and although it's just by email, we'll use it to do additional evaluation, Real Soon Now :) best, Amir -- Amir Herzberg Comcast professor of Security Innovations, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> On Wed, Dec 9, 2020 at 1:42 PM Lars Prehn <lpr...@mpi-inf.mpg.de> wrote: > 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 > > 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 > > Foundations of Cyber-Security (part I: applied crypto, part II: > network-security): > https://www.researchgate.net/project/Foundations-of-Cyber-Security > > >
