swinog

swinog@lists.swinog.ch

2933 discussions

Fwd: BGP Experiment
by Steven Glogger 23 Dec '18

23 Dec '18

fyi > Von: Arnold Nipper <arnold(a)nipper.de> > Datum: 23. Dezember 2018 um 08:16:51 MEZ > An: DENOG <denog(a)lists.denog.de> > Betreff: Wtr:⁨ BGP Experiment⁩ > > Erholsame Feiertage und viele Grüße > Arnold > > > -------- Weitergeleitete Nachricht -------- > Betreff: BGP Experiment > Datum: Tue, 18 Dec 2018 10:05:26 -0500 > Von: Italo Cunha <cunha(a)dcc.ufmg.br> > An: NANOG <nanog(a)nanog.org>, DISCO experiment mailing list > <disco-experiment(a)googlegroups.com> > > NANOG, > > We would like to inform you of an experiment to evaluate alternatives > for speeding up adoption of BGP route origin validation (research > paper with details [A]). > > Our plan is to announce prefix 184.164.224.0/24 with a valid > standards-compliant unassigned BGP attribute from routers operated by > the PEERING testbed [B, C]. The attribute will have flags 0xe0 > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > development), and size 0x20 (256bits). > > Our collaborators recently ran an equivalent experiment with no > complaints or known issues [A], and so we do not anticipate any > arising. Back in 2010, an experiment using unassigned attributes by > RIPE and Duke University caused disruption in Internet routing due to > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > attributes have been assigned (BGPsec-path) and adopted (large > communities). We have successfully tested propagation of the > announcements on Cisco IOS-based routers running versions 12.2(33)SRA > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > 1.6.3. > > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > predefined period of 15 minutes starting 14:30 GMT, from Monday to > Thursday, between the 7th and 22nd of January, 2019 (full schedule and > locations [E]). We will stop the experiment immediately in case any > issues arise. > > Although we do not expect the experiment to cause disruption, we > welcome feedback on its safety and especially on how to make it safer. > We can be reached at disco-experiment(a)googlegroups.com. > > Amir Herzberg, University of Connecticut > Ethan Katz-Bassett, Columbia University > Haya Shulman, Fraunhofer SIT > Ítalo Cunha, Universidade Federal de Minas Gerais > Michael Schapira, Hebrew University of Jerusalem > Tomas Hlavacek, Fraunhofer SIT > Yossi Gilad, MIT > > [A] https://conferences.sigcomm.org/hotnets/2018/program.html > [B] http://peering.usc.edu > [C] https://goo.gl/AFR1Cn > [D] > https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experim… > [E] https://goo.gl/nJhmx1 > > -- > Arnold Nipper > email: arnold(a)nipper.de > mobile: +49 172 2650958 >

1 0

Byebye SwissIX, hello Equinix Zurich Exchange
by Fredy Kuenzler 21 Dec '18

21 Dec '18

