Dear all,
this is the Call for Presentations for the European Peering Forum 2023.
AMS-IX, DE-CIX, LINX, NETNOD and guest IXP NIX.CZ, are happy to host the
European Peering Forum (EPF) 2023 from Sunday the 10th to Wednesday 13th
September 2023 in Prague, Czech Republic.
The event will welcome peering managers and coordinators from networks
connected to the host and guest Internet exchanges.
Besides some interesting topical agenda, the three-day event
accommodates room for attendees to meet on a one-to-one basis to discuss
bilateral peering business opportunities.
The programme committee will be looking for presentations and related to
peering and technical topics of interconnection. Your presentation
should address:
* Interconnection Automation
* Regional Peering
* Interconnection / Peering Internet Governance and Regulatory Topics
* Economic and Product Trends
* Peering / Interconnection strategies
* Interesting findings about Peering / Interconnection
* 400GE and beyond
* Any other hot topic related to Interconnection / Peering
Submissions
===========
Presentations must be of a non-commercial nature. Product or marketing
heavy talks are strongly discouraged.
Submissions of presentations should be made to the programme committee
<epf-pc(a)peering-forum.eu>. Please include:
* Author's name and e-mail address
* Presentation title
* Abstract
* Slides (if available)
* Time requested (max. 30 minutes incl. Q&A)
Deadlines
=========
Please send in your presentation asap. We decide on a first come first
serve basis. The latest date for submission is July 30th, 2023.
More information about the event and other activities around EPF16 may
be found at
* https://peering-forum.eu/2023/
* https://www.facebook.com/groups/1486607564933665/
On behalf of EPF,
Best regards,
AMS-IX, DE-CIX, LINX and NETNOD
--
Keep calm, keep distance, keep connected!
Arnold Nipper
email: arnold(a)nipper.de
mobile: +49 172 2650958
Hey all
A friend just told me that Cybernet told him there is a Switzerlandwide Internet Problem.
Does anybody know something?
Cheers
Michele
--------
Online Consulting AG, Michele Capobianco, System Administrator, Weststrasse 38, CH-9500 Wil
Phone +41 (0)71 913 31 31, Fax +41 (0)71 913 31 32
http://www.online.ch, michele.capobianco(a)online.ch<mailto:michele.capobianco@online.ch>
--------
Hello
Curious about the «best practice» you use for IPv6 gateways in server config / datacenter.
Votes for static gateway settings on servers? Or do you use IPv6 nd/ra? Or perhaps DHCPv6?
Regards, Urs
SBB AG
Cyber Security
Cyber Defense Center
Poststrasse 6, 3072 Ostermundigen
Mobil +41 79 433 21 67
urs.bf.mueller(a)sbb.ch<mailto:urs.bf.mueller@sbb.ch> / www.sbb.ch<http://www.sbb.ch>
(Resend von der richtigen Absender-Adresse)
https://www.haaretz.com/israel-news/security-aviation/2023-05-10/ty-article…
The Secretive Swiss Dealer Enabling Israeli Spy Firms
(…)
It leads from the Americas to Africa to South-East Asia, but also to Basel, a mediaeval town on the banks of the Rhine and the unassuming home of Andreas Fink, a Swiss telecom expert whose unusual skills have placed him at the centre of this industry.
(…)
reveal how Fink's systems have served as a conduit for probing and attacking phone networks across the globe
(…)
When contacted by this investigation, Fink admitted to working with companies and “legally entitled government agencies” as a provider of surveillance services.
(…)
Fink's request to Robert was for "SS7 access" and "a bunch of global titles". In other words, he wanted a list of phone numbers, belonging to Robert's phone company, which could be used to send queries to other networks in other countries.
(…)
--
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matthias(a)leisi.net <mailto:matthias@leisi.net>
Hmm, instead of securing their networks and pushing for better security standards they'll cut access to one fish. Is that an ideal strategy? Some other bigger meaner fish will still use those vulnerabilities.
I was wondering if the GSMA is or should regularly perform security audits.
https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
Or perhaps award publicly visible badges of honor to those mobile networks that are not vulnerable to similar attacks.
I mean how many companies do we know? that publicly stated: Hello our mobile users btw. we fixed those vulnerabilities in our network! You should now be better protected.
I never got any such information from any of my providers. Did you?
Beste Grüsse, Regards si s-auzim de bine
Florin Sfetea
On Friday, May 19, 2023, 12:00:21 PM GMT+2, <swinog-request(a)lists.swinog.ch> wrote:
Send swinog mailing list submissions to
swinog(a)lists.swinog.ch
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
swinog-request(a)lists.swinog.ch
You can reach the person managing the list at
swinog-owner(a)lists.swinog.ch
When replying, please edit your Subject line so it is more specific
than "Re: Contents of swinog digest..."
Today's Topics:
1. Re: Sicherheit von SS7 - mit Schweiz-Bezug (Ralph Krämer)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 May 2023 22:33:17 +0200 (CEST)
From: Ralph Krämer <ralph.kraemer(a)vable.ch>
Subject: [swinog] Re: Sicherheit von SS7 - mit Schweiz-Bezug
To: swinog <swinog(a)lists.swinog.ch>
Message-ID: <172298345.199.1684441997706.JavaMail.zimbra(a)vable.ch>
Content-Type: text/plain; charset=utf-8
nice : https://www.spiegel.de/netzwelt/netzpolitik/andreas-fink-mobilfunkverband-g…
about time ;-)
----- Am 15. Mai 2023 um 13:31 schrieb Florin Sfetea via swinog swinog(a)lists.swinog.ch:
> Hello all,
>
> I was reading this old(2018) ENISA Report [
> https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
> |
> https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
> ]
> Might help in some way but reading it had reminded me of ARP spoofing/poisoning
> attacks which even today are still used and work in a lot of networks that I
> have been. :)
>
> One year later I had open a case with Salt where I requested a public statement
> that they had fixed/mediated the issues discovered up to that time(March 2019)
> or at least that a remediation plan was in place.
>
> Someone from Support answered that " The introduction of 5G will only take place
> if data security is guaranteed for our customers and we can assume that the
> security issue will not lead to a delay in the introduction of 5G. "
>
> I was not satisfied ::)) with the answer and requested an escalation
>
> They eventually closed my case in July 2019 with:
>
> " Dear Sir,
>
>
> Salt follows industry best practices in terms of security for its entire mobile
> infrastructures and improves constantly the protection of its mobile
> infrastructures and customers. The case you mention is known and has been
> addressed accordingly.
> "
> No public statement nor such other mentions of which fix was exactly addressed.
>
> I don't have anything with any mobile provider. At that time it was just happen
> to be Salt. I move from time to time to different other ones.
>
> I think we should have here in Switzerland more or less a same similar to ENISA
> organization that should supervise and perform regular audits on mobile
> providers. Melani/NCSC would that fit your bill?
>
> I never really had time to further test if any of those vulnerabilities or newer
> where actually fixed. Someone should definitely do it. Free for fame or payed
> from a government branch is to
> [ https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
> | https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
> ]
>
>
> Regards,
> Florin
>
> _______________________________________________
> swinog mailing list -- swinog(a)lists.swinog.ch
> To unsubscribe send an email to swinog-leave(a)lists.swinog.ch
------------------------------
Subject: Digest Footer
_______________________________________________
swinog mailing list -- swinog(a)lists.swinog.ch
To unsubscribe send an email to swinog-leave(a)lists.swinog.ch
------------------------------
End of swinog Digest, Vol 219, Issue 11
***************************************
Hello all,
I was reading this old(2018) ENISA Report https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
Might help in some way but reading it had reminded me of ARP spoofing/poisoning attacks which even today are still used and work in a lot of networks that I have been. :)
One year later I had open a case with Salt where I requested a public statement that they had fixed/mediated the issues discovered up to that time(March 2019) or at least that aremediation plan was in place.
Someone from Support answered that "The introduction of 5G will only take place if data security is guaranteed for our customers and we can assume that the security issue will not lead to a delay in the introduction of 5G."
I was not satisfied ::)) with the answer and requested an escalation
They eventually closed my case in July 2019 with:
"Dear Sir,
Salt follows industry best practices in terms of security for its entire mobile infrastructures and improves constantly the protection of its mobile infrastructures and customers. The case you mention is known and has been addressed accordingly.
"
No public statement nor such other mentions of which fix was exactly addressed.
I don't have anything with any mobile provider. At that time it was just happen to be Salt. I move from time to time to different other ones.
I think we should have here in Switzerland more or less a same similar to ENISA organization that should supervise and perform regular audits on mobile providers. Melani/NCSC would that fit your bill?
I never really had time to further test if any of those vulnerabilities or newer where actually fixed. Someone should definitely do it. Free for fame or payed from a government branch is to
https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
Regards,
Florin
Hello
One of my clients got a problem to receive mails from one customer.
He sends mails from its system through isis.servercorner.net and the mailserver refuses to accept the mail with a «no such mailbox» answer.
But the mailserver should not look for the mailbox but forward to M365.
We suspect a wrong mx in the dns of servercorner.net.
When we look into the mx of the customer, it looks like:
dig mx 4plusarchitektinnen.ch +short
0 4plusarchitektinnen-ch.mail.protection.outlook.com.
dig 4plusarchitektinnen-ch.mail.protection.outlook.com +short
104.47.22.10
104.47.22.74
The customer was on a hosting somewhere inside servercorner.net and we suspect there are leftovers.
Anybody here from servercorner.net? How to contact?
Regards, Urs
Hi,
The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to APNIC:
151866-152889 Assigned by APNIC 2023-05-10
152890-153913 Assigned by APNIC 2023-05-10
You can find the registry at:
https://www.iana.org/assignments/as-numbers/
The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries:
https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en
Best Regards,
Selina Harrington
IANA Operations Manager