[swinog] Re: 15% IPv6 drop in Switzerland
Nico Schottelius writes: > Salut everyone, > on this sunny Sunday, is anyone else wondering why we had a drop of > about 15% points from 2021 to 2022 of detected IPv6 usage? > I am referring to https://stats.labs.apnic.net/ipv6/CH which shows it > quite impressive. My guess would be that this is because in 2022, people spend relatively more time in the office/at schools/universities/traveling compared to 2021, and less time at home. And in Switzerland, IPv6 connectivity is still heavily biased to home users. Enterprises generally don't care, universities have some IPv6 but have a hard time rolling it out campus-wide, mobile carriers in Switzerland - unlike some other countries - haven't rolled out IPv6 on a large scale yet. (Anybody knows what's cooking in that department? Will some IPv6 come with 5G or do we have to wait for 6G? ;-) But that's really just a guess! > Is this due to UPC/Sunrise merger? It seems lise AS6730 "lost" a lot of > IPv6 traffic since end of May 2021: > https://stats.labs.apnic.net/ipv6/AS6730?c=CH&p=1&v=1&w=30&x=1 Would be interesting to overlay these graphs with data that shows mobility or other effects of anti-COVID-19 measures to corroborate or refute my hypothesis. > Best regards and enjoy your Sunday, > Nico > p.s.: This drop finally places Switzerland BEHIND Austria, which > historically lagged behind Switzerland in terms of IPv6 traffic for > many, many years. Congratulations, Austria! Cheers, -- Simon. ___ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-le...@lists.swinog.ch
[swinog] NEW: Matrix group! Let 1000 flowers bloom [was: Re: Telegram group]
jma writes:
> I usually remain silent and read interesting threads but on this
> topic I would like to express a few things.
Sincere thanks from me for your contribution.
> I'm part of those to conceive Internet concepts such as distributed
> and federated protocols as the core values of the system. [...]
For what it's worth: I violently agree with your analysis and your
values/preferences (mostly). And certainly that such values matter.
> I won't argue for a specific project or protocol, but I would like to
> express that I wish people favor interop, decentralized, and help
> supporting such Internet strengh.
Well said. So in the spirit of experimentation ("just do it"), I have
created a group on Matrix:
#swinog:swinot.ch
https://matrix.to/#/!emivqjAwXhILUrtwFM:swinot.ch?via=swinot.ch&via=matrix.org
I also started a small VM and installed a Matrix "homeserver" and Web UI
on it. For now it's running under
matrix.swinot.ch (server)
https://riot.swinot.ch (Web UI, no good way to get accounts yet)
Sorry for the stupid domain name! I'll happily move everything to
swinog.ch (and save a few Francs by not renewing the domain name :-)
Didn't want to bother the swinog.ch DNS admins over the weekend...
Further reading for background/motivation:
https://swinot.ch/post-irc/
--
Simon.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Telegram group
Ralph Krämer writes: > why telegram and not signal or threema? Why not all! And fivema and sixma as well!! Seriously, what was wrong with irc.swinog.ch? Is IRC considered a boomer thing that millenials won't touch? Just curious - I'm happy to follow everyone everywhere, but not everybody does, and I worry about fragmenting the community. Cheers, -- Simon. > - Am 11. Feb 2020 um 17:46 schrieb Massimiliano Stucchi m...@stucchi.ch: >> Hi everyone, >> >> I created a telegram group for Swinog. It is meant to be a place to >> have discussions that are more informal than what you could have on the >> mailing list or simply for something more interactive. >> >> The link to join is https://t.me/SWINOG >> >> I've created a similar group for ITNOG almost two years ago and it >> proved to be a good initiative, now with about 450 members and with >> daily discussion on different topics. Maybe we can make it happen also >> for Swinog. >> >> Keep in mind this is just a personal initiative and not an official one >> from Swinog. If it works out and it's positive, we'll see if we can >> make it more official. >> >> If you have any question or comment, please feel free to approach me. >> >> Ciao! >> -- >> Massimiliano Stucchi >> MS16801-RIPE >> Twitter/Telegram: @stucchimax >> >> >> >> >> >> ___ >> swinog mailing list >> swinog@lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] security talk by Landon Noll in Zurich, 18 Sep 18:15 @SWITCH
Date & venue have now been defined for this talk: Wednesday 18 September 18:15 - 19:30 Location: SWITCH, Werdstrasse 2 (near Stauffacher), Zurich room "Rigi" (1st floor) Please continue to use the Doodle link to register if you would like to attend, so that we know how many people to expect. Also, please try to be there on time. -- snip -- Landon Noll http://www.isthe.com/chongo/bio.html will be in Zurich, Switzerland Sept 18-20 and has prepared a 40-minute talk which he would enjoy presenting to us, if there is interest. Failures of Shallow, Inconsistent & Incomplete Security With a number of best security practices, great security concepts and sincere security implementations, why do security systems fail? Many fail because the security is trivial, inconsistent and/or incomplete. Trivial security may be ridiculed as being useless. Inconsistent security may be blamed on logic faults, or on the poor implementation of a sound idea. But of the three, it is the incomplete security flaws that are often the hardest to identify and most difficult to fix. Worse still, attacks on systems with incomplete security often produce the most devastating results. We will look at security failures, from the historic to the modern, for examples of the trivial, inconsistent and incomplete security: with takeaway lessons that will help you avoid repeating those mistakes. Please fill out the poll http://doodle.com/uhend5rbrkw5ewsu [...] -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] security talk by Landon Noll in Zurich, 18/19/20 September (tbd)
I'm posting this on behalf of my friend Adrian Steinmann. Hope it's not considered off-topic! Anyway, if interested, please participate in the doodle. I'll post the final date & place to the list. Enjoy!-- Simon. -- snip -- Landon Noll http://www.isthe.com/chongo/bio.html will be in Zurich, Switzerland Sept 18-20 and has prepared a 40-minute talk which he would enjoy presenting to us, if there is interest. Failures of Shallow, Inconsistent & Incomplete Security With a number of best security practices, great security concepts and sincere security implementations, why do security systems fail? Many fail because the security is trivial, inconsistent and/or incomplete. Trivial security may be ridiculed as being useless. Inconsistent security may be blamed on logic faults, or on the poor implementation of a sound idea. But of the three, it is the incomplete security flaws that are often the hardest to identify and most difficult to fix. Worse still, attacks on systems with incomplete security often produce the most devastating results. We will look at security failures, from the historic to the modern, for examples of the trivial, inconsistent and incomplete security: with takeaway lessons that will help you avoid repeating those mistakes. Please fill out the poll http://doodle.com/uhend5rbrkw5ewsu so I can gauge interest. I will finalize by mid September, starting time would be 18:00 unless a majority of you mention in comment that it should be later. Thanks Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] AS3303 overlapping prefix
Andy Grawehr writes: > when i check our prefix 193.105.5.0/24 on www.ris.ripe.net i get an > overlapping prefix: 192.0.0.0/3 announced by AS3303. Google "AS3303 semi-default". AS3303 announces this /3 to their customers and possibly use it internally. It's part of an elaborate mechanism to trade off routing table size against path quality. Some ISPs (including ourselves) even announce 0.0.0.0/0 to customers. Note how this also "overlaps" with your 193.105.5.0/24. Best regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BÜPF...again ; )
> Privacy is something, only old people seem to care about. I hear that a lot, but it doesn't seem to hold up to scientific scrutiny: http://www.readwriteweb.com/archives/study_youth_not_only_care_about_facebook_privacy_t.php But just continue to claim this; it makes old people feel better. -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Urgent request to clear DNS cache for cablecom.net
Jerome Tissieres writes:
> From behind SWITCH; www.cablecom.ch is not known and www.cablecom.net
> goes to a godaddy sponsor page.
Some of our anycast nameservers had cached the temporary delegation and
NXDOMAIN responses for ns{1,2}.cablecom.net. Unfortunately we only
heard about it this morning. Caches have been cleared. But note that
universities usually operate their own DNS caches rather than using ours.
--
Simon.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] IPv6 deployment questionnaire for ISPs
As part of the work of the IETF v6ops WG, Brian Carpenter is soliciting input from ISPs on IPv6 deployment: http://www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html If you have a couple of minutes, please consider filling out this ASCII questionnaire and mailing it to Brian. It would be great if you could do this by next Friday (5 February), so that he can integrate your input before the next IETF meeting. Note that the questionnaire addresses both ISPs who already offer IPv6 services and those who don't. Thanks & best regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] SWITCH Sourceforge mirror available again
Over the past couple of weeks, you might have noticed that for Sourceforge downloads, "Lausanne, Switzerland (SWITCH)" (switch.dl.sourceforge.net) was no longer listed as a mirror option. The reason was that the disk array of the server had become too small to hold the entire Sourceforge mirror dataset (because of all the binary stuff I guess - this thing should be called ".iso-forge" :-). We have now replaced it with a new server with larger disks, so now it should be fully included in the Sourceforge download mirror set. Note that, like mirror.switch.ch and many other of our services, this is reachable over IPv6 in addition to IPv4. Now go and test that thing :-) -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Bluewin SMTP Policy
Jeroen Massar writes: > Just display the captcha from the signup on $pornsite, a person will > fill it in for you, captcha bypassed. If it is interesting and cheap > for then to abuse it, they will. The approach is mentioned in an excellent talk by Louis von Ahn, who invented the CAPTCHA: http://video.google.com/videoplay?docid=-8246463980976635143&q=Google+techtalks -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Rant about DNS and TCP [was: Re: [swinog] Has Bluewin a DNS Problem]
Claudio Jeker writes:
> Until recently only AXFR was using tcp,
If you look at the original DNS specs, i.e. RFC 1035, RFC 1123, etc,
you will find that the protocol always specified that any DNS queries
can be performed over TCP. In particular, this is the normal fallback
method when a query over UDP results in a truncated (TC) response.
Actually, in the olden days there were even resolver implementations
that *only* supported TCP for DNS queries, cf.
http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01855.html
(I'm not saying this was a good idea :-)
Then people stopped listening to Jon Postel's (may he rest in peace)
advice to "be liberal in what you expect, conservative in what you
send". Instead, concerns of "security" and short-term optimization
and punishing people with "stupid" (= unexpected) configurations
became more important. So IT people and their consultants and ISPs
started to block DNS over TCP in many places, often leaving it open
only for zone transfers, and felt good about it. Thus the new (you
call it old, maybe I'm just an old fart) "rule" was born:
> normaly resolver queries had to be udp.
Some people tried to evolve the DNS to carry other information, such
as IPv6 addresses, digital signatures (actually meta-information to
make DNS information more trustable), mail policy information. And
some zones (such as the root) wanted to have many nameservers for
robustness.
So suddenly, the 512 byte (yes, 512 bytes!) limit became a real issue,
as fallback to TCP would very often just Not Work.
> This rule was a bit relaxed because of the increased space needed
> for IPv6 but many authorative dns servers will only listen to UDP
> port 53 requests..
I would say, the "new rule" ("if you use TCP for DNS queries other
than AXFRs, then you are stupid/up to no good, so I will block you")
proved to harm the long-term evolution of the DNS protocol - as is
quite often the case with these kinds of "security best practices"
that violate transparency and other design principles. But since such
rules are/were "best practices", you can never really get rid of them.
So what happened instead is that the DNS protocol was extended to
support larger-than-512-byte queries over UDP (EDNS0, RFC 2671).
While "dig" doesn't use EDNS0 by default (but see the example below),
modern recursive nameservers should normally make use of this, so that
fallback to TCP isn't necessary that often.
The fact that EDNS0 was added to the DNS is probably a good thing.
But I think it would also be good if DNS over TCP generally worked.
Although TCP does have higher overhead than UDP for typical DNS usage,
it has some security advantage, e.g. it is much harder to spoof
requests.
So to me this is another example of short-sighted and badly
thought-out "security" thinking that has harmed progress and brought
dubious security improvements at best.
Note that some people consider EDNS0 a security risk, because it
facilitates "reflection" attacks with UDP DNS requests from spoofed
(victim) source addresses that result in very large responses to be
sent to the victim.
--
Simon.
$ dig @www.multipop.ch. +edns=0 ptr -x 195.141.232.78
; <<>> DiG 9.5.0a6 <<>> @www.multipop.ch. +edns=0 ptr -x 195.141.232.78
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;78.232.141.195.in-addr.arpa. IN PTR
;; ANSWER SECTION:
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.spacebbs.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.amigaland.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.augsauger.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.begegnung.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satvision.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.hackernews.ch.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.natel-news.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satanlagen.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satantennen.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.wiso-schoch.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.xariffusion.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.sat-receiver.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.estherundpetr.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.luisenstrasse.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.arthurandersen.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.elektronik-news.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.zuerichsee-gastro.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.pop.ch.
78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.rtv.ch.
78.232.141.195.in-addr.arpa
Re: [swinog] Update
> hm.. do i miss something here? what is this about? In order to embarrass/amuse susbcribers, this mailing list adds a Reply-To: [EMAIL PROTECTED] header to all messages. It has always been that way. Maybe one day, we can decide that everybody knows when to use "reply" and when "followup/reply to all", and we can remove this... Until we do this, we have to live with the occasional intended "unicast" response that ends up being sent to the list. -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Beer-Event-Year 2007 in Zurich
>> Is this sort of an insider-joke? > Kind of. Do you recognise somebody here? [...] Ah, now I finally understand why most of the Google ads on www.colo.ch are about dating sites :-) -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BGP problems at Cablecom?
Xaver Aerni writes: > Zürich kann auch weit weg sein, von Zürich. > Mach mal einen Trace von CC nach Sunrise... Da gehst ja schnell nach > Belgien kehren... ??? I'd love to learn how to use "trace" (route?) thingie, I keep hearing good things about it... mtr from my home gateway on a normal Hispeed connection in Zurich: HostLoss% Snt Last Avg Best Wrst StDev 1. ??? 2. ch-gva01a-ra1-10ge-1-1-0-911.aor 84.2%20 14.8 23.5 14.8 29.7 7.8 3. ch-gva01a-ra1-10ge-1-1-0-911.aor 78.9%20 16.1 15.6 14.0 17.8 1.7 4. ch-zrh01a-ra1-so-0-0-0.aorta.net 60.0%20 14.8 22.6 13.6 48.8 13.2 5. 213.46.171.38 0.0%20 16.3 16.1 13.2 30.2 4.2 6. g5-0.zur01b03.sunrise.ch 0.0%20 14.8 16.2 13.4 38.0 5.2 7. gi10-0-0.ber08d02.sunrise.ch 0.0%20 266.2 40.1 17.1 266.2 58.0 8. v5.ber08s02.sunrise.ch0.0%20 21.0 21.2 17.1 41.2 7.0 9. ??? Zurich-Geneva(oh well)-Zurich-Berne... where do you see Belgium? (real traceroute has trouble with the first three hops, which only send ICMP messages for one in 3-5 packets.) -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] dns10.register.com
Philippe Strauss writes: > following my own post, > switch and nordunet bgp looking glass return "network not in table", Note that "network not in table" doesn't mean much for SWITCH, since we don't have full routing (we use multiple default routes to different upstream providers). > RIPE looking glass return a default route, [...] That's a bad sign however :-) -- Simon Leinen [EMAIL PROTECTED] SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] SwiNOG-13
Hey, the agenda is out! http://www.swinog.ch/meetings/swinog13/swinog13_agenda-txt.txt (Oh well, probably I'm the last one to notice because I don't IRC on #swinog, right? :-) Register here as long as there's still space: http://www.swinog.ch/meetings/swinog13/index.asp -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] CIXP power outage this morning ?
Jérôme Tissières writes: > 2nd, Frederic you send your mails to the whole list :)) This is excusable because the Swinog mailing list has this dreaded "Reply-to: swinog@swinog.ch" policy, so a "reply" becomes a "followup". Can we please get rid of this? -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] [Rob Thomas] Re: Infected list
In case you haven't read NANOG lately, there are DDoS attacks against Prolexic (AS32787), apparently using Linux/Unix servers compromised through vulnerabilities in PHP tools... there are a few Swiss ASes in this list, so please have a look. Here are some I spotted myself: 1836| 194.191.0.1 | AS1836 VIA NET.WORKS/CH Autono 6730| 195.141.204.164 | SUNRISE sunrise (TDC Switzerla 8928| 81.31.2.234 | INTEROUTE Interoute Communicat 29097 | 217.26.52.16 | HOSTPOINT-AS Hostpoint GmbH, S (The source in our own AS559 has already been silenced.) Merry Christmas, -- Simon. --- Begin Message --- Hi, NANOGers. Here is Barrett's list, including and sorted by ASN. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty); ASN IP AS Name 59 | 128.105.45.101 | WISC-MADISON-AS - University o 224 | 129.177.162.218 | UNINETT UNINETT, The Norwegian 224 | 129.241.192.22 | UNINETT UNINETT, The Norwegian 224 | 158.37.52.20 | UNINETT UNINETT, The Norwegian 559 | 128.178.179.34 | SWITCH SWITCH, Swiss Education 680 | 134.102.79.79| DFN-IP service G-WiN 680 | 134.169.6.37 | DFN-IP service G-WiN 680 | 134.245.10.75| DFN-IP service G-WiN 680 | 139.174.190.120 | DFN-IP service G-WiN 680 | 141.35.2.247 | DFN-IP service G-WiN 680 | 194.94.36.112| DFN-IP service G-WiN 680 | 212.201.68.131 | DFN-IP service G-WiN 684 | 205.200.160.250 | MTSAL-ASN - MTS Allstream Inc. 703 | 210.80.180.119 | UNSPECIFIED UUNET 819 | 129.100.10.240 | LARG-NET - LARG_net 852 | 208.181.144.80 | ASN852 - Telus Advanced Commun 1257| 83.72.0.197 | TELE2 AB 1659| 140.122.65.149 | ERX-TANET-ASN1 Tiawan Academic 1659| 163.23.66.1 | ERX-TANET-ASN1 Tiawan Academic 1785| 209.236.174.66 | USLEC-ASN-1785 - USLEC Corp. 1835| 130.226.142.11 | FSKNET-DK Forskningsnettet - D 1836| 194.191.0.1 | AS1836 VIA NET.WORKS/CH Autono 1955| 193.225.21.50| HBONE-AS HUNGARNET 2107| 193.2.75.15 | ARNES-NET ARNES 2200| 193.49.17.120| FR-RENATER Reseau National de 2269| 129.175.56.150 | FR-U-PARISSUD-ORSAY FR 2578| 194.87.149.34| DEMOS-AS Demos, Moscow, Russia 2586| 194.204.11.65| UNINET-AS AS Uninet 2607| 147.232.40.15| SANET Slovak Academic Network 2607| 158.197.44.28| SANET Slovak Academic Network 2614| 193.226.13.210 | ROEDUNET Romanian Education Ne 2819| 62.168.63.139| GTSCZ GTS NOVERA (GTS CZ) 2820| 194.190.223.164 | ELVIS-AS Elvis-Telecom, Moscow 2852| 147.229.88.129 | CESNET2 Czech National Researc 2852| 160.217.96.178 | CESNET2 Czech National Researc 2852| 195.113.97.230 | CESNET2 Czech National Researc 3064| 72.4.161.75 | AFFINITY-FTL - Affinity Intern 3215| 193.253.96.133 | AS3215 France Telecom Transpac 3242| 151.1.32.221 | ASN-ITNET # AS-ITNET CONVERTE 3246| 212.20.196.86| TDCSONG TDC Song 3246| 81.216.82.22 | TDCSONG TDC Song 3249| 217.159.236.34 | ESTPAK Estonian Telephone Comp 3265| 82.93.81.39 | XS4ALL-NL XS4ALL 3292| 80.232.36.1 | TDC TDC Data Networks 3304| 193.121.149.70 | SCARLET Scarlet Belgium 3352| 217.125.26.79| TELEFONICA-DATA-ESPANA Interne 3356| 62.67.209.30 | LEVEL3 Level 3 Communications 3356| 62.67.228.12 | LEVEL3 Level 3 Communications 3356| 80.253.108.80| LEVEL3 Level 3 Communications 3450| 160.36.56.64 | UTK - University of Tennessee, 3452| 138.26.238.9 | UAB-AS - University of Alabama 3561| 209.1.163.22 | SAVVIS - Savvis 3561| 72.21.49.154 | SAVVIS - Savvis 3595| 72.9.224.146 | GNAXNET-AS - Global Net Access 3599| 64.73.24.167 | BINCNET - Berbee Information N 3786| 211.174.53.4 | ERX-DACOMNET DACOM Corporation 4134| 211.155.23.81| CHINANET-BACKBONE No.31,Jin-ro 4230| 200.253.251.52 | Embratel 4264| 63.240.62.101| CERNET-ASN-BLOCK - California 4670| 210.118.194.56 | HYUNDAI-KR Shinbiro 4670| 61.111.254.95| HYUNDAI-KR Shinbiro 4686| 202.210.168.34 | BEKKOAME BEKKOAME INTERNET INC 4766| 218.144.240.70 | KIXS-AS-KR Korea Telecom 4766| 220.125.208.3| KIXS-AS-KR Korea Telecom 4795| 219.83.67.86 | INDOSAT2-ID INDOSATNET-ASN 4808| 202.108.59.135 | CHINA169-BJ CNCGROUP IP netwo 4812| 61.129.70.191| CHINANET-SH-AP China Telecom ( 4812| 61.172.245.21| CHINANET-SH-AP China Telecom ( 5413| 212.67.206.149 | AS5413 PIPEX Communications 5432| 194.78.7.66 | BELGACOM-SKYNET-AS Belgacom re 5483| 195.228.156.68 | HTC-AS Hungarian Telecom 5483| 195.228.254.6| HTC-AS Hungarian Telecom 5483| 195.228.75.111 | HTC-AS Hungarian Telecom 5483| 195.228.75.72| HTC-AS Hungarian Telecom 5533| 195.22.3.28 | VIA NET.WORKS Portugal - Tecn 5550| 153.19.121.200
[swinog] TIX flapping this afternoon?
Anybody else noticed BGP flaps on the TIX? We lost several sessions between 17:46 and 17:47 (MET) today, then sessions coming and going until most stabilized around 20:22. Maybe it was our router, but curiously the other sessions on that router somehow survived (SwissIX and Telia), so I'm suspecting some kind of instability on the TIX fabric. -- Simon (AS559) ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Wasserschaden>>>Outage of Swisscom lines
Daniel Lorch writes: > Here are the pictures: > http://verkehr.pipeline.ch/index-l.html Our favourite free daily paper also has a few images on the Web: http://www.20min.ch/news/diashows/index.tmpl?showid=5492 Presumably they received this as MMS messages from a reader. Regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] NetFlow
Raffael Marty writes: > I am doing some research on NetFlow and wanted to ask you guys a few > things: How are you using NetFlow? For what purposes? Billing? > Security? Yes, both billing (and coarse-grained traffic analysis on our upstream and peering connections) and security (detection and localization of malicious traffic, trend analysis, "cyberepidemiology" research). > Do you have NetFlow enabled on all your routers? In our setup we only use data from our border (peering) routers. > Do you enable it on all the interfaces or just on the > external/internal interface? We have it enabled in the ingress direction on all interfaces, so that we can count all traffic both inbound and outbound through the router. Also our current platform (with current software) cannot enable Netflow selectively. > Do you utilize any tool to stitch the NetFlows back together? Why > would you do that? In the part I'm responsible for (billing etc.), I don't try to match related unidirectional flows to bidirectional flows. Maybe for security applications this would be more useful. At any rate it's difficult in our network, because the two directions often go through different routers. > I guess you can tell that I was never exposed to NetFlow in the ISP > world. Any answers or comments are really appreciated. I maintain a page with pointers to Netflow-related software packages - maybe you find it useful: http://www.switch.ch/tf-tant/floma/software.html -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] [Fwd: [Full-disclosure] DNS Smurf revisited]
Fabian Wenk writes: > This Mail [1] arrived just over the Full-Disclosure mailinglist [2], > but should probably also be of interest to some people here. >[1] > http://lists.grok.org.uk/pipermail/full-disclosure/2005-May/034342.html >[2] https://lists.grok.org.uk/mailman/listinfo/full-disclosure Yes, at least it should remind our community that ingress filtering is important. When I tried the "spoofer" test software from http://momo.lcs.mit.edu/spoofer/#software , I was shocked to see that I can spoof packets from my home broadband connection (and probably the 299'999 other broadband customers of that Swiss ISP can do so as well :-). Hopefully other Swiss ISPs do this better. I hate to say something in defense of NATs, but at least the problem is somewhat mitigated by the fact that many surfers (especially those with broadband connections) use NATs. They make address spoofing from compromised PCs ineffective. As for enterprise connections, I'm not sure. I assume most small enterprises use NATs as well. Large enterprises use firewalls, but if something behind the firewall does get infected, I'm not sure those firewalls would protect the outside world against spoofed packets (or any other kind of junk) from those machines. -- Simon. PS. SWITCH has ingress filters on all customer access interfaces, so compromised systems inside universities cannot used spoofed source addresses from outside the respective site's address space. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] delay simulation
Marcel Leuenberger writes: > Has anyone experience with a tool to simulate delays in packet Nitpick... I think you mean "introduce artificial" or "emulate" rather than "simulate". For network simulation you could use something like the NS2 Network Simulator, which I'm sure has arbitrarily configurable delays/losses etc. per link. > forwarding - Especially to simulate high delays as they occur in > satellite networks? Have anyone already used a free tool based on > linux, freebsd, (windows). Most people seem to use Dummynet for FreeBSD: http://info.iet.unipi.it/~luigi/ip_dummynet/ For Linux, there's NIST NET: http://cs.ecs.baylor.edu/~donahoo/tools/nistnet/ For Solaris, there's ONE (Ohio Network Emulator): http://masaka.cs.ohiou.edu/one/ Note that I don't have personal experience with any of these, but I know that at least Dummynet and NIST NET have succefully been used for research... Regards, -- Simon. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
