- swinog - vmaill01.sys

Anyone from Post.ch on this list?
by Benoît Panizzon 02 Feb '23

02 Feb '23

Hi List Failing to sort out an email newsletter issue related to www.swisspost.info with the post.ch customer and IT services. Anyone involved in post.ch newsletter 'services' on this list? Please contact me offlist. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

Neues PeeringDB Objekt carrier // Visualisierung /// New PeeringDb object carrier // Visualization
by Arnold Nipper 02 Feb '23

02 Feb '23

[ English version below ] Hallo Gemeinde, mit Version 2.43.0 vom Mittwoch vergangener Woche hat PeeringDB [0] das neue Objekt "carrier" (Endpunkt /carrier) eingeführt, um damit auch L1- und L2-Dienste abbilden zu können. Das Objekt ist zunächst sehr einfach gehalten. Eine Organisation kann lediglich angeben, dass sie Carrierdienste anbietet und in welchen Colocationen/RZ (Endpunkt /carrierfac) sie vertreten sind. Dazu wird die Zustimmung des RZ-Betreibers benötigt [1]. Sollte das carrier-Objekt auf große Resonanz stoßen, wird PeeringDB das Objekt um spezifische Dienste (DF, Wellen, Ethernet, ...) erweitern. Um als Carrier gelistet zu werden, meldet ihr auch bei PeeringDB als admin an, geht über das Menue rechts oben zu der Organisation, für die ihr den Carrierdienst anlegen wollt und findet im 4. Tab die Maske. Ausfüllen, abschicken, fertig! // Jay Hanke (MICE/QCIX) stellt unter [2] eine KML-Datei zur Verfügung, die alle RZ in PeeringDB mit den IXP und Carriern auflistet. Tolle Sache! Jay schreibt dazu: --- You can create a "Network Link" from inside Google Earth [Pro] and refresh as needed. To create a network link, right click on "My Places" and select new Network Link. In the url use https://qcix.net/map/peeringdb.kml --- Viele Grüße Arnold [0] https://www.peeringdb.com/ [1] derzeit noch buggy, siehe https://github.com/peeringdb/peeringdb/issues/1315, wird umgehend gefixt [2] https://qcix.net/map/peeringdb.kml --------------------- English version Hello community, With version 2.43.0 from Wednesday last week, PeeringDB [0] introduced the new object "carrier" (endpoint /carrier) to be able to map L1 and L2 services with it. The object is initially kept very simple. An organization can only indicate that it offers carrier services and in which colocations/data centers (endpoint /carrierfac) they are represented. This requires the consent of the data center operator [1]. If the carrier object is well received, PeeringDB will add specific services (DF, waves, Ethernet, ...) to the object. To be listed as a carrier, log in to PeeringDB as admin, use the menu at the top right to go to the organization you want to create the carrier service and find the mask in the 4th tab. Fill out, send, and done! // Jay Hanke (MICE/QCIX) provides a KML file under [2] that lists all data centers in PeeringDB with the IXP and carriers. Great thing! Jay writes: --- You can create a "Network Link" from inside Google Earth [Pro] and refresh as needed. To create a network link, right click on "My Places" and select new Network Link. In the url use https://qcix.net/map/peeringdb.kml --- Many greetings Arnold [0] https://www.peeringdb.com/ [1] currently still buggy, see https://github.com/peeringdb/peeringdb/issues/1315, will be fixed immediately [2] https://qcix.net/map/peeringdb.kml -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

Service Provider Network Topologies
by Urs Baumann 18 Jan '23

18 Jan '23

Good day, We want to analyse different network graphs from service providers in a Bachelor Thesis. Would anyone be willing to share the topology? Of course, the data can be anonymised. The students will need to find typical characteristics of service provider networks, and the thesis aims to create new topologies with these characteristics. Attached you can find the own-developed prototype helping to analyse the graph characteristics. Kindes regards, Urs Baumann Network and Research Engineer P central +41 58 257 44 99 P direct +41 58 257 44 84 urs.baumann(a)ost.ch OST – Eastern Switzerland University of Applied Sciences INS – Institute for Network and Security | Oberseestrasse 10 | 8640 Rapperswil | Switzerland | http://www.ost.ch

2 1

