https://www.koreatimes.co.kr/www/tech/2021/11/133_318025.html
KT to pay W40 bil. in compensation for network outage
KT will pay out up to 40 billion won ($33.97 million) in compensation to
customers of its wired and wireless services, which underwent nationwide
disruptions Oct. 25, the company said.
[...]
KT said it will pay compensation for 10 times the disruption time of 89
minutes...
[...]
NTT Docomo, AT&T, Verizon and T-Mobile caused disruptions in services for
subscribers (customers) in recent years, but none offered compensation.
"We are offering the greatest level of compensation compared to both local
and foreign companies in the same industry," a KT official said.
[...]
The Ministry of Science and ICT said the mistake of an employee of a KT
subcontractor caused the nationwide disruption.
received this vuln notice four days before these children intend to
disclose. so you can guess how inclined to embargo.
randy
From: Koen van Hove <k.w.vanhove(a)student.utwente.nl>
Subject: CVD: Vulnerabilities in RPKI Validators
To: randy(a)psg.com, sra(a)hactrn.net
Cc: cert(a)ncsc.nl
Date: Wed, 27 Oct 2021 14:59:21 -0700
Dear Randy Bush and Rob Austein,
Apologies, this email was previously sent to the wrong email address.
On behalf of the University of Twente and the National Cyber Security
Centre of the Netherlands (NCSC-NL) we want to notify you of a Coordinated
Vulnerability Disclosure for RPKI vulnerabilities that also impact rcynic
developed by Dragon Research Labs.
The vulnerabilities were discovered by scientific research on the
implementation of RPKI validators.
Together with you, the NCSC-NL, the University of Twente, and multiple
other parties, we would like to come to a timely solution before the
results of this research will be made public. More information about
Coordinated Vulnerability Disclosure can be found here [1].
The vulnerabilities are classified as a denial of service vulnerability and
impact multiple implementations of RPKI validators including rcynic. Since
RPKI is of international interest we hope that you will work together with
us on this CVD.
The goal is to have fixes available before 1 November which will also be
the date that the results of this research will become public. Before 1
November the information in the CVD, or the fact that a CVD is taking
place, is to be kept strictly confidential. The fixes are to be released
collectively on 1 November.
Please let us know whether you agree to these terms, and want to
participate in this CVD. If so, we will send you the details. We hope to
hear from you.
If there are any further questions, please let us know.
Yours sincerely,
Koen van Hove
University of Twente
[1] https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
- --
Koen van Hove
-----BEGIN PGP SIGNATURE-----
Version: FlowCrypt Email Encryption 8.1.5
Comment: Seamlessly send and receive encrypted email
wsDzBAEBCgAGBQJhecu4ACEJEPnqm/++VTh9FiEE5Q3GCKqW0RQyUpA/+eqb
/75VOH1CjwwAq8Hd0psDhfj6mL4X9ybLGogONpzFKYp9Okv9/CKzQvG4AkLR
Cvrz3vHlQRKJP8I2PYSLZvtG9D/HXjjKcU+m24jjl2qbKKuSwprqQhLAqabN
Md+RZFjQGve5Z4vtJsfhXKc4PhaAzMujVc4Mh5Mdbs4sFEdrub1hSnYKlcQV
PvS/O9SpCYU0E0IC1I455HXxSXUtme+KHtzbGIWQe/mz4KpnZD2Me/Cr1LvG
Od9izri0Qx5vF+kdpR51PEiwHgN+QkmnUP6Gkrca8TSC2x3ta9B1/ZprdCoZ
ZYQ7QUFUAkfV+tKCMaBECNOrnDjw8E9GonvzmqpDHBtKBZ3LaxjZX/sxuuTC
+Ele5nVeWW0ZFqrbanbPy9y1q04tFQd8ewdSN40iXdTj7Ha8GadUhcdSLWqJ
cLmf71qUAvdwpp0Bt1nhExpU/bEtAaxfnEcTRDX43yUkZXSqV5BxYEyneSLj
IvFV9AUi56Cx45ESkGRR1ASuCzoc8FCjRH7KOWnaL3fl
=YQZI
-----END PGP SIGNATURE-----
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" <jhellenthal(a)dataix.net>
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(a)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-…. 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(a)walster.org> wrote:
>>
>>
>>> On Fri, 29 Oct 2021, 15:55 A Crisan, <alina.florar(a)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
>>
Question: if I have a written contract with a peer that covers the link and IP service in general, but that contract does not specifically discuss BGP or peering, is that a Yes or No?
Also, how should I indicate "unknown" , particularly for the Written Contract field?
-Adam
Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>
________________________________
From: NANOG on behalf of Bill Woodcock
Sent: Friday, October 29, 2021 06:47
To: NANOG
Subject: PCH Peering Survey 2021
Background:
Five and ten years ago PCH conducted comprehensive global surveys characterizing Internet peering agreements. They are the only ones of their kind, and are relied upon by legislators and regulators throughout the world to understand the Internet interconnection landscape.
Our write-ups of the prior surveys can be found here:
https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016…
…and video of the NANOG presentation of the 2016 results is here:
https://www.youtube.com/watch?v=lPuoBmxyXMc
At the time of the 2011 survey, we committed to repeating the survey every five years, to provide time-series data about the direction peering trends take. We’re now conducting the third iteration of the survey.
Among other things, the surveys have helped establish a better understanding of trends in:
• The increasingly uniform global norms of interconnection
• National preferences within the network operator community for country of governing law
• The long tail of small networks which don’t yet support IPv6 routing
• The significance of multilateral peering agreements in the density of the interconnection mesh
These findings, particularly the first, have been invaluable in giving regulators in the vast majority of the world’s countries a data-driven basis for refraining from prescriptively regulating Internet interconnection. They have demonstrated in objective terms that the Internet self-regulates in a way that’s more globally uniform and closely harmonized than any coordination of national regulatory bodies could accomplish.
Participation:
The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world. Your participation ensures that your norms and ways of doing business are represented accurately and proportionately in the dataset. If you don’t participate, the way you do business will be less well-represented in the data, and will seem less normal to regulators and policy-makers. We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 4,331 networks in 96 countries, or 86% of the world’s ISPs at that time. In 2016, responses represented 10,794 networks in 148 countries, or 60% of the world’s ISPs in 2016. Our aim is to be equally inclusive this year.
Since our principal method of soliciting participation is via NOG mailing lists, I’m afraid many of you will see this message several times, on different lists, for which we apologize.
Privacy:
In 2011 and 2016, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as was successfully employed the last two times. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed.
The Survey:
We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with:
• Your peer’s ASN (peers only, not upstream transit providers or downstream customers)
• Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement")
• Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes)
• Whether a jurisdiction of governing law is defined
• Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are)
The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns:
Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean [true,1,yes,y] or [false,0,no,n]
Symmetric: Boolean [true,1,yes,y] or [false,0,no,n]
Governing Law: ISO 3166 two-digit country-code, or empty
IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n]
For instance:
42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr>
42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr>
We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we will protect your privacy by discarding the raw data of the responses, and only final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN.
If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine.
If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs.
If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that.
If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results.
If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one.
Finally, if there are questions you’d like us to try to answer when we analyze the data, please suggest them, and if there are any additional questions you’d like us to include in future iterations of the survey, please let us know so that we can consider including them in the 2026 survey.
Please respond by replying to this email, by the middle of November, two weeks from now.
Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community.
-Bill Woodcock
Executive Director
Packet Clearing House
