<div dir="ltr">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. <div><br></div><div>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 : <a href="https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking" target="_blank">https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking</a></div><div><br></div><div>Let me respond to all your comments/questions; </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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). </blockquote><div><br></div><div>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!</div><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>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.<br></blockquote><div><br></div><div>We definitely don't reject ROV! it does improve security considerably - although, our results do show there seem to be room to improve. </div><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>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.<br></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>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). </blockquote><div><br></div><div>Serial 2 - I think, most works in the area use this. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. </blockquote><div><br></div><div>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!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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. <br></blockquote><div><br></div><div>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 :) </div><div><br></div><div>best, Amir</div><div>-- </div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, University of Connecticut</div><div>Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div><div>`Applied Introduction to Cryptography' textbook and lectures:<a href="https://sites.google.com/site/amirherzberg/applied-crypto-textbook" target="_blank"> https://sites.google.com/site/amirherzberg/applied-crypto-textbook</a></div><div><br></div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 1:42 PM Lars Prehn <<a href="mailto:lprehn@mpi-inf.mpg.de" target="_blank">lprehn@mpi-inf.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Amir, <br>
</p>
<p>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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Those are at least my thoughts. I hope they initiate some
discussion. <br>
Best regards, <br>
Lars <br>
</p>
<div>On 09.12.20 09:04, Amir Herzberg wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">Hi, the paper:
<div> ROV++: Improved Deployable Defense against
BGP Hijacking
<div>will be presented in the NDSS'21 conference. </div>
<div><br>
</div>
<div>The paper is available in:</div>
<div><a href="https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking" target="_blank">https://www.researchgate.net/publication/346777643_ROV_Improved_Deployable_Defense_against_BGP_Hijacking</a></div>
<div><br>
</div>
<div>Feedback, by discussion here or by direct email to
me, is welcome, thanks.</div>
<div><br>
</div>
<div>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.</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div>--</div>
<div>Amir Herzberg<br>
</div>
<div><br>
</div>
<div>Comcast professor
of Security
Innovations,
University of
Connecticut</div>
<div><br>
Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div>
<div><br>
</div>
<div>Foundations of
Cyber-Security (part
I: applied crypto,
part II:
network-security): </div>
<div><a href="https://www.researchgate.net/project/Foundations-of-Cyber-Security" target="_blank">https://www.researchgate.net/project/Foundations-of-Cyber-Security</a></div>
</div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div>