Reminder Invitation for Domain Pulse in Winterthur Feb 6./7. 2023
by Michael Hausding 16 Jan '23

16 Jan '23

Dear Swinog list Allow me to remind you for the Domainpulse 2023 on February 6. & 7. In Witherthur. The event is organised by the 3 registries SWITCH (.ch/li), Denic (.at) and nic.at <http://nic.at/> (.at) and focuses on Domain Names. Most of the talks are also interesting for network operators, like the talk from Geoff Houston on measurements or the discussion about fiber ins Switzerland and Liechtenstein. Participation is free and you can register here: https://www.domainpulse.ch/#rsvp <https://www.domainpulse.ch/#rsvp> Hope to see you in Winterthur Michael ------------------------------------ Michael Hausding, Competence Lead DNS & Domain Abuse SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 77, incident phone +41 44 268 15 40 michael.hausding(a)switch.ch <mailto:michael.hausding@switch.ch> http://securityblog.switch.ch <http://securityblog.switch.ch/>

1 0

DNSSEC issue with swizzonic DNS servers?
by Benoit Panizzon 06 Jan '23

06 Jan '23

Hi List Fancy another DNS issue hunt? We have DNSSEC validation enabled on our BIND DNS Servers. We started seeing: no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 2a01:8100:2901::1:183:202#53 no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 2a01:8100:2901::1:183:201#53 no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 81.88.58.219#53 no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 195.110.124.196#53 broken trust chain resolving 'www.numberportability.ch/HTTPS/IN': 2a01:8100:2901::1:183:202#53 broken trust chain resolving 'www.numberportability.ch/AAAA/IN': 2a01:8100:2901::1:183:202#53 client @0x803541d60 X.X.X.X#27325 (www.numberportability.ch): query failed (broken trust chain) for www.numberportability.ch/IN/AAAA at query.c:7724 And of course the query fails, disrupting access some some quite important API. numberportability.ch. 900 IN SOA dns1.swizzonic.ch. hostmaster.swizzonic.ch. 2022121601 10800 3600 604800 86400 $ dig +dnssec RRSIG www.numberportability.ch @dns1.swizzonic.ch ; <<>> DiG 9.16.33-Debian <<>> +dnssec RRSIG www.numberportability.ch @dns1.swizzonic.ch ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 39132 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available So, from my point of view, the authoritative DNS server thinks, this is a recursive query and refuses to answer with the RRSIG, breaking validation of that record. Do you get to the same conclusion? Can you resolve this host via any other DNSSEC validating nameserver? I had no success contacting any technical inclined staff willing to look at the issue since the issue started on 16. December via hostmaster(a)swizzonic.ch by phone or via support(a)register.it. So if anyone from Swizzonic is reading here, it would be nice to get a direct contact to further investigate that issue. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

8 9

Reach Swizzonic Support outside of working hours
by lizzy＠hennig.ch 05 Jan '23

05 Jan '23

Does someone know a way to reach Swizzonic outside their working hours? A Domain of us got deactivated in the evening outside their working hours, event though the bill is paid and wouldn't be due yet. Said domain is used for our dns servers we use for customer...

4 3

urgent swizzonic problem
by Peter Blaser 29 Dec '22

29 Dec '22

Somebody from Swizzonic here ? Please contact me offline Does somebody knows how to contact swizzonic off business hours ?

2 1

DNS contact at Sunrise needed
by Filip Hruška 15 Dec '22

15 Dec '22

Hi there, We are seeing some DNS resolution issues for a specific domain through Sunrise's recursors specifically. Does anyone perhaps have a contact at Sunrise that could be helpful with debugging this please? Already tried normal contact methods listed in PeeringDB etc and have been ignored or told that they don't help non-customers. Regards, Filip

1 0

How to destroy data effectively?
by Martin Ebnoether 07 Dec '22

07 Dec '22

Hi all. As some of you know, I work at a money laund... financial company. Some time ago, the question arose, how to effectively destroy data safely and securely in an easy way? How does your company deal with hard disks (or any media) that needs to be decommissioned? Do you just dd a few times over it? Or rather let a professional company shred your media to little bits? CU, Venty -- 10 PRINT "BASIC programmers don't die." 20 PRINT "They just GOSUB without RETURN." 30 END READY.

11 11

