From spoofer-info at caida.org Fri Jan 8 19:00:56 2021 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Fri, 08 Jan 2021 18:00:56 -0000 Subject: [atnog] Spoofer Report for ATNOG for Dec 2020 Message-ID: <1610128852.963497.22420.nullmailer@caida.org> 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 aut. Inferred improvements during Dec 2020: none inferred Source Address Validation issues inferred during Dec 2020: ASN Name First-Spoofed Last-Spoofed 31543 MYNET 2017-02-24 2020-12-31 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=aut&no_block=1 Source Address Validation issues inferred during Dec 2020 using open resolver tests: ASN Name Last-Detected 25447 JM-DATA 2020-12-03 Further information for these tests is available at: https://spoofer.caida.org/ornog.php?country_include=aut Please send any feedback or suggestions to spoofer-info at caida.org From lendl at cert.at Tue Jan 12 11:49:01 2021 From: lendl at cert.at (Otmar Lendl) Date: Tue, 12 Jan 2021 10:49:01 -0000 Subject: [atnog] VIX Outage In-Reply-To: References: <22D5362E-71E7-4290-9937-9CA172D84F97@schallert.com> <5e96625d-feb1-020d-6deb-7def4652542c@UniVie.ac.at> Message-ID: Hallo allerseits, ich bin schon l?nger aus dem Netzwerkmanagement drau?en, aber drei Sachen muss ich loswerden: On 21.12.2020 10:22, Thomas Fritz wrote: > > Ich finde die Tatsache, dass diese St?rung solche Auswirkungen bei > zahlreichen Kunden der national t?tigen Access-Providern hatte, viel > bedenklicher. Es w?re den Internetkunden in ?sterreich zu w?nschen, > dass dieser Zwischenfall die entsprechenden Verantwortlichen zu einem > ?berdenken ihrer Peering Policy anregt. Was wir hier hatten, war eben kein **Ausfall**, sondern eine **St?rung**. Also nicht "Funktioniert perfekt" oder "Ist weg", sondern irgendwas dazwischen. Und das war schon immer nahe am worst-case f?r das Routing: Probleme auf einem Link, aber das Routing-Protokoll merkt das nicht und schickt weiter Pakete dr?ber. Ob die das in einem Peering Fabric, im LAN oder auf einem Backbone Link passiert, ist egal. Da helfen dir Redundanzen, eine andere Peering Policy und auch ein zweiter Exchange Point in ?sterreich rein gar nichts. Weil wenn das Routing-Protokoll die St?rung nicht mitbekommt, warum sollte es die Alternativen nutzen? (Deswegen brachte ja Rene BFD auf: das soll genau diese F?lle adressieren.) Es w?re echt ein interessantes Experiment, den VIX mal bewusst f?r eine Stunde (sauber) abzudrehen um sich anzuschauen, wie sich die Verkehrsstr?me umorientieren. Was davon geht ?ber Upstreams, wie viel wechselt zu Peerings in FRA oder AMS? Oder l?uft eh schon so viel ?ber private Peerings, dass der Impact minimal ist? Tauchen wo Engp?sse auf, mit denen keiner gerechnet hat? Also das ?quivalent zu einem Umschalttest auf USV oder das 2. Rechenzentrum. Das sollte man ja auch immer wieder testen. > Ein zweiter Aspekt dr?ngt sich mir auch noch auf: Wenn der VIX im > Zuge der Netz- und Informationssystemsicherheits-Verordnung vom B?ro > f?r ebendiese Sicherheit des Bundeskanzleramts richtigerweise als > "wesentlicher Dienst" eingestuft wird, wieso wird dann dort nicht > gesehen, dass es doch auch nach einer Redundanz f?r einen solchen > wesentlichen Dienst verlangt? Das ist im NIS Kontext nicht vorgesehen und in vielen Bereichen auch gar nicht machbar. Beispiele: * Stromnetz: von der APG als Backbone bis hin zu den regionalen Verteilnetzbereibern. Wir werden sicher hier keine parallelen Infrastrukturen aufbauen. * Trinkwasser: detto * Erdgas: detto * B?rse: Brauchen wir in AT wirklich eine zweite? * Unter das NISG f?llen auch Beh?rden: brauchen wir ein zweites Au?enministerium? Gesundheitsministerium? Einen zweiten Kanzler? * ... Das Argument kann maximal andersherum funktionieren: Wenn es zu einem Dienst eines Anbieters viele Alternativen gibt, dann ist er nicht so wesentlich. otmar -- // Otmar Lendl - T: +43 1 5056416 711 // CERT Austria - https://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From klaus.darilion at nic.at Fri Jan 22 12:53:31 2021 From: klaus.darilion at nic.at (Klaus Darilion) Date: Fri, 22 Jan 2021 11:53:31 -0000 Subject: [atnog] Routingfrage zu Withdraw Message-ID: <3E18C1A0C550C44DA156DA5DA8ECCC6AB65DA91A@NICS-EXCH2.sbg.nic.at> Hallo Leute! Normalerweise announcen wir an unsere Upstreams nur unser 83.136.32.0/21 Netz. Heute habe ich zu Testzewcken ?ber einer der Transits auch das more specific 83.136.36.0/24 announced. 1. Wie erwartet wurde dann eingehend f?r dieses more specific alles ?ber diesen einen Transit geroutet. Beim announce gab es keine Unterbrechungen. 2. Beim Withdraw sind Traceroutes wie erwartet kreuz und quer zwischen den Tier1 Providern geloopt bis endlich alle Tier1 die more-specific gel?scht hatten und wieder die /21 Route verwendet wurde. Ich h?tte erwartet, dass es 1-2 Minuten dauert bis das /24 aus dem BGP verschwunden ist und die /21 Route verwendet wird. Gedauert hat es aber exakt 363 Sekunden. Dazu meine Fragen: a) Die 363 Sekunden schauen aus, als ob jemand einen "Cache" von 6 Minuten verwendet bis eine Route gel?scht wird. Ist so etwas ?blich? b) W?hrend den 6 Minuten in denen das /24 geloopt hat hatte ich so einen Traceroute von Hetzern zu unserem /24: sb34 (0.0.0.0) Fri Jan 22 11:53:11 2021 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. static.129.98.9.176.clients.your-server.de 0.0% 30 0.4 0.4 0.3 2.2 0.2 2. ??? 3. core5.fra.hetzner.com 0.0% 30 5.1 5.9 4.9 12.7 1.6 4. ffm-b4-link.telia.net 0.0% 30 5.3 5.2 5.0 5.5 0.0 5. ffm-bb2-link.ip.twelve99.net 0.0% 30 16.0 16.0 15.9 16.2 0.0 6. hbg-bb4-link.ip.twelve99.net 0.0% 30 15.9 16.1 15.7 16.9 0.0 7. hbg-b1-link.ip.twelve99.net 0.0% 30 15.6 15.7 15.5 18.2 0.4 8. be3044.rcr11.b015763-1.ham01.atlas.cogentco.com 0.0% 30 16.4 17.8 16.1 24.3 2.3 9. be3221.ccr42.ham01.atlas.cogentco.com 0.0% 30 17.6 16.9 16.3 18.7 0.4 10. be3029.ccr21.prg01.atlas.cogentco.com 0.0% 30 19.1 17.6 16.9 19.4 0.4 11. be3045.ccr22.bts01.atlas.cogentco.com 0.0% 29 24.5 26.6 24.3 55.1 5.9 12. be3463.ccr52.vie01.atlas.cogentco.com 0.0% 29 23.0 23.0 22.2 24.8 0.4 13. et-0-1-4-0-r60.inx.vie.at.nextlayer.net 0.0% 29 23.0 26.1 22.8 51.6 7.6 14. ??? 15. win-b1-link.telia.net 0.0% 29 23.5 24.4 22.9 44.8 3.9 16. win-bb3-link.ip.twelve99.net 0.0% 29 44.2 43.3 32.4 66.9 7.5 17. ffm-bb1-link.ip.twelve99.net 0.0% 29 32.4 32.7 32.3 34.0 0.3 18. hbg-bb3-link.ip.twelve99.net 0.0% 29 33.5 32.9 32.4 34.4 0.2 19. hbg-b1-link.ip.twelve99.net 0.0% 29 35.6 34.4 31.9 40.7 2.4 20. be3044.rcr11.b015763-1.ham01.atlas.cogentco.com 0.0% 29 32.7 33.5 32.5 37.1 0.9 21. be3221.ccr42.ham01.atlas.cogentco.com 3.4% 29 34.2 34.1 32.8 37.2 1.1 22. be3029.ccr21.prg01.atlas.cogentco.com 0.0% 29 36.3 35.3 33.4 42.4 2.0 23. be3045.ccr22.bts01.atlas.cogentco.com 0.0% 29 43.0 42.2 40.9 45.2 1.2 24. be3463.ccr52.vie01.atlas.cogentco.com 0.0% 29 38.9 40.4 38.9 44.9 1.4 25. et-0-1-4-0-r60.inx.vie.at.nextlayer.net 0.0% 29 51.2 45.9 39.2 109.7 14.7 26. ??? 27. win-b1-link.telia.net 0.0% 29 43.2 42.1 39.2 51.3 3.4 28. win-bb3-link.ip.twelve99.net 0.0% 29 53.2 51.1 48.8 59.5 2.6 29. ffm-bb1-link.ip.twelve99.net 0.0% 29 51.3 50.2 48.8 55.7 1.5 30. hbg-bb3-link.ip.twelve99.net 6.9% 29 49.6 50.1 49.0 53.9 1.1 Als Cogent in Hamburg hat sich anscheined die Route lange aufgehoben und dann an Nextlayer weitergeleitet, NExtlayer aber wieder zu Telia. Ansich schon komisch, aber was mich mehr stutzig gemacht hat war der Looking Glass Output von Cogent und NTT: NTT Query Results: Router: Amsterdam - NL Command: show bgp ipv4 unicast 83.136.36.1 BGP routing table entry for 83.136.36.0/24 Versions: Process bRIB/RIB SendTblVer Speaker 193123549 193123549 Last Modified: Jan 22 10:51:25.940 for 00:05:45 Paths: (0 available, no best path) Not advertised to any peer Cogent Fri Jan 22 10:57:43.624 UTC BGP routing table entry for 83.136.36.0/24 Versions: Process bRIB/RIB SendTblVer Speaker 2536606237 2536606237 Last Modified: Jan 22 10:50:45.491 for 00:06:58 Paths: (0 available, no best path) --> Also Cogent und NTT mapped die 83.136.36.1 auf 83.136.36.0/24, hat daf?r aber dann keine Route? Wenn NTT/Cogent keine Route hat, woher wei? der Router dann, dass er 83.136.36.1 auf 83.136.36.0/24 mappen soll? Kennt von euch jemand dieses Verhalten oder kann es erkl?ren? danke Klaus