On Fri, 29 Oct 2021, 15:55 A Crisan, <alina.florar@gmail.com> wrote:

Hi Matthew, I was reading the above exchange, and I do have a question linked to your last affirmation. To give you some context, the last 2021 ENISA report seem to suggest that internet traffic is "casually registered" by X actors to apply post Retrospective decryption (excerpt below). This would be at odds with your (deescalating) affirmation that hijacks are non-malicious and they are de-peered quickly, unless you pinpoint complete flux arrest only. Are there any reportings/indicators... that look into internet flux constant monitoring capabilities/capacities? Thanks.

RPKI uses authentication not confidentiality. There is no encryption taking place, other than the signatures on the certificates etc. Excerpt from the introduction: "What makes matters worse is that any cipher

text intercepted by an attacker today can be decrypted by the attacker as soon as he has access to a large quantum computer (Retrospective decryption).

Which do not exist (yet). Analysis of Advanced Persistent Threats (APT) and Nation State

capabilities,

Buzzwords. along with whistle blowers’ revelations

have shown that threat actors can and are casually recording all Internet

traffic in their data centers

No they're not. It's just not possible or indeed necessary to duplicate everything at large scale. Perhaps with a large amount of filtering, certain flows would be captured, but in the days of pervasive TLS, this seems less and less worthwhile. and that they select encrypted traffic as interesting and worth

storing.This means that any data encrypted using any of the standard public-key systems today will need to be considered compromised once a quantum computer exists and there is no way to protect it retroactively, because a copy of the ciphertexts in the hands of the attacker. This means that data that needs to remain confidential after the arrival of quantum computers need to be encrypted with alternative means"

None of this is relevant to RPKI (ROV) at all. In fact, it reads like the fevered dreams of a cyber security research student. What's your point regarding your message? ROV does not use (nor needs) encryption. M

He answered it completely. "You" worried about interception of RPKI exchange over the wire are failing to see that there is nothing there important to decrypt because the encryption in the transmission is not there ! And yet you've failed to even follow up to his question... "What's your point regarding your message? ROV does not use (nor needs) encryption." So maybe you could give some context on that so someone can steer you out of the wrong direction. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Oct 30, 2021, at 10:31, A Crisan <alina.florar@gmail.com> wrote:

 Hi Matthew,

Quantum computing exists as POCs, IBM being one of those advertising them and announced to extend their project. There are others on the market, Amazon advertised quantum computing as a service back in 2019: https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-c.... The bottle neck of the current technology is scalability: we will not see QC as personal computing level just yet (to go in more detail, current technologies work at cryogenic temperatures, thus they are hyper expensive and not really scalable), but they exist and one could be imagine they are/will be used for various tasks.

On the other hand, you've actually commented every word of my mail, minus the stated question. Thanks.

Best Regards, Dora Crisan

...

On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster <matthew@walster.org> wrote:

...

On Fri, 29 Oct 2021, 15:55 A Crisan, <alina.florar@gmail.com> wrote: Hi Matthew, I was reading the above exchange, and I do have a question linked to your last affirmation. To give you some context, the last 2021 ENISA report seem to suggest that internet traffic is "casually registered" by X actors to apply post Retrospective decryption (excerpt below). This would be at odds with your (deescalating) affirmation that hijacks are non-malicious and they are de-peered quickly, unless you pinpoint complete flux arrest only. Are there any reportings/indicators... that look into internet flux constant monitoring capabilities/capacities? Thanks.

RPKI uses authentication not confidentiality. There is no encryption taking place, other than the signatures on the certificates etc.

...

Excerpt from the introduction: "What makes matters worse is that any cipher text intercepted by an attacker today can be decrypted by the attacker as soon as he has access to a large quantum computer (Retrospective decryption).

Which do not exist (yet).

...

Analysis of Advanced Persistent Threats (APT) and Nation State capabilities,

Buzzwords.

...

along with whistle blowers’ revelations

...

have shown that threat actors can and are casually recording all Internet traffic in their data centers

No they're not. It's just not possible or indeed necessary to duplicate everything at large scale. Perhaps with a large amount of filtering, certain flows would be captured, but in the days of pervasive TLS, this seems less and less worthwhile.

...

and that they select encrypted traffic as interesting and worth storing.This means that any data encrypted using any of the standard public-key systems today will need to be considered compromised once a quantum computer exists and there is no way to protect it retroactively, because a copy of the ciphertexts in the hands of the attacker. This means that data that needs to remain confidential after the arrival of quantum computers need to be encrypted with alternative means"

None of this is relevant to RPKI (ROV) at all. In fact, it reads like the fevered dreams of a cyber security research student. What's your point regarding your message? ROV does not use (nor needs) encryption.

M

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