Anyone else having email issues with Metanet?
by Benoît Panizzon 02 Dec '22

02 Dec '22

Hi List Yes, I am already in contact with Metanet techs. We have a very strange issue with two of their email servers. Connecting to Port 25 starts fine. SYN, SYN-ACK but then we start seeing re-transmits until the connections times out. This first happened to one of their server, then to another one, the the first server became reachable again at the beginning of this week, the second one still causes the same problem. The Problem also occurs the other way round. Metanet is unable to establish tcp connection to port 25 on rrmx.imp.ch Is anyone else seeing such an issue, either to metanet or towards our rrmx.imp.ch? Has anyone any clue what could cause such an issue? I compared traces of tcp connections to both of the affected metanet servers, to the working one and to the one causing re-transmits. The two initial SYN and SYN-ACK look identical and then to one destination the re-transmits start and to the other destination I get the SMTP HELO banner. PS: Yes, I did disable the firewall on our mail-plattform and re-test. This does not seem to be the cause. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

Sudden RTT drops after changing fiber OTO plug
by Mat Kowalski 29 Nov '22

29 Nov '22

Hi folks, This is mostly to satisfy my curiosity, but if someone has technical insights I would be more than happy to hear. Background - yesterday my residential Sunrise fiber has changed the OTO plug from #1 to #2 (in Zurich). It's still XGS-PON, it's just that I'm using a different line now. I have a setup that runs a continuous ICMP test towards various targets. I have observed that after changing the fiber plug, all the RTTs suddenly dropped. My guess (may be wrong though) is that with OTO#1 I was connected to a more complex PoP setup than with OTO#2 and this is what reduced the RTT. For interested, here are 3 graphs presenting the drop. For every graph the left side is OTO#1 and the right is OTO#2. Monday morning was the time of changing the line: 1) https://i.ibb.co/qRL1Hyb/1.png 2) https://i.ibb.co/9ZL60KB/2.png 3) https://i.ibb.co/k2YJzJL/3.png Cheers, Mat

3 3

Buried alive in switzerland (long and painfull swiss intel hiccup)
by Catseye Chandra 25 Nov '22

25 Nov '22

Hello swinogers, Here's an update with my swiss intel affair in the field of telecoms. The feds are using IME/TrustZone for "étouffe, écrase d'affaire". I've had a supposed economical warfare act using the latest wifi hole in the linux kernel of mid october, an infiltration using IME on macOS deleting some files and modifying my OCaml compiler, all to prevent information leak about it. BE FRIGHTENED THE ROTTEN COPS ARE REALLY REALLY STRONG IN THIS COUNTRY BWAHAHAHHAAHHH! (do like me, go tell them to fuck off and you'll get a job change for FREE :) It's in french on my website - Google translate is your friend -- Version html disponible sur: http://www.strauss-engineering.ch/posts/sevices.html A noter que je n'ai, matériellement parlant, plus rien. Je vis désormais dans un établissement psycho-social médicalisé, à l'assurance invalidité, poussé par la force des choses, de loin pas par maladie mentale. Mon réseau de relation amicale ne compte plus qu'un à deux amis. 48 ans, pas de femme, pas de gosses, ce contre mon gré aussi. La plus grande partie de mon réseau de relation, essentiellement passé donc, est "réseauté" de manière sécuritaire. Le contact avec mes amis informaticiens m'est factuellement interdit. Le monde des avocats aussi, réseauté activement sur mes traces électroniques (emails, appels téléphoniques). 160 avocats contacté par email, 40 par lettres papier, 6 de visu ou par téléphone, réponses toujours négatives. Etouffe complète, à 100%, en tout cas tentative. Je n'ai jamais détenu le moindre secret, sauf les mots de passe de mon informatique. Aussi je coûte mensuellement plus de 7000.- par mois à la communauté, sans compter, sans connaître le budget de l'étouffe de cette affaire dans laquel je n'ai rien à voir. Probable jeux d'information fallacieux de la part d'enrôlés dans les télécoms il y a de cela plus de 20 ans en arrière. Je demande 3.5mio CHF net d'impôts comme réparation, probablement que l'enveloppe globale concernant l'étouffe de cette affaire est bien plus élevé. Constament des tentatives de petits roquets, petits rats de hiérarchie sécuritaire de me mettre dans une colère noir, afin que j'invective par email, aussi autour de moi voire que j'en arrive aux mains. 3 ans de lavage de cerveau, 3 ans de dépression abyssale, 14 ans de planche à savon, 20 ans à revenir à une forme normale. Pour rien, strictement rien, je n'ai jamais mis les pieds dans un central téléphonique (génération internet). Aussi google semble avoir été contacté afin de retourner très peu de résultat provenant de mon site web. Ne vous gênez pas de communiquer à ce sujet autour de vous. Salutations.

