02.10.2020 10:30
Nachdem die Umstellung vom AMSIX-nahe Peering eines meiner Upstreams zu einem nach außerhalb der EU geräusch- und reibungs-los vonstatten ging zum Qusrtalswechsel habe ich eben die Verbindungen zum IXP K***** kappen müssen. Grund ist daß die ohne jede vor-ankündigung plötzlich anfangen diesen RPKI Bullshit für mandatory zu erklären du daß sie nicht auf Tickets geantwortet haben. RPKI ist nur für Leute interssant die z.B.: ebgp multihop peeren aber fürdiejenigen die zu ihren Peering gegenstellen hin sowieso VPN-Tunnels betreiben ist RPKI unnötiger Overhead der vor allem eiens nämlich Performanceienbußen bedeutet. Anstatt EBGP Multihop zu betreiben nutze ich immer Tunnel zu ner VPS die bei dem Upstream vor Ort steht mit dem ich peere so das die vpn-interfaces directly connected sind. Für alles andere gibt es aut-num import/export filter! Ob einer meiner Upstreams Scheiße statt meines Announcments weitergibt kann ich nämlich sowieso nur insofern kontrollieren als ich das Peering dorthin im aut-num schließe. Denn jede Gegenseite im Netz müsste ja einzeln permanent mein RPKI gegenchecken und könnet wenn sie was falsches announct bekommt auch nur auf ihrer Seite als abwehrmaßname die fehlerhafte session runternehmen, vorausgesetzt sie ist multi-homed angebunden wie ich. Das Problem läge dann ja auf der anderen Seite die irrtümlicha nnimmt ein von eienm ihrer Uopstersms gespooftes Netz wäre das meien. Da kann ich von meienr Seite her ja nichts vile drann ändern denn mein Announc-ment geht ja zu meien Uostreams richtig raus, ds problemist jd das poofing am denren Ende, shclimstenfalls zahlreiche AS hops weiter.
Ich kann ja nicht deren Roter konfigurieren von hier aus um solche ein Problem gegebenfalls abzustellen. Die hätten ja ein Problem it rhem Upsteram nicht ich. Wenn due diene Oma die in Australienw ohns von Dustchaldn aus anrufts und die hat das Teelfonkabel fslch ind ie Dose egsteckt dann kanst du vonheir aus shclcht was drann ädnern. DU kannst nur eien eigen Vebrinung in Orndung halten. Genau deshlab routet man ja multihomed. Spätestns wenn ich einen von midnestsns zwo Uplinks verändere würde eine gespoofte Verbidnung ihren Traffic verlieren. Wenn ich zwo Ausgänge aus nem Haus habe dann kann ich nicht kontrolleiren an welchem jemand das Haus verlässt der dann aber trptzdem am reisziel ankommt. Und wenn der dernicht bagefangenw urde ankommt fällt auf daß die andern pakete abgefangen wurden, was siee ewgaagt kein Absenderpoblem is sondenr einpemfängserioetenproblem. Multihomed ist automstcihs icher wie ztwo factor auth. Das probnlem betrifft nur leute die nicht an midnetsns zwo voneidner unabhägigen upstreams peeren. Wenn mein uopsterm mich verrcht hab ich soweiso nur die möglichkeit nene andere upsterm zu nutzen. Daran ändetr wie egsta rpki nichts. Es erleichtert lediglich das auffidnen gespoofter routen bei der gegenseite ohne die möglichkeit einzugreifen. Den entscheidende ist ja daß der Empfänger das prüft, udndarauf hat der absendr eekinen Einfluß. Gespoofte Verbidnungen können keien Routingädnerungen mitamchen also Umleitungen wenn irgendo imNetz wratnsgabriten sind oder Ausfälle. Das fällt sofort auf weil dan auf der Umleitung um eien Baurbeitenstrecke keiene Fahrzeuge vrobeikommen. Man kann also nur sehr nah am Absender oder Ziellort spoofen.
Ein Pakte was von Hamburg nach München unetwregs ist kann über eien Autobahn bei Frankfurt gehen aber auch über Würzburg oder nürnberg und das kann ich nicht vorhersehen (Stau, Baustellen) daher kann ich nen Transport nur sehr nahe am Beginn oder ende der stecke zuverlässig abfangen. Wer den Weg hin zur Autobahn kontrolleirt kann sich auch als falsche Autobahnpolizeibehörde ausgeben also den RPKI Key eintrag in eienm vorgteäsuichten Whois einer gepooften RIPEDB fälschen die er seinem Dowbnstrema-Kudnen anliefert. Da ist ein Henne-Ei Problem. Mulrihomig ist das Mittel zur zuverlässigen abwehr solcher spoofing attacken. Nur hier würde ein gespoofter Key als abweichend auffallen weil die ripe abfrage üebr anbindung eisn was anderes ergbit als die üebr anbidnung zwo. Jmedn der etwas originales absendet kann nicht kontrolleiren ob was faslches ankommt weil das pre shared secret (Fingerprint-Checksummeebenfalls üebr den per Man inthe Midde atatckieten Weg augtesuchtw ird. Der angrifer würde dem absender einfch eienen falschen Einschrieben-Rückschein ausstellen dne der nur ekrneennt wenne r die Unetsrift seines Ggenüebr kennt. Wer mitsoclehn probleme zu kämpfen hat sollte mal seine kriminelle Nchbarschaft austsuschen. Spätestens wenn man sich vor Gericht sieht beemrkt die Gegnesite ob sie abgefangene Schriftstücke nicht bekommen hat. Dann müssen eben sämtliche Bvriefträger in den Kanst bis die shcchstelle gefudnen ist.
-------- Weitergeleitete Nachricht --------
Betreff: [KL #2009230125] K******/AS31142 network maintenance on 01/10/2020 (RS1 and RS2 affected)
Datum: Thu, 01 Oct 2020 20:25:51 +0200
Von: info@K******.net
Antwort an: info@K******.net
Dear valued customer,
the RS maintenance has been carried out successfully. Our exchange now drops RPKI invalid prefixes on all route-servers.
In attention the looking glass service offeres now more detailed information per peer.
You can find our LG under the following URL:
https://manager.K******.net/lg
Have a nice evening!
--
Mit besten Grüßen // Kind regards
K****** NOC
Am Mi 23. Sep 15:35:17 2020, JK schrieb:
> Dear valued customer,
>
>
> we want to kindly inform you about a scheduled maintenance work which
> will be performed on 01/10/2020. Further details you will find in the
> list below.
>
> Please note that time frames are approximate, as unexpected delays can
> occur in case of any problems occuring. We endeavor to complete all
> maintenance as quickly as possible and thank you for your
> understanding.
>
>
> Start: 01/10/2020 20:00:00 CEST
> End: 01/10/2020 22:00:00 CEST
> Duration: 2 hours
> Impact: 15 - 30 minutes (per RS)
> Location: Frankfurt
> Reason: Software upgrade on RS1 and RS2
> Device: rs1.K******.net, rs2.K******.net
>
> During our maintenance we will upgrade the route-server software in
> order to implement RPKI validation.
>
> We will upgrade the route-servers after another. Our RS1 will be the
> first one affacted. The upgrade on RS2 will start after the RS1 is
> back in service.
>
> We apologize in advance for any inconvenience this might cause.
>
>
>
> --
>
> Mit besten Grüßen // Kind regards
>
> AS31142 Network Operations
K****** Internet Exchange
Zwischen Validierung implementieren (angekündigt) und Routen ohen RPKI droppen (nicht angekündigt) gib es einen gewaltigen Unterschied.
[0] "202010021030-0-1.jpg"
[1] "202010021030-0-2.jpg"
[2] "202010021030-0-3.jpg"
[3] "202010021030-0-4.jpg"
[4] "202010021030-0-5.jpg"
|
