[swinog] Re: Swisscom DNS issue: spectrum-conference.org wrongfully resolves to a bluewin address in swisscom mobile networks

[Andreas Fink via swinog]

it would only be fair if swisscom declare their offer not to be "internet" but 
some "protected network connectivity including part of the internet". At least 
then the end user can decide.
I don't think their concept is compatible with net neutrality otherwise.

And you can not opt-in or opt-out if you are not aware.

> On 23 Apr 2024, at 12:30, Marc SCHAEFER via swinog  
> wrote:
> 
> Hello,
> 
> On Tue, Apr 23, 2024 at 10:04:14AM +0200, Stefan via swinog wrote:
>> But you know that it is already daily business that Swiss ISP's are blocking
>> websites?
> 
> One of the example you give was voted by the Swiss people (Casino blocking).
> ISP have no say in that matter.  Some countries go way further in blocking
> "content" (as was mentionned on the list earlier).
> 
> But here, we are discussing additional security measures that some ISPs,
> including Swisscom, are taking: Swiss people did not vote yet about blocking
> malware.
> 
> And Swisscom also blocks / intercepts / redirects SMTP for quite a few years
> now, for end users.  On port 25 (not on 587 nor 465 AFAIK).  I think they are
> pretty unique in that aspect (other ISPs usually simply block incoming
> port 25, they don't AFAIK filter out outgoing).
> 
>> Use other DNS-Servers if you want to be "free", but accept the risk.
> 
> That could be a solution: an opt-out.  It *seems* to me that Sunrise, e.g.,
> actually even offers an opt-in, as their firewalling service is usually
> valued at 5 CHF/month but in essence free to the end user (not sure what it
> really does) and can be refused when ordering.
> 
> In my opinion, the most important thing is that the blocking be documented to
> the end-user, even on every month's invoice, and that opt-out (or opt-in) be
> offered for everything that is not compulsory by law.
> 
> Have a nice day.
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swisscom DNS issue: spectrum-conference.org wrongfully resolves to a bluewin address in swisscom mobile networks

[Andreas Fink via swinog]

I disagree. Its not swisscoms role to censorship the internet. Even if the idea 
might be honorable,  to keep the bad guys out, the machinery put in place is 
resulting in something which will be abused for political agendas. Given 
swisscom is state owned, the risk is even higher. Its a risk to democracy you 
should not under estimate. Maybe you are too young but you should read George 
Orwells 1984 to see where this is going. I have been an indirect victim of a 
blocking which costed me 10 years in court case and legal fees of half a 
million stacking up. You can not imagine what political blocking can do to your 
business. And here we have swisscom put a machinery in place that politicians 
can just ask for it by the clock of a button. Now dont tell me they will not 
use this powerful weapon one day agains someone they dont like their political 
views of. Totalitarian states do it already up to certain extent (Russia, 
Turkmenistan, US, Iran, middle east, Turkey...)

> Am 23.04.2024 um 11:34 schrieb Daniel Stirnimann via swinog 
> :
> 
> 
>> 
>>> Yes, I understand the technical issues. And yes it's ugly. But do you have 
>>> a better solution?
>> Swisscom should stop tampering with DNS, as it does not work, and is no 
>> solution to the problem.
> 
> I disagree, Swisscom still misses a lot of phishing and malware websites. I 
> would like them to be way more aggressive. Their support staff has to deal 
> with calls from infected customers. They might as well try as good a possible 
> to prevent it from happening in the first place. If you belong to the <0.1% 
> of people who want unfiltered DNS, just run your recursive resolver.
> 
>> Part of the problem is that the user doesn’t get an error message at all, 
>> and then mails us „hey, your website is down“.
> 
> Eventually, web browser will show better responses for none resolvable domain 
> names e.g. by utilizing Extended DNS Errors (RFC 8914).
> 
> EDE has code points for filtered or blocked DNS responses. Until web browser 
> care more about DNS, I advice to be as verbose as possible when you block 
> something.
> 
> For example, make the DNS output more verbose so that at least administrators 
> realize why a domain name is blocked. Swisscom could have used a CNAME in the 
> answer section to blocked.swisscom.com and they could also add an additional 
> section with a SOA indicating the origin of the blocking. The RNAME field 
> could be their report false positive email address and so on.
> 
> Daniel
> 
> ___
> swinog mailing list -- swinog@lists.swinog.ch
> To unsubscribe send an email to swinog-le...@lists.swinog.ch


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

Re: [swinog] SPF checking on upcmail.net failing

[Andreas Fink]

Are you getting emails saying you double paid your UPC bill / Sunrise
Bill / Swisscom Bill? I have seen some phishing attemts lately like this.
some are like "you paid twice click this link to refund: [button named
"pay bill here"] ".. doesnt makes a lot of sense ;)...


Marc SCHAEFER wrote on 25.01.22 14:38:
> On Tue, Jan 25, 2022 at 01:03:23PM +, Beat Eichenberger wrote:
>> Is there a UPC mailadmin following this list?
> Also,  the return address for billing bounces:
>
> : host mx2.tripolis.com[87.253.151.86] said: 450 
> 4.1.1
> : Recipient address rejected: unverified 
> address:
> User unknown in virtual alias table (in reply to RCPT TO command)
>
>
> ___
> 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

Re: [swinog] SSL Certs question

[Andreas Fink]

Jeroen Massar wrote on 13.05.21 10:46:
> On 2021-05-13 11:29, Andreas Fink wrote:
>> Hello all,
>>
>> I need to get some SSL certificates for some african country operations
>> and i can unfortunately not use letsencrypt for this.
>
> Any reason? What are your requirements?

the mailserver I use, does not support ACME setup. I can only do old
style SSL certificate requests.
for the webserver its not an issue though.

> Would ZeroSSL (https://zerossl.com) who also do ACME work?

No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare
with a cloudflare SSL certificate. So by definition not DSGVO conform as
NSA could theoretially infiltrate cloudflare to infliltrate all my certs
etc. etc. It might be far fetched but since snowden, we know that many
things we considered far far far fetched are not anymore.

> (yes people, Let's Encrypt is not the only game... if you do ACME for
> your systems, also setup zero ssl and issue certs from both places at
> the same time, just in case LE ever has an issue, though that will be
> resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)
Cloudflare's juristiction is definitively a red flag for me.

>
>> I was trying to
>> get a certificate from Swissign for this but for some reason they refuse
>> issuing certificates to domains for Guinea and Guinea Bissau
>
> Do you need org validated or something that the country matters?
no. I simply need the domain be in that country.
The holder of the domain can be myself in switzerland or one of the
entities in Africa which is not on the blacklist (which is actually what
I tried). Swisssign put the certificate under embargo because the domain
ending contained .gw and .com.gn. Thats all.
And I don't want to buy a domain for every mailserver separately, thats
why I want a multidomain certificate. As it has to be renewed every
years its painfully enough already.





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SSL Certs question

[Andreas Fink]

Serge Droz wrote on 13.05.21 10:02:
> Hi Andreas
>
> These two countries are not currently under comprehensive US sanctions:
>   >
> https://home.treasury.gov/policy-issues/financial-sanctions/sanctions-programs-and-country-information
>
> So any CA, except, it seems SwissSign, should do.
>
> Best
> Serge
Any "CA" which is not owned by a US controlled entity was the target.

I find it rather sad that a swiss (=neutral) SSL certificate provider
owned by the Swiss Post which is in turn owned by the Swiss Government
sanctions by themselves countires just because they are afraid that a
drug smuggler could buy a domain...
But thats a rant for another day... Banks are not too big to fail
anymore. They are destined to fail (Keyword: advance obedience).

Andreas Fink



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] SSL Certs question

[Andreas Fink]

Hello all,

I need to get some SSL certificates for some african country operations
and i can unfortunately not use letsencrypt for this. I was trying to
get a certificate from Swissign for this but for some reason they refuse
issuing certificates to domains for Guinea and Guinea Bissau because
these countries are on their embargo TLD list. It is known that some
individuals from these countries are on a UN embargo list, but thats
also true for some people from Germany or Switzerland or USA. And these
countries are not blocked. In other words, I need another certificate
provider, preferrably not under US control (so not Comodo, Digicert,
Thawte, Symantec, Verisign etc), who can issue multidomain certificates
for .gw, .com.gn, .sl, .io, .com domains.

Anyone have a good hint?




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] New glue record, transfer of domains and such things

[Andreas Fink]

Glue Records do exist for domain name servers which are in the same domain.

For example if you have two nameservers:

ns1.example.com
ns2.example.com

and your registrar would have entries to resolve example.com like this:

example.com NS  ns1.example.com
example.com NS  ns2.example.com


Then it can't resolve because to resolve the nameserver's names, it has
to ask the nameserver for example.com which results in a infinite loop.
That's why the addresses of the nameservers have to be hardcoded in the
upstream DNS so the downstream can always be resolved.

So the upstream domain must have entries like this:

example.com NS  ns1.example.com
example.com NS  ns2.example.com
ns1.example.com.   A 1.2.3.4
ns2.example.com.   A  4.5.6.7

so the domain name servers can always be found without asking a yet
unknown DNS server.


But if you use

example.com NS ns1.some-other-domain.com
example.com NS ns2.some-other-domain.com

Then this is not necessary if some-other-domain.com can always be
resolved because the IP's of the nameservers are in that zone's DNS.

Now if you port the domain to some other registrar, I presume these glue
record entries have to be taken care of by the new registrar as the NS
entries is whats going to be managed by your registrar.

This is whats happening on the DNS level.
Whats happening on the registrar database level might be a different
thing but I doubt that if you take over a domain from Registrar A to
Registrar B all the entries in the root zone would automatically be
taken over because usually you just remove all entries from the old
registrar and the new registrar would put your new entries in (which you
have to tell the new registrar).