1 0

Fwd: [NLNOG] Voorkom AS-set namespace collisions. AS-A2B vs AS51088:AS-A2B // AS-SET Squatting
by Arnold Nipper 22 Nov '22

22 Nov '22

[ h/t Erik Bais ... helemaal bedankt, Erik! ] Erik hat eine einfache Anleitung, um AS-SET Squatting zu umgehen bzw. auf hierarchische AS-SET zu wechseln * Erstelle einen neuen AS-Set-Namen .. der mit der eigenen AS-Nummer beginnt .... ASNUMBER:<alter AS-Set-Name> * Kopiere alle Informationen darin, die auch im aktuellen (Short) AS-Set enthalten sind * Speichern und überprüfe es in der RIPE DB * Im alten AS-Set .. trägst du eine Referenz ein .. und lässt den Rest leer .. Du bekommst also nur eine Zeile mit Mitgliedern: ASNUMBER:<alter AS-Set-Name> * benachrichtige alle Peers und ändere auch den Eintrag in PeerinDB etc. Viele Grüße Arnold P.S.: Siehe auch https://www.ripe.net/ripe/mail/archives/routing-wg/2022-November/004649.html ff -------- Weitergeleitete Nachricht -------- Betreff: [NLNOG] Voorkom AS-set namespace collisions. AS-A2B vs AS51088:AS-A2B Datum: Fri, 18 Nov 2022 13:02:28 +0000 Von: Erik Bais <erik(a)bais.name> An: nlnog(a)nlnog.net <nlnog(a)nlnog.net> Ollah, Er loopt momenteel bij de RIPE Database Working group ( DB-WG ) een discussie <https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html> waarbij de AS-Set name misbruikt kan worden, omdat de normale short notatie zoals ( AS-A2B ) bij het aanmaken van een ‘nieuwe’ short as name, geen authorisatie vereist in referentie naar een origineel of naar een eigenaar van een netwerk. Nu is er een optie om je AS nummer als authorisatie te gebruiken .. en dan moet je dus je AS set naam aanpassen .. in <ASnummer>:<AS-set naam> Dit is al misbruikt in de afgelopen weken.. waarbij een of andere leukerd in de RIPE Database een AS-Set aangemaakt had met een naam AS-<grote cloud provider> .. Aangezien hun normaal hun AS-Set bij een andere database bijhielden, hadden ze hierdoor opeens een AS-Set name collission .. met als resultaat .. dat alle partijen die bijvoorbeeld bgpq4 gebruiken om de prefixfilters te maken, een lege prefixfilter als resultaat set kregen .. omdat ze tegen de lege AS set in de RIPE db aanliepen ..en daarna exit. Het is dus sterk aan te raden om de ‘long’ AS-Set notatie te gaan gebruiken voor je eigen (en je klanten) hun bereikbaarheid. Wat je nu binnen een paar minuten kan doen is: Creëer een nieuwe AS-Set naam .. die begint met je eigen AS nummer …. ASNUMMER:<oude AS set naam> Kopieer daar alle informatie in, die ook in je huidige (Short) AS-Set staat.. Bewaar en check die dan even in de RIPE DB. ( A2B voorbeeld : https://apps.db.ripe.net/db-web-ui/query?searchtext=as51088:as-a2b <https://apps.db.ripe.net/db-web-ui/query?searchtext=as51088:as-a2b> ) In de oude AS-Set .. zet je 1 verwijzing in .. en de rest laat je leeg .. Dus je krijgt dan alleen een regel met .. members: ASNUMMER:<oude AS set naam> ( Voorbeeld van AS-A2B - https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true… <https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true…> ) En bij peeringdb : zet je de nieuwe AS set naam (ASNUMMER:<oude AS set naam>) .. en wil je het helemaal fancy doen .. dan doe je RIPE:: ASNUMMER:<oude AS set naam> Als je RIPE:: ervoor zet, dan is dat een referentie naar in welke RIR DB je AS-Set te vinden is .. ( voorbeeld in PeeringDB : https://www.peeringdb.com/net/3237 <https://www.peeringdb.com/net/3237> ) Daarna is het handig om ook je AS object even een update te geven .. En loop even overal na, dat je je nieuwe AS-Set in je export regels hebt staan.. zoals : * remarks: Transits * remarks: ============================================================ * import: from AS2914 action pref=100; accept ANY AND NOT {0.0.0.0/0} * export: to AS2914 announce AS51088:AS-A2B * import: from AS3257 action pref=100; accept ANY AND NOT {0.0.0.0/0} * export: to AS3257 announce AS51088:AS-A2B Mocht je dat bij peers / klanten of internet exchanges ook hebben staan.. rinse & repeat .. you know the drill. ( Voorbeeld AS51088 - https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true… <https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true…> ). Het is een pleister tegen een mogelijk issue .. maar wel handig om dit correct te fixen .. waar je later veel plezier van kan hebben .. dus doe er je voordeel mee. Die fix die er besproken wordt in de RIPE DB WG, zorgt er voor dat er geen nieuwe AS-Sets met een short notatie aangemaakt kunnen worden. Maar verhelpen is beter dan genezen. Alvast prettig weekend, Groetjes, Erik Bais -- Keep calm, keep distance, keep connected! Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 0