More than 10 years ago Init7 unplugged from the Exchange formerly known as TIX Telehouse Internet Exchange in Zurich. When we decided to do this, it was evident that SwissIX was offering much more value for money, in fact, SwissIX offered ports without recurring monthly fees. SwissIX was completely community driven and a lot of volunteer work made it happen. The fact of free ports made SwissIX big in the number of participants. (Disclaimer: I was president of the SwissIX association between 2004 and 2009). This has changed. The SwissIX association decided to charge for ports above 1 Gigabit a few years ago, in order to renew the infrastructure and to pay a salary for operations (to my knowledge SwissIX pays one part time employee). I respect that decision, while I was not supporting it. Consequently Init7 downgraded to 1 Gigabit then and did not accept new peers ever since. The price for a 10 Gigabit port apparently was lowered recently to CHF 750 per month. Which sums up to CHF 9000 per year. The 2nd port is cheaper: CHF 400 per month. Details can be found here: https://www.swissix.ch/participation I made a quick count of the ports and found ~100 ports with 10 Gigabit and two 100 Gigabit ports (according to PeeringDB). Assuming that 50% are secondary ports a quick estimate of the association revenue adds up to this sum: 50* CHF 750 = CHF 450000 50* CHF 400 = CHF 240000 2* CHF 2600 = CHF 62400 Total ≃ CHF 750000 per year, not including membership fees I suppose that this amount is sufficient to buy the complete equipment required to operate the SwissIX peering mesh twice a year (yes, gear gets cheaper these days; though it's an absurd example) and still includes the salary of the one part time employee. Since such a charging and revenue scheme is in force for several years I suppose SwissIX has accumulated a seven-digit fortune. However it seems that no one really knows about it, as the association of SwissIX didn't make financial reports accessible on the website (I assume they have been presented on the yearly General Meetings only, though it's not possible for all association members to be part of it). So the question remains for many of us: Where did the money go? SwissIX is hardly visible in the international community, so I guess "money was spent for Marketing" is not a valid answer. SwissIX port fees are today among the most expensive in Europe (not including any membership fees), and all of these Exchanges are way bigger in terms of traffic and marketing efforts: LINX 750£ + 424£ (1st, 2nd) AMS-IX 720€ DE-CIX - no price list published anymore, depends on your negotiation skills... Equinix Paris: €400 MIX Milano €750 which includes 1/3 cabinet and power SwissIX claims to be "Not for Profit". Equinix, in contrary, is listed on the stock market. Still, the first 10 Gigabit port on Equinix Zurich Exchange costs CHF 400 per month and includes a cross connect. That's about half of the cost of the Not-for-Profit SwissIX. More than 10 years ago, Init7 unplugged from the Exchange formerly known as TIX Telehouse Internet Exchange in Zurich. Now we are reverting this decision, as preconditions have reverted too. Init7 has cancelled it's membership of the SwissIX association to the end of 2018 and will unplug the remaining 1 Gigabit port anytime soon. We are happy to accept new peering sessions at Equinix Exchange Zurich as long as the requirements are met (no peering with customers or customers of customers). We are also happy to accept new PNI peers in any common location, if resources are available. Please send inquiries to peering at init7 dot net. Happy Peering and good luck, SwissIX. PS. some useful URLs: History of SwissIX: https://www.swissix.ch/about Where it all started - SwiNOG 1: https://www.swinog.ch/meetings/swinog1/ -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 Technoparkstrasse 5 CH-8406 Winterthur http://www.init7.net/

2 1

SwiNOG #34 – first videos published
by Steven Glogger 16 Dec '18

16 Dec '18

Hi everybody, As announced at SwiNOG #34 we we're recording the presentations and I'm glad to announce that first two Videos are published. Link to the presentation & video: http://www.swinog.ch/meetings/swinog34/ Youtube-Playlist for SwiNOG #34 https://www.youtube.com/playlist?list=PLMP2Spqss4Ipu2bEWyqnHPDziyK74uoi0 SwiNOG Channel: https://www.youtube.com/channel/UCNc3EckU23H4rXn_SdgpTUw We release more videos in the next weeks. Please note that we're not announcing every video on the mailinglist. Simply use the playlist, subscribe to the youtube channel or follow us on twitter. greetings -steven SwiNOG Core Member

2 2

How do website operators get the mobile phone number of visitors?
by Benoit Panizzon 07 Dec '18

07 Dec '18

Hi List I have read: https://nakedsecurity.sophos.com/2012/01/25/smartphone-website-telephone-nu… And I have sniffed the traffic between my swisscom mobile Samsung Mobile and my Website, but can't find any of the additional headers disclosing my phone number. Is there a trick to make a mobile phone disclose it's phone number while connected via the mobile network's operator network? How can 'website payment' operator like 'obligo' get the phone number associated with a visitor? Obligo states they got the phone number to bill 'from the service operator'. Would it be possible, that a fraudster injects such headers from a client to make obligo bill the wrong number? PS: I know obligo's reputation. 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 2

Re: [swinog] swinog Digest, Vol 167, Issue 1
by Martin Fischer 07 Dec '18

07 Dec '18