Mueller Urs SBB CFF FFS wrote on 15.04.21 14:48:
> Hi there
>
> A friend reminded me to use the list, as it is sometimes a bit quiet here. ;-)
>
> My understanding of a glue record is, that the registrar of a domain is 
> responsible to configure them (in my case at home, this was Cyon, but they 
> were a bit puzzled, as they don't do this very often).
>
> Just to understand this technically (I'm perhaps totally wrong):
> - Domain registrar receives customer order (put dns.xyz.zyx with 1.2.3.4 as 
> glue record into some system)
> - Registrar has an interface (fax, carrier pigeon or something similar) to 
> tld registry, which can save the record to its database
>
> If I further change my registrar, this doesn't affect that entry, but any 
> change has to be ordered through the new registrar.
>
> There is usually no way to do this myself (if the registrar is not offering 
> such an interface).
>
> Please help or correct me. Thank you.
>
> Urs Müller
>
> SBB AG
> Cyber Defense Center
> Poststrasse 6, 3072 Ostermundigen
> Mobil +41 79 433 21 67
> urs.bf.muel...@sbb.ch / www.sbb.ch 
>
>
>
> ___
> 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

Re: [swinog] G.Fast DSL modems - bridge only

[Andreas Fink]

If you have line of sight between the DSLAM location and your home? Slam
a microwave on to it and you get 10Gbps over such distances easily.
And if you can't afford that, 1Gbps at 60Ghz you can get for a couple of
100 bucks and can go as far as 10km (LOS only).

Since I moved away from VDSL2 area to Fiber to the home place, I can not
really understand these issues anymore.
Why go and abuse copper wires to the absolute limit when its not a
solution long term any way. Its dead technology.

It's always an edge case and full of problems like this one. Fiber in
contrary is so darn simple and straightforward. Router (of choice) + SFP
or SFP+. Done!
Simple. Easy. Always works! (if not, try another fiber patch cable or
the right port maybe. That's about it).

So my recommendation: talk to your fiber provider of choice (real FTTH
not that shitty GPON stuff) instead of wasting time on copper with all
kinds of "lets squeeze the last bit out of a noisy copper wire" options.
It really pays off to go the extra mile there.

But if you don't have the choice, consider move to another place if
having good internet is your daily bread and butter (which is probably
the case for most of us on this list).
Seriously, it helps a lot in peace of mind.

Another option these days is switch to 5G wireless and set up a IPSec
tunnel to your preferred router in the Datacenter.
I get like 150 - 450Mbit on 5G depending on where I am at. Still faster
than VDSL2.

Benoît Panizzon wrote on 01.04.21 12:26:
> Hi Jeroen
>
> Interesting topic!
>
> Swisscom deployed 'FTTS' at my home last year, promising 'at least
> 500 mbit/s with g.fast' for every household, causing the municipal
> administration to reject plans for proper FTTH from competitors, this
> as a sidenote.
>
> Actual situation: I live about 250m away form the DSLAM in the street.
> After several cases opened @ Swisscom, they found out it is just about
> a little too far away for g.fast to work properly.
>
> In this 'at the limit' situation I tested two ZyXEL XMG3927-B50A (to
> make sure I had not a broken one) in bridge mode (PPPoE on Mikrotik).
> Tested directly at the HÜP.
>
> Results:
> * g.fast is slower than VDSL2 at this distance in both up and down
>   speed (way slower than what Swisscom announced).
> * XMG3927 shows very strange packet delays. There is no packetloss, but
>   latency sometimes jumps to about 500ms or more, for single packets
>   (usually small packets like tcp syn) causing re-transmits, without
>   apparent reason. This happens in g.fast AND VDSL2 mode.
>   Also happening if ethernet interface is set to 100Mbit/Fduples.
>   Opened Case @Studerus, They never heard of that issue.
> * Older VDSL2 only Modem: VMG1312-B10A odes not show this lately issue
>   (so I kept that modem)
>
> I know, that the XMG3927 has wider filters (up to 500Mhz or so) to
> allow g.fast. I know there are a couple of low power 430MHz
> transmitters in my neighbourhood. Could they be the cause of that issue?
>
> Looking forward of other's experiences with g.fast bridges.
>





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Handling of UCE / RBL while minor misconfigurations

[Andreas Fink]

Hello Urs,

From my long term experience with e-mail (I think I got my first internet email 
address around 1988 where nobody thought of spam yet) I can tell you the 
follwoing:

Fighting spam is honorable and its good that some people take it serious. 
However


Things like SPF etc can help to block routes coming from the wrong IP and they 
are used technically.
Correcting a SPF however should immediately fix the delivery. If thats not the 
case, then the DNS cache can delay it. Thats just how the technology works.
The only annoying guys I run into who you always require special "treatment" 
are google and microsoft. Luckily most of my business partners stay away from 
US mailproviders but some have not understood the danger there yet.
Now SPF is domain based. So if SPF triggers, then mails from that IP for that 
domain must be blocked. Nothing else.

If there is a blacklist involved, in your case, then it's clearly a very 
aggressive one. I have seen some "companies" who blame themselves to be the 
good guys, playing the cyberpolice and who are deciding for millions of 
mailservers whats good and whats bad. But they overblock and take the ISP 
hostage. I once had to go the legal path because of such a stupid overblocking. 
And our friends at Swisscom where using them at the time so if this happens, 
you are disconnected from a lot of people from one minute to the next. This 
just to show you the huge power these "companies" have and how little due 
diligence there is. You already have problems talking to them to start with.

 What I'm trying to say here is that blacklist providers are not perfect by 
far. They fight their own private wars and they can be abused for cyberwar  or 
revenge attacks as well. So from the view of a mailserver operator, you should 
choose well whom you trust to decide who can send you emails and who doesn't. 
As far as UCEProtect goes (which I have never seen before), I see serious legal 
issues. You don't know whom you are trusting. There's no names, no legal 
entity, no contact information on their webpage.They hide which is never a good 
sign.
And if you look at their delisting policy, you see immediately what they real 
goal is. If an ISP asks for delisting, it can take up to 7 days. However if you 
PAY them, you can be immediately removed. This means, they have a direct 
financial interest to have as many hosts listed as it generates sales. (its 
"only" 89 CHF per IP). So they would definitively not be my hero's fighting the 
nasty spam...

Spam is reality and everybody hates it. However spam should not be fought 
primary by simply throwing emails away or blocking. It should be fought primary 
by taking actions against the spammers itself which makes him stop his odd 
behaviour.
Because otherwise they continue to overload the internet and annoy everyone and 
making e-mail became useless.


I give you a example:

I run a company in Iceland which has a datacenter. For some reason its sales@.. 
email address got added into a list of mailing addresses. Since a couple of 
years I got tons of spams in french advertizing stuff from France which I have 
absolutely no relation with. For example it was promoting to change my home 
electricity to another provider which is even impossible unless you live in 
France. Blocking these emails is not really possible on technical means without 
lots of collateral damage because they came from valid mailservers and valid 
companies. Unsubscribe buttons usually did work and reduce the volume already 
quite a bit. Replying to these people with something like this:

>Thank you for your query.
>Given I have never given you an opt-in to send me spam, I would like to remind 
>you that the law on unfair competition act, 
> especially article 23 togeter with article 333 and 34 of the criminal code 
> defines the maximum penalty for spamming as 1'080'000 CHF or up to 3 years in 
> prison.
>So please think again before sending the next spam.

and also asking through GDPR to show them the opt-in or where they got the 
email address from, makes these companies quickly remove that email address and 
think again if it was a good idea to buy this "email addresses for cause X..." 
list from some shady seller.
These measures have reduced the "French" spam I am getting to very very few. So 
this was much more effective than blindly trusting a 3rd party to just block 
everything. Sure >90% of the blocked stuff is spam but there might be a few 
mails which get deleted which are important for your business. And if its in 
your spam folder on your computer, you can at least find it if needed. If its 
deleted before even hitting your machine, you are dead and you don't even yet 
know it.

The technical things help for mailservers going nuts, anonymous viagra spams 
etc. But these don't stay for long. If an IP doesn't work anymore, these folks 
have a million other mailservers to try and just move on.

So to answer your question: someone putting an IP on to a 

Re: [swinog] Weird Bluewin Error: 'Unable to verify MX-Record for domain'

[Andreas Fink]

your reverse DNS is not matching for 157.161.57.26 as it returns aleka.scout.ch.

list.scout.ch. is not the same as aleka.scout.ch
You could do instead


list.scout.ch  MX 50 aleka.scout.ch

or 

list.scout.ch  CNAME aleka.scout.ch.


> On 31 Mar 2020, at 10:05, Benoît Panizzon  wrote:
> 
> Hi List
> 
> Has anyone seen this error message and has a clue about the cause?
> 
> ... while talking to mxbw.lb.bluewin.ch.:
> 
> <@bluewin.ch>
>   (reason: 550-5.1.0 MAIL FROM:
>   <*@list.scout.ch>
>   Unable to verify MX-Record for domain list.scout.ch)
> 
> list.scout.ch.3600IN  MX 50 list.scout.ch.
> list.scout.ch.3600IN  A 157.161.57.26
> list.scout.ch.3600IN   
> 2001:4060:dead:beef:200:e2ff:fe70:3b2f
> list.scout.ch.3600IN  TXT "v=spf1 a:list.scout.ch 
> a:akela.scout.ch a:list.scoutnet.org -all"
> 
> Can't find anything wrong with the MX entry. Actually an MX is not even
> really necessary.
> 
> -Benoît-
> 
> 
> ___
> 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] MELANI / GovCERT.ch

[Andreas Fink]

Hello Swinog Users,

Has anyone of you received some info from MELANI  / GovCERT about some IoT 
vulnerability you might be exposed to?

Well I did and I found very very strange things in this report.

1. The report contains only a  timestamp, an IP address and a DNS name. Not 
which vulnerability, not potential loopholes, traces or ANYTHING useful to 
analyze whats happening.

2. The single IP address in the report is not in my network (I used to have 
that IP range in the past but I sold it in 2016. So long long ago. )
3. The abuse email they sent the report to is not in the whois of that network.
4. The DNS name used in the report is not the reverse PTR of that IP. Nor does 
the forward DNS point to that IP. 
5. The DNS name points to a host in my network but that host is definitively 
not a IoT device which has any kind of default password. Its a solid Linux 
machine with a up to date distribution with 2 usernames only on it with very 
secure passwords and only one specific application running which doesn't talk 
to outside my network at all. If that machine would have gotten hacked, it 
would surprise me very much. At least I have found nothing unusual on that IP. 
No unexpected network activity, CPU load, processes etc.

So MELANI tells me my big fat Linux server is now a IOT device which has 
default passwords and I should simply do a factory default  (and by doing this 
erase terabytes of data). I should look for "_SOMETHING_" without specifying it 
on SOME IP I don't own. And they address such a report to me while I am not the 
abuse contact of this SOME_IP. Furthermore SOME_IP looked not being reachable 
anyway when I tested.

So the report contains ZERO  usable information. The only thing which might not 
be wrong in the report is the timestamp (but thats not verified neither).

I am shocked that a government entity which should take security seriously, is 
sending out such utter nonsense reports and wasting all our precious time.
If they got such reports from 3rd parties it should contain verifiable 
information and USEFUL information. Apparently MELANI has become some kind of 
open CERT-SMTP relay without authentication.


Let me know your experiences.


Andrea Fink
Fink Telecom Services
--.-  .-.   -


>> ENGLISH VERSION
>> 
>> Dear Sir or Madam
>> 
>> You are receiving this email because your email address is either registered 
>> as abuse contact for AS6775 in our system or because your email address is 
>> referenced as abuse contact for AS6775 at RIPE.
>> 
>> The Reporting and Analysis Centre for Information Assurance (MELANI) has 
>> been informed by a partner about one of more devices (IoT - "Internet of 
>> Things") in your network that are likely to be compromised by Hackers and 
>> that are being used for malicious purpose. Attached to this email, you can 
>> find a list of all IP addresses that has been reported to us in the past 24 
>> hours.
>> 
>> The affected devices have most probably been compromised by hackers, likely 
>> due to the usage of a a default password. Therefore, hackers where able to 
>> install a malware (Mirai) on the said devices
>> 
>> We therefore recommend you to identify the affected devices or customers, 
>> securing them and clean them up (e.g. by doing a factory reset). An overview 
>> of recommendations concerning IoT devices can be found on our website:
>> 
>> Security in the internet of things (IoT):
>> https://www.melani.admin.ch/iotsecurity 
>> 

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Strange IPv6 scans from big networks

[Andreas Fink]

except scanning a /64 takes a ethernity 

> On 1 Dec 2019, at 19:05, Nico Schottelius  
> wrote:
> 
> 
> Hey Klaus,
> 
> I am surprised you are surprised.
> 
> Why would one *not* want to scan your particular home network?
> 
> IPv6 is on the rise and scanning networks / IPs is a standard thing in
> the IPv4 world. So it would be a surprise to me, why people would not
> want to at least try to find devices in IPv6 based networks.
> 
> Best,
> 
> Nico
> 
> 
> Klaus Ethgen  writes:
> 
>> Hi,
>> 
>> Currently I see day long IPv6 scans from networks of Akamai
>> (2a02:26f0:f3::/48), Google (2a00:1450:4000::/37), Apple
>> (2a01:110::/31), Microsoft (2a01:b740::/29), Swisscom (2001:918::/32)
>> and Init7 (2001:1620::/32) to my Network @HOME. They all try to
>> enumerate hosts and ports in 2a02:168:4e82:0:* that does not and never
>> have exists.
>> 
>> The net is a fiber7 port.
>> 
>> Anybody an idea what is going on here? On request I can provide more
>> informations like pcaps.
>> 
>> The scans are sourced from all over that mentioned networks above.
>> 
>> While I have no scruples to block Apple, Microsoft, Akamai or other bad
>> behaving networks, I do not want to block Swisscom or Init7 if not
>> needed.
>> 
>> Needless to say that I do not have any public service behind my fiber7
>> port.
>> 
>> Gruß
>>   Klaus
> 
> 
> --
> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
> 
> 
> ___
> 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

Re: [swinog] swinog Digest, Vol 174, Issue 3

[Andreas Fink]

On 11 Jul 2019, at 14:55, Daniel Stirnimann  wrote:
> 
> The pointers have been given before. This is your problem:
> 
> https://www.spamhaus.org/query/ip/79.134.251.203
> 
> Daniel


Yes above is my problem but at the same time it can not be the reason for mail 
delivery to bluewin.ch <http://bluewin.ch/> coming back with a cryptic  DNSNULL 
error

Spamhaus has a issue with a customer of mine but they have not shown any proof. 
Above IP however is not in the disputed IP range, its my my well maintained 
mailserver which has never sent any spam and is not listed as sending any spam 
anywhere else. What Spamhaus is doing is trying to get ISPs to cancel contracts 
with well paying customers on first call (no judge, no proof) by putting the 
ISP's whole IP range into a blacklist (a /19 !) and thus punishing legitimate 
3rd parties as well. This is called coercion (Nötigung) which is a criminal 
offense punishable by law for up to 3 years in jail. We will see if Spamhaus 
prefers to go to jal or change their blacklisting policy.

Never the less. Sending emailst o bluewin.ch <http://bluewin.ch/> has never 
been affected. I sent emails successfuly yesterday to bluewin users without a 
problem. I don't think Spamhaus's blacklist are being used by bluewin.ch 
<http://bluewin.ch/> as otherwise we would have had issues a lot earlier.

So this doesn't explain any DNSNULL error. And frankly, the error message is 
really stupid misleading...


> 
> On 11.07.19 14:25, Andreas Fink wrote:
>> Except that this is not applicable. In my case my mailserver is not
>> hosted at Swisscom but on my own infrastructure, is on the same IP since
>> years, has proper MX records and reverse DNS entries and has delivered
>> email to the same bluewin customer yesterday successfully. Only the
>> reply on that receiver today which I received and replied again got
>> rejected. And the response is cryptic to me.  
>> 
>> And if you mail to ab...@bluewin.ch <mailto:ab...@bluewin.ch> you get
>> the same error...
>> 
>> So who is this famous DNSNULL I should contact?
>> 
>> 
>> 
>>> On 11 Jul 2019, at 13:49, Florin sfetea >> <mailto:f_sfe...@yahoo.com>> wrote:
>>> 
>>> See 
>>> https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eigener-Domain-nicht/td-p/570002
>>>  
>>>  
>>> Beste Grüsse, Regards si s-auzim de bine 
>>> Florin Sfetea
>>>  
>>> *From: *swinog-requ...@lists.swinog.ch
>>> <mailto:swinog-requ...@lists.swinog.ch>
>>> *Sent: *Thursday, July 11, 2019 12:00
>>> *To: *swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
>>> *Subject: *swinog Digest, Vol 174, Issue 3
>>>  
>>> Send swinog mailing list submissions to
>>>   swinog@lists.swinog.ch <mailto:swinog@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-requ...@lists.swinog.ch
>>> <mailto:swinog-requ...@lists.swinog.ch>
>>>  
>>> You can reach the person managing the list at
>>>   swinog-ow...@lists.swinog.ch <mailto:swinog-ow...@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. bluewin & DNSNULL (Andreas Fink)
>>>  
>>>  
>>> --
>>>  
>>> Message: 1
>>> Date: Thu, 11 Jul 2019 11:32:38 +0200
>>> From: Andreas Fink mailto:af...@list.fink.org>>
>>> To: "swi...@swinog.ch <mailto:swi...@swinog.ch>" >> <mailto:swi...@swinog.ch>>
>>> Subject: [swinog] bluewin & DNSNULL
>>> Message-ID: <75da5d85-1a68-4d10-94b8-6237fd9d5...@list.fink.org
>>> <mailto:75da5d85-1a68-4d10-94b8-6237fd9d5...@list.fink.org>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>  
>>>  
>>> Does any one have a clue what DNSNULL means in the following context
>>> of a mail delivery error?
>>>  
>>>  
>>>  
>>> <@bluewin.ch
>>> <http://bluewin.ch/> <mailto:claudine.be...@bluewin.ch>>
>>> (mx-v02.bluewin.ch
>>> <http://mx-v02.bluewin.ch/> <http://mx-v02.bluewin.ch/>:
>>> 554 mxbw.lb.bluewin.ch
>>> <http://mxbw.lb.bluewin.ch/><http://mxbw.lb.bluewin.ch/> vim
>>> dzmsp-mxin12.bluewin.ch
>>> <http://dzmsp-mxin12.bluewin.ch/> <http://dzmsp-mxin12.bluewin.ch/>
>>> Swisscom AG IP: 79.134.251.203, You are not allowed 
>>> to send us mail. Please see DNSNULL if you feel this is in
>>> error)Reporting-MTA: dns; mail.fink.org
>>> <http://mail.fink.org/> <http://mail.fink.org/>
>>> Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200
>>> ...


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] swinog Digest, Vol 174, Issue 3

[Andreas Fink]

Except that this is not applicable. In my case my mailserver is not hosted at 
Swisscom but on my own infrastructure, is on the same IP since years, has 
proper MX records and reverse DNS entries and has delivered email to the same 
bluewin customer yesterday successfully. Only the reply on that receiver today 
which I received and replied again got rejected. And the response is cryptic to 
me.  

And if you mail to ab...@bluewin.ch <mailto:ab...@bluewin.ch> you get the same 
error...

So who is this famous DNSNULL I should contact?



> On 11 Jul 2019, at 13:49, Florin sfetea  wrote:
> 
> See 
> https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eigener-Domain-nicht/td-p/570002
>  
> <https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eigener-Domain-nicht/td-p/570002>
>  
>  
> Beste Grüsse, Regards si s-auzim de bine 
> Florin Sfetea
>  
> From: swinog-requ...@lists.swinog.ch <mailto:swinog-requ...@lists.swinog.ch>
> Sent: Thursday, July 11, 2019 12:00
> To: swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
> Subject: swinog Digest, Vol 174, Issue 3
>  
> Send swinog mailing list submissions to
>   swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
>  
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog 
> <http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog>
> or, via email, send a message with subject or body 'help' to
>   swinog-requ...@lists.swinog.ch <mailto:swinog-requ...@lists.swinog.ch>
>  
> You can reach the person managing the list at
>   swinog-ow...@lists.swinog.ch <mailto:swinog-ow...@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. bluewin & DNSNULL (Andreas Fink)
>  
>  
> --
>  
> Message: 1
> Date: Thu, 11 Jul 2019 11:32:38 +0200
> From: Andreas Fink mailto:af...@list.fink.org>>
> To: "swi...@swinog.ch <mailto:swi...@swinog.ch>"  <mailto:swi...@swinog.ch>>
> Subject: [swinog] bluewin & DNSNULL
> Message-ID: <75da5d85-1a68-4d10-94b8-6237fd9d5...@list.fink.org 
> <mailto:75da5d85-1a68-4d10-94b8-6237fd9d5...@list.fink.org>>
> Content-Type: text/plain; charset="us-ascii"
>  
>  
> Does any one have a clue what DNSNULL means in the following context of a 
> mail delivery error?
>  
>  
>  
> <@bluewin.ch <http://bluewin.ch/> <mailto:claudine.be...@bluewin.ch 
> <mailto:claudine.be...@bluewin.ch>>> (mx-v02.bluewin.ch 
> <http://mx-v02.bluewin.ch/> <http://mx-v02.bluewin.ch/ 
> <http://mx-v02.bluewin.ch/>>: 554 mxbw.lb.bluewin.ch 
> <http://mxbw.lb.bluewin.ch/><http://mxbw.lb.bluewin.ch/ 
> <http://mxbw.lb.bluewin.ch/>> vim
> dzmsp-mxin12.bluewin.ch <http://dzmsp-mxin12.bluewin.ch/> 
> <http://dzmsp-mxin12.bluewin.ch/ <http://dzmsp-mxin12.bluewin.ch/>> Swisscom 
> AG IP: 79.134.251.203, You are not allowed 
> to send us mail. Please see DNSNULL if you feel this is in 
> error)Reporting-MTA: dns; mail.fink.org <http://mail.fink.org/> 
> <http://mail.fink.org/ <http://mail.fink.org/>>
> Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200
> ...
>  
>  
>  
> Andreas Fink
> --
> Paradieshofstrasse 101, 4054 Basel, Switzerland
> andr...@fink.org <mailto:andr...@fink.org> <mailto:andr...@fink.org 
> <mailto:andr...@fink.org>> https://www.fink.org <https://www.fink.org/> 
> <https://www.fink.org/ <https://www.fink.org/>>
> Mobile: +41-78-6677333 Office: +41-61-330 Home: +41-61-345
> Skype: andreasfink   Jabber/XMPP: andr...@fink.org <mailto:andr...@fink.org> 
> <mailto:andr...@fink.org <mailto:andr...@fink.org>>ICQ: 8239353
> Twitter: @kiwi66  PGP Key: https://www.fink.org/FILES/afink-pgp.asc 
> <https://www.fink.org/FILES/afink-pgp.asc>
> --
>  
>  
>  
>  
>  
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.swinog.ch/public/swinog/attachments/20190711/87899b9d/attachment-0001.html
>  
> <http://lists.swinog.ch/public/swinog/attachments/20190711/87899b9d/attachment-0001.html>>
>  
> --
>  
> ___
> swinog mailing list
> swinog@lists.swinog.ch &

[swinog] bluewin & DNSNULL

[Andreas Fink]

Does any one have a clue what DNSNULL means in the following context of a mail 
delivery error?



 <@bluewin.ch <mailto:claudine.be...@bluewin.ch>> (mx-v02.bluewin.ch 
<http://mx-v02.bluewin.ch/>: 554 mxbw.lb.bluewin.ch 
<http://mxbw.lb.bluewin.ch/> vim
dzmsp-mxin12.bluewin.ch <http://dzmsp-mxin12.bluewin.ch/> Swisscom AG IP: 
79.134.251.203, You are not allowed 
to send us mail. Please see DNSNULL if you feel this is in error)Reporting-MTA: 
dns; mail.fink.org <http://mail.fink.org/>
Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200
...



Andreas Fink
--
Paradieshofstrasse 101, 4054 Basel, Switzerland
andr...@fink.org <mailto:andr...@fink.org> https://www.fink.org 
<https://www.fink.org/>
Mobile: +41-78-6677333 Office: +41-61-330 Home: +41-61-345
Skype: andreasfink   Jabber/XMPP: andr...@fink.org <mailto:andr...@fink.org>
ICQ: 8239353
Twitter: @kiwi66  PGP Key: https://www.fink.org/FILES/afink-pgp.asc
--






___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SafeHost AS21217 accused to leak routes for two hours to China Telecom AS4134 - anyone from SafeHost to comment?

[Andreas Fink]

Interesting thas this happens at times where a certain bloody event in china 
has its 30th birthday.
Could well be a coincident to see how the world deals with it or an attempt to 
censor it outside of china.
...
or it might just be a stupid engineer's mistake...



> On 9 Jun 2019, at 13:22, Fredy Kuenzler  wrote:
> 
> https://blog.apnic.net/2019/06/07/large-european-routing-leak-sends-traffic-through-china-telecom/
>  
> 
> 
> --
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
> Technoparkstrasse 5
> CH-8406 Winterthur
> Switzerland
> 
> http://www.init7.net/ 
> 
> 
> ___
> 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

Re: [swinog] New BÜPF / VÜPF: Technical, Organisational and Administrative Requirements, March 1, 2019

[Andreas Fink]

where are "FDAs with reduced requirements" defined?


> On 21 Jan 2019, at 20:30, Fredy Kuenzler  wrote:
> 
> Did anyone notice and read the new BÜPF / VÜPF Technical, Organisational
> and Administrative Requirements, valid from March 1, 2019?
> 
> To my understanding FDAs with reduced requirements don't have to do
> anything.
> 
> Press release in DE/FR/IT
> 
> DE
> https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-73716.html
> 
> FR
> https://www.admin.ch/gov/fr/accueil/documentation/communiques.msg-id-73716.html
> 
> IT
> https://www.admin.ch/gov/it/pagina-iniziale/documentazione/comunicati-stampa.msg-id-73716.html
> 
> -- 
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
> AS13030
> Technoparkstrasse 5
> CH-8406 Winterthur
> Twitter: @init7 / @kuenzler
> http://www.init7.net/
> 
> 
> ___
> 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

Re: [swinog] How do website operators get the mobile phone number of visitors?

[Andreas Fink]

> On 7 Dec 2018, at 16:44, Gregor Riepl  wrote:
> 
> 
>> 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.

This is operator specific. It might not work on Swisscom mobile for example.
Also another identifier might be there which can be translated by a service 
from the operator.

Also some cheap mobile phone might leak an identifier while big brands might 
not.

> 
> TLS would effectively defeat any attempt at injecting headers into HTTPS
> traffic - unless the network operator controls a browser-trusted CA and uses
> it to break TLS for man-in-the-middle traffic manipulation.
> 
> Also: It doesn't matter if the connection is direct or goes through a proxy.
> 
>> Is there a trick to make a mobile phone disclose it's phone number
>> while connected via the mobile network's operator network?
> 
> I found this, but I'm not sure if it's implemented in any common mobile
> browser: https://wiki.mozilla.org/WebAPI/MobileIdentity
> 
>> 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'.
> 
> I suspect some network operators provide an API for obtaining subscriber
> information. You should confront your network operator if you're sure you
> didn't agree to disclosing private information via such a service.
> 
> See here for an example:
> https://developer.att.com/technical-library/device-technologies/user-identification
> Seems like a legacy from the WAP age to me.
> 
> I'm pretty sure that such an API would not be public, and there would be
> adequate access protection. It's possible that 'obligo' has an agreement with
> network operators to access such information.
> 
>> Would it be possible, that a fraudster injects such headers from a
>> client to make obligo bill the wrong number?
> 
> If the service uses a local API like MobileIdentity and the service provider
> trusts that information, then sure.
> If it uses strong transport layer security and the information is obtained via
> a secondary channel (like a provider API), then no. Well, unless the attacker
> hijacks the provider API, of course...
> 
> 
> ___
> 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

Re: [swinog] Battery powered wifi link (20km, multihop)

[Andreas Fink]

> On 8 Aug 2018, at 15:43, Nico Schottelius  
> wrote:
> 
> 
> Hey Swinog,
> 
> does anyone have experiences with long distance (~20km) wifi powered
> by battery?
> 
> With have the situation that we basically want to connect Schwanden to
> Linthal by wifi for at least 12 hours.
> 
> The idea is to go via several hops, some of them not having any power
> resource.
> 
> So my questions to the list are:
> 
> - What kind of equipment have you used for similar cases or can you recommend?
> - Are there any battery recommendations?
> - Other creative ideas on how to get a direct link with >= 100 Mbit/s
>  connectivity?
> 


Given big enough dishes and line of sight, this is achieveable. We had 40km 
links in rural areas of Iceland working. Its all a question of terrain, 
interfearance and right equipment.
As far as power goes, a solar system can help to keep it operational.

> Best,
> 
> Nico
> 
> 
> 
> 
> --
> Your Swiss, Open Source and IPv6 Virtual Machine. Now on 
> www.datacenterlight.ch.
> 
> 
> ___
> 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

Re: [swinog] Public Wifi and BüPF

[Andreas Fink]

> On 9 Apr 2018, at 08:44, Jean-Pierre Schwickerath  wrote:
> 
> Dear colleagues
> 
> I'd like to ask if anyone can confirm that the information published on 
> https://www.digitale-gesellschaft.ch/publicwlan/ is accurate in regards
> to being subject to "Überwachungspflichten gemäss BÜPF".
> 
> We have been asked by a customer to sell him a Wifi-Installation for
> his café. We are going to sell him the hardware and do the one time
> installation. Afterwards the customer is running the infrastructure
> himself, he might ask us for help for firmware upgrades and similar
> tasks but we are not going to run that Wifi as a service or do any
> monitoring. 
> 
> If I understand the information on the above page correctly, he doesn't
> need to identify his users, so he won't (and won't store any logs) and
> as a consequence he will not have any information to be stored for 6
> months for the büpf. 
> Is that so?
> 
> The other question that comes to my mind: if the customer provides a
> captive portal to have users acknowledge a "Hausordnung" / code of
> conduct, then the APs will "store" which MAC address has checked the
> box. Does that make his subject to the Büpf?


To my knowledge the information presented represents the current status quo. 
The BÜPF's rule is to assist the police in criminal investigations. Assuming a 
user has used the Wifi-installation and further assume that user has committed 
a serious crime the police has to investigate, then the Cafe owner could be 
asked to assist by providing information. However the simple MAC address would 
not help here because it would only mean that _someone_ has signed up to the 
Café, not that this person has committed the crime or has anything to do with 
it. For that the MAC to IP address matching would have to be stored. 
Furthermore if you don't store any data on the user itself, it wont lead 
anywhere.

If the Cafe owner is considered a telecommunications operator, then he could be 
forced to tolerate wiretapping in such a case (assuming the criminal comes to 
that Café regularly to commit his crime) but I have my severe doubts that this 
might ever be relevant. Firstly because the wiretapping could occur one level 
up by the Café's ISP, secondly, because a Café owner is not really a 
telecommunications provider etc. The people from the BÜPF are not stupid 
neither. They know the real world out there and they know the limitations. So 
they don't go for impossible solutions just because the law could imagine them.

So for the Café owner I think its much more relevant to take care of the 
Datenschutzgesetz properly by _NOT_ storing anything. Then he should be on the 
safe side. The likelyhood he ever will hear from the BÜPF again is very very 
low.

> 
> Thank you very much for your input on this topic. 
> 
> 
> Best Regards
> 
> Jean-Pierre
> 
> -- 
> HILOTEC Engineering + Consulting AG - Langnau im Emmental
> IT für KMUs: Netzwerke, Server, PCs, Linux, Telefonanlagen, 
> VOIP, Hosting, Datenbanken, Entwicklung, WLAN, Cloud, Firewalls
> Tel: +41 34 408 01 00 - https://www.hilotec.com/
> 
> 
> ___
> 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

Re: [swinog] GSM AT command to set 'Validity Period'?

[Andreas Fink]

the validity period is part of the SMS PDU. Which means inside the PDU you need 
to set the correct values.
The AT+CSMP command might only apply to the sms being sent from the handset 
itself or as part of plaintext SMS being sent. But if your software sends raw 
PDU's then it has to be in it.
You might want to look at kannel.org  for sending SMS to a 
GSM modem. Then you can submit the SMS via HTTP to kannel and send it to the 
modem that way. Kannel supports setting the validity period on HTTP.



> On 16 Oct 2017, at 11:56, Benoit Panizzon  wrote:
> 
> Dear Swinogers
> 
> We use smsd to send our nagios alarms via a GSM usb stick.
> 
> I'm looking for some advice after I was not able to find a working
> solution.
> 
> The mobile operator we use has a somewhat short queue to accept SMS
> and when a recipient is not getting the SMS (mobile off during vacation
> or whatever) this sms blocks the queue until it expires. If the queue is
> full, no more sms are being accepted.
> 
> The SMS are being sent with a default validity period of 7 days. So
> they expire from the queue after this period. Well, the easy solution
> would be to sent the period to a couple of hours. No need for techs to
> get old SMS.
> 
> What I did is:
> 
> AT+CSMP=17,143,0,0 // Set Validity Period to 12 hours.
> AT+CSAS // Save settings to SIM
> 
> If I query the settings:
> 
> AT+CSMP?
> 
> I see these values are set. But after contacting the mobile operator to
> check if the VP is correct, he tells me we still send them with default
> 7 days.
> 
> Does anyone have a hint on how to set the VP correctly via AT commands?
> 
> Kind regards
> 
> -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 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> 
> 
> ___
> 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

Re: [swinog] Bind9 9.9.5 memory exhaustion attack?

[Andreas Fink]

The permuted case serves a well documented purpose and will not generate 
duplicate cache entries.
See this document explaining it: 
https://indico.dns-oarc.net/event/20/session/2/contribution/12/material/slides/0.pdf
 
<https://indico.dns-oarc.net/event/20/session/2/contribution/12/material/slides/0.pdf>

Andreas Fink

Fink Telecom Services, Rackbone.ch, Cajutel.com
--
E-Mail: andr...@fink.org www.fink-telecom.com www.rackbone.ch www.cajutel.com
Mobile: +41-78-6677333 Skype: andreasfink Jabber/XMPP: andr...@fink.org
--



> On 4 Feb 2017, at 11:03, Benoit Panizzon <paniz...@woody.ch> wrote:
> 
> Hello All
> 
> Anyone else running bind9 and seeing a lot of request with permuted
> case in the requested resource, which I fear causes bind9 to cache
> each reply individually leading to memory exhaustion?
> 
> -Benoît-
> 
> 
> ___
> 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

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Andreas Fink]