Netbox or similar DCIM consulting/services
by Olaf 22 Nov '22

22 Nov '22

Hi, I am looking for someone that offers/provides consulting/services around Netbox or similar DCIM software for Staging/PoC for engineering before we would handover towards operations at my current employer. Gladly off-list via olaf.baumert(a)wz.axpo.com Sorry for the noise everyone not interested. Kind regards, Olaf

1 1

SWINOG Beers - Zurich, 1st December 2022
by Massimiliano Stucchi 15 Nov '22

15 Nov '22

Hi everyone, following the event from last week in Geneva, we are now organising swinog beers in Zurich for the 1st of December. We will be meeting at Paddy Reilly's (https://goo.gl/maps/M4Qqvka1FaE1yX1A7) at 17:30 on Thursday, December 1st. Everyone is welcome and there's no need to pre-register, although if you send me an email to let me know of your intentions, it will help in understanding how big of a group we will be. The formula is simple: just show up and enjoy meeting other networkers. Everyone pays for his/her own drinks and food. For any question, please feel free to get in touch with me. I hope to see many of you at the event! Ciao! -- Massimiliano Stucchi MS16801-RIPE Twitter: @stucchimax Telegram: https://t.me/stucchimax

1 0

SWINOG Beers - Geneva 10th November
by Massimiliano Stucchi 04 Nov '22

04 Nov '22

Hi everyone, together with Will (PorCus), and after some discussions in Belgrade at RIPE85 last week, we have decided to organise some "Swinog Beers" in Geneva on the 10th of November. We will be meeting at Mulligan's (https://goo.gl/maps/VYm7T8P9uQ2dCTqs8) at around 17:30 on Thursday. Everyone is welcome and there's no need to pre-register, although if you send me an email to let me know of your intentions, it will help in understanding how big of a group we will be. The formula is simple: just show up and enjoy meeting other networkers. Everyone pays for his/her own drinks and food. For any question, please feel free to get in touch with me. I hope to see many of you next week! Ciao! PS: We will have a similar event in Zurich in a few weeks -- Massimiliano Stucchi MS16801-RIPE Twitter: @stucchimax Telegram: https://t.me/stucchimax

1 0

Is AS203790 reading this list? (up-network.ch)
by Benoît Panizzon 31 Oct '22

31 Oct '22

Hi If so, could you please contact me off-list (attempted your abuse desk last week) regarding either a joe-job against your company, or a real incident where our customer involved is hiding his IP in our network behind cloudflare. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

4 4

Server racks abzugeben / server cabinets available
by juergen＠jaritsch.at 21 Oct '22

21 Oct '22

