<div dir="ltr"><div>(this is an answer to Matthew but also with a question to all NANOGers, see below, under `is this true?')</div><div><br></div>Matthew, thanks for your feedback on our paper - always welcome - although the email I sent wasn't about ROV++ but on our need for historical data on blacklisted prefixes. (our use is not limited to ROV++ as we are investigating other attacks and defenses, including our own and proposed by others). <div><br></div><div>Anyway let me briefly respond to the issues you raised. </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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I read your paper. I note "<span style="font-family:Arial,Helvetica,sans-serif">ROV provides disappointing security </span><span style="font-family:Arial,Helvetica,sans-serif">benefits". I think we all know that ROV provides very little in the way of security from deliberate hijack without the protection of BGPsec as you later point out in your paper. </span></div></div></blockquote><div><br></div><div>I mostly agree. Not fully, since, actually, there _is_ an advantage to an attacker to perform prefix-hijack (and esp. subprefix hijack) compared to path manipulation attacks (which ROV fails against). Basically the reason is exactly the fact that most paths are short, as you mention. [E.g., see our `path-end' paper in SigComm'16] </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"><div><div class="gmail_default" style=""></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What<span style="font-family:Arial,Helvetica,sans-serif"> you seem to have failed to understand is that most traffic hijacks on the internet are not malicious in nature, they are "fat finger" incidents</span></div></div></blockquote><div><br></div><div>Apparently, I somehow caused you to believe that I think that most hijacks are due to attacks; never my intention (or belief). I'm well aware that errors are more common than attacks. </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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"> where someone has accidentally announced something they did not intend to, either because of faulty software (the infamous "BGP optimizer") or someone leaking internal "blocks" such as the Pakistan/YouTube incident</span></div></div></blockquote><div><br></div><div>Let's not mix route-leakage here... (but of course, that incident wasn't a leakage but a hijack - probably meant to be only within Pakistan, so I guess you could say it was also leakage)</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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"> -- certifying the origin of a prefix allows you to mitigate most of this as the origin AS will change. Anyone seen deliberately causing hijacks is likely to be depeered very quickly -- commercial pressure rather than technical.</span></div></div></blockquote><div><br></div><div>Now, is this true?  I'm really curious to know if all/most NANOGers agree that an AS deliberately causing hijacks would be very quickly depeered. </div><div><br></div><div>My concern is that providers may not disconnect a customer AS (or even a peer) `just' due to what may be an intentional hijack. Indeed one advantage of hijack (cf. to more advanced attacks) is that it may be _excused_ as a mistake, and there were some (in)famous incidents... And I suspect depeering is not such a quick response by an admin suspecting foul play; there are contracts and payments involved... Am I wrong?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Likewise, the core purpose of ROV is not to secure the entire address space. It is (as I understand it) to prevent *your* address space from being stolen, and</div></div></blockquote><div><br></div><div>Matthew, I know you know this stuff, so I think you mis-typed here, no? Obviously, you protect your address space by publishing ROAs. The purpose of ROV is _only_  </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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">to prevent your network from being affected by false advertisements.<span style="font-family:Arial,Helvetica,sans-serif"> </span></div></div></blockquote><div><br></div><div>(we agree on that!)</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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The superprefix attacks you mention are pretty much theoretical only at this time, </div></div></blockquote><div><br></div><div>I really like to do applied research, but sometimes I also do some research which is more for fun, and I agree these superprefix attacks are probably not very practical against _announced_ prefixes. Of course, sometimes we later find these works `for fun' do have practical importance...</div><div><br></div><div>And in this case... superprefix attacks may become practical against _unannounced_ prefixes (with ROA 0), _if_ ROV is widely deployed (making it ineffective to hijack them by simple prefix hijack). So, there is motivation to think about them! </div><div><br></div><div>btw, superprefix attacks can also allow foiling of feasible-uRPF, you know... so, again, could be practical. </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"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">because of the maximum prefix length attribute and the nature of peering in that networks either tend to be adjacent (therefore very low AS Path) or via transit (and most transit providers deploy ROV validation). It's true that traffic could be re-routed if the longer prefixes are not advertised to all parties, but that would also come under the AS Path length case.</div></div></blockquote><div><br></div><div>I don't quite see how this is relevant to the superprefix attacks; clearly the attack fails if a more specific prefix is available, but that's obvious.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hijacking a prefix is not useful unless you can do something with it, either to hand out to customers (in which case, the prefix is going to be sufficiently ignored around the internet that it's not practically useful) or to engage in denial of service activities in which case there are far easier measures to use.</div></div></blockquote><div><br></div><div>Intentional hijacking has different goals, many of which don't require universal success. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Any help would be appreciated. I'm not sure the list would be interested so I recommend you respond to me privately; if there are useful responses, I could post a summary to the list after few days (of collecting responses, if any). </div></div></blockquote><div><br></div></span><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I would strongly encourage engaging with the IETF (<a href="https://datatracker.ietf.org/wg/sidrops/about/" target="_blank">https://datatracker.ietf.org/wg/sidrops/about/</a> et al) who are much more likely to be able to point you in the right direction.</div></blockquote><div><br></div><div>Thanks - I agree, it'll be good idea to ask there (too). </div><div><br></div><div>Best, Amir</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr">-- <br><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, Computer Science and Engineering, 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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 29, 2021 at 8:13 AM Matthew Walster <<a href="mailto:matthew@walster.org">matthew@walster.org</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 dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Oct 2021 at 00:48, Amir Herzberg <<a href="mailto:amir.lists@gmail.com" target="_blank">amir.lists@gmail.com</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 dir="ltr">Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21), we need access to historical data of blacklisted prefixes (due to spam, DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we already have). </div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I read your paper. I note "<span style="font-family:Arial,Helvetica,sans-serif">ROV provides disappointing security </span><span style="font-family:Arial,Helvetica,sans-serif">benefits". I think we all know that ROV provides very little in the way of security from deliberate hijack without the protection of BGPsec as you later point out in your paper. </span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What<span style="font-family:Arial,Helvetica,sans-serif"> you seem to have failed to understand is that most traffic hijacks on the internet are not malicious in nature, they are "fat finger" incidents where someone has accidentally announced something they did not intend to, either because of faulty software (the infamous "BGP optimizer") or someone leaking internal "blocks" such as the Pakistan/YouTube incident -- certifying the origin of a prefix allows you to mitigate most of this as the origin AS will change. Anyone seen deliberately causing hijacks is likely to be depeered very quickly -- commercial pressure rather than technical.</span></div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Likewise, the core purpose of ROV is not to secure the entire address space. It is (as I understand it) to prevent *your* address space from being stolen, and to prevent your network from being affected by false advertisements. The superprefix attacks you mention are pretty much theoretical only at this time, because of the maximum prefix length attribute and the nature of peering in that networks either tend to be adjacent (therefore very low AS Path) or via transit (and most transit providers deploy ROV validation). It's true that traffic could be re-routed if the longer prefixes are not advertised to all parties, but that would also come under the AS Path length case.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hijacking a prefix is not useful unless you can do something with it, either to hand out to customers (in which case, the prefix is going to be sufficiently ignored around the internet that it's not practically useful) or to engage in denial of service activities in which case there are far easier measures to use. </div></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"><div dir="ltr"><div>Any help would be appreciated. I'm not sure the list would be interested so I recommend you respond to me privately; if there are useful responses, I could post a summary to the list after few days (of collecting responses, if any). </div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I would strongly encourage engaging with the IETF (<a href="https://datatracker.ietf.org/wg/sidrops/about/" target="_blank">https://datatracker.ietf.org/wg/sidrops/about/</a> et al) who are much more likely to be able to point you in the right direction.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Matthew Walster</div></div></div>
</blockquote></div>