(this is an answer to Matthew but also with a question to all NANOGers, see below, under `is this true?')

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). 

Anyway let me briefly respond to the issues you raised. 

I read your paper. I note "ROV provides disappointing security 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. 

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] 
 
What 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

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. 
 
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

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)
 
-- 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.

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. 

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?

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

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_  
 
to prevent your network from being affected by false advertisements. 

(we agree on that!)
 
The superprefix attacks you mention are pretty much theoretical only at this time,

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...

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! 

btw, superprefix attacks can also allow foiling of feasible-uRPF, you know... so, again, could be practical. 
 
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.

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.  

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.

Intentional hijacking has different goals, many of which don't require universal success. 
 
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). 

I would strongly encourage engaging with the IETF (https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more likely to be able to point you in the right direction.

Thanks - I agree, it'll be good idea to ask there (too). 

Best, Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut
`Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Fri, Oct 29, 2021 at 8:13 AM Matthew Walster <matthew@walster.org> wrote:
Hi,

On Fri, 29 Oct 2021 at 00:48, Amir Herzberg <amir.lists@gmail.com> wrote:
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). 

I read your paper. I note "ROV provides disappointing security 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. 

What 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.

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.

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.
 
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). 

I would strongly encourage engaging with the IETF (https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more likely to be able to point you in the right direction.

Matthew Walster