Servus die Runde, wir bauen derzeit einen unserer Cages im Interxion ZUR1 um und haben dadurch einen kompletten Kaltgang abzugeben: 16 Stk 47U 800x1000 Minkels Racks Türen an der Rückseite Keine Trennwände (gibt es nach wie vor von Minkels direkt!) Keine Türen an der Front Kaltgang Dach Doppelte Schiebetüre an der Stirnseite Zweite Stirnseite offen Das System ist derzeit noch vollständig aufgebaut und kann auch besichtigt werden. Preis-Vorschläge gerne per Mail - wir stellen uns etwa 7000 CHF für die komplette Anlage vor. Per sofort verfügbar. Fotos: https://cloud.jaritsch.at/index.php/s/TJB3Z5RyEbYqyfN?path=%2F Weitere Details bzw Besichtung bitte direkt per Mail mit mir ausmachen. Danke & viele Grüße Jürgen #### Dear colleagues, we do rebuild one of our cages at Interxion ZUR1. Therefore we do have the below cold corridor containment available: 16 pcs 47U 800x1000 Minkels Racks Doors at the rear no slide-in walls between the cabinets (available from Minkels!) No doors at the front Cold corridor roof Sliding doors at the entrance of the roof No wall at the tail end System is still installed and can be reviewed in the datacenter. Price-discussions by email - we do guess to achieve something like 7000 CHF for the whole thing (16 racks incl cold corridor, etc). Counter offers are welcome! The system is immediately available. Pcitures: https://cloud.jaritsch.at/index.php/s/TJB3Z5RyEbYqyfN?path=%2F More details and discussion: please send me an email. thanks & best regards Jürgen

1 1

Detecting, mitigating, and preventing distributed large-scale prefix de-aggregation attacks
by Lars Prehn 21 Oct '22

21 Oct '22

Dear SwiNOG, Our apologies to those who received this message via multiple channels. My colleagues and I recently revisited the topic of prefix de-aggregation attacks. We believe that the current IPv6 allocation policies combined with the ever-growing number of interconnection opportunities may facilitate those attacks to the point where they may circumvent traditional prevention mechanisms. Hence, we'd like to raise awareness on how to detect, mitigate, and prevent these kinds of attacks. # Prefix De-aggregation Attacks While allocation policies in IPv4 are very tight, even a new LIR can obtain, e.g., a /29 IPv6 address block from RIPE without justification [1]. This /29 may source more than a million unique IPv6 prefixes when using all CIDR sizes between /29 and /48 (the largest CIDR size that is not filtered). To prevent this many prefixes from flooding the DFZ, many ASes set a maximum prefix limit on their eBGP sessions. When initially introduced, these max-prefix limits prevented prefix de-aggregation attacks. In today's hyper-connected world, prefix limits transform these attacks into session-hunting challenges. To better illustrate this relationship, consider the following example: If an adversary combines two remote-peering offerings of BSO's IXReach [2] and Epsilon's Infinity Platform [3], they can establish ports at more than a hundred peering LANs. If this adversary uses Hurricane Electric as their IPv6 transit provider and establish a BGP session at every in-common peering LAN [4], this will lead to 100+ sessions. With a per-session limit of e.g. 500 prefixes, the adversary could redistribute 50K unique prefixes via this setup alone. If an adversary further increases the number of remote peering providers, adds announcements from BGP-enabled VPS services (e.g., Vultr [5] among many others [6]), and contracts additional IPv6 transit providers, they may globally increase the current IPv6 routing table size manifold. Notably, each of these new routes would have a valid ROV status once the adversary adds a single ROA entry for a /29 with a max CIDR size of /48; hence, they would pass the redistribution requirements for various transit providers. While many current router models support multiple million IPv6 routes, especially older models may crash, drop sessions, or behave in other unintended ways when either their FIB or RIB runs out of memory. When the adversary also withdraws all routes simultaneously, the number of updates generated from BGP's path-hunting may further lead to very high load for extended periods of time. To put this into perspective: Some of you might have noticed increased CPU load alongside other effects when Vultr was de-aggregating 12k IPv6 prefixes on October 5th [7]. Using the different methods described above, an highly-motivated adversary might be able to produce 1-2 orders of magnitude more updates. Please note that we performed various smaller (<600 prefixes) de-aggregation tests as part of our research---see sections 6 and 8 in the document referenced at the end of this notification for detailed explanations. While our experimental setup was very similar to the October 5th incident (we also announced address space obtained from SecureBit via VMs within Vultr), we are in no way related to that incident neither did we share any information about our research or findings with individuals outside our research group prior to the start of our private disclosure phase on October 11th. # Detection, Mitigation, and Prevention Mechanisms. Luckily, prefix de-aggregation attacks are easily detectable (e.g., based on prefix-limit notification thresholds or direct routing table size monitoring) and can be mitigated quickly by filtering either the more specifics of the covering prefix or all prefixes announced by the adversary's ASN(s). Effectively, damage can only be done within the human reaction time---which we hope to shorten with this notification. To protect yourself from prefix de-aggregation attacks, you may establish dynamic yet tight per-session limits on all eBGP sessions. As an adversary could enter unreasonably large values into databases such as PeeringDB, we'd recommend to not solely rely on them but also accept at most 1.5-2x the number of yesterday's prefixes for peers and customers and 1.2x yesterday's routing table size for transit providers (which would currently reflect a headroom of ~32k prefixes with a yearly growth rate of <50k prefixes [8]). We'd also recommend ensuring that the summed prefix limits across all sessions do not drastically exceed the router's maximal FIB size. To protect others, you may: (i) ensure that you only redistribute a certain number of routes per origin; currently, AS 9808 announces the most (~4K) IPv6 prefixes. (ii) ensure that you only redistribute a certain number of more-specific routes for each assigned address block; currently, 2409:8000::/20 is the prefix with the most (~10K) more-specifics. If you want to know more about the research that initiated this notification (including our concluded private disclosure process), you may find a write-up at: https://arxiv.org/pdf/2210.10676.pdf Best regards, Lars [1] https://www.ripe.net/publications/docs/ripe-738#initial_size [2] https://www.ixreach.com/services/remote-peering/ [3] https://epsilontel.com/global-network-footprint/internet-exchanges/ [4] https://he.net/peering.html [5] https://www.vultr.com/features/advanced-networking/ [6] https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6… <https://docs.google.com/spreadsheets/d/1abmV_mXWWCsVxHLfouSivyS7ch-PcUww8S6…> [7] https://twitter.com/Qrator_Radar/status/1577748939805278209 [8] https://bgp.potaroo.net/v6/as2.0/index.html