> Am 14.09.2016 um 18:33 schrieb Jeroen Massar <jer...@massar.ch>:
> 
> On 2016-09-14 18:13, Andreas Fink wrote:
>> I could do a presentation on the SCTP networking protocol which combines
>> some features of TCP and UDP and offers some unique features neither TCP
>> nor UDP have.
> 
> Is there any tool that actually uses SCTP ? :)

I'm using it day in day out since 15 years. And theres no alternative to it for 
me. The Sigtran family (SS7 signalling over IP) requires it mandatory. Theres 
no other option there. SCTP was mainly developed because signalling over IP 
needed reliable multipath support. So protocols which 100% depend on SCTP are 
at least M2UA, M2PA, M3UA, SUA, IUA.

> IPFIX is supposed to use it, but everybody still sends over UDP, rare
> support for SCTP (except for purists like me who did implement it and
> then also never really used it).

Great. why did you not use it? UDP is not a reliable datagram service. SCTP is.

> WebRTC is supposed to go partially over SCTP, never seen it actually used.

WebRTC requires it (but can work around by encapsulating it into UDP which just 
means more useless overhead).

> Apple chose to use Multipath TCP instead...

OS X has a implementation of SCTP since OS X  10.3.8. Its open source. Apple 
has not added it to the kernel (besides promising it many many many times) 
because it would mean changing their NAT & Firewall as well and as there is no 
user demand, they where too lazy and rather wanted to spend time on nice shiny 
guy stuff. The kext is kernel dependent due to a missing API to link in a 
layer4 protocol so every new version needs awaiting new kernel sources to be 
published and recompiling (10.12 however worked out of the box with 10.11 
sources). I have like 20 radars open with Apple about it (*big sight*).

Linux has SCTP built in since a long time. Solaris, has it. HP/UX has it. 
Windows I actually don't know.

Part of the problem is:  If desktops don't have it, then developers don't tend 
to use it. If developers don't want to use it, then the OS vendors dont tend to 
implement it.  This however also applies to other layer 4 transport protocol. 
Thats why everyone uses plain old TCP and UDP.

Also 10$ crap ADSL routers who don't understand how to properly implement NAT 
don't help either. Hopefully NAT will be a relict of the past soon due to IPv6 
(*cough cough*).

> The article on Wikipedia does not list much more:
> https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
> 
> Apparently some variant of SSH should support it, but no actual
> implementations mentioned there either.

Any application which uses TCP or UDP could be changed into using SCTP by a 
single line of code. (hint: IPPROTO_SCTP on socket()) However there are 
additional features which neither TCP or UDP have such as seamless adding 
removing IP's on a established session, Multipath support. stream multiplexing, 
concurrent establishment of a connection from both sides (think of tunnels for 
example) and others. From a developers point of view there's a lot in it, 
especially if you care about reliability. SCTP is proven, reliable, established 
and well supported in the Unix arena. Developers just have to know about that 
its there and it is useful for many things.

That's why I think the key is to let developers know that there's a cherry to 
be picked up. 
And I would be happy to present its benefits and features.

But if we only have java developers here who usually encode a boolean into a 
UTF16 string into XML over SOAP over HTTP over a 10G fiber link, then it would 
be a waste of time of course.


Andreas Fink


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Andreas Fink]

I could do a presentation on the SCTP networking protocol which combines some 
features of TCP and UDP and offers some unique features neither TCP nor UDP 
have.


> Am 14.09.2016 um 18:02 schrieb Simon Ryf <si...@swinog.org>:
> 
> Dear SwiNOG supporter,
> 
> this is the official Call for Paper email. Please send your proposal to
> swinog-core (at) swinog.ch or directly to me.
> The 30th meeting of the Swiss Network Operators Group (SwiNOG) will be held
> in Berne on top of the Gurten on November 4th 2016.
> 
> 
> Important Dates for SwiNOG#30
> ---
> 17.08.2016 Announcement of Meeting
> 05.09.2016 Registration opens
> 14.09.2016 Call for Papers
> 16.10.2016 Call for Papers closing
> 23.10.2016 Final publication of agenda
> 27.10.2016 Registration closes
> 01.11.2016 Deadline for all slides
> 04.11.2016 Meeting day
> 
> 
> Topics for Presentations/Talks
> ---
> The number and length of presentations per session is not fixed, although
> due to time constraints we would prefer the length of the presentations to
> be between 5 to 45 minutes.
> Here is a non-exhaustive list of typical SwiNOG meeting topics:
> - Security - DDOS Mitigation - AntiSpam
> - IPv6
> - Open Source tools
> - International view of the internet (incidents, outages, measurements)
> - Routing
> - Server applications (DNS, Web, etc.)
> - Legal issues (BÜPF, etc.)
> - Telecommunication politics (Net Neutrality, Incumbent monopoly, etc.)
> 
> -> PLEASE feel free to talk to us about any kind of topic and
> collaboration!!!
>   You can always start a discussion on the list - I'm sure people join in.
> 
> Language of Slides and Talks
> ---
> The whole day will be held in English, therefore we kindly ask you to
> produce your presentation in English.
> 
> Submission Guidelines
> ---
> All submissions must have a strong technical bias and must not be solely
> promotional for your employer.
> Please remember that your presentations should be suitable for a target
> audience of technicians from varied backgrounds, working for companies whose
> sizes may vary considerably.
> To submit a proposal for a presentation, we request that you provide the
> following information to :
> 
> * the name of the presenter (and if applicable your affiliation)
> * a working email address
> * the name and number of the topic which will contain the presentation
> * the title of the presentation
> * its expected length (in minutes)
> * a short abstract of the presentation (so we know what it is about)
> 
> We also welcome suggestions for specific presentations which you feel would
> be valuable to the SwiNOG community.
> Please be aware that your presentation will be published on the SwiNOG
> website after the event. We can publish modified slides if requested - it
> might be that some confidential data will be presented by you which are not
> intended for publication on the internet.
> 
> Greetings,
> Simon Ryf
> SwiNOG Core Team
> 
> 
> General Information (SwiNOG Community)
> ---
> The Swiss Network Operators Group (SwiNOG) is an informal group of people
> who are concerned with engineering and operation of the Swiss Internet.
> SwiNOG exists to enhance the quality of Internet services available in
> Switzerland. It does this by fostering the free exchange of technical ideas
> and information between different companies and organisations.
> SwiNOG is a community for professionals who are operating, designing or
> researching the Internet. It provides a technical forum where those working
> on, with and for the Internet can come together to solve problems with every
> aspect of their (net)work.
> The meeting is designed to provide an opportunity for the exchange of
> information among network operators, engineers, researchers and other
> professionals close to the network community.
> 
> More information about SwiNOG can be found at http://www.swinog.ch/,
> Facebook, Xing, 
> Information about the meeting will be published at
> http://www.swinog.ch/meetings/swinog30/ 
> 
> General Information (SwiNOG Organisation)
> ---
> The SwiNOG Organisation Association is a non-profit association under
> article 60 and further of the swiss civil law. It manages the SwiNOG
> community ressources (domain, web, mailing-lists, etc..) and organises
> SwiNOG meetings.
> 
> Contact:
> SwiNOG Organisation
> 8000 Zurich
> Switzerland
> 
> 
> 
> ___

Re: [swinog] TCP timestamps

[Andreas Fink]

> On 11 Mar 2016, at 11:40, Robert Meyer  wrote:
> 
> Hi,
> 
>> Furthermore ICMP is _mandatory_ for MTU path discovery to work. So be ready 
>> for all kind of non functioning stuff if you transfer larger packets than 
>> the MTU somewhere in the middle (such as trying to squeeze a 1500 byte 
>> ethernet packet into a  IPSec tunnel with a MTU around 1426). TCP/IP is 
>> built in the way that it reacts on these ICMP MTU mismatch messages when 
>> packets get dropped on the way due to too big size. TCP can adapt but if 
>> ICMP is filtered away, then TCP will not notice and a endless retransmission 
>> dance begins. The odd thing there is that it "kinda works". Sometimes its 
>> just slow and sometimes nothing works. We use IPSec in our network heavily 
>> and we have seen that happening with large corporations such as 
>> Networksolutions.com (which is one of the oldest companies in the internet, 
>> they should know this stuff!). T1his can be a big issue. So if I ever find a 
>> consultant telling me I should filter away ICMP just because, I will kick 
>> him out of the door immediately. The on
> ly reason where this could be valid is if you still have Windows95 machines 
> in your network due to the "ping-of-death" bug. But if you have that, then 
> you're hopelessly lost anyway.
> 
> This is basically only true for ipv6. In ipv4 network devices
> can fragment. This does not mean, that I would consider
> filtering icmp a reasonable idea.

they COULD fragment but 99% of the routers do drop and send back a ICMP back

> 
>> 
>> Let's face it. Firewalls and NAT have been built to break the internet in 
>> the way it has been intended with all kinds of strange side effects. 
>> Thinking they are the only defence to protect you is so wrong. Social 
>> engineering brings hackers behind firewalls and they attack from with 
>> inside. A well secured localhost is way more important. I'm using machines 
>> on public IP's without firewall or NAT in between over 20 years and the 
>> issues I've seen have all been controllable (but I'm not an interesting 
>> target to hack like a Bank). On the other hand NAT & Firewalls (and their 
>> admins) have turned out to be a way bigger problem.
> 
> NAT and Firewalls are not the biggest problem, but there is just
> too many people around configuring these devices with a limitted
> understanding, of how the internet works.

I can only confirm  that..



signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] TCP timestamps

[Andreas Fink]

> On 11 Mar 2016, at 01:33, Roger <ro...@mgz.ch> wrote:
> 
> Hi Swinogers
> well maybe the same experts where asked for an expertise  from AVM for the 
> new Firmware upgrade on the router products this days.
> They proudly announced to have a Stealthmode implemented, which of corse is 
> just a drop of ICMP Requests, which user find Evil because someone told once 
> in a newspaper several years agow :D
> But they maybe never did have the idea there are ICMP types which could be 
> used for real evil things than just getting an answer back ;)
> i would read this crap several times, then think about what made sense, maybe 
> that will be unsuccessful and then i will be shure there is a dustbin 
> unterneath your desk.
> 
> Roger
> 

Furthermore ICMP is _mandatory_ for MTU path discovery to work. So be ready for 
all kind of non functioning stuff if you transfer larger packets than the MTU 
somewhere in the middle (such as trying to squeeze a 1500 byte ethernet packet 
into a  IPSec tunnel with a MTU around 1426). TCP/IP is built in the way that 
it reacts on these ICMP MTU mismatch messages when packets get dropped on the 
way due to too big size. TCP can adapt but if ICMP is filtered away, then TCP 
will not notice and a endless retransmission dance begins. The odd thing there 
is that it "kinda works". Sometimes its just slow and sometimes nothing works. 
We use IPSec in our network heavily and we have seen that happening with large 
corporations such as Networksolutions.com (which is one of the oldest companies 
in the internet, they should know this stuff!). T1his can be a big issue. So if 
I ever find a consultant telling me I should filter away ICMP just because, I 
will kick him out of the door immediately. The only reason where this could be 
valid is if you still have Windows95 machines in your network due to the 
"ping-of-death" bug. But if you have that, then you're hopelessly lost anyway.

Let's face it. Firewalls and NAT have been built to break the internet in the 
way it has been intended with all kinds of strange side effects. Thinking they 
are the only defence to protect you is so wrong. Social engineering brings 
hackers behind firewalls and they attack from with inside. A well secured 
localhost is way more important. I'm using machines on public IP's without 
firewall or NAT in between over 20 years and the issues I've seen have all been 
controllable (but I'm not an interesting target to hack like a Bank). On the 
other hand NAT & Firewalls (and their admins) have turned out to be a way 
bigger problem.


Andreas Fink
DataCell ehf, Backbone ehf, Cajutel Inc, Alisanus GmbH
--
c/o Alisanus GmbH Clarastreasse 3, 4058 Basel, Switzerland
E-Mail: andr...@fink.org <mailto:andr...@fink.org> https:// 
<https://www.fink.org/>www.fink.org <https://www.fink.org/>
Mobile: +41-78-6677333 Office: +41 61 330
Skype: andreasfinkJabber/XMPP: andr...@fink.org <mailto:andr...@fink.org> 
ICQ: 8239353
--


> 
> 
> 
> On 10/03/2016 12:12, Andre Keller wrote:
>> Dear fellow SwiNOGers,
>> 
>> in the last few months we had several security audits and all of them 
>> proposed to disable tcp timestamps. (i.e. on Linux 
>> net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp relies 
>> on this and there might be implications for PAWS (tcp sequence number 
>> wrapping).
>> 
>> What do you guys think about this?
>> 
>> 
>> Regards
>> André
>> 
>> 
>> ___
>> swinog mailing list
>> swinog@lists.swinog.ch <mailto:swinog@lists.swinog.ch>
>> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog 
>> <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



signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] VoIP provider

[Andreas Fink]

Does anyone know a list of VoIP providers in Switzerland who can port in a 
number block?

I'm looking for one which supports SIPS (via TLS) and SRTP and can do trunking 
to a PABX of my choice.
The big guys only support their own certified crap and the small ones don't 
support privacy required features which  changed post Snowden from "want to 
have" to "absolutely mandatory" feature.


Andreas Fink
DataCell ehf, Backbone ehf, Cajutel Inc, Alisanus GmbH
--
c/o Alisanus GmbH Clarastreasse 3, 4058 Basel, Switzerland
E-Mail: andr...@fink.org <mailto:andr...@fink.org> https:// 
<https://www.fink.org/>www.fink.org <https://www.fink.org/>
Mobile: +41-78-6677333 Office: +41 61 330
Skype: andreasfinkJabber/XMPP: andr...@fink.org <mailto:andr...@fink.org> 
ICQ: 8239353
--





signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Mikrotik SFP no link

[Andreas Fink]

things to know:

Your device has one SFP (1G only) and one SFP+ port (10G)

1. I'm not 100% sure but I think the SFP+ port is 10G only on this model. So be 
sure to use the 1G only port. On the  CCR1072 I know it's 10G or 1G but you 
have to put auto-negotiation to off and set the rate to 1G manually to get 1G 
on a 10G port. Otherwise you will see light and link but the other side see's 
nothing. For a 1G port, use auto negotiation.

2. the web interface returns wrong values for  rxpower in RouterOS 6.33 as they 
changed some API to it but didn't update the Web GUI for it. The command line 
value is ok however. Its fixed in current 6.34 release candidate. In my case I 
got like 4 billion watts of light power indicated which would convert my tiny 
little router in an atomic reactor in the size of our sun if it would be 
correct.

3. Your system says no-link  which sounds to me like no incoming light. Are you 
sure the patch cable is of correct type and orientation? try swapping RX/TX


> On 17 Nov 2015, at 13:20, Andre Timmermann  wrote:
> 
> Hello,
> 
> I recently bought a Mikrotik CR1009-8G-1S-1S+. I added a Mikrotik S
> -31DLC20D SFP module to connect my internet uplink.
> The uplink provider confirmed that the uplink should be working with
> wavelength 1310 nm, single mode, 1GBit, no auto negotiation.
> 
> Unfortunately the webinterface shows "no link". Firmware is 6.33 and I
> rebooted the device - still no link.
> 
> Please note that I do NOT get a value for sfp-rx-power in the
> webinterface or the following dump. Is that a hint that the fiber is
> not OK or is that conclusion invalid?
> 
> /interface ethernet monitor 9
> name: sfp1
> status: no-link
> auto-negotiation: disabled
> sfp-module-present: yes
> sfp-rx-lose: yes
> sfp-tx-fault: no
> sfp-type: SFP-or-SFP+
> sfp-connector-type: LC
> sfp-link-length-9um: 2m
> sfp-link-length-50um: 550m
> sfp-link-length-62um: 550m
> sfp-vendor-name: Mikrotik
> sfp-vendor-part-number: S-31DLC20D
> sfp-vendor-revision: A0
> sfp-vendor-serial: MT50617H2074
> sfp-manufacturing-date: 15-06-24
> sfp-wavelength: 1310nm
> sfp-temperature: 50C
> sfp-supply-voltage: 3.237V
> sfp-tx-bias-current: 21mA
> sfp-tx-power: -7.055dBm

this is how mine looks:
/interface ethernet> monitor 9
  name: sfp1
status: link-ok
  auto-negotiation: done
  rate: 1Gbps
   full-duplex: yes
   tx-flow-control: no
   rx-flow-control: no
   advertising:
  link-partner-advertising:
sfp-module-present: yes
   sfp-rx-lose: no
  sfp-tx-fault: no
  sfp-type: SFP-or-SFP+
sfp-connector-type: copper-pigtail
sfp-link-length-copper: 3m
   sfp-vendor-name: Molex Inc.
sfp-vendor-part-number: 74743-0021
   sfp-vendor-revision: A
 sfp-vendor-serial: 131330080
sfp-manufacturing-date: 10-11-09


signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Legal: Email Dienstleistung: Kunden im Ausland?

[Andreas Fink]

Als schweizer Firma unterstehst du schweizer Recht.
Wenn deine Server auch in der Schweiz stehen, kann dir das Ausland egal sein.

Dein Kunde wiederum kann dem ausländischen Recht unterstehen. D.h. dein Kunde 
muss dann ev. dafür sorgen das seine Ermittlungsbehörden zugriff kriegen, das 
ist dann aber nicht dein Problem.

 On 03 Mar 2015, at 12:04, Benoit Panizzon benoit.paniz...@imp.ch wrote:
 
 Hallo zusammen
 
 Wir bieten einen Email Hosting Service für Kunden und andere Provider an.
 
 Wir haben nun einen potentiellen Interessenten im Ausland. Einen ISP.
 
 Nun stellt sich die Frage, nach welchem Recht wir den Service erbringen
 müssen. Gilt, weil der Service in der Schweiz erbracht und die Mailboxen auf
 Storage in der Schweiz liegen, Schweizer Recht?
 
 Oder gilt, da der ISP sozusagen Reseller unserer Dienstleistungen ist, was
 Legal Intercept, Überwachung und Anforderung an Logging betrifft, das Recht im
 Land des ISP der unsere Leistung unter seinem 'Markennamen' verkauft?
 
 Was also heissen müsste, dass wir unser System möglicherweise entsprechend
 anpassen und entsprechende Schnittstellen für die Überwachung aus einem
 Drittstaat anbieten müssten?
 
 Gruss
 
 Benoit Panizzon
 --
 I m p r o W a r e   A G-
 __
 
 Zurlindenstrasse 29 Tel  +41 61 826 93 07
 CH-4133 PrattelnFax  +41 61 826 93 02
 Schweiz Web  http://www.imp.ch
 __
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Auskunft über Personendaten / deutsches Recht anwendbar?

[Andreas Fink]

 Am 23.12.2014 um 13:06 schrieb Q-X GmbH - Pascal Wagenhofer 
 wagenho...@q-x.ch mailto:wagenho...@q-x.ch:
 
 Hallo SWINOGer
  
 I hope, you’re enjoying already the holidays somewhere around.
  
 We’re having here a little difficulties with a german lawyer. We’re offering 
 shared hosting services. One of our customers is sharing links to 
 uploaded.net http://uploaded.net/, which contains music, which might be 
 copyright protected.
  
 The german law agency is now requesting the data of the owner which – 
 apparently – we cannot provide due to restrictions of the data protection law 
 of Switzerland. They’re supplying us this judgement: 
 http://www.justiz.nrw.de/nrwe/olgs/koeln/j2011/6_U_87_10urteil20110325.html 
 http://www.justiz.nrw.de/nrwe/olgs/koeln/j2011/6_U_87_10urteil20110325.html 
 .
  
 Question to the community:
 1.   What are you doing in such situations? (Yes, appart from contact 
 your lawyer ;-) ).


Assuming you are in Switzerland they can decide whatever they want in germany 
according to german law but if they want to enforce it, then they have to ask 
for help from the swiss authorities (Rechtshilfeverfahren). However the swiss 
side would only provide help if the request would be valid under swiss law as 
well.

In other words, you can simply sit back and wait until a swiss judge asks you 
to provide the information. Then you are safe as you only followed what a swiss 
court has ruled. Otherwise you risk of giving out information whereas your 
customer could sue you because under swiss law you are not allowed to give it 
out.

The only exception would probably if there is imminent danger which requires 
immediate action to prevent severe damage.

The more interesting question in this judgment from 2011(so already 3 years 
old, do you have that old logs) is that they talk about copyright infringement. 
However linking to a download page can not be considered illegal as downloading 
copyrighted content is not illegal neither under swiss law. Only providing the 
download (uploading of the content, not a link to content) is considered 
illegal.


 2.   Did you have similar issues and how did you handle them?


Not directly that way but, yes. Let the police work it out between them. As a 
swiss entity you are obliged to follow swiss laws and nothing else.
otherwhise we would have tons of DCMA court cases here. The only thing I 
usually see is some Lawyers (in big quotes) trying to intimidate the end user 
to try to stop what they think is piracy. MPAA pays millions and millions for 
this with no result (accoring to the Sony leaks...). I would not worry until 
the swiss police asks you the information with a court order according to swiss 
law.

If you still have the information after that many years is then another story.



  
 I wish you merry Christmas and a happy new year.
  
 kind regards
  
 Pascal Wagenhofer
 Technical Services
  
 Q-X GmbH
 Schmittestrasse 5
 Postfach 61
 CH-8308 Illnau / Switzerland
  
 Phone 0840 11 11 10 (International +41 840 11 11 10) (Lokaltarif)
 Fax 0840 22 22 20 (International +41 840 22 22 20) (Lokaltarif)
 www.Q-X.ch http://www.q-x.ch/
  
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch mailto:swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog 
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



Andreas Fink

CEO DataCell ehf
CEO Backbone ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org mailto:andr...@fink.org
www.datacell.com http://www.datacell.com/, www.backbone.is 
http://www.backbone.is/, www.finkconsulting.com 
http://www.finkconsulting.com/ www.fink.org http://www.fink.org/
---
Jabber/XMPP: andr...@fink.org mailto:andr...@fink.org
ICQ: 8239353 Skype: andreasfink 





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] 3G Repeater

[Andreas Fink]

On 31 Jul 2014, at 10:26, Roger Schmid ro...@mgz.ch wrote:

 Am 31/07/2014 02:28, schrieb Miguel Elias:
 
 First, any usage of active signal repeater is forbidden in Switzerland.
 (Statement of Bakom). Any base station system or signal repeater has to
 be owned / managed by an official frequency licensee. Signal repeater
 used in the field, do have some sophisticated measurement and control
 abilities.
 
 very strange are there bakom aproved repeater on the market
 
 http://www.antx.ch/repeater.php they claim to be the only aproved one
 well i know the amplitec, they dont have a sufficient feedback control, i 
 would question this advertisement
 and:
 a friend got from arp i believe, a repeater with an bakom bakom certification.

note: having a CERTIFICATION means the device operates within the bounds. This 
does not automatically mean it is LICENSED to use.
For example if I buy a Radio for taxi operation, the vendor CERTIFIES it 
follows all the rules and doesnt make spurious emissions  but that doesnt mean 
I can operate it as I want. I still need a license to operate it. The tricky 
thing here is that the repeater will start to transmitt on frequencies 
allocated to base statiions which are licensed to the mobile operators. Hence 
Sunrise, Siwscom and Orange could use this device but you as an individual not. 
Its a bit of a grey zone in most countries as the legal question is who is  
transmitting. Is it the original base station or is it the repeater.





signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] 3G Repeater

[Andreas Fink]

On 30 Jul 2014, at 02:43, Fredy Kuenzler kuenz...@init7.net wrote:

 Is anyone familiar with 3G repeater gear? I'm asking for a neighbor whose 
 family owns a cottage in a Swiss mountain valley with poor 3G reception.

As a licensed amateur radio operator, I know that there is no easy answer.

Things to consider:

 3G is a term used for the modulation and protocol technology but is not in 
reflection to the frequency. 
Traditionally 1900 or 2100Mhz is used but these days you might see 3G on 900Mhz 
too.
If we talk about LTE 4G, we have over 40 official frequency ranges which in 
theory could be used. And LTE uses technologies such as MIMO with multiple 
antenna paths to get more throughput.
As far as I know in Switzerland 2600MHz and 800MHz are used for LTE besides the 
traditional GSM frequencies 900,1800,1900,2100.
All of these bands have different uplinks and downlink frequencies (FDD).

The chinese repeater products at the end of the day are simply an antenna + 
amplifier + band splitter. This means they receive the downlink from the 
outside antenna, amplify it and feed the inside antenna with the signal and on 
the uplink it does the reverse. The problem arises if the indoor antenna can 
feed a signal into the outdoor antenna. In this case, the repeater would send a 
signal to itself and start to oscillate. Secondly, if you look at the 
frequencies, you would have the need for amplifiers for all the different bands 
separately and also good band filter. This means the cheap devices simply only 
operate on one frequency band only. You sometimes see dual band versions but 
they are already rate.

On terms of the legality I'm not 100% sure as you would start to transmit a 
frequency which belongs to the operator.
Its at least a bit of a grey zone as you don't control the transmission as you 
only repeat. Maybe with the blessing of the operator this could be ok.
I'm sure they do such things for locations such as shopping centers. On the 
other hand they could as well use microcells in those areas for capacity 
reasons.
Something which is not possible without a wired connection.

The best thing you could do is to put a good outside highly directional antenna 
and connect it directly to the device. A good antenna is your best amplifier.
Also possible is a passive setup with a indoor antenna coupled with an outdoor 
antenna. This will basically simply change the antenna characteristic of the 
internal antenna of the device by coupling it with the outdoor antenna. It is 
never as good as a direct wired connection as you have considerable coupling 
losses.
If this doesn't work, you can still consider adding an active repeater.

Another alternative is to simply put up a microwave point to point link to a 
location where you have better connectivity and simply relay the connectivity 
through. But this of course needs another location with power. If i say 
microwave, this can be some decent Wifi devices such as a Mikrotik SXT on 
5GHz. They cost like 60-110$ a piece.

 
 Any recommendation for gear which is easily installable, more or less 
 plug-n-play, not too expensive (less than CHF 1000) and last but not least 
 legal to operate would be appreciated.
 
 --
 Fredy Kuenzler
 Init7 (Switzerland) Ltd.
 St.-Georgen-Strasse 70
 CH-8400 Winterthur
 Switzerland
 
 http://www.init7.net/
 
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



signature.asc
Description: Message signed with OpenPGP using GPGMail

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Scenic route of the day: L3 towards UPC

[Andreas Fink]

...or modify your webservers to not deliver web content on such routes to avoid 
PRISM and inform the customer about the shortcut of his switzerland to 
switzerland data over NSA territory...
Imagine seeing such alerts while trying to pay your bills on ebanking...
Reminds me of redwindow around the 1996 for the oldies among you.



On 26.09.2013, at 15:57, Matias Meier me...@matias.ch wrote:

 Hi
  
 Ccom helpdesk won’t help you, because they don’t even know what routing is… 
 You need to send routing related things to peer...@aorta.net
  
 remarks:Peering Requests: peer...@aorta.net
 remarks:Routing Issues:   peer...@aorta.net
  
  
 Freundliche Grüsse
  
 Matias Meier
 Online WebToolbox: www.webtoolbox.ch
  
 Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch] 
 Im Auftrag von Stephan Wolf
 Gesendet: Donnerstag, 26. September 2013 15:47
 An: swinog
 Betreff: Re: [swinog] Scenic route of the day: L3 towards UPC
  
 I have seen things here similar to this very often / permanently:
 
 cablecom  to UK/NL often via level3 and washington instead going directly
 
 may something to do with UPC and partnership with level3 - and the 
 Nonpartners of level3.
 
 we do not peer with you politics ?! 
 
 imho   cogent vs level3
 
 below a trace to system in london from cablecom home:
 
   2 9 ms17 ms 7 ms  x.dclient.hispeed.ch [x]
   310 ms11 ms10 ms  217-168-58-101.static.cablecom.ch 
 [217.168.58.101]
   4   111 ms   101 ms   101 ms  84.116.211.22
   5   101 ms   183 ms   102 ms  84.116.204.225
   6   102 ms   101 ms   101 ms  84-116-130-181.aorta.net [84.116.130.181]
   7   102 ms   101 ms   101 ms  84.116.133.185
   8   101 ms   101 ms   110 ms  84.116.134.62
   9   110 ms   107 ms   158 ms  te-4-1.car3.Washington1.Level3.net 
 [4.79.168.201]
  10 *  110 ms   117 ms  ae-3-80.edge3.Washington4.Level3.net 
 [4.69.149.146]
  11   108 ms   107 ms   109 ms  Cogent-level3-1x10G.washington.Level3.net 
 [4.68.63.174]
  12   149 ms   109 ms   109 ms  be2113.mpd21.dca01.atlas.cogentco.com 
 [154.54.6.170]
  13   111 ms   174 ms   107 ms  te0-0-0-20.ccr21.jfk02.atlas.cogentco.com 
 [154.54.42.22]
  14   180 ms   179 ms   191 ms  te0-2-0-2.mpd22.lon13.atlas.cogentco.com 
 [154.54.42.54]
  15   200 ms   179 ms   193 ms  te0-7-0-30.ccr21.lon01.atlas.cogentco.com 
 [130.117.0.117]
  16   215 ms   232 ms   192 ms  te2-1.ccr01.lon18.atlas.cogentco.com 
 [154.54.61.214]
  17   190 ms   191 ms   183 ms  149.14.8.34
  18   179 ms   179 ms   180 ms  y
 
 tried multiple times to escalate this in ccom helpdesk.
 was silted there..
  
 
  
 
  
 
 2013/9/26 Fredy Kuenzler kuenz...@init7.net
 Anyone else seeing this... do we have a new peering spat or is it just a
 random routing issue?
 
 Regards,
 Fredy
 
 
 
 traceroute to 84.116.204.234 (84.116.204.234), 30 hops max, 60 byte packets
  1  r1zlz1.core.init7.net (77.109.136.233) [AS13030]  23.682 ms  23.741
 ms  23.775 ms
  2  r1zrh1.core.init7.net (77.109.128.209) [AS13030]  0.188 ms
 r1zrh2.core.init7.net (77.109.128.74) [AS13030]  0.199 ms
 r1zrh1.core.init7.net (77.109.128.209) [AS13030]  0.193 ms
  3  r1bas1.core.init7.net (77.109.128.130) [AS13030]  1.090 ms  1.129 ms
 r1fra1.core.init7.net (77.109.128.250) [AS13030]  38.806 ms
  4  r1fra2.core.init7.net (77.109.128.133) [AS13030]  5.997 ms  5.988 ms
  6.016 ms
  5  TenGigabitEthernet8-1.ar2.FRA4.gblx.net (64.213.54.33) [AS3549]
 6.653 ms  6.134 ms  6.673 ms
  6  ae7.edge2.SanJose3.level3.net (4.68.62.177) [AS3356]  153.420 ms
 152.925 ms  153.399 ms
  7  vlan70.csw2.SanJose1.Level3.net (4.69.152.126) [AS3356]  161.564 ms
 vlan90.csw4.SanJose1.Level3.net (4.69.152.254) [AS3356]  161.054 ms
 vlan70.csw2.SanJose1.Level3.net (4.69.152.126) [AS3356]  161.807 ms
  8  ae-71-71.ebr1.SanJose1.Level3.net (4.69.153.5) [AS3356]  160.948 ms
 ae-61-61.ebr1.SanJose1.Level3.net (4.69.153.1) [AS3356]  160.512 ms
 160.433 ms
  9  ae-2-2.ebr2.NewYork1.Level3.net (4.69.135.186) [AS3356]  161.355 ms
  161.310 ms  161.509 ms
 10  ae-47-47.ebr2.NewYork2.Level3.net (4.69.201.34) [AS3356]  161.949 ms
 4.69.201.38 (4.69.201.38) [AS3356]  161.581 ms  161.724 ms
 11  ae-1-100.ebr1.NewYork2.Level3.net (4.69.135.253) [AS3356]  162.124
 ms  161.121 ms  161.658 ms
 12  4.69.201.85 (4.69.201.85) [AS3356]  161.126 ms 4.69.201.93
 (4.69.201.93) [AS3356]  161.524 ms 4.69.201.85 (4.69.201.85) [AS3356]
 161.193 ms
 13  ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS3356]
 161.151 ms  161.558 ms ae-82-82.csw3.Washington1.Level3.net
 (4.69.134.154) [AS3356]  161.627 ms
 14  ae-33-80.car3.Washington1.Level3.net (4.69.149.133) [AS3356]
 185.388 ms ae-43-90.car3.Washington1.Level3.net (4.69.149.197) [AS3356]
  263.449 ms ae-23-70.car3.Washington1.Level3.net (4.69.149.69) [AS3356]
  264.054 ms
 15  UPC-BROADBA.car3.Washington1.Level3.net (4.79.168.202) [AS3356]
 161.118 ms  161.109 ms  160.838 ms
 16  84.116.134.61 (84.116.134.61) [AS6830]  167.752 ms  167.674 ms
 159.751 ms
 17  

Re: [swinog] Public IP with mobile subscription

[Andreas Fink]

Swisscom has this option as APN corporate.swisscom.ch, user testprofil password 
temporary
You have to call them to get this option enabled. You will get public IP but 
dynamic one without NAT or filtering

Von meinem iPad gesendet

Am 07.06.2013 um 13:38 schrieb Silvan M. Gebhardt gebha...@openfactory.ch:

 I recall that a couple of years (3 or 4) I was able to order the VPN option 
 (and had to change the APN afterwards) with sunrise and actually managed to 
 get a public IP that way.
 
 - Ursprüngliche Mail -
 Von: Jeroen Massar jer...@massar.ch
 An: Wunderlin Daniel d...@icgroup.ch
 CC: swinog@lists.swinog.ch
 Gesendet: Freitag, 7. Juni 2013 17:03:19
 Betreff: Re: [swinog] Public IP with mobile subscription
 
 On 2013-06-07 01:00, Wunderlin Daniel wrote:
 Does anyone know: Is it possible to buy a public ip with a mobile
 subscription (gprs) or use a dyndns? I think they do nat at swisscom and
 sunrise.
 
 Just get one of those cheap (ahem) connections and run any kind of
 tunnel/VPN over it.
 
 AYIYA works like a charm in these kind of setups and nicely gives you a
 public IPv6 prefix ;)
 
 Greets,
 Jereon
 
 
 
 
 ___
 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

Re: [swinog] Cablecom Home to London via USA

[Andreas Fink]

side note: I was testing LTE in Basel. Speed is lower than 3G (like 3-5M/sec)
I wondered why as my friends in Finland get like 40M/s

What spring to my mind however is that the speed test tools do in fact measure 
speed with local providers around the corner. And as far as I know, swisscom 
doesn't peer on SwissIX with them so it might very likley be a similar 
ping-pong through somewhere else in europe or USA which is potentially ruining 
the speed. Of course it could simply be not enough capacity inside the mobile 
network. 

My point is:
PEERING PAYS OFF. No matter how evli your competitor might look like, both 
save money and gain speed.
Even ISP's in other parts of the world have started to realize that its stupid 
to send off traffic across continents just because they don't like the 
competitor.


On 05.02.2013, at 23:47, Bernd SPIESS bernd.spi...@essgroup.at wrote:

 
  358 ms58 ms43 ms
 217-168-58-101.static.cablecom.ch[217.168.58.101]
  4   139 ms   140 ms   145 ms  84.116.211.22
 I'd say here's where the problem begins and it still UPC network I think.
 
 sorry - no - as the handover takes part in washington you have twice
 the atlantic in between... it´s a problem of peering/transiting in usa and 
 not a 
 upc internal problem in ch.
 
 it is the responsibility of the first network handing over in europe on the
 way up and it is the responsibility of the second network handing 
 over also in europe on the way down. (zurich, amsterdam or london
 would be suited in this case)
 
 as this is not the the case here you should tell them to fix that, or choose
 another provider who does good ip housekeeping.
 
 bernd
 
 
 
 
 ___
 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

Re: [swinog] Switzerland judged Cleanest Country

[Andreas Fink]

Doesnt matter. Switch is only following the rules in the law.
Now we can argue if its a good law or not. And we can launch a public voting 
for this in switzerland (not like in germany)



On 13.08.2012, at 21:47, Oliver Schad oliver.sc...@oschad.de wrote:

 On Mon, 13 Aug 2012 10:55:04 +0200
 Guillaume Leclanche guilla...@leclanche.net wrote:
 
 I think the law makes a good job of delimiting the cases where the
 block can be done. In addition, I think Switch makes a good job
 applying this law.
 I'd be happy that switch blocks one of my domains to prevent me
 from being sued for damages by some infected people.
 
 If the entities domain owner, server owner and service owner are the
 same - no problem.
 
 You want that your email communication is blocked because one of your
 clients has a client that hosts a vulnerable PHP application? Come on.
 
 Regards
 Oli
 
 
 ___
 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

Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN

[Andreas Fink]

One thing to watch out in VLAN config is that DHCP broadcasts are sent in the 
default VLAN, not the tagged VLAN.
But I'm not sure how this applies to access ports. I remember however that I 
once expected DHCP requests to come in on the tagged VLAN on the router (which 
was DHCP server) but they did come in untagged and later discovered that the 
standard is defining this (odd) behaviour.

Also as they are broadcasts, the ip helper command can help you to get DHCP 
over layer 3. Most cisco switches do support it  and it is actually useful to 
set it so DHCP broadcasts are being directed to the DHCP server immediately.


On 03.04.2012, at 09:24, Tobias Brunner wrote:

 Hi there,
 
 Maybe there are some Cisco specialists reading this List =)
 
 On a WS-C3750X it tooks about 1 minute after connecting a port to change the 
 status from LINK-3-UPDOWN up to LINEPROTO-5-UPDOWN up
 
 Mar 27 16:25:37 192.168.1.144 788: *Mar  8 00:30:48.032: %LINK-3-UPDOWN: 
 Interface GigabitEthernet1/0/1, changed state to up
 Mar 27 16:26:38 192.168.1.144 790: *Mar  8 00:31:49.227: %LINEPROTO-5-UPDOWN: 
  
 Line protocol on Interface GigabitEthernet1/0/1, changed state to up
 
 Mar 27 16:25:54 192.168.1.144 789: *Mar  8 00:31:05.086: %LINK-3-UPDOWN: 
 Interface GigabitEthernet2/0/1, changed state to up
 Mar 27 16:26:56 192.168.1.144 791: *Mar  8 00:32:06.583: %LINEPROTO-5-UPDOWN: 
 Line protocol on Interface GigabitEthernet2/0/1, changed state to up
 
 
 The ports are configured like that:
 
 interface GigabitEthernet1/0/1
 switchport access vlan 27
 switchport mode access
 spanning-tree portfast
 spanning-tree bpdufilter enable
 channel-group 1 mode active
 !
 interface GigabitEthernet2/0/1
 switchport access vlan 27
 switchport mode access
 spanning-tree portfast
 spanning-tree bpdufilter enable
 channel-group 1 mode active
 !
 interface Port-channel1
 switchport access vlan 27
 switchport mode access
 end
 
 The server which is connected has nothing special configured... It should 
 boot 
 via DHCP/PXE (of course without Bonding) and then the installed Linux with 
 Bonding configured.
 Does anyone have an idea why this takes so long?
 
 Thanks!
 
 Cheers,
 Tobias
 
 -- 
 Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich
 Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13
 Skype nine.ch_support
 
 
 ___
 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] OT

[Andreas Fink]

Dear Collegues,

Anyone have a latest Cisco AS5400HPX software image sitting around.  Due to 
maintenance Cisco download is offline and I'm stuck in the middle due to that 
now. Contact me off list. 

Thanks


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Zygma7

[Andreas Fink]

Hat von euch jemand je Erfahrungen mit Zygma7 Ethernet Switches oder Karten 
gemacht? Insbesonder 10GE?


Andreas Fink

Fink Consulting GmbH
DataCell ehf
SMSRelay AG

---
Tel: +41-61-330 Fax: +41-61-331
Mobile: +41 78 66 77 333 (new!)
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay
Skype: andreasfink
Yahoo: finkconsulting 
Global.AQ SMS: +88234 7000 00 12





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] 6 months logs... no, that's not enough :)

[Andreas Fink]

one year is already in law for telecommunication (voice calls, SMS etc). My 
daily headake to keep logs of 3 billion messages

On 18.01.2011, at 16:45, Pascal Gloor wrote:

 Its not yet translated, because they just filed it, but some of our national 
 parliament people would like us to log a year instead of 6 months... just 
 wanted to let you know.
 
 http://www.parlament.ch/f/suche/pages/geschaefte.aspx?gesch_id=20104133
 
 cheers,
 Pascal
 
 ___
 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

Re: [swinog] Blocking Malware distribution sites

[Andreas Fink]

Am 11.11.2010 um 11:36 schrieb Daniel Kamm:

 On 11/11/2010 11:01 AM, Martin Jaggi wrote:
 You did mention AEFV SR784.104. Art 14bis requires Switch to do this:
 
 Die Registerbetreiberin muss einen Domain-Namen blockieren und die 
 diesbezügliche Zuweisung zu einem Namenserver aufheben:
 
 a.
 wenn der begründete Verdacht besteht, dass dieser Domain-Name benutzt wird:
 1.
 um mit unrechtmässigen Methoden an schützenswerte Daten zu gelangen, oder
 2.
 um schädliche Software zu verbreiten, und
 b.
 wenn eine in der Bekämpfung der Cyberkriminalität vom BAKOM anerkannte 
 Stelle die Blockierung beantragt hat.
 
 Source: http://www.admin.ch/ch/d/sr/784_104/a14bist.html 
 
 Neither Serge nor Martin is noticing the next paragraph:
 
 2 Wenn die Bedingungen gemäss Absatz 1 Buchstabe a erfüllt sind, aber
 der Antrag auf Blockierung einer Stelle gemäss Absatz 1 Buchstabe b
 fehlt, kann die Registerbetreiberin für höchstens fünf Werktage einen
 Domain-Namen blockieren und die diesbezügliche Zuweisung zu einem
 Namenserver aufheben. Nach Ablauf der festgelegten Frist hebt sie jede
 Massnahme auf, die nicht durch einen Antrag einer Stelle gemäss Absatz 1
 Buchstabe b bestätigt wird.
 
 So this is only a temporary blockage of at max 7 days. After this
 periode, the zone file must be delegated again. If DNS caches are not
 flushed or overriden within this time, this non-delegation is futile.
 
 But what really makes me angry is, that Swiss parliament agreed in self
 judgement of a third party company. It really seems, that our parliament
 needs more technical understanding.

This is a denial of service potential with being accuser and judge in one. It 
violates the splitting of power.
I think this will be challenged big time in court.




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] The ISP Association: one for all, all for one

[Andreas Fink]

Am 29.10.2010 um 12:08 schrieb Claudio Prezzi:

 Hi all
 
 Why do you plan to build a new association if there are already so many
 associations in this industry?
 
 ICTSwitzerland.ch for example is the head association of the ICT industry.
 Below it there are for example asut.ch, the Swiss Telecommunications
 Association and simsa.ch, the Swiss Internet Industry Association. Both
 associations already are involved in the political process of BÜPF and have
 many members of our industry. Why not just build a new workgroup in one of
 these associations especially for BÜPF issues?
 
 Just my opinion ;)
 
 
 Kind regards
 Claudio Prezzi
 
 COMsulting GmbH

The IT or Internet Industry is not really the same as Internet Provider. 
People who provide services to internet users have different issues than people 
who provide the wires. A YouTube has to deal for example with copyright 
issues on a totally different level as they are more in a responsible 
situation while a internet provider just transports content but is not 
auditing or controlling the content and actually is not even allowed to look at 
what contents go over his wire. So as you can see in this example, the issues 
BÜPF would raise are totally different for those two example companies. That 
means an organisation built out of YouTubes, Google's, Facebooks etc would not 
be able to understand or at least care less on the issues of an  underlying 
transport layer operator.

As far as ASUT goes, it represents all the big guys. Ttheir approach is also 
very different. While a Swisscom, Sunrise, Orange, Cable Com can afford 100'000 
€ boxes to filter traffic just for the fun of it, many small ISP's get killed 
by those costs. Small ISP's which might serve very specific nice markets and 
create jobs in specific areas are not being heard. Swinog is basically such an 
organisation where lots of ISP geeks are participating but its not 
organized enough as a legal entity to represent the ISP's.

So my recommendation would be to either build something new (Pascal's Idea)  or 
make SwinOG a real organisation which represents the ISP's better.


Andreas Fink
Backbone ehf
DataCell ehf
SMSRelay AG





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SMS provider

[Andreas Fink]

try ww.smstrade.de
good prices and very reliable folks

On 30.06.2010, at 07:55, Rebert Luc wrote:

 Dear SWINOG Users,
 
 I need a SMSC Gateway provider which can communicate with SMPP protocol for 
 example.
 
 Thanks
 
 Best regards
 
 Niklas
 
 
 L

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SMS provider

[Andreas Fink]

those are just delivery providers, not SMSC providers..
That's a totally different thing.

On 29.06.2010, at 21:40, Andy Ashley wrote:

 On 29/06/2010 21:50, li...@rebert.name wrote:
 
 Dear SWINOG users, 
 
 I am looking for a SMSC.. 
 Does anybody has an experience with one of them ? 
 
 Thank you for your feedback. 
 
 Niklas 
 
 We have used http://www.aspsms.com/ for about 6 years (Swiss, seem to be very 
 reliable)
 
 I see http://www.clickatell.com) are very popular too (South African based 
 but also international offices)
 
 Regards,
 Andy.
 
 -- 
 This message has been scanned for viruses and 
 dangerous content by MailScanner, and is 
 believed to be clean.
 
 ___
 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

Re: [swinog] Port 25 Blockade @ Swisscom (Bluewin)

[Andreas Fink]

I do agree on Jeroen's comment. Redirecting and doing content inspection is 
evil.

I've seen a similar case with a nation wide operator in another country. What 
they did was simply block port 25 except for their own mailserver. This might 
sound nasty but after all, all swisscom customers should use the bluewin 
mailserver except if they use some corporate server in which case they for sure 
want to use SSL and should be able to use the specific SSL port.

I think the most important thing to note is that endusers must know that the 
connection is limited for a specific reason (fighting spam distribution by 
customers) and that they can opt out if they have a specific need for it.