....with a code that is sent by an SMS to confirm identity before transaction becomes confirmed.. Fründlechi Grüess Martin > Am 07.12.2018 um 12:00 schrieb swinog-request(a)lists.swinog.ch: > > Send swinog mailing list submissions to > swinog(a)lists.swinog.ch > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > or, 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. How do website operators get the mobile phone number of > visitors? (Benoit Panizzon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Dec 2018 14:54:04 +0100 > From: Benoit Panizzon <benoit.panizzon(a)imp.ch> > To: swinog(a)swinog.ch > Subject: [swinog] How do website operators get the mobile phone number > of visitors? > Message-ID: <20181206145404.74dcac40(a)go.imp.ch> > Content-Type: text/plain; charset=UTF-8 > > Hi List > > I have read: > > https://nakedsecurity.sophos.com/2012/01/25/smartphone-website-telephone-nu… > > And I have sniffed the traffic between my swisscom mobile Samsung > Mobile and my Website, but can't find any of the additional headers > disclosing my phone number. > > Is there a trick to make a mobile phone disclose it's phone number > while connected via the mobile network's operator network? > > How can 'website payment' operator like 'obligo' get the phone number > associated with a visitor? Obligo states they got the phone number > to bill 'from the service operator'. > > Would it be possible, that a fraudster injects such headers from a > client to make obligo bill the wrong number? > > PS: I know obligo's reputation. > > 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 > ______________________________________________________ > > > > ------------------------------ > > _______________________________________________ > swinog mailing list > swinog(a)lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > > End of swinog Digest, Vol 167, Issue 1 > **************************************

1 0

CANCELLED: SwiNOG-BE169
by Viktor Steinmann 26 Nov '18

26 Nov '18

Dear SwiNOGers, Due to scheduling conflicts, I'll have to cancel the announced Beer Event on Monday, 3rd December 2018. It seems, the Beer Events have come to an end. If someone would like to take the lead for 2019, please let me and/or Steven know off-list. Kind regards, Viktor (aka Stony)

1 0

Do ISP still offer outgoing smtp relaying services to business customers with own smtp server?
by Benoit Panizzon 16 Nov '18

16 Nov '18

Dear List We sometimes get requests from business customers, with own mailserver, which directly receives email via smtp, for an outgoing smtp-relay. I then argue with: * Their server is absolutely capable of sending emails directly * They have better control of the sending process. * They can look for problem them self in their logs. * Anti-Spam thresholds aimed at end users, not companies. * They are not affected if another customer is spaming and therefore the IP of the relay blacklisted. But still, I then often get an "BUT... you are our ISP, isn't it your duty to offer such a relay service? Other ISP do this!" rly? Do other ISP still offer smtp relaying services to business customers with own email infrastructure? 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 3

Inbound DNS query filtering on "broadband" IPs?
by Claudio Luck 13 Nov '18

13 Nov '18

Hi all I'm currently experimenting to host DNS zones on dynamic IP addresses and dynamic DNS. But I'm encountering more difficulties than expected on "broadband connections" in receiving UDP port 53 DNS query packets. In one case they're filtered completely (TCP port 53 works, UDP port 53 is blacked out), while on some there seems to be some adaptive filtering requiring like 10 minutes to "open up". Does this ring a bell? I would be thankful about any hint what could be interfering, PM or here. Thanks! Best Claudio Luck

2 1

Invalid ROA on Sunrise managed IP range
by Mike Kellenberger 12 Nov '18

12 Nov '18

Hi Could someone from Sunrise contact me off-list? We received a message about an invalid ROA of one of our customers IP-ranges, which is managed by Sunrise. I've tried contacting ip-reg(a)sunrise.net multiple times already, but I'm not getting any response. Regards, Mike -- Mike Kellenberger Teamleader Network & Security nexellent ag Sägereistrasse 33 CH-8152 Glattbrugg Phone: + 41 44 872 20 00 Direct: + 41 44 872 20 30 Mobile: + 41 79 421 17 78 www.nexellent.ch twitter.com/nexellent

1 0

.CH/.LI DNSSEC Algorithm Rollover
by Daniel Stirnimann 12 Nov '18

12 Nov '18

Hello, for your information, SWITCH will perform a DNSSEC algorithm rollover from RSA to ECDSA for ch. and li. ECDSA uses smaller keys and signatures than their RSA counterparts, which means responses to DNS queries are smaller. ECDSA was already standardised for use in DNSSEC in 2012. While switch.ch has been signed with ECDSA since 2016, IANA the root zone operator has only recently allowed TLDs to use it. The changes to the ch. and li. zones DNSKEY record are as following with times reported in UTC: 2018-11-21T13:30 Add new ECDSA key to DNSKEY record set 2018-12-21T13:30 Remove old RSA key from DNSKEY record set Between this interval, the chain of trust for ch. and li. will be updated in the root zone to point to the new ECDSA key only. Operators of DNSSEC validating DNS resolvers do not need to do anything. In the unlikely case that your validating DNS resolver only understands RSA but not ECDSA, then it will answer to ch. or li. queries as if they were not DNSSEC signed. You can test which DNSSEC algorithms are supported by the DNS resolver(s) configured on your system by visiting: https://rootcanary.org/test.html Best regards, Daniel Stirnimann, SWITCH -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 daniel.stirnimann(a)switch.ch, www.switch.ch

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog