Re: Need for historical prefix blacklist (`rogue' prefixes) information

[David Conrad]

I’m a little confused.  I thought the concern was about decrypting 
intentionally mis-routed traffic, not a suggestion that ROV uses encryption…

Regards,
-drc

> On Oct 30, 2021, at 5:57 PM, J. Hellenthal via NANOG  wrote:
> 
> 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  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-computing-as-a-service
>>  
>> .
>>  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 > > wrote:
>> 
>> 
>> On Fri, 29 Oct 2021, 15:55 A Crisan, > > 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
>> 

Re: Need for historical prefix blacklist (`rogue' prefixes)

[Jakob Heitz (jheitz) via NANOG]

It may be possible to create a fake certificate for a fake ROA.
However, to do that requires a lot of steps to go right.

First, the RSA private key needs to be derived from the public key.
The quantum computer physics exists to do it.
However, the known technology is massively behind and may never materialize.
OTOH, it is a wide open field and someone may find a way to create enough
qubits and entangle them all and keep them stable long enough to
perform the calculation tomorrow.
People have been trying for several years, so this is extremely unlikely.

Second, relying parties need to be convinced/tricked into downloading
the fake certificates. Since each certificate contains the publication points
of its child certificates, the certs are chained together.
The route to a publication point needs to be hacked to cause relying parties
to access the fake publication point.

A point was made that encrypted data can be captured and stored and then
be decrypted later once the technology becomes available. This possibility
is not useful for creating fake ROA certs.

Therefore quantum resistant certificates will not be needed in advance of
the development of quantum certificate crackers.

Regards,
Jakob.

-Original Message-
Date: Sat, 30 Oct 2021 19:57:25 -0500
From: "J. Hellenthal" 

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  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-computing-as-a-service.
>  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  wrote:
>> 
>> 
>>> On Fri, 29 Oct 2021, 15:55 A Crisan,  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 

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[J. Hellenthal via NANOG]

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  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-computing-as-a-service.
>  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  wrote:
>> 
>> 
>>> On Fri, 29 Oct 2021, 15:55 A Crisan,  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
>> 

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[A Crisan]

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-computing-as-a-service.
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  wrote:

>
>
> On Fri, 29 Oct 2021, 15:55 A Crisan,  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
>
>

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Amir Herzberg]

I am very grateful for the help I received from several people (mostly off
list, which is great to avoid spamming the list).

In particular, +Giotsas, Vasileios  , introduced
by Joe Provo, provided a wonderful RIPE resource which provides convenient
API to data from (at least) UCEprotect and SpamHaus, perfectly meeting out
current needs: https://stat.ripe.net/docs/data_api#blocklist.

Let me also use this email to briefly comment on two points from  Matthew
Walster's posts; and Matthew, I really come at peace, I have a lot of
respect for you and your work, but we can also disagree on some things,
right? So:

1. Matthew's email basically seemed to imply intentional hijacks are not a
concern (rare/non-existent?). Few measurement works seem to show the
contrary; I esp. recommend the `Profiling BGP serial hijackers' paper from
IMC'19 by a team of excellent researchers.

2. A bit off-topic, Matthew's response to Dora Crisan seem to imply BGP
eavesdropping for eventual cryptanalysis, possibly using Quantum computing,
isn't a concern. On the one hand, I agree that Quantum computing seems
still quite far from ability to break state-of-art PKC, and it may long
till it becomes practical (if ever). OTOH, it may also not take that long;
also, `conventional' cryptanalysis may still happen, e.g., see
Schnorr's recent paper, ia.cr/2021/232, which claimed to `destroy' RSA
[withdrawn later, so apparently even Schnorr can err - that's part of
science - but this doesn't mean next effort won't succeed or that some
TLA  (three lettered adversaries) didn't succeed already]. TLAs may have
other motivations for eavesdropping, like collecting meta-data. Now, I am
sure many customers and providers may not care about security against such
TLAs, but I think it is legitimate for some people to be concerned.

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





On Thu, Oct 28, 2021 at 7:48 PM Amir Herzberg  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).
>
> Basically we want to measure if the overlap (and non-overlap) btw such
> `suspect' prefixes and ROV-Invalid prefixes.
>
> 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).
>
> thanks and regards... 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
> 
>
>
>

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Amir Herzberg]

(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 

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Matthew Walster]

On Fri, 29 Oct 2021, 15:55 A Crisan,  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

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[A Crisan]

Hi Matthew,


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

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). Analysis of Advanced Persistent Threats (APT) and Nation State
capabilities, along with whistle blowers’ revelations have shown that
threat actors can and are casually recording all Internet traffic in their
data centers 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"

Best to all,
Dora

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Matthew Walster]

Hi,

On Fri, 29 Oct 2021 at 00:48, Amir Herzberg  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

Need for historical prefix blacklist (`rogue' prefixes) information

[Amir Herzberg]

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

Basically we want to measure if the overlap (and non-overlap) btw such
`suspect' prefixes and ROV-Invalid prefixes.

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

thanks and regards... 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

Verizon mail IP blacklist contact?

[Tim Burke]

Anyone happen to have a contact at Verizon that can actually get an IP 
delisted in their mail blacklist? I've been attempting to get an IP 
delisted with Verizon for quite some time, and haven't had luck through 
their web form ( 
http://my.verizon.com/micro/whitelist/RequestForm.aspx?id=isp), their 
abuse address, etc. Their autoresponder claims the IP is a dynamic 
address, when this range is considered static with SORBS, Spamhaus, etc.



--Tim

Spamcop Blacklist

[Clinton_Popovich]

Anyone-

We are having a bit of trouble with spamcop blocking 2 of our MTAs with IPs of 
208.65.145.71 and 208.65.145.66. We have yet to receive any samples of the spam 
and do not seem to be able to submit for removal as it appears someone has 
attempted to do this for us and basically used up all our our requests for a 
period of time. Does anyone have a contact over at spamcop that might be able 
to assist us in removing these MTAs before this becomes a large issue or us and 
our customers?

Below is the Bounce message we are receiving.
Bounce message
  554 Service unavailable; Client host [pXXcXXoXXX.mxlogic.net] blocked 
by bl.spamcop.net

Just to let everyone know, we do vigorously monitor outbound spam traffic and 
take seriously any reports of spam from our network. If someone can get us a 
sample of what spamcop is see this would also help!

Any help is greatly appreciated.

Thanks,

--
Clinton Popovich
Linux Systems Administrator
McAfee
9781 S. Meridian Blvd., Suite 400, Englewood, CO 80112 USA

Re: Spamcop Blacklist

[Rich Kulawiec]

This is probably much more appropriate over on mailop; please see:

http://chilli.nosignal.org/mailman/listinfo/mailop

I don't recall offhand is any Spamcop personnel hang out there, but
it's plausible to think they might.

---rsk

APEWS spam blacklist?

[Tim Burke]

Anyone have a contact involved with the APEWS blacklist? They have had a /19 of 
ours blacklisted for almost two years and there seems to be no way to contact 
them to get this resolved.

Re: APEWS spam blacklist?

[Michael J Wise]

On Aug 8, 2012, at 6:41 AM, Tim Burke wrote:

 Anyone have a contact involved with the APEWS blacklist? They have had a /19 
 of ours blacklisted for almost two years and there seems to be no way to 
 contact them to get this resolved.


In a word, no.
Much sage advice here:


http://www.dnsbl.com/2007/08/what-to-do-if-you-are-listed-on-apews.html

Aloha,
Michael.
-- 
Please have your Internet License 
 and Usenet Registration handy...

Blacklist entry

[Larry Sheldon]

For some reason I am getting a ton of DNR spam from blackberry.net
with Subject: lines that imply that somebody here is the culprit.
(Hence this message here.)

I am blacklisting blackberry.net in an effort to reduce the spam load
here.
-- 
Democracy: Three wolves and a sheep voting on the dinner menu.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: Blacklist entry

[Valdis . Kletnieks]

On Sun, 28 Mar 2010 08:51:51 CDT, Larry Sheldon said:
 For some reason I am getting a ton of DNR spam from blackberry.net
 with Subject: lines that imply that somebody here is the culprit.
 (Hence this message here.)

I figured it was just another case of something that *still* doesn't understand
the semantic difference between RFC821 MAIL FROM: and RFC822 From:




pgpz2Ja6yBNda.pgp
Description: PGP signature

Re: Blacklist entry

[Larry Sheldon]

On 3/28/2010 12:00, valdis.kletni...@vt.edu wrote:
 On Sun, 28 Mar 2010 08:51:51 CDT, Larry Sheldon said:
 For some reason I am getting a ton of DNR spam from blackberry.net
 with Subject: lines that imply that somebody here is the culprit.
 (Hence this message here.)
 
 I figured it was just another case of something that *still* doesn't 
 understand
 the semantic difference between RFC821 MAIL FROM: and RFC822 From:

I'm comfortable with what stupidity is sufficient to explain.

I figure they are not bright enough to be malicious.

-- 
Democracy: Three wolves and a sheep voting on the dinner menu.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Air Force Blacklist

[Brad Fleming]

Hello all,

We have a customer that appears to have a portion of their ARIN- 
assigned IP space blocked from accessing specific US Air Force  
resources. We've tried opening tickets with various groups and are not  
getting anywhere after several months of dancing.


I was wondering if:
1) Anyone has experience getting themselves OFF an Air Force blocked  
list and is willing to share tips.
2) If there are any Air Force contacts that can confirm or deny that a  
specific IP is indeed blocked or if we're chasing the wrong problem.


Off-list replies (obviously) welcome.
--
Brad Fleming

Blacklist

[David Gower]

We are an ISP and one of our users webmail account was hacked into (poor 
passwd). Spam was sent out from it. We are black listed on Hotmail. I can't 
find anyway to get off their list. Who do I contact?

Thanks

David Gower
President 

Gower Computer Support, Inc.
903 597-9220

Re: Blacklist

[William Pitcock]

On Fri, 2009-09-11 at 09:37 -0500, David Gower wrote:
 We are an ISP and one of our users webmail account was hacked into (poor 
 passwd). Spam was sent out from it. We are black listed on Hotmail. I can't 
 find anyway to get off their list. Who do I contact?

http://postmaster.live.com/ - it is listed in their bounce messages,
even...
-- 
William Pitcock SystemInPlace - Simple Hosting Solutions
1-866-519-6149 http://www.systeminplace.net/
Follow us on Twitter:   http://www.twitter.com/systeminplace