- Test - lists.nanog.org

Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues
by Lauren Weinstein 17 Feb '09

17 Feb '09

Announcing GCTIP - New Forums for Internet Transparency, Performance, and ISP Issues http://lauren.vortex.com/archive/000506.html Greetings. I'm pleased to announce the availability of a new venue for discussion, reporting, analysis, information sharing, queries, and consumer assistance regarding Internet performance, transparency, and measurement, plus a wide range of topics associated with consumers and their interactions with Internet Service Providers (ISPs). Called GCTIP Forums: http://forums.gctip.org this project -- The "Global Coalition for Transparent Internet Performance" -- is the outgrowth of a network measurement workshop meeting sponsored by Vint Cerf and Google at their headquarters in June, 2008 for a number of academic network measurement researchers and other related parties. This is the same meeting that formed the genesis of the open platform M-Lab ("Measurement Lab") project that was recently announced ( http://www.measurementlab.net ). GCTIP was the original name for the mailing list that I maintained for that Google meeting and subsequent discussions (full disclosure: I helped to organize the agenda for the meeting and also attended). Unless we know what the performance of the Internet for any given users really is -- true bandwidth performance, traffic management, port blocking, server prohibitions, Terms of Service concerns, and a wide range of other parameters, it's impossible for anyone who uses Internet services to really know if they're getting what they're paying for, if their data is being handled appropriately in terms of privacy and security, and all manner of other crucial related issues. While transparency and related concerns do have impacts on "network neutrality" issues, neither GCTIP nor GCTIP Forums are oriented toward network neutrality discussions. The purpose of GCTIP Forums is to provide a free discussion environment to act as a clearinghouse for all stakeholders (technical, consumers, ISPs, government-related, etc.) to interact on the range of "network transparency" and associated topics. The focus is on collecting, analyzing, and disseminating reports relating to Internet measurement/test data -- plus associated concerns, discussions, etc., in manners that are most useful to the network community at large. There are many groups working in the network measurement area, but surprisingly little data sharing, coordination, or ongoing reporting in a form that is useful to most ordinary Internet consumers or other interested observers. An area of particular concern is helping to assure that measurement tests and perceived consumer problems with their ISPs aren't misinterpreted by users resulting in unfair or simply wrong accusations against those ISPs. I feel strongly that consumers need a place to go with these sorts of issues where the broader community and experts can help interpret what's really going on. Guilty firms should be exposed, but the innocent must not be inappropriately branded. All current GCTIP Forums topics can be viewed without signing up on the system. Simple registration is required to post new discussion threads and replies, but no non-administrative topics are currently pre-moderated (any reported materials confirmed to be inappropriate will be deleted promptly). GCTIP Forums exist to enable the exchange of relevant ideas, queries, data, and other information for anyone concerned about the Internet worldwide. The Forums are seeded with five top-level discussion topics to get things rolling, but suggestions for additional categories are welcome. New threads (e.g. discussions of particular measurement tools, measurement results, specific ISP issues and concerns, etc.) can be created by registered users, starting right now. Please note that I am running GCTIP on my own dime at this point. At such a time as any outside support funding becomes available for the project (which would be very much appreciated!) it will be publicly announced of course. Spread the word! This is your chance to help yourself and everyone else better understand what the Internet is <b>really</b> doing, and by extension, where it is going tomorrow. Thanks very much. Be seeing you ... at: http://forums.gctip.org ... --Lauren-- Lauren Weinstein lauren(a)vortex.com or lauren(a)pfir.org Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Co-Founder, NNSquad - Network Neutrality Squad - http://www.nnsquad.org Founder, PRIVACY Forum - http://www.vortex.com Member, ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com

1 0

Shadowserver - ASN & Netblock Alerting & Reporting Service
by Andre' M. DiMino 17 Feb '09

17 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Shadowserver Foundation is pleased to announce the formal rollout of our ASN/netblock alerting and reporting service. This reporting service is provided free-of-charge and is designed for ISPs, enterprises, hosting providers, and other organizations that directly own or control network space. It allows them to receive customized reports detailing detected malicious activity to assist in their detection and mitigation program. Shadowserver has been providing this service to many subscribers for over two years, and currently generate over 4000 reports nightly. Since the response to this service has been extremely positive from our consumer base, we now wish to make it more widely and openly available. The reporting service monitors and alerts the following activity: Detected Botnet Command and Control servers Infected systems (drones) DDoS attacks (source and victim) Scans Clickfraud Compromised hosts Proxies Spam relays Malicious software droppers and other related information. The Shadowserver Foundation filters data received from its worldwide sensor and monitoring networks and employs an analysis engine to classify the attacks. It then sorts this data according to ASN, netblock, and even Geolocation. Detected malicious activity on a subscriber's network is flagged accordingly and is included in daily summarization reports detailing the previous 24 hours of activity. Reports are only sent upon detection of malicious activity. These customized reports are made freely available to the responsible network operators as a subscription service. To request a free subscription to The Shadowserver Foundation's ASN/netblock reporting service, send an email from your organization's email account to admin(a)shadowserver.org Please provide the following information: Name Organization Networks of responsibility by ASN or CIDR Email address(es) of the report receipients Contact information for verification The Shadowserver Foundation is an all volunteer, non-profit, vendor-neutral organization that gathers, tracks, and reports on malicious software, botnet activity, and electronic fraud. It is the mission of the Shadowserver Foundation to improve the security of the Internet by raising awareness of the presence of compromised servers, malicious attackers, and the spread of malicious software. - -- Andre' M. Di Mino - SemperSecurus The Shadowserver Foundation http://www.shadowserver.org Skype: sempersecurus AIM: sempersecurus "Make sure that nobody pays back wrong for wrong, but always try to be kind to each other and to everyone else." 1 Thessalonians 5:15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmaQsEACgkQPJaIJoADD653DQCgkF4aRfxbpSh+IxBfGyrMqT3X eAYAnjfPpeA8ATZ//s1VUrim8DbZPO0C =oMJw -----END PGP SIGNATURE-----

1 0

Global Blackhole Service
by Jens Ott - PlusServer AG 16 Feb '09

16 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, in the last 24 hours we received two denial of service attacks with something like 6-8GBit volume. It did not harm us too much, but e.g. one of our upstreams got his Amsix-Port exploded. With our upstreams we have remote-blackhole sessions running where we announce /32 prefixes to blackhole at their edge, but this does not work with our peers. Also our Decix-Port received something like 2Gbit extra-traffic during this DoS. I can imagine, that for some peers, especially for the once having only a thin fiber (e.g. 1GBit) to Decix, it's not to funny having it flooded with a DoS and that they might be interested in dropping such traffic at their edge. Well I could discuss with my peers (at least the once who might get in trouble with such issue) to do some individual config for some blackhole-announcement, but most probably I'm not the only one receiving DoS and who would be interested in such setup. Therefore I had the following idea: Why not taking one of my old routers and set it up as blackhole-service. Then everyone who is interested could set up a session to there and 1.) announce /32 (/128) routes out of his prefixes to blackhole them 2.) receive all the /32 (/128) announcements from the other peers with the IPs they want to have blackholed and rollout the blackhole to their network. My questions to all of you: - - What do you think about such service? - - Would you/your ASN participate in such a service? - - Do you see some kind of usefull feature in such a service? - - Do you have any comments? Thank you for telling me your opinions and best regards - -- =================================================================== Jens Ott Leiter Network Management Tel: +49 22 33 - 612 - 3501 Fax: +49 22 33 - 612 - 53501 E-Mail: j.ott(a)plusserver.de GPG-Fingerprint: 808A EADF C476 FABE 2366 8402 31FD 328C C2CA 7D7A PlusServer AG Daimlerstraße 9-11 50354 Hürth Germany HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823 Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe Aufsichtsratsvorsitz: Claudius Schmalschläger =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmVilwACgkQMf0yjMLKfXpNuQCeKcicthIadISe7I+Xs5ZNHS+1 0qUAnRDkOY9/6kokq3Hf68BRQFfkP3xy =jKUA -----END PGP SIGNATURE-----

21 28

Looking for GBLX contact + check your ACL for 66.249.96.0/20 please :)
by Swen Wulf 16 Feb '09

16 Feb '09

Hello, We have been assigned 66.249.96.0/20 in April of 2008. Little did we know that this network was used by a spammer in 2004 (Lightwave Transit) and with this is deeply embedded in a lot of ACL's that seem to be unmaintained. If a GLBX engineer could take a look, it seems traffic originating from 66.249.96.0/20 can't reach some website when passing thru GBLX. Other prefixes we announce from our AS (22442) such as 66.60.224.0/20 don't have this problem. Customer with source of 66.249.106.112/27 can't get to the website of www.ups.com (72.246.89.243 (akamai)). core1#traceroute 72.246.89.243 source 66.249.106.113 Type escape sequence to abort. Tracing the route to a72-246-89-243.deploy.akamaitechnologies.com (72.246.89.243) 1 ge-1-11.r03.hstntx01.us.bb.gin.ntt.net (128.241.5.1) 0 msec 0 msec 0 msec 2 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) [AS 2914] 0 msec 0 msec 0 msec 3 p64-1-3-0.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) [AS 2914] 8 msec 8 msec 8 msec 4 po-2.r03.dllstx09.us.bb.gin.ntt.net (129.250.4.38) [AS 2914] 4 msec 4 msec 8 msec 5 xe-0.globalcrossing.dllstx09.us.bb.gin.ntt.net (129.250.8.190) [AS 2914] 4 msec 8 msec 4 msec 6 te7-1-10G.ar2.DAL2.gblx.net (67.16.129.117) [AS 3549] 8 msec 12 msec 4 msec 7 * * * 8 * * And from a different source IP from the same router core1#traceroute 72.246.89.243 source 66.60.233.1 Type escape sequence to abort. Tracing the route to a72-246-89-243.deploy.akamaitechnologies.com (72.246.89.243) 1 ge-1-11.r03.hstntx01.us.bb.gin.ntt.net (128.241.5.1) 4 msec 0 msec 0 msec 2 xe-0-1-0.r20.hstntx01.us.bb.gin.ntt.net (129.250.2.228) [AS 2914] 0 msec 4 msec 0 msec 3 p64-1-3-0.r20.dllstx09.us.bb.gin.ntt.net (129.250.3.129) [AS 2914] 8 msec 8 msec 8 msec 4 po-2.r03.dllstx09.us.bb.gin.ntt.net (129.250.4.38) [AS 2914] 4 msec 8 msec * 5 xe-0.globalcrossing.dllstx09.us.bb.gin.ntt.net (129.250.8.190) [AS 2914] 4 msec 8 msec 8 msec 6 te7-1-10G.ar2.DAL2.gblx.net (67.16.129.117) [AS 3549] 4 msec 8 msec 8 msec 7 PCCW-Global-Chicago-Dallas.te3-2.ar2.DAL2.gblx.net (64.211.211.186) [AS 3549] 200 msec 24 msec 212 msec 8 * * * 9 I tried an email to their puck noc email address, but without being a customer I can't open a ticket. Thanks, Swen Wulf Network Security Manager Email: swulf(a)phonoscope.com Phone: 832-615-7743 (direct) Fax: 832-213-0110 --- * Network Operations Center (NOC): 713-272-4600 (24x7x365) --- Phonoscope - moving at the speed of light

1 0

3/11 (invalid or corrupt AS path)
by Ozar 16 Feb '09

16 Feb '09

I am starting to see random BGP neighbor messages from multiple neighbors on different boxes. %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt AS path) 516 bytes I dont see much documentation on this, and we are in the process of opening a TAC case, just curious if anyone else has seen these and may be able to shed some light. Thanks

3 2

Littering the global BGP - AS 47868
by Ran Liebermann 16 Feb '09

16 Feb '09

Hi all, We're seeing some garbage being thrown into the global BGP table by AS 47868. %BGP-6-ASPATH: Long AS path 3549 3257 29113 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 received from 208.49.128.49: Has more than 255 AS This is hitting some routers with older software versions. Is there someone here from AS 29113 (Sloane Park Property Trust in the Czech Repulic) that can filter this from the source? Cheers, -- Ran Liebermann VP Engineering, PurePeak ranl(a)purepeak.com http://purepeak.com

1 0

Re: Linux Router: TCP slow, UDP fast
by Chris 15 Feb '09

15 Feb '09

Thanks, Karl, Allen and Nickola. I failed-over to another router last night and briefly had full expected throughput but this morning despite dropping providers and moving between routers again for trial and error I still see _outbound_ TCP at about the same 300 - 600kbps per session. I eliminated conntract modules firstly, then iptables as a whole. I've eliminated TSO and checksumming (which caused very sticky connections) on the e1000 NIC. The failover router has a slightly older kernel and was working before Christmas so it's not most likely not kernel versions. I've also tried removing FIB_TRIE as a stab in the dark with no success. And the failover router connects using FE not GE so I've eliminated NICs and connection speeds to a front-facing switch. The only constant is the front-facing switch (it's negotiating perfectly at FD though) so all I can think of is removing that from the equation. It's definitely only _outbound_ TCP getting buffered though ! I've pushed 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. Any last ideas appreciated before causing headaches removing switches would be appreciated. Thanks, Chris

2 1

Re: Linux Router: TCP slow, UDP fast
by Chris 15 Feb '09

15 Feb '09

Thanks for the suggestions everyone. I've got to the bottom of the problem now (I'm sure there will be a collective sigh of relief from the list because of the noise this thread generated :-)). I installed two brand new, low spec, 3Com switches one at the 'front' of the network and one 'behind' the routers. They are the same model, same latest firmware, same config (saved to and then copied off disk) and only their IPs were different. The front switch was the problem. As two final tests before removing it we switched off unicast/multicast broadcast control and flow control (and simultaneously on the same port on the switch behind the routers) because there were pause frames showing but not a massive amount in terms of percentage. The switch behind the routers however is serving the same bandwidth equally well ! We've put an ancient switch in place of the front switch and its been working perfectly so far. My lesson learned is too change as little as possible at once ! That said, recent network changes were spread about a month apart and this very odd issue was far easier to dismiss than believe due to its bizarre nature. Especially when providers have changes in their network conditions as testing is done. I really appreciate all the input and have learnt loads, possibly just not in the way I would have liked to :-) Doubles all round, Chris

1 0

Re: Linux Router: TCP slow, UDP fast
by Mathias Wolkert 15 Feb '09

15 Feb '09

I would turn off ethernet flow control. Maybe you already have. It can be really mean on tcp's own flow control if the switch has an issue of some kind (load). /Tias 15 feb 2009 kl. 10.24 skrev Chris <chris(a)ghostbusters.co.uk>: > Thanks, Karl, Allen and Nickola. > I failed-over to another router last night and briefly had full > expected > throughput but this morning despite dropping providers and moving > between > routers again for trial and error I still see _outbound_ TCP at > about the > same 300 - 600kbps per session. > > I eliminated conntract modules firstly, then iptables as a whole. I've > eliminated TSO and checksumming (which caused very sticky > connections) on > the e1000 NIC. > > The failover router has a slightly older kernel and was working before > Christmas so it's not most likely not kernel versions. I've also tried > removing FIB_TRIE as a stab in the dark with no success. And the > failover > router connects using FE not GE so I've eliminated NICs and connection > speeds to a front-facing switch. > > The only constant is the front-facing switch (it's negotiating > perfectly at > FD though) so all I can think of is removing that from the equation. > > It's definitely only _outbound_ TCP getting buffered though ! I've > pushed > 92Mbps on a FE link with UDP and uploaded at 16Mbps on a 16Mbps link. > > Any last ideas appreciated before causing headaches removing > switches would > be appreciated. > > Thanks, > > Chris

1 0

Re: Global Blackhole Service
by Nuno Vieira - nfsi telecom 15 Feb '09

15 Feb '09

Hi Suresh, But in the meanwhile, a decade later, it does not longer exist. At least, i can't reach that host, and i was unable to find working documentation on google of how about this project works, today. In fact, the first link that google gave out, says that this project is dead at least 2 years ago. http://www.dnsbl.com/2007/02/status-of-rblmapsvixcom-invalid-domain.html I think that we all have a real opportunity here for make something that can be useful to all. And, we are not talk of spam here, but, to mitigate time, money and patience consuming DDoS attacks, which often are easier to mitigate only at the Source and at the Destination, while at Destinatation, sink is the only viable solution that is out there today. regards, --- Nuno Vieira nfsi telecom, lda. nuno.vieira(a)nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Suresh Ramasubramanian" <ops.lists(a)gmail.com> wrote: > On Fri, Feb 13, 2009 at 8:27 PM, Jens Ott - PlusServer AG > <j.ott(a)plusserver.de> wrote: > > - - What do you think about such service? > > - - Would you/your ASN participate in such a service? > > - - Do you see some kind of usefull feature in such a service? > > - - Do you have any comments? > > Ah. rbl.maps.vix.com from about a decade back when it was available > as > a bgp feed. But only for ddos sources. > > srs

10 14