1 0

Re: MaxMind location determination (was: Contact: geoiplookup.net)
by Jeroen Massar 20 Oct '22

20 Oct '22

Hi, If you configure it (remarks and/or geofeeds: attribute in whois), they will come. I see a bit below a thousand IPs fetching my geofeed data over the last few days Quick grep (with some filtering due to versions etc) of UAs; see below; quite some normal web crawlers, but also dedicated it seems. Note that like anything, geofeed is just an indicator, somebody might use or not use it. Many build precise geoloc based of physical orders and/or GPS in mobile phones, thus depending on users logging in to certain websites or ordering things and having GPS enabled for that site... Greets, Jeroen -- "APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)" "CheckMarkNetwork/1.0 (+http://www.checkmarknetwork.com/spider.html)" "Crawlbot/Nutch-1.19-SNAPSHOT" "Go-http-client/2.0" "IonCrawl (https://www.ionos.de/terms-gtc/faq-crawler-en/)" "Ipregistry/2.0.0 (geofeeds; +https://ipregistry.co)" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; +http://www.komodia.com/newwiki/index.php/URL_server_crawler) KomodiaBot/1.0" "Mozilla/5.0 (compatible; Adsbot/3.1; +https://seostar.co/robot/)" "Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)" "Mozilla/5.0 (compatible; Barkrowler/0.9; +https://babbar.tech/crawler)" "Mozilla/5.0 (compatible; Crawlson/1.0; +https://www.crawlson.com/search?q=site:as57777.net)" "Mozilla/5.0 (compatible; DataForSeoBot/1.0; +https://dataforseo.com/dataforseo-bot)" "Mozilla/5.0 (compatible; Dataprovider.com)" "Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help(a)moz.com)" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help(a)moz.com)" "Mozilla/5.0 (compatible; EntferBot/0.1; +https://entfer.com; +a_new_independent_search_engine;)" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "Mozilla/5.0 (compatible; Linespider/1.1; +https://lin.ee/4dwXkTH)" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)" "Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +http://megaindex.com/crawler)" "Mozilla/5.0 (compatible; SeznamBot/4.0-RC1; +http://napoveda.seznam.cz/seznambot-intro/)" "Mozilla/5.0 (compatible; TorusBot/1.0; +https://torus.company/bot.html)" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" "Mozilla/5.0 (compatible; Yeti/1.1; +http://naver.me/spd)" "Mozilla/5.0 (compatible; ips-agent)" "Python/3.9 aiohttp/3.8.1" "Slackbot-LinkExpanding 1.0 (+https://api.slack.com/robots)" "Wget/<various>" "axios/0.27.2" "clark-crawler2/Nutch-1.19-SNAPSHOT" "colly - https://github.com/gocolly/colly/v2" "curl/<various>" "db-ip "libwww-perl/6.42" "ltx71 - (http://ltx71.com/)" "netEstate NE Crawler (+http://www.website-datenbank.de/)" "python-requests/2.22.0" "serpstatbot/2.1 (advanced backlink tracking bot; https://serpstatbot.com/; abuse(a)serpstatbot.com)" "x28-job-bot; +http://x28.ch/bot.html" > On 17 Oct 2022, at 11:39, Fredy Kuenzler <kuenzler(a)init7.net> wrote: > > I think that the RFC8805 approach is the way to go for the industry, however I wonder which ISP is already using it in real life today. I couldn‘t find much about it besides the slides of RIPE81. > > We see GeoIP complaints of end customers on a regular basis and it would be nice if RFC8805 could solve the problem. > > https://ripe81.ripe.net/presentations/27-RIPE81_geofeeds_discovery.pdf > 27-RIPE81_geofeeds_discovery > PDF-Dokument · 2.3 MB > > > -- > Fredy Künzler > > Init7 (Switzerland) Ltd. > Technoparkstrasse 5 > CH-8406 Winterthur > https://www.init7.net/ > > <(null).(null)>_______________________________________________ > swinog mailing list -- swinog(a)lists.swinog.ch > To unsubscribe send an email to swinog-leave(a)lists.swinog.ch

2 1

Contact: geoiplookup.net
by Benoit Panizzon 20 Oct '22

20 Oct '22

Hi Swinogers Does anyone know who operates geoiplookup.net and how to contact them? They repeatedly put parts of our IP ranges into Germany creating vast service disruptions for our affected customers by Swiss service providers that use their API for GeoBlocking. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

8 10

switch started blocking whois queries?
by Benoit Panizzon 17 Oct '22

17 Oct '22

Hi Gang From three different IP Addresses I get: Requests of this client are not permitted. Please use https://www.nic.ch/whois/ for queries. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 4

DNS help: named 'end of file resolving' a hostname.
by Benoît Panizzon 17 Oct '22

17 Oct '22

Hi Team Maybe some of you has already come over that issue and know how to fix. Bind 9.18.4 fails to resolve the A record of: fd19g0409.drive.pro.io Bind 9.11.36 works. Both versions have DNSSEC Validation enabled and connected to a network not restricting EDNS. Bind Logs: named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53 Dr. Google does not spit out any useful answer to this error. Analyzing the traffic with Wireshark, shows the authoritative server for this domain is answering and nothing jumps to my eye which could be wrong with the answer I see in the trace. I guess _.drive.pro.io is a dummy query performed to get OPTIONS. So my usual attempt is to disable all options that might cause issues: $ dig +noedns +nocookie +nodnssec +noednsnegotiation A fd19g0409.drive.pro.io @{BIND-9.18.4-NS} Error persists. Any help appreciated in a pointer to the possible cause. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

4 4

Looking for /22 PA Space
by Matias Meier 14 Oct '22

14 Oct '22

Hello colleagues If anyone of you would like to sell a clean /22 IPv4 PA network, please reach out to me off list with your asking price. Thank you and have a nice day and soon, a nice weekend. Greetings Matias

1 0

DEC-IX buy SwissIX?
by peerwithme 13 Oct '22

13 Oct '22

Today news is DE-CIX buy of SwissIX Why that is not consulted to the members? Why that is plan? Job of Rémy? Port price raise? garantie no price raise? DE-CIX is €€€€€€€€€ for small swiss network! DE-CIX = profit SwissIX = verein how is possible?

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog