Hi all,
As you might know, the organisers of MCH2021 ( https://mch2021.org/#/ <https://mch2021.org/#/>) have started the ticket sales. Some of us in the board of NLNOG thought it would be cool to have an NLNOG Village there.
But we had an NLNOG Camp a few years back and although it was great fun, if was a bit expensive for the amount of people that attended. That’s why we decided to first find out if there is enough interest to move forward with this.
We’ve set up a 3 question (30 seconds!) questionnaire on SurveyMonkey: https://nl.surveymonkey.com/r/LT86B8G <https://nl.surveymonkey.com/r/LT86B8G>
If you don’t want to click links, you can also reply to the questions in this mail:
-Are you considering to attend MCH2021?
-Would you join the NLNOG Village?
-Would you be interested to help out organising? (build-up, program, bar, etc.)
It would help us tremendously if you could take 30 seconds to reply or fill in the survey on SurveyMonkey! (Also if you’re not going to attend MCH2021!)
Thanks and happy holidays from all of us!
NLNOG Crew
Beste allemaal,
Aanstaande maandag word blijkbaar "RPKI-patchdag"! Er zitten problemen
in meerdere RPKI-validators. En zoals jullie misschien weten, beheer ik
zelf een aantal veel gebruikte RPKI software packages.
Maar anders dan "we vermoeden dat er een probleem in jouw RPKI-software
zit" heeft NCSC-NL geen informatie aan mij verstrekt waar ik op kan
handelen.
Ik wil een aantal kanttekeningen plaatsen bij het beleid van NCSC-NL.
Het komt op mij over alsof NCSC-NL een discriminerend beleid voert
aangaande welke mensen wanneer worden betrokken in zogenaamde
"coordinated vulnerability disclosure" (CVD) processen.
Een van de ideeën achter "CVD" is dat het voor de verschillende
betrokken software- ontwikkelaars een 'level playing field' creëert:
niemand krijgt extra voordeel.
Maar... die vlieger gaat natuurlijk niet op wanneer men mij
eergisterenavond informeert dat er aanstaande maandag mogelijk 0-days
aankomen, terwijl andere softwareontwikkelaars al MEERDERE WEKEN geleden
op de hoogte gebracht waren!
Het NCSC wilde enkel concrete informatie verstrekken als ik akkoord zou
gaan met een full disclosure-publicatie aanstaande maandag. Maar de boel
loopt vast als het NCSC niet vertelt wat het probleem is, waardoor ik
niet kan beoordelen hoeveel tijd nodig is, en dus geen idee heb of we
voor maandag überhaupt een oplossing hebben voor onze gebruikers.
Ik ga niet akkoord met zulke knetterstrakke deadlines. Ik kan geen
blinde cheque schrijven. Want stel: wat als het gerapporteerde probleem
een maand kost om op te lossen?
Of wat als: het probleem blijkt een topje van een ijsberg te zijn, en de
scope bij meerdere validators groter is? (Ik plaats vraagtekens bij
NCSC-NL's vermogen om BGP/RPKI problemen te beoordelen!)
Waarom ging NCSC-NL geen gesprek aan met mij? Naar eigen zeggen vinden
ze problematisch dat het OpenBSD project in de zogenoemde 'full
disclosure' methode gelooft (zie: https://www.openbsd.org/security.html)
Echter, het feit dat OpenBSD duidelijk omschrijft wat het project
belangrijk vindt, zegt natuurlijk niet dat we idioten zijn die geen
geheim kunnen bewaren.
(hallo, wij beheren iedereen's openssh, en ook libcrypto op je Mac, en
natuurlijk schitterende IKE/IPsec/RPKI/SMTP/BGP implementaties...)
Ik kan prima over NDAs onderhandelen en afspraken maken met mensen die
een ons probleem aanmelden. Maar dan moet men wel een gesprek aanknopen.
Het is mogelijk voor 'andersgelovigen' om productief met elkaar samen te
werken.
Voor zover ik kan beoordelen heeft NCSC-NL enkel overlegd met een
handjevol programmeurs. Verder lijkt het er op dat er geen enkele
default-free network operator op de hoogte is gesteld.
In mijn optiek is bij RPKI/BGP securityproblemen een heel belangrijk
aspect de deployment te coordineren tussen globale ISP / IXPs.
Er is niet nagedacht over hoe ISPs nieuwe software versies moeten
kwalificeren alvorens ze uitgerold kunnen worden, en hoeveel tijd dit
kost. Dit is kostbare tijd waarin allerlei ISPs vanaf maandag dus
mogelijk kwetsbaar zijn.
Ook bestaan er verschillende operationele 'trust circles' specifiek voor
het onderwerp Internet routing. NCSC-NL heeft hier blijkbaar geen weet
van, en dus geen gebruik van kunnen te maken. Gemiste kans!
In deze casus lijkt het NCSC-NL onzorgvuldig gehandeld te hebben met
mogelijk sensitieve informatie over kritieke Internet infrastructuur.
Wat mij betreft niet voor herhaling vatbaar.
Met vriendelijke groeten,
Job
In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.
This report summarises tests conducted within nld.
Inferred improvements during Sep 2021:
none inferred
Source Address Validation issues inferred during Sep 2021:
ASN Name First-Spoofed Last-Spoofed
8587 Infracom 2019-10-28 2021-09-08
213268 Cloudwebservices 2020-12-07 2021-09-30
Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=nld&no_block=1
Please send any feedback or suggestions to spoofer-info(a)caida.org