On 08.03.2010, at 13:49, Jeroen Massar wrote:

 steven.glog...@swisscom.com wrote:
 Hi everyone
 
 To officially talk about the mail problems on port 25 with swisscom dsl
 I would like to give you some (technical) information.
 
 Thanks for the extensive explanation!
 
 One question there though: do you send a message to all customers
 actually stating that you are going to do this? Especially the
 content-inspection part which infringes on the freedom of speech and
 privacy of the people using your connectivity.
 
 One can't expect them to go to the Swisscom website all the time thus a
 letter or at least an email is very appropriate.
 
 As for the rest: (short: don't do content inspection) I fully agree with
 things that a lot of spam will come from DSL etc. BUT the part where you
 are effectively MITM connections, being judge on what people are allowed
 or not allowed to send(*) is a really really bad thing.
 
 (* = I for instance send/receive viruses sometimes because I am taking a
 look at them, not because they are spreading. Same for spam, if you are
 postmaster@ or abuse@ then you need to look at them if you want to
 handle them.)
 
 The really worrying part is the connection stealing. When you are able
 to do that for SMTP and especially as you are doing content inspection
 there (if you look at it as a person or not does not matter, something
 is looking at it and interpreting it), then you can also do it for HTTP
 and any other protocol.
 
 I wonder what crack-pot of a government official will come next to then
 demand that you actually start doing that for port 80 too and start
 blocking sites which for instance say UBS is bad or Switzerland
 sucks and I don't know what, heck just on the Host: header.
 
 Any kind of inspection is a bad thing and will cause some politician to
 make you do it for every other protocol: HTTP first, DNS later.
 
 Which will in the end mean that the governments control the internets
 for the general folks and only the technically savvy people will be
 doing full crypto everywhere which at one point or another will then be
 banned out, nevertheless it will mean that we will not have a proper
 internet anymore, quite a shame of the country where WWW was invented.
 
 
 Will we start to block completely port 25 in the future? No,
 absolutely not.
 
 I rather have that you actively block port 25 without any inspection and
 just like you are offering now allow people to request the port to be
 opened. This avoids the whole legal issue with doing a MITM.
 
 Yes, it will raise the support cost too as customers who are not using
 SUBMISSION over port 587 as they are supposed to will have problems. But
 your support folks can point to an easy URL where they can figure that out.
 
 And actually the http://www.swisscom.com/p25 url which points to:
 http://www.swisscom.ch/res/hilfe/sicherheit/spam25/index.htm
 Already states that. It does *NOT* state that you are doing content
 inspection. Please keep it that way.
 
 
 This method IMHO is pure infringement of privacy.
 
 Please reconsider this setup and just block port 25 instead of doing
 this inspection.
 
 
 A last nasty question: how do you guarantee that some person does not
 get access to the spam-filtering box and then can read along with almost
 every single email send on the Swisscom network? oh my...
 
 Greets,
 Jeroen
 
 
 ___
 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

Re: [swinog] DNS virtual Appliance

[Andreas Fink]

 :wq Claudio
 
 PS: to my knowledge there is no simple gui for management for good and
 reliable DNS server. The closest I know is powerdns that allows to use
 various DB backends for the lookups and there are some bad and less bad
 web GUIs around the net.

MacOS X Server has a GUI management...
but it doesn't run in a virtual machine unless you run MacOS XServer in VMWare 
fusion which runs on a Mac.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Juge d'instruction du canton de Vaud

[Andreas Fink]

Has anyone received the latest letter from the Juge d'instruction
du canton de Vaud?

I'm quite astonished how this judge is trying to break about any law of 
Switzerland and goes beyond all the rules of our legal system.

Does anyone have an idea where to complain against a judge which does very 
obviously break many laws in a row...

their request:
http://www.fink.org/vaud-letter-27nov09.pdf

Our draft answer:
http://www.fink.org/vaud-answer02dez2009.pdf





Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] EJPD = Access Denied??

[Andreas Fink]

Does anybody get on:

www.ejpd.admin.ch

the result

  Access Denied (policy_denied)
Your system policy has denied access to the requested URL.
For assistance, contact your network support team.






Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Data Retention etc.

[Andreas Fink]

Folks,

I will be interviewed on radio today about my letter to EJPD and my  
view on the new law on surveillance.
I'm putting all arguments together now and sorting them by priority  
(not enough time to say everyting)


One thing which is missing is the cost of such equipment to completely  
automated wiretap.
Does anyone have some figures there? I can only estimate what kind of  
work it would take us to do it ourselves.


Please let me know quickly. The interview is in a few hours and on  
radio on friday (Espresso)




Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Lawful interception - what's new?

[Andreas Fink]

On 27.07.2009, at 14:29, Manuel Wenger wrote:


Hi everyone,
as the discussion about the new lawful interception proposal is going
on, an issue always comes up with people saying that saving real time
data of all customers takes up a lot of hard disk space.

Now, as far as I understand this proposal, only information about
logins and mailbox accesses has to be stored pro-actively. Real-time
data intercepted from the DSL connection is only to be sent to the ÜPF
in case of an interception order, in real-time, from that moment on
(and no historical information).


The technical document does not specify which information to be  
stored. That's the point. The law says Verbindungs und  
Abrechungsdaten.
However what is connection data? connection to the mailserver?  
connection to website XYZ. This is all communication. So they could  
say every tcp connection from A to B is connection data. Of course  
storing all data is ridiculous and is for sure not happening but today  
they want email, tomorrow they want instant messaging, then they want  
skype etc. etc. It will go on and on.


So far we have never stored historical data because there was  
absolutely no need to. Thats where ISP's differ from Telco's because  
you dont need to know whom has sent whom an e-mail to collect the  
bill. Furthermore if you compare it to non electronic world, does the  
Post Office take a photocopy of every envelope they deliver ? no! eve  
though there every single envelope is being paid for. So why are we  
under stricter rules than the non electronic world? Because its  
technically possible. Thats the key. And just because its technically  
possible is not the right reason to ask for it.




This means that nothing changes from the present situation for what
the storage of historic data is concerned. This new proposal only
brings the following changes:
- new real-time interception of data transmitted through a broadband
connection (no historical storage)
- new interfaces to communicate with ÜPF

Is this correct?



The new interface basically brings the problem of authenticity. We can  
not control if this order is legal or not. It brings SEVERE costs.



Now, do you think it would be possible to talk to ÜPF in order to find
ad-hoc solutions in the rare cases these real-time interceptions
should become necessary? Otherwise it's definitely overkill. What
would be the best way to approach this?


This was the solution of the past as far as I have heard. I would have  
absolutely no problem if the police would show up with a judge's order  
to wiretap my customer XYZ with a laptop in their hand and active  
connecting to an ethernet. This would work very well for most ISP's I  
would imagine. But this administrative jumbo interface will basically  
kill 50% of the ISP's who have less than 10'000 customers as they can  
not afford it.



I think some lawyers wrote this proposal without having the slightest
idea of what they were doing, and I'm sure the techies working at ÜPF
are smart people who would be willing to negotiate a more efficient
implementation. What do you think?


ÜPF is the author. They are greedy for information. They want  
everything they can get. I don't think they will move. Their opinion  
will be its the law so do what we ask. The only thing is to move  
this a few levels up to the Bundesrat (namely Evelyne Widmer Schlumpf)  
and make it clear what kind of nonsense they produce.


The german Twittosphere (the guys who have invented Zensursula)  
already has a word for it... Ueberwachungsschlumpf (Surveillance  
smurf).







Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Lawful interception - what's new?

[Andreas Fink]

PS: what also changed is that they now ask for certification of this  
whole nonsense.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Ansatz zur Umgehung der Echtzeitüberw achung ;-)

[Andreas Fink]

On 23.07.2009, at 11:50, Manuel Wenger wrote:


Il giorno 22-lug-09, alle ore 18:40, Claudio Prezzi ha scritto:

Was haltet ihr von der Idee, einen Kunden sofort abzuschalten,
sobald eine Echtzeitüberwachung angefordert wird. Mit etwas
Kreativität in den AGB’s würde das sicher gehen. Auf diese Weise
entstehen schon gar keine Daten, die Überwacht werden müssten ;-)



Diese Idee ist gar nicht so dumm :-). Mit den AGBs wuerde das sicher
gehen. Dann muss man nur noch das EJPD ueberzeugen, dass keine Daten
entstehen werden, und deshalb keine Zertifizierung des
Ueberwachungsequipments durchgefuehrt werden muss.

Koennte man nicht ernsthaft in diese Richtung arbeiten?
Echtzeitueberwachungen wird es, realistisch gesehen, sowieso fast
keine geben. Wenn man mal einen Kunden im Jahr oder so fristlos
kuendigen muss wegen einer Ueberwachung ist das auch nicht so schlimm.
Dann soll er eben zu Bluewin gehen, dort koennen sie ihn dann beliebig
ueberwachen :-)

-Manuel



Das seh ich als problematisch. Es könnte als Behinderung der Justiz  
ausgelegt werden. Überwachung an sich ist ja schon seit Ewigkeiten im  
Gesetz. Dagegen sollten wir uns nicht wehren. Schliesslich sollen  
Schwerverbrecher ja auch gefasst werden. Die wichtige Frage ist wie  
weit sie gehen darf und unter welchen Umständen.


Die Hauptkritik sollte aber darauf liegen das massenweise sehr  
persönliche Daten erfasst werden müssen von jedermann ohne jegwelchen  
Verdacht. Daten die nicht einfach so sonst anfallen und eh für  
irgendwas gebraucht werden. Wo persönliche Daten rumliegen, können sie  
auch misbraucht werden. Sei es von Hackern die unsere Server  
eindringen, sei es von unseren eigenen Mitarbeitern, sei es von EJPD  
Mitarbeitern oder von findigen Geheimdiensten. Wenn diese sensitiven  
Daten nicht erhoben werden, so entfällt diese Gefahr des Missbrauchs  
automatisch. Weiss jeder das die Daten da sein müssen, so werden die  
ISP's zur Goldgrube für Informationen und definitiv interessante Ziele  
von Geheimdiensten mit jeder menge Kohle im Rücken.


Ich empfehle jedem wirklich die ersten paar Kapitel der CCC  
Stellungnahme zu lesen und ihr werdet Verstehen wieso solche Daten so  
gefährlich sind. Selbst mir als schon seit 15 jahren in diesem  
Business Tätig waren diese enormen Gefahren in diesem Ausmasse nicht  
bewusst.


Und alles mal auf Halde zu speichern bedeutet jeder ist generell mal  
unter Verdacht.


Der zweite Kritikpunkt sind die Kosten für die Infrastruktur der  
Echtzeitabhörung. Da das EJPD komplizierte Aufwändige Interfaces haben  
will, werden alle ISP dazu verdonnert das zu implementieren obwohl bei  
den meisten die Chance besteht dass sie das nie jemals brauchen. Das  
ist Verschwendung von Steuergeldern und unverhältnismässig.







Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Antwort eines Basler Internet Providers a uf die Pläne des Überwachungsstaates

[Andreas Fink]

Sorry for the non german speaking folks but it was not possible to  
translate this to french english or italian yet.



Da das EJPD nicht in der Lage ist 10MB Attachements zu verarbeiten ,  
ist das Attachment nun unter


http://www.fink.org/ejpd-antwort.pdf

downloadbar.

On 22.07.2009, at 10:12, Andreas Fink wrote:

An:
Informatik Service Center ISC-EJPD
Überwachung Post- und Fernmeldeverkehr
Provider Management
Fellerstrasse 15
3003 Bern

Bitte nehmen sie angehängtes Dokument zur Kentniss und kontaktieren  
Sie uns erst wieder sobald sie die Grundlagen der schweizer Demokratie  
verstanden haben.


Mit freundlichen Grüssen


Andreas Fink
BebbiCell AG
--
Tel: +41-61-330  Fax: +41-61-331   Mobile: +41-79-2457333
BebbiCell AG. Clarastrasse 3, 4058 Basel, Switzerland
E-Mail: af...@bebbicell.ch
Web: http://www.bebbicell.ch/
--
ICQ: 8239353 MSN: af...@bebbicell.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333


ejpd-antwort.pdf




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Vorratsdatenspeicherung

[Andreas Fink]

For your information:

I had a call today on the subject from EJPD, Dienst für Überwachung,  
asking if we didn't had any response to the document they submitted to  
us.
So in fact they are awaiting feedback from us. We will reply before  
the end of the month officially.

I would urge you all to do the same, despite the document shows a  
shorter date.




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] special mail solution?

[Andreas Fink]

how about the simple solution to send an email to every mailbox, stop  
the server getting any new incoming mail and simply leave everything  
alone.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] off topic

[Andreas Fink]

for those of you who are idle, I'm currently doing a survey on the  
landscape of datacenters worldwide:

http://www.surveymonkey.com/s.aspx?sm=zLm7M_2fVF_2bqPcUjI0RYzvNg_3d_3d

If you can spare 5 minutes, I would be very thankful. Thank you.


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Censurship in Germany Take 2

[Andreas Fink]

its getting worse:

http://www.heise.de/newsticker/Kinderporno-Sperren-Provider-sollen-Nutzerzugriffe-loggen-duerfen--/meldung/136450


On 18.04.2009, at 17:00, Pascal Mainini wrote:


Hi all


Very good article about the reality versus View of Politicians.
I think we will have this discussion in Switzerland soon as well.


I also recommend the article from C'T:

http://www.heise.de/ct/Die-Argumente-fuer-Kinderporno-Sperren-laufen-ins-Leere--/artikel/135867

Have a nice weekend, kind regards,

Pascal


___
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] Censurship in Germany

[Andreas Fink]

FWIW

http://www.carechild.de/news/politik/internetzensur_die_grossen_luegen_der_ursula_von_der_leyen_572_1.html

Very good article about the reality versus View of Politicians.
I think we will have this discussion in Switzerland soon as well.


Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] our neigbours do fancy things / DeNIC

[Andreas Fink]

Here's what german DeNIC did to suppress the freedom of speech.

http://www.wikileaks.org/wiki/More_detail_on_WikiLeaks.de_suspension

Its quite heavy in my eyes. Anyone from SWITCH want to comment on if  
such a thing could happen in Switzerland?


If you want to protest, address it to the fax and emails on 
http://www.denic.de/de/transit-info.html


Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Fwd: Re: Hackerparagraph

[Andreas Fink]

On 23.03.2009, at 18:28, Rainer Duffner wrote:

 Michael Naef schrieb:
 On Monday 23 March 2009, Rainer Duffner wrote:
 [..]

 People can survive without email


 I am tempted to doubt that. The reactions to mail outage suggest
 the contrary ;-)



 Well, it depends.
 I survived a week without email on my holiday.
 ;-)
 But our customers' business sort-of depends on email-availability,  
 yes.

 Can you eat/drink email?
 Can you breath email?
 Can you email the garbage away?
 ;-)

 Nope, it's fully virtual.
 Email's non-availability is only an issue, if you're the only one
 without it.
 If everybody else didn't have it, it wouldn't be such a problem.


Whole industries depend on it. Without e-mail my business would be  
dead. In todays world communication is a vital issue to the service  
industry.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Fwd: Re: Hackerparagraph

[Andreas Fink]

we have to make sure that they get aware of the issue and that it is a  
big concern...

LOBBYING...

On 19.03.2009, at 10:54, Ihsan Dogan wrote:


Am 18.3.2009 19:43 Uhr, Norbert Bollow schrieb:


I believe that in order to agree to be bound to a treaty of this
type, there must be approval from Ständerat and Nationalrat and the
possibility of a referendum!


For that it would make sense, if we would get in contact with the
political parties. At the moment, it seems that none of the parties in
the parliament have an opinion on this issue.




Ihsan

--
ih...@dogan.ch  http://blog.dogan.ch/

___
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

Re: [swinog] BGP over xDSL ... is evil? says who?

[Andreas Fink]

On 05.03.2009, at 19:28, Lukas Beeler wrote:

On Thu, Mar 5, 2009 at 19:08, Fredy Kuenzler kuenz...@init7.net  
wrote:
Remember http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt 
 - in


I just skimmed through that, and i wonder if it's still current.

There's some talk about requiring about 128MB of memory, and budget
concerns of smaller ISPs.

Now, even expensive FB-DIMM memory by vendors like HP and IBM only
costs around 360 CHF for 4 GB. And even small two way x86 boxes max
out at around 32 - 48 GB. Even if Cisco and Juniper charge 10x as
much, that'd still be only 3600 CHF.

I understand that routers use ASICs and probably faster memory than
servers, but i can't really imagine it to be a problem to pop 4GB
memory into a router that's connected directly to the internet.

Now, where am i mistaken?


When I started using BGP first (1994), we did run BGP on a 2501 router  
(2 serial ports of 2Mbps + 1 ethernet 10Mbps) which had maybe 32MB of  
ram and costed 7'000 CHF at the time. This was not good enough, so  
years later a 7206 was used with 128MB of RAM (this was probably  
around 1998)


Those routers which costed like 100'000 CHF at that time. Today, you  
reach the limits on a 7206VXR with like 512MB on a NPE-300 CPU card.  
You can not stick more than 512MB ram into it. So you need a bigger  
router CPU which does support more RAM.


Don't forget that more RAM requires hardware which supports it. So its  
not enough to simply stick a bigger bar into a box. Also most routers  
are 32bit CPU's so you get into the hard limits of the CPU if you  
think of 4GB.


but the way bigger problem is the processing speed. Think of the  
following. In worst case scenario, EVERY SINGLE PACKET's destination  
IP has to be searched in a routing table of 4GB. RAM is fast but going  
through 4GB of ram is still not that fast that it would not affect  
speed if its done on every single packet. Of course there are caching  
mechanisms who remember last used IP's because they will likely be  
reused for the next paket etc. But its not as trivial as it might  
sound. There's more to routing than just holding the routing table in  
memory. That part is easy and cheap but processing every packet  
against it in minimum time is what's costly.


Thats probably the reason why on a NPE-300 processor you can not stick  
more than 512MB of RAM because it would not be fast enough to handle  
it anyway. So then you go and buy a NPE-G1 or now a NPE-G2 and you end  
up with a few thousand CHF bill.


Now multiply this with number of ISP's and BGP routers they have and  
you see the picture. Big ISP's will take care of the core routers,  
whatsoever as its their core business. But the multihomed customers at  
the other side of the planet now has to buy a new router just because  
you added one route more into the table. This is the global effect.






___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 04.03.2009, at 16:05, Beat Rubischon wrote:


Hello!

Quite interesting discussion you have!

Am 26.02.09 11:17 schrieb Andy Davidson unter a...@nosignal.org:


 - There seems to be no consensus about how to serve end user
addressing for ipv6


I see some open points which must be addressed in advance before  
IPv6 could

be delivered to anyone - not only to geeks like me.

Think about Cable. It's easy there - you have a modem with one or more
Ethernet ports. Some RA announcements for the customers /64 and  
everyone is
happy. Think about the advantage of two computers when using IPv4  
and an
infinite amount of computers when using IPv6 for only 29.95 per  
month. What
a motivation for the customer to use it ;-) Of course all the  
Router /

Blackbox Firewall users are lost.


Basically every customer gets a /64 on the ethernet. Thats the idea.


ADSL is a bit more problematic. Standard ppp handles just the link  
layer
addresses. Who should get the /64? The ppp endpoint itself or the  
network

behind?


The end user cares about what's on his Ethernet, not if PPP, ATM, HDLC  
or whatever is used on the wire. Basically the ADSL router has to get  
ONE IPv6 for the broadband side (through autoconfiguration as normally  
in IPv6) and be a router in the most traditional straightforward  
sense. NAT boxes in my view are not real routers even though a lot of  
vendors call them router. They are some kind of level 4 proxy crap  
someone has invented to get around IP adress usage limitations. They  
break in many ways if you want to do many things. Using properly  
routed IPv6 solves all those nice bogous workarounds.


Apple for example goes the simple way and passes all the  
configuration to the user.


Which configuration are you referring to? MacOS X clients do simply  
take router anoucement and autoconfigures everything. I have not seen  
any Apple ADSL router yet so I'm not sure what you mean by above  
statement.



ppp devices won't accept RA announcements. How
does Windows behave? I don't now.


Where you see PPP? Ethernet is what end users will see. Or do you  
consider IPv6 for Dialup 56kbps modems? I'm sure PPP LCP could  
negotiate an IPv6 in that case for those who really want to use that.


Next point: DNS. DHCPv6 is IMHO only supported by some Linux  
distros. Apple
once again uses the DNS configured by IPv4 DHCP or manually  
configured ones.


Well here you have to distinguish. Using a IPv6 DNS server answering  
on IPv6 addresses or querying IPv6 information on a IPv4 server.
Currently, we will have a dual standard world for a while. so having  
IPv4 server responding with IPv4/Ipv6 information is what we are going  
to see for a long long while. Nobody says you should NOT have IPv4.  
Just not only. I see the future as IPv4-NAT-limited, IPv6-Native.


Windows has some site wide addresses out of a deprecated space  
predefined
(fec0:0:0:::1~3). The approach to pack DNS IPs into RA is yet  
too young

and not standardized or even implemented.




So we have still a lot of work in front of us.


Not really. You can reach any IPv4 DNS from IPv6. So DHCP v4 can  
announce the DNS Server and the rest is simple magic.

Of course there is always room for improvement.


Even more work will come for small and medium business networks.  
Today there
is a NAT gatway in front of the network and tunneling VPN for the  
remote
workers or office interconnect. There is usually an internal DNS  
(Windows
AD) carrying the local addresses. Everyone knows the basics and how  
to set

up such environemnts.


... and everyone gets puzzled once NAT doesn't work. Try to use it for  
VoIP or just try to do MSN / ICQ filetransfers and in 90% of the cases  
you have issues. And if you want to use advanced layer 4 protocols  
such as SCTP on NAT, you will see that 99.9% of the NAT devices don't  
know how to handle anything besides TCP, UDP and maybe ICMP.


What about the future? Route IPv6 directly to the clients? What  
about remote workers? Delegate the reverse and forward lookup

to the internal DNS?


VPN will still stay. its purpose is still the same. IPv4 or IPv6  
doesnt change anything there. But you COULD use IPv6 and IPSEC  
directly and skip the tunneling part as IPSEC support is mandatory in  
IPv6. So if you access office from home, you get a secure tunnel while  
you access the internet, you get direct connection.


Of course all those questions are answered when you operate an open  
network.
Like universities or ISPs usually do. Or when you run an independend  
company
network only connected by proxies. But for other usage, like SOHO  
users,

there are still open points.



For SOHO its solveable. The worst I can currently think of is that  
someone would have to enter a IPv6 DNS server by hand.
Compared to what you have to enter into a current DSL modem, this is a  
snap.
If the DNS issue is solved, its at the end of the day pure plug and  
play instead of plug and pray...

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 04.03.2009, at 22:57, Norbert Bollow wrote:


Andreas Fink af...@list.fink.org wrote:


Currently, we will have a dual standard world for a while. so having
IPv4 server responding with IPv4/Ipv6 information is what we are  
going

to see for a long long while. Nobody says you should NOT have IPv4.
Just not only. I see the future as IPv4-NAT-limited, IPv6-Native.


How do you (reliably) talk with IPv4-only hosts via the internet when
you're on an (IPv6 natively connected) IPv6-only ethernet?



1st: 		who says its IPv6 ONLY ethernet? IPv4 can and should stay.  
Maybe through crappy NAT or proxy. Maybe only to assign DNS ;-)
2nd:	IPv6 maps IPv4 addresses into a specific IPv6 prefix. So if you  
talk purely IPv6, you can address an IPv4 host by using the :::  
prefix.





Andreas Fink
Fink Consulting GmbH
---
Tel: +41-61-332 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  af...@finkconsulting.com
Homepage: http://www.finkconsulting.com
---
ICQ: 8239353 MSN: af...@finkconsulting.com AIM: smsrelay
Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 28.02.2009, at 21:52, Martin Ebnoether wrote:

 On the Sat, Feb 28, 2009 at 12:39:46PM +0100, Tonnerre Lombard  
 blubbered:

 Apple is gaining a lot of market share, and their products configure
 IPv6 all by themselves. Same goes for Windows Vista. Ok, for XP you
 have to install IPv6 support first, I think.

 True, true. Though, there still are some Win 2000 and even older
 OS around.

Sure and there are some analogue TV around who can't watch HDTV. What  
do you do to those. The Industry of which Fust and Interdiscount etc  
live of have shown many times in history that they produce products of  
lifespans of 1-2 years. I'm sure some of you have betamax video  
recorders, HD-DVD players, Analogue TV's, Natel-C's etc out there  
which all can no longer be used. You can't have everything. But you  
can update your Win2000 box to run Linux (or WinXP or Vista if you  
have the patience). Win2000 is end of life, end of support by  
Microsoft. Its 9 years old by now. And I'm sure a 9 year old computer  
will have plenty of problems in today's Internet with highspeed video  
etc.

 Besides, even if they start offering v6 today, users will not buy  
 it,
 because of that Interdiscount/Fust issue. Also most windows PCs and
 home servers would need some tuning for v6.

 Not true, see above.

 What about all the plastic routers, firewalls and WLAN access
 points? And then, gameconsoles, mobile phones, PDAs,
 Squeezeboxes, etc?

Pure WLAN access points are ethernet bridge devices, they don't care  
about IPv4 or IPv6 except for their own configuration (which can stay  
on 192.168.x.x without a problem). Only if they do in addition NAT you  
get into trouble. On the other hand if you have native IPv6 on your  
ethernet, you don't need NAT anymore and all your NAT issues go away  
(why does MSN/Skype/ICQ filetransfer sometimes do not work behind NAT  
and sometimes it does? Why does my VoIP not work properly etc etc.)

Firewalls in any case have to deal with IPv6 if you like it or not but  
because you skip NAT, it becomes a lot simpler as it's simply a port  
blocker.
You would be surprised how many of the plastic boxes support IPv6  
today or can be made to support it with a simple software update. It  
might not be widely advertized yet.

Remember this discussion is about OFFERING IPv6. Not REQUIRING IPv6.  
IPv4 will stay here for quite some time but an upgrade path has to be  
established. This is a long term transition and the IPv6 standards  
have lots of things in them to allow a smooth transition. And the  
first steps are the backbones. Today all the good ones have IPv6 in  
the core. And if not, you can use IPv4/IPv6 tunnels. Mainstream  
operating systems all have IPv6 support built in. The access link is  
now the last hurdle. The standards are there. You just have to plan  
and execute.





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

- Original Message 

From: Andreas Fink af...@list.fink.org



well, the Docsis 3.0 CMTS hardware is quite expensive,
if not saying dramatically expensive.



Then, the Docsis provisioning software is also quite expensive,


I guess you simply bought a dead end solution. Good hardware  
vendors supply IPv6
out of the box or at least with firmware upgrades. There's no  
reason to be

expensive


I haven't bought anything, I just know the Docsis technology market.
The provisioning software is generally not v6-ready, and the
hardware generally needs expensive upgrade.


Well, nobody said deploying IPv6 has to be free.
With open source software IPv6 is for sure added. So replace needs  
expensive upgrade with choose right product. It's no exucse.


in DSL market, it's even worse: the Broadband Forum has not  
released yet any

ipv6 related document...


Who cares what the broadband forum says. We're in a IP world.  
There's 100's of
RFC's documenting IPv6. I personally run IPv6 natively over a SHDSL  
link and it
just works. As SHDSL shares the same basic ATM structure underneath  
like ADSL, I
don't see why anyone could NOT do IPv6 if he just tries hard  
enough. IPv6 is at
the end not that different to IPv4. Even with PPP it should work as  
PPP
encapsulates link frames, not IP packets so you can easily stuff  
IPv6 packets

into PPP.


The fact that Andreas or Tonnere is able to configure ipv6 at home  
does not
create a business case. Go look at your nearest Interdiscount or  
Fust shop --

how many of the consumer routers/firewalls/modems would support ipv6?
How many of the shop salesmen would ever hear such word?


There's two sides of the story, the ISP and the end user.
If the ISP doesnt supply IPv6, no one will ever ask Fust or  
Interdiscount for IPv6 capable devices.
And on top of my head I already know a few who are IPv6 ready. The  
FritzBox from AVM for example does  also support IPv6 over IPv4  
tunneling. Apple Airport Express does also. Cisco does support it  
(which isnt really the same class).
But of course crappy dirt cheap devices like Zyxels don't. But no one  
want's to use them anyway.
The end user has a choice. The ISP limits his choice. The non IPv6  
ISP's will simply loose in the long term as IPv6 awareness has raised  
in 2008 drastically.



Who cares what the broadband forum says.


any ISP with more than few thousand xDSL customers does. You know,  
they are lazy
enough to build something that does not have a standard supported by  
vendor majority.


Besides, even if they start offering v6 today, users will not buy  
it, because of that
Interdiscount/Fust issue. Also most windows PCs and home servers  
would need some

tuning for v6.


Sorry but most windows PCs and home servers would need some tuning  
for v6 is just WRONG.
If you have a proper configured IPv6 router and you plug a MacOS X or  
Linux box, they get IPv6 addresses automatically and are connected.  
This is part of the beauty of IPv6 to have  autoconfiguration. I  
presume its the same in Windows Vista as its part of the standard.


So, give it another 4-5 years, it's coming, but not as fast as you'd  
like it to :)


I already waited 10 years. I won't have to wait for another 4-5. We  
have full IPv6 connectivity and we make extensive use of it.


Its also a management issue. in USA IPv6 is not that common simply  
because
everyone can get tons of IPv4 addresses too easy (at least in the  
past).
But you gotta start sometime. And the time is now. Everyone  
supports IPv6 these
day and personally I would not choose a BGP4 uplink which does NOT  
suport IPv6
(we actually have thrown a IPv4 provider out just recently and  
replace it with a

IPv6 capable one).


it's purely an economy issue. Big ISPs will not invest into
something that the end-users don't require on massive scale. Those  
home end-users
who have no idea what BGP or PPP means. They just connect their  
computers into the

wall sockets and expect them to work.


Right and exactly for this, IPv6 is good. Plug and play is much more a  
reality than in IPv4.
I recently had to configure a Zyxel VDSL router and its a nightmare.  
Terms are unclear, too many weird buttons. NAT is getting into your  
way all the time. And once you configured it wrong and then configure  
it right (so all settings look exactly as they should) the dam thing  
doesnt work. Erase to factory defaults and reconfigure exactly the  
same settings made it work. Those kinds of problems are expensive for  
the ISP due to support, it makes an ISP look bad towards the customer.  
Nothing works will be the result. This is a cost to keep in mind.  
IPv6 is way way more plug it in and it just works. And as it's been  
around since over 10 years, it is mature enough for deployment now.


Anyway, enough said. Users have a choice and they will pick.
Me as an end user will not pick anything not supporting native IPv6  
unless I would have no other choice

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 26.02.2009, at 10:00, Stanislav Sinyagin wrote:


 Andreas, you forgot one thing: you are not a user (although replying  
 in HTML to a
 techie mailing list is a typical user behavior :-)

 A typical user has windows XP at home, he buys cheap zyxel or D-link  
 hardware,

Windows XP is end of life... forgot?
and Zyxel or D-Link is dead end. IPv6 is not for everyone right now  
but a good part will want to use it.

 and he does not know what an IP address is. Usually such users bring  
 80%
 of ISP's income, and the ISP will rather keep them happy :)

it brings 80% of the income and 95% of the support cost.
So make yourself happy by saving it...

Whatever, IPv6 might not be for you. Your customers will go away one  
day. Not immediately but longer term. And by that time others have  
picked up your business.
























___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 26.02.2009, at 11:27, Stanislav Sinyagin wrote:




From: Andreas Fink af...@list.fink.org




Windows XP is end of life... forgot?


so what? 50 to 80% of users still use it. On 2-4 years old hardware.  
Try telling them

that they have to buy new computers :)


why do you care ? They simply stay on IPv4. If they have vista, they  
can profit of IPv6. Nobody asks to REPLACE IPv4 with IPv6. Its a  
migration. And you gotta start sometime with it.





tell it to Swisscom/Sunrise/Cablecom -- or just any real ISP with  
real private users :-)


Believe me. As I've been an ISP since 1994 in the early days where you  
had to tell people how to configure Trumpet Winsock on windows 3.11, I  
know very well that support IS a hassle. If you get it right however,  
you get very loyal customers long term. Swisscom / Sunrise / Cablecom  
are not the best examples in this even though Swisscom has improved  
lately, Cablecom is still far away from customer friendly in my eyes.  
But they have the de facto monopoly on cable internet. So often  
customers have no choice and get abused because of that.


For what its worth my router tells me this:

IPv6 routes: 1'577 entries, 1'194 AS numbers
IPv4 routes:  274'504 Ientries, 30'488 AS numbers

If the wold would be all IPv6, our routers would need 10 times less  
memory ;-)



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IPV6 Go (lazy providers)

[Andreas Fink]

On 26.02.2009, at 14:22, Claudio Jeker wrote:


On Thu, Feb 26, 2009 at 12:07:12PM +0100, Andreas Fink wrote:


On 26.02.2009, at 11:27, Stanislav Sinyagin wrote:



...


For what its worth my router tells me this:

IPv6 routes: 1'577 entries, 1'194 AS numbers
IPv4 routes:  274'504 Ientries, 30'488 AS numbers

If the wold would be all IPv6, our routers would need 10 times less
memory ;-)



Do you think that if IPv6 is used worldwide the number of ASs would be
smaller then today? The same question is also true for the number of
networks.


This wont change much I guess. The political boundaries which exist  
in autonomous systems will stay the same.
Maybe some multihomed customers would instead become dual homed and  
would not need an AS number.


This is the biggest lie of IPv6. The routing table will not get  
smaller

and will gain the same exponential growth that IPv4 has now.


This is not true. ISP's today own dozens of subnets. The average AS  
number announces 8 routes.
With IPv6 most of those who do announce dozens of nets would only  
announce one prefix.



If the world would be all IPv6 you would need at least 4 times as
much memory on your routes. Most probably you need to replace most  
because

their CAMs are to small or the ASICs do not support IPv6.


The current routers out there have no problem with IPv6. If they would  
have such issues, they have even bigger issues with IPv4 as it is  
currently. IPv6 has been designed from the ground up to allow easy  
routing in hardware. One of the reasons why IPv6 headers are always on  
4 byte boundaries.
And by the time we have all IPv6 ranges, routers with 4 times as much  
memory are widely available. My 10 year old Cisco7206VXR can still  
easily cope with a full routing table.


About the size reduction / increase, here's an example:

Below you see the BGP4 routing table of Swisscom (AS3303) for all  
routes ending with AS3303 (which excludes multihomed clients):
This routing table has 147 entries. In IPv6 it would have ONE entry  
because that ONE subnet gives by far enough space.
Also if a subnet would been taken over from another ISP (merger etc),  
renumbering is changing prefixes on routers but not changing all hosts  
in a subnet. So way easier. Also the prefix can be replaced 1:1. This  
is not possible in IPv4 and renumbering is a major hassle in that case  
(which is why no one does it) because the size constraints required to  
use optimal size allocation and over time what's optimal changes. IPv6  
does not have that burden.


This example shows a 147 : 1 tradeoff in routing table entries.  
Assuming a table entry takes 4 times as much space (which I dont think  
because an entry holds more than just the IP... so it will be 24 bytes  
longer, not 4 times as big). you are still saving a factor of 1:36.


See for your self

* 77.72.128.0/21
* 78.110.128.0/20
* 91.199.186.0/24
* 91.208.130.0/24
* 134.146.200.0/23
* 138.187.128.0/18
* 138.188.0.0
* 138.190.0.0
* 145.234.0.0
* 145.250.128.0/17
* 146.109.0.0
* 146.159.0.0
* 156.25.248.0/21
* 156.106.0.0
* 161.78.0.0
* 163.168.0.0
* 164.128.0.0
* 192.53.104.0
* 192.83.223.0
* 192.102.95.0
* 193.5.0.0
* 193.5.3.0
* 193.5.4.0/23
* 193.5.38.0
* 193.5.59.0
* 193.5.61.0
* 193.5.67.0
* 193.5.224.0/20
* 193.8.145.0
* 193.8.167.0
* 193.8.196.0
* 193.8.198.0/23
* 193.16.241.0
* 193.47.232.0
* 193.72.79.0
* 193.73.106.0/23
* 193.73.208.0
* 193.134.32.0/22
* 193.134.36.0/22
* 193.134.131.0
* 193.134.206.0
* 193.134.210.0
* 193.134.214.0
* 193.134.248.0
* 193.135.0.0/23
* 193.135.46.0
* 193.135.108.0/23
* 193.135.128.0/22
* 193.135.132.0
* 193.135.143.0
* 193.135.144.0/23
* 193.135.156.0
* 193.135.173.0
* 193.135.214.0/23
* 193.135.216.0/23
* 193.135.218.0
* 193.135.219.0
* 193.135.255.0
* 193.201.122.0/23
* 193.222.64.0/19
* 193.223.68.0
* 193.223.112.0/20
* 193.223.224.0/20
* 193.246.0.0/23
* 193.246.16.0/21
* 193.246.48.0/23
* 193.246.50.0
* 193.246.56.0
* 193.246.57.0
* 193.246.62.0/23
* 193.246.99.0
* 193.246.100.0
* 193.246.104.0
* 193.246.113.0
* 193.246.122.0
* 193.246.127.0
* 193.246.205.0
* 193.246.246.0
* 193.246.248.0/22
* 193.246.252.0
* 193.246.254.0
* 193.247.36.0/22
* 193.247.40.0
* 193.247.44.0/22
* 193.247.48.0/20
* 193.247.86.0
* 193.247.128.0/22
* 193.247.132.0
* 193.247.151.0
* 193.247.154.0
* 193.247.217.0
* 193.247.224.0/21
* 193.247.244.0/23
* 193.247.247.0
* 193.247.250.0
* 194.6.160.0/19
* 194.11.128.0/23
* 194.11.144.0/21
* 194.11.166.0/23
* 194.11.223.0
* 194.35.252.0
* 194.40.244.0
* 194.56.0.0
* 194.56.3.0
* 194.56.4.0
* 194.56.127.0
* 194.56.234.0
* 194.93.112.0/22
* 194.124.209.0
* 194.124.232.0
* 194.124.233.0
* 194.124.242.0/23
* 194.147.52.0/22
* 194.147.96.0
* 194.147.134.0/23
* 194.169.219.0
* 194.191.65.0
* 194.209.0.0/16
* 194.209.86.0/23
* 195.8.108.0
* 195.35.121.0
* 195.47.231.0
* 195.47.245.0
* 195.65.0.0/16
* 195.144.32.0/19
* 195.158.230.0/23
* 195.176.128.0/19
* 195.176.192.0/19
* 195.225.60.0/23
* 195.234.37.0
* 195.245.228.0
* 195.248.91.0

Re: [swinog] SIUG position Re: Post from Canton de Vaud

[Andreas Fink]

 Another question is this:  What happens when one of those domain
 names expires and someone else registers it and uses it for some quite
 honorable purpose?  That (now-suspended) court order does not appear
 to foresee any way in which the censorship order could be challenged
 at a later time on the grounds that the censorship demand no longer
 has any legal basis.


this already happened:

www.freejustice.de is on the list of sites to block and currently  
available to buy from a domain grabber.
So one of our lawyers could pick it up and offer legal consultation or  
other legitimate use ;-)



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

I've uploaded the scan of the request to our webserver:


http://www.bebbicell.ch/PE03.018380.pdf




Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

On 18.02.2009, at 13:45, Pascal Gloor wrote:


I've uploaded the scan of the request to our webserver:
http://www.bebbicell.ch/PE03.018380.pdf


Thanks Andreas for sharing this information (since, somehow, we  
didn't receive it).


Question for you Christa. The order is suspended, does it mean that  
blocking those websites becomes now illegal ?


Oh, and thank you Christa for participating in the SwiNOG community  
debate, its always interesting (and almost required) to have a  
lawyer in such discussions.



Pascal___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


you have to read the thing fully:

The cover letter in french says CYBERLINK has opposed.
The german text says despite the recurs of Cyberlink, it stays in force:

	Der Rekurs hat keine aufschiebende Wirkung aauf die  
Untersuchungshandlungen ; der angefochtene
	Entscheid ist trotz des Rekurses Rechtskräftig, es sei den der  
Untersuchungsrichter hat das Gegenteil

entschieden


Also, the original order was not sent to me, I wonder most about the  
sentence


gegen die vorliegende Verfügung keine Rechtsmittel möglich sind.

So a judge decides to force me to do anything without hearing my  
voice, without giving me the right to oppose is really out of my sense  
of democracy and law.







Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

On 18.02.2009, at 16:38, robert.guentensper...@swisscom.com robert.guentensper...@swisscom.com 
 wrote:



Funny “Verfügung”.
But what about Swisscom and sunrise and maybe others?
Are those not ISP??

Just a stupid question…

Cheers,
Günti



Actually a good question. The list shows a carrier operators in it  
which is in the wholesale voice but for sure is not an ISP.


in the text it says

stellt fest dass er somit den wichtigsten Access-Providern der  
Schweiz verordnet hat, Schritte zu unternehmen, um ihren Abonenten den  
Zugang zur internetseite... zu verhindern.


I guess this is the proof that Swisscom and Sunrise is considered  
unimportant in this respect.


Another proof that this judge has no clue on what he's into...
- or -

he probably knows that the Lawyers of Swisscom, Sunrise etc would kill  
his judgment on the spot.



___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] SIUG position Re: Post from Canton de Vaud

[Andreas Fink]

 is this:  What happens when one of those domain
names expires and someone else registers it and uses it for some quite
honorable purpose?  That (now-suspended) court order does not appear
to foresee any way in which the censorship order could be challenged
at a later time on the grounds that the censorship demand no longer
has any legal basis.


Blocking a domain name is not blocking the page.
think of

www.hotmail.com/mybadguyshomepage/blabla.html ?


what does SIUG say to that topic ? there sems to be no activity at  
all.


I have a few hours ago put up copies of the two recent court orders
(without the lists of ISP contact person names, which IMO raise some
privacy concerns) together with a very minimal comment up on siug.ch

If you're interested in seeing SIUG take further action, such as
publishing a position statement that explains why such censorship
is a bad idea, or organizing public events (e.g. a podium discussion)
on this topic, well, you're welcome to volunteer to do the necessary
work, or pay someone to do it. :-)

Best regards
Norbert Bollow,
president of SIUG
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog



To summarize: we MUST react or we might let further such cases come in  
daily.







Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Post from Canton de Vaud

[Andreas Fink]

Hello Collegues,

Today I got a document sent to us because we are listed as ISP. You  
probably have all received it as well.
Its a case of a Party A against unknown who has said something wrong/ 
bad about Party A. (Ehrverletzung/Verleumdung etc.)


While I can understand that Party A tries to get their right to get  
things wrong written about them is being changed to correct, the ISP's  
of Switzerland are now out of a sudden involved in this as they are  
in charge of blocking the corresponding site.



Also what upset's me most is the sentence that this is the status of a  
Verfügung from a Untersuchungsrichter and there is no legal way to  
oppose (gegen die vorliegende Verügung keine Rechtsmittel möglich  
sind). This might be true for the immediately accused as they had  
their chance to answer but for us other 3rd party ISP's it can not  
hold true as we have never heard of this case ever before and we have  
not been involved in this case before.


I would suggest the ISP community of Switzerland stands up united  
against such ridiculous practice of judges who have no clue how the  
internet works:



I see two possible ways


a) All ISP's send an INvoice to the Party A for the installment of the  
filters. They have caused this work so they are liable for the cost.  
Its not our fault.


b) all ISP's object in written to the decision of being in this case  
and oppose.


or both.


What are your oppinions?





Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

I have answered the judge the following in german. I think he's  
stepping totally over the fence.



-- 
SNIP 


Basel, 16. Februar 2009

Dossier N° PE03.018380-YNT

Sehr geerte Damen und Herren,

Nehmen Sie zur Kentniss das ihr Schreiben von 11. Februar 2009 für uns  
keinerlei Relevanz hat. Als Internet Provider sind wir nicht  
verpflichtet die Verbindungen unserer Kunden ins Internet zu  
Zensurieren. Des weiteren verfügen wir nicht über die technischen  
Möglichkeiten dies zu tun und haben auch keine entsprechenden  
Absichten dies je zu tun. Auch wurde uns das Recht auf Anhörung  
verwehrt und jegliche Rekursmöglichkeit ausgeräumt was sicher nicht im  
Sinne der Rechtssprechung ist.


Falls Sie trotzdem darauf beharren das wir diese Seiten sperren  
sollen, weisen wir Sie darauf hin das dies nur unter dem Vorbehalt der  
vollständigen Vorausbezahlung sämtlicher Kosten geschene würde. Wir  
gehen davon aus das die Kosten für eine entsprechende Infrastruktur  
sich in der Grössenordnung von mehreren hundert tausend Franken liegt.


Mit freundlichen Grüssen

Andreas Fink

Geschäftsführer BebbiCell AG

--
On 16.02.2009, at 16:18, Mike Kellenberger wrote:

What about making the site URL public so as many people as possible  
can set up a mirror before the filter for original site is  
installed? Just to show how the Web works and that site filters are  
no good at all…


Besides, Google/Archive.org and others will have a copy as well…

Regards,

Mike

--
Mike Kellenberger  mike.kellenber...@escapenet.ch
Escapenet - the Web Company   Tel +41 52 235 0700
http://www.escapenet.ch   Skype mikek70atwork

Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch 
] Im Auftrag von Andreas Fink

Gesendet: Montag, 16. Februar 2009 16:09
An: swi...@swinog.ch
Betreff: [swinog] Post from Canton de Vaud

Hello Collegues,

Today I got a document sent to us because we are listed as ISP. You  
probably have all received it as well.
Its a case of a Party A against unknown who has said something  
wrong/bad about Party A. (Ehrverletzung/Verleumdung etc.)


While I can understand that Party A tries to get their right to get  
things wrong written about them is being changed to correct, the  
ISP's of Switzerland are now out of a sudden involved in this as  
they are in charge of blocking the corresponding site.



Also what upset's me most is the sentence that this is the status of  
a Verfügung from a Untersuchungsrichter and there is no legal  
way to oppose (gegen die vorliegende Verügung keine Rechtsmittel  
möglich sind). This might be true for the immediately accused as  
they had their chance to answer but for us other 3rd party ISP's  
it can not hold true as we have never heard of this case ever before  
and we have not been involved in this case before.


I would suggest the ISP community of Switzerland stands up united  
against such ridiculous practice of judges who have no clue how the  
internet works:



I see two possible ways


a) All ISP's send an INvoice to the Party A for the installment of  
the filters. They have caused this work so they are liable for the  
cost. Its not our fault.


b) all ISP's object in written to the decision of being in this case  
and oppose.


or both.


What are your oppinions?



Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
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

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

I have answered the judge the following in german. I think he's  
stepping totally over the fence.



-- 
SNIP 


Basel, 16. Februar 2009

Dossier N° PE03.018380-YNT

Sehr geerte Damen und Herren,

Nehmen Sie zur Kentniss das ihr Schreiben von 11. Februar 2009 für uns  
keinerlei Relevanz hat. Als Internet Provider sind wir nicht  
verpflichtet die Verbindungen unserer Kunden ins Internet zu  
Zensurieren. Des weiteren verfügen wir nicht über die technischen  
Möglichkeiten dies zu tun und haben auch keine entsprechenden  
Absichten dies je zu tun. Auch wurde uns das Recht auf Anhörung  
verwehrt und jegliche Rekursmöglichkeit ausgeräumt was sicher nicht im  
Sinne der Rechtssprechung ist.


Falls Sie trotzdem darauf beharren das wir diese Seiten sperren  
sollen, weisen wir Sie darauf hin das dies nur unter dem Vorbehalt der  
vollständigen Vorausbezahlung sämtlicher Kosten geschene würde. Wir  
gehen davon aus das die Kosten für eine entsprechende Infrastruktur  
sich in der Grössenordnung von mehreren hundert tausend Franken liegt.


Mit freundlichen Grüssen

Andreas Fink

Geschäftsführer BebbiCell AG

--
On 16.02.2009, at 16:18, Mike Kellenberger wrote:

What about making the site URL public so as many people as possible  
can set up a mirror before the filter for original site is  
installed? Just to show how the Web works and that site filters are  
no good at all…


Besides, Google/Archive.org and others will have a copy as well…

Regards,

Mike

--
Mike Kellenberger  mike.kellenber...@escapenet.ch
Escapenet - the Web Company   Tel +41 52 235 0700
http://www.escapenet.ch   Skype mikek70atwork

Von: swinog-boun...@lists.swinog.ch [mailto:swinog-boun...@lists.swinog.ch 
] Im Auftrag von Andreas Fink

Gesendet: Montag, 16. Februar 2009 16:09
An: swi...@swinog.ch
Betreff: [swinog] Post from Canton de Vaud

Hello Collegues,

Today I got a document sent to us because we are listed as ISP. You  
probably have all received it as well.
Its a case of a Party A against unknown who has said something  
wrong/bad about Party A. (Ehrverletzung/Verleumdung etc.)


While I can understand that Party A tries to get their right to get  
things wrong written about them is being changed to correct, the  
ISP's of Switzerland are now out of a sudden involved in this as  
they are in charge of blocking the corresponding site.



Also what upset's me most is the sentence that this is the status of  
a Verfügung from a Untersuchungsrichter and there is no legal  
way to oppose (gegen die vorliegende Verügung keine Rechtsmittel  
möglich sind). This might be true for the immediately accused as  
they had their chance to answer but for us other 3rd party ISP's  
it can not hold true as we have never heard of this case ever before  
and we have not been involved in this case before.


I would suggest the ISP community of Switzerland stands up united  
against such ridiculous practice of judges who have no clue how the  
internet works:



I see two possible ways


a) All ISP's send an INvoice to the Party A for the installment of  
the filters. They have caused this work so they are liable for the  
cost. Its not our fault.


b) all ISP's object in written to the decision of being in this case  
and oppose.


or both.


What are your oppinions?



Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
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

Re: [swinog] Post from Canton de Vaud

[Andreas Fink]

Its about the same content I believe. But very questionable legal  
wording from the judge.
And I found it very questionable to involve all ISP's into the case as  
part of the order without hearing them and without giving them the  
right to oppose.

This means we MUST SPEAK or we have silently accepted.

I'll have a scan online tomorrow for those who want to read it fully  
and have not got it themselves.


On 16.02.2009, at 17:01, Viktor Steinmann wrote:


Same same, but different...?

http://www.mail-archive.com/swi...@swinog.ch/msg00847.html

Kind regards,
Viktor


Andreas Fink wrote:

Hello Collegues,

Today I got a document sent to us because we are listed as ISP. You  
probably have all received it as well.
Its a case of a Party A against unknown who has said something  
wrong/bad about Party A. (Ehrverletzung/Verleumdung etc.)


While I can understand that Party A tries to get their right to get  
things wrong written about them is being changed to correct, the  
ISP's of Switzerland are now out of a sudden involved in this as  
they are in charge of blocking the corresponding site.



Also what upset's me most is the sentence that this is the status  
of a Verfügung from a Untersuchungsrichter and there is no  
legal way to oppose (gegen die vorliegende Verügung keine  
Rechtsmittel möglich sind). This might be true for the immediately  
accused as they had their chance to answer but for us other 3rd  
party ISP's it can not hold true as we have never heard of this  
case ever before and we have not been involved in this case before.


I would suggest the ISP community of Switzerland stands up united  
against such ridiculous practice of judges who have no clue how the  
internet works:



I see two possible ways


a) All ISP's send an INvoice to the Party A for the installment of  
the filters. They have caused this work so they are liable for the  
cost. Its not our fault.


b) all ISP's object in written to the decision of being in this  
case and oppose.


or both.


What are your oppinions?





Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org mailto:andr...@fink.org
www.finkconsulting.com http://www.finkconsulting.com www.global-networks.ch 
 www.bebbicell.ch

---
ICQ: 8239353 MSN: m...@gni.ch mailto:m...@gni.ch AIM: smsrelay  
Skype: andreasfink

Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK







___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog









Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  andr...@fink.org
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: m...@gni.ch AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Netclean - news

[Andreas Fink]

 And how long it will be before such machinery is
mandatory for all ISPs.

The excuse that there is no technical solution is gone - it was a lie
all along the way, and most techies knew.

Hmm it's not a lightly engineered solution. it was not an obvious one.


One thing to consider is that there are people out there who are ISP's  
just for a bunch of people or for people outside Switzerland.
So I'm not too sure what the solution costs but I'm sure its not  
available for free. I assume its around 10k at least.
Today this solution is easily affordable for the big guys but still  
expensive for the smaller ones (but I assume not out of reach as it  
was assumed).


Tomorrow they want to filter google for the search keyword child  
porn etc. Now go figure how many requests then will go through the  
box...!


The day after, the government thinks its smart and we should go one  
step further and start filtering videostreams by using a box which  
looks at the content. Then such a solution will start to cost  
100'000's of francs (at least once its invented). And down goes the  
deadly spiral. Someone pays the bill. Always.


If we give in to such matters, it means we will be asked more and more  
because everyone thinks its so easy to do technically. But that's not  
the point.


Blocking the sites won't bring the effect compared to the cost to the  
economy. Think of this: we sure have more than 40 ISP's in  
Switzerland. Assuming the box costs 10'000 CHF (and thats a pure  
guess), the cost to the swiss economy is 400'000 CHF (someone pays for  
it and I believe its going to be the end user at the end). Not even  
including the cost of maintaining it. For that amount you can send out  
quite a few policemen to take down child porn sites at the other end  
of the world which would be way more effective.


The law doesn't allow us to wiretap and intercept. So lets not start  
burning our fingers with something which does exactly that . The human  
rights of free speech should be hold high even in the fact that  
someone might stumble on.


One thing which would be interesting to hear is how many requests do  
such site actively block today? How many people have been prevented  
from seeing nasty content? What has this saved Switzerland that those  
people did not see the content? Is this bigger than the cost?


Frankly, since the 15 years I'm using the internet, there has not been  
a single time where I stumbled on to child porn, and if I would, it  
would take me 0.5 seconds to realize and go away. This was probably  
because I was not actively looking for it. So for me (taking the hat  
of a  a normal typical user now), such a solution would bring zero  
value. The value might more be negative because there's the danger  
that something might get blocked by mistake.


The key question is who do you want to protect and from what?

The child porn lover wont be protected. You might make him more  
angry maybe, but it wont change his intention. He might even go and  
rape real children instead because he can't do it in virtuality.  
Everybody else with a normal moral sense who would see such content  
would either close the window immediately and/or call the police to  
take down the publisher.


Closing your eyes in front of a problem wont solve the problem.
Its like selling sunglasses to protect your skin at the beach.










Andreas Fink

Fink Consulting GmbH
Global Networks Schweiz AG
BebbiCell AG
IceCell ehf

---
Tel: +41-61-330 Fax: +41-61-331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
E-Mail:  [EMAIL PROTECTED]
www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
---
ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333

http://a-fink.blogspot.com/   A developers view about iPhone SDK





___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog