- Test - lists.nanog.org

AS3.196 [91.213.29.0/24] IM-AS Info-Media Ltd
by Paul Ferguson 13 Oct '09

13 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm a bit confused (nothing really new here) with this BGP announcement, but following up on some cyber crime activity I stumbled on this: [Querying v4.whois.cymru.com] [v4.whois.cymru.com] AS | IP | AS Name 23456 | 91.213.29.250 | -Reserved AS- Is this legitimate? route-views2.routeviews.org> sho ip bgp 91.213.29.250 BGP routing table entry for 91.213.29.0/24 Paths: (42 available, best #33, table Default-IP-Routing-Table) Not advertised to any peer 6939 9002 40965 196804 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external Last update: Mon Oct 12 17:18:08 2009 13030 9002 40965 196804 213.144.128.203 from 213.144.128.203 (213.144.128.203) Origin IGP, metric 1, localpref 100, valid, external Community: 13030:1 13030:1016 Last update: Mon Oct 12 13:10:14 2009 14608 4323 9002 40965 196804 209.161.175.4 from 209.161.175.4 (209.161.175.4) Origin IGP, localpref 100, valid, external Community: no-export Last update: Mon Oct 12 08:06:19 2009 286 9002 40965 196804 134.222.87.3 from 134.222.87.3 (134.222.85.108) Origin IGP, metric 0, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:50 2009 1299 3549 9002 40965 196804 213.248.83.252 from 213.248.83.252 (213.248.83.252) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:43:18 2009 3303 9002 40965 196804 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 1120:2 3303:1004 3303:1006 3303:3056 Last update: Thu Oct 8 15:06:42 2009 2905 702 9002 40965 196804 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external Last update: Thu Oct 8 15:42:42 2009 31500 3267 9002 40965 196804 95.140.80.254 from 95.140.80.254 (1.0.0.10) Origin IGP, metric 0, localpref 100, valid, external Last update: Tue Oct 13 00:33:35 2009 1221 4637 3549 9002 40965 196804 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:32 2009 5056 1239 3549 9002 40965 196804 167.142.3.6 from 167.142.3.6 (167.142.225.101) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 15:10:31 2009 7660 2516 3549 9002 40965 196804 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 Last update: Thu Oct 8 14:44:01 2009 6762 3549 9002 40965 196804 195.22.216.188 from 195.22.216.188 (195.22.216.188) Origin IGP, metric 100, localpref 100, valid, external Community: 6762:31 Last update: Thu Oct 8 14:43:28 2009 16150 9002 40965 196804 217.75.96.60 from 217.75.96.60 (217.75.96.60) Origin IGP, metric 0, localpref 100, valid, external Community: 16150:63392 16150:65215 16150:65320 Last update: Thu Oct 8 14:43:26 2009 6453 3549 9002 40965 196804 207.45.223.244 from 207.45.223.244 (66.110.0.124) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:25 2009 2152 11164 9002 40965 196804 137.164.16.12 from 137.164.16.12 (137.164.16.196) Origin IGP, localpref 100, valid, external Community: 2152:65299 2152:65506 11164:1130 11164:7880 Last update: Sat Oct 10 13:52:50 2009 6453 3549 9002 40965 196804 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:22 2009 3277 3267 9002 40965 196804 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 Last update: Thu Oct 8 14:43:51 2009 852 3561 9002 40965 196804 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Thu Oct 8 14:43:21 2009 3356 9002 40965 40965 196804 4.69.184.193 from 4.69.184.193 (4.68.3.50) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076 65000:0 Last update: Tue Oct 13 06:09:59 2009 701 3549 9002 40965 196804 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:48 2009 8492 9002 40965 196804 85.114.0.217 from 85.114.0.217 (85.114.0.2) Origin IGP, localpref 100, valid, external Community: 8492:1101 9002:0 9002:64677 Last update: Thu Oct 8 14:43:16 2009 5413 9002 40965 196804 62.72.136.2 from 62.72.136.2 (62.72.136.2) Origin IGP, metric 47, localpref 100, valid, external Last update: Thu Oct 8 14:43:15 2009 1239 3549 9002 40965 196804 144.228.241.130 from 144.228.241.130 (144.228.241.130) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:45 2009 286 9002 40965 196804 134.222.87.1 from 134.222.87.1 (134.222.86.1) Origin IGP, localpref 100, valid, external Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3044 286:4019 Last update: Sat Oct 10 22:44:29 2009 6539 9002 40965 196804 216.18.31.102 from 216.18.31.102 (216.18.31.102) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:12 2009 3130 2914 3549 9002 40965 196804 147.28.7.1 from 147.28.7.1 (147.28.7.1) Origin IGP, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 3130:380 Last update: Thu Oct 8 14:43:11 2009 11686 11164 9002 40965 196804 96.4.0.55 from 96.4.0.55 (96.4.0.55) Origin IGP, localpref 100, valid, external Last update: Sat Oct 10 13:53:11 2009 1668 3549 9002 40965 196804 66.185.128.1 from 66.185.128.1 (66.185.128.3) Origin IGP, metric 502, localpref 100, valid, external Last update: Thu Oct 8 14:43:36 2009 3549 9002 40965 196804 67.17.82.114 from 67.17.82.114 (67.17.82.114) Origin IGP, metric 14124, localpref 100, valid, external Last update: Fri Oct 9 06:56:29 2009 3130 1239 3549 9002 40965 196804 147.28.7.2 from 147.28.7.2 (147.28.7.2) Origin IGP, metric 0, localpref 100, valid, external Community: 3130:370 3130:380 Last update: Thu Oct 8 14:43:21 2009 2914 3549 9002 40965 196804 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin IGP, metric 10, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3549 Last update: Thu Oct 8 14:43:21 2009 2914 3549 9002 40965 196804 129.250.0.171 from 129.250.0.171 (129.250.0.79) Origin IGP, metric 5, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3549 Last update: Thu Oct 8 14:43:23 2009 2497 9002 40965 196804 202.232.0.3 from 202.232.0.3 (58.138.96.149) Origin IGP, localpref 100, valid, external, best Last update: Thu Oct 8 14:43:02 2009 852 3561 9002 40965 196804 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 Last update: Sun Oct 11 01:25:14 2009 3257 3549 9002 40965 196804 89.149.178.10 from 89.149.178.10 (213.200.87.91) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901 Last update: Thu Oct 8 14:43:09 2009 7018 3549 9002 40965 196804 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 Last update: Thu Oct 8 15:14:46 2009 13237 9002 40965 196804 81.209.156.1 from 81.209.156.1 (81.209.156.1) Origin IGP, localpref 100, valid, external Community: 13237:40044 13237:46441 Last update: Thu Oct 8 14:42:58 2009 8001 9002 40965 196804 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external Community: 8001:2000 8001:2001 Last update: Thu Oct 8 14:42:58 2009 3549 9002 40965 196804 208.51.134.246 from 208.51.134.246 (67.17.80.153) Origin IGP, metric 2633, localpref 100, valid, external Community: 3549:350 3549:4721 3549:31276 Last update: Thu Oct 8 14:42:58 2009 3561 9002 40965 196804 206.24.210.102 from 206.24.210.102 (206.24.210.102) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:42:58 2009 293 9002 40965 196804 198.129.33.85 from 198.129.33.85 (134.55.200.25) Origin IGP, localpref 100, valid, external Community: 293:14 Last update: Sat Oct 10 19:41:35 2009 812 3549 9002 40965 196804 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external Last update: Thu Oct 8 14:43:56 2009 route-views2.routeviews.org> See also: http://www.cidr-report.org/cgi-bin/as-report?as=196804 There's been some major criminal activity in this prefix and I was just following up on some research... http://www.malwareurl.com/search.php?domain=&s=91.213.29&match=0&rp=200&url s=on&redirs=on&ip=on&reverse=on&as=on Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFK1CD9q1pz9mNUZTMRAlfUAJ9u05ha1WP1RBnpW9ZpI5l5BLNERgCg8htQ UTeIoSWYUG8rBOTFltiWn9M= =1hHh -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/

2 2

APRICOT 2010 Call for Papers
by Jonny Martin 12 Oct '09

12 Oct '09

[Apologies for duplicates] Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 23 February - 5 March 2010, Kuala Lumpur, Malaysia http://www.apricot2010.net CALL FOR PAPERS =============== The APRICOT 2010 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2010. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at http://submission.apricot.net/paper/user/login.php?event=22 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 12 October 2009 First Deadline for Submissions: 30 November 2009 First Draft Programme Published: 7 December 2009 Final Deadline for Submissions: 14 February 2010 Final Programme Published: 15 February 2010 Final Slides Received: 19 February 2010 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CFP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at http://submission.apricot.net/paper/user/login.php?event=22 Any questions or concerns should be addressed to the Programme Committee by e-mail. We look forward to receiving your presentation proposals. Jonny Martin & Philip Smith Co-Chairs, APRICOT Programme Committee program(a)apricot.net

1 0

Re: Does Internet Speed Vary by Season?
by Frank A. Coluccio 12 Oct '09

12 Oct '09

Hi Fred. I think you are referring, in the case of hierarchical synchronous architectures (SONET/SDH), to the absolute periodicity of the timing coming from clock sources. Frame slips and overwrites can occur when too many ppm lagging or leading are exceeded, as I believe was implied in your post. In contrast, I believe the notions that are being discussed in this thread have more to do with the effects of temperature coefficients of metallic conductors during shifts in outside temperature conditions, and the ensuing changes in the nominal velocity of propagation that accompany those changes, relative to the speed of light. In any case, I have been following this discussion from its beginning with a great amount of interest, finding it a great memory jogger from times misspent in my youth. I started a parallel discussion on my forum, where today I responded to another poster with the following observations, for anyone interested. [1]http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089 Frank --- fred(a)cisco.com wrote: From: Fred Baker <fred(a)cisco.com> To: Dragos Ruiu <dr(a)kyx.net> Cc: nanog(a)nanog.org, Joe Greco <jgreco(a)ns.sol.net> Subject: Re: Does Internet Speed Vary by Season? Date: Sat, 10 Oct 2009 14:27:07 -0700 On Oct 9, 2009, at 5:38 PM, Dragos Ruiu wrote: > Well, since it's been documented that internet speed / usage varies > with > the weather (it gets faster when it's sunny, slower when it rains) > I'm sure some > seasonal correlation could be found. Could you point to the documentation? I having trouble with language that sounds like one concept and I suspect is in fact another. Take as one example the basic digital signaling hierarchy. The specifications call for a certain rate plus or minus some number of parts per million. If they are within tolerance, the amount that they would speed up or slow down is measured in a pretty small number of bits per second. So I don't think the speed of the links is materially changing. If on the other hand we are discussing the volume of traffic using that available capacity, it is absolutely clear that there are diurnal, weekly, and seasonal variations as well as growth in time. Are we talking about bit rate, which one might expect to be modified by environmental characteristics and is in fact very tightly controlled to prevent that, or traffic volume? References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26010089

4 4

Does Internet Speed Vary by Season?
by Hank Nussbacher 12 Oct '09

12 Oct '09

http://www.wired.com/gadgets/miscellaneous/magazine/17-10/ts_burningquestion -Hank

22 26

Invalid prefix announcement from AS9035 for 129.77.0.0/16
by Matthew Huff 11 Oct '09

11 Oct '09

About 4 hours ago BGPmon picked up a rogue announcement of 129.77.0.0 from AS9035 (ASN-WIND Wind Telecomunicazioni spa) with an upstream of AS1267 (ASN-INFOSTRADA Infostrada S.p.A.). I don't see it now on any looking glass sites. Hopefully this was just a typo that was quickly corrected. I would appreciate if people have time and can double check let me know if any announcements are active except from our AS6128/AS6395 upstreams. If this were to persist, what would be the best course of action to resolve it, especially given that the AS was within RIPE. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139

10 14

32-bit AS numbers
by Iljitsch van Beijnum 10 Oct '09

10 Oct '09

Hi all, As you (hopefully) know, as of 1-1-2010, the RIRs will only be giving out 32-bit AS numbers. I'm writing an article for Ars Technica about this, and I was wondering about the perspective of network operators who may be faced with customers with a 32-bit AS number in the near future, and how the vendor support for 32-bit AS numbers is working out. If you send me info in private mail, let me know your title/ affiliation and whether I can quote you or not. Iljitsch

10 9

Re: NEED Some HELP
by Bong Barnido 10 Oct '09

10 Oct '09

Hi Roland, My GSR and 6509 are newly installed and no ACLs in place. You can try to ping 180.178.73.1 and 180.178,73.2. 180.178.73.1 - GSR 180.178,73.2 - 6509 I can only reach 180.178.73.1 from outside. I cannot reach 180.178.73.2 which is the IP of my 6509. Not sure if this has something to do with the hardware. I am just wondering why I can't reach 180.178,73.2. Like I said earlier in my email, I have the default route from my 6509 to te GSR. My GE module is inserted to the GSR slot 1. Is the "hw-module" config requred on the GSR? Please help. Thanks, -bong ------------------------------ Message: 7 Date: Sat, 10 Oct 2009 16:24:35 +0700 From: Roland Dobbins <rdobbins(a)arbor.net> Subject: Re: NEED Some HELP To: NANOG list <nanog(a)nanog.org> Message-ID: <0D85644F-A83F-461B-A9FB-EEBF54259DD6(a)arbor.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Oct 10, 2009, at 4:12 PM, Bong Barnido wrote: > I cannot ping the IP on my Cisco 6509 from the internet. Quite out of the context of the connectivity issue you're trying to troubleshoot, it's in fact extremely desirable to have your 6509 (and all your routers, for that matter) unpingable from the outside your own network. The BCP is to use iACLs, CoPP, et. al. to keep out all unsolicited traffic headed to, as opposed to through (like traceroute, pinging customer hosts, etc.), your network infrastructure. ----------------------------------------------------------------------- Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ------------------------------ Message: 6 Date: Sat, 10 Oct 2009 17:12:13 +0800 From: Bong Barnido <bong.barnido(a)gmail.com> Subject: NEED Some HELP To: nanog(a)nanog.org Message-ID: <16a26ba20910100212i2158e929peef59520613150c8(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi Nanog Members, I've been troubleshooting this problem for a few days already but i'm still unable to fix it. I think it's now time to ask some help from Nanog members. I cannot ping the IP on my Cisco 6509 from the internet. Here are the setup: *Internet*---(copper)-->*GSR*----(fiber)--->* Cisco 6509* <<<<<This setup is NOT OK - I cannot ping *Internet*---(copper)-->*GSR*----(copper)---> *Cisco 6509* <<<<< This setup is OK - I can ping(this is directly connected to the PRP2) NOTES: - I am using PRP2 on my GSR and the fiber is connected to the 4xGE module - I have a default route from Cisco 6509 to GSR - From the 6509 I can only ping the IP addresses on the GSR, addresses outside the GSR are not reachable - From the internet, I can only ping up to the GSR - I can ping from GSR to 6509 and vise versa - The IP on the 6509 is configured on the interface that is directly connected to the GSR. Thanks, -bong

1 0

NEED Some HELP
by Bong Barnido 10 Oct '09

10 Oct '09

Hi Nanog Members, I've been troubleshooting this problem for a few days already but i'm still unable to fix it. I think it's now time to ask some help from Nanog members. I cannot ping the IP on my Cisco 6509 from the internet. Here are the setup: *Internet*---(copper)-->*GSR*----(fiber)--->* Cisco 6509* <<<<<This setup is NOT OK - I cannot ping *Internet*---(copper)-->*GSR*----(copper)---> *Cisco 6509* <<<<< This setup is OK - I can ping(this is directly connected to the PRP2) NOTES: - I am using PRP2 on my GSR and the fiber is connected to the 4xGE module - I have a default route from Cisco 6509 to GSR - From the 6509 I can only ping the IP addresses on the GSR, addresses outside the GSR are not reachable - From the internet, I can only ping up to the GSR - I can ping from GSR to 6509 and vise versa - The IP on the 6509 is configured on the interface that is directly connected to the GSR. Thanks, -bong

2 1

Dutch ISPs to collaborate and take responsibility for botted clients
by Gadi Evron 10 Oct '09

10 Oct '09

The story is covered by PC mag: ------- ... major Dutch ISPs have agreed to share information and establish a common set of rules for responding to users infected with malware, especially those in botnets. The agreement, called a "treaty" by locals, involves 14 ISPs covering 98% of the market. A major reason ISPs are hesitant to take deliberate measures against such systems is that they are afraid that disconnecting users and making them spend time and money cleaning up their systems will only drive them into the hands of competitors. And the support process itself is expensive, probably wiping out the profit from that user. But with such high coverage of the market users may not have permissive alternatives. This will be an interesting phenomenon to watch. If it is successful perhaps it could work here too." ------- I couldn't find the story in English in a version that did not link to my original post, I waited a few days to see if anyone else picks it up, as I don't want yet another self-promotion fight. No one I found in under 2 minutes on Google did, so this second-hand link should do. http://blogs.pcmag.com/securitywatch/2009/09/dutch_isps_sign_anti-botnet_tr… Enjoy, Gadi.

25 37

RE: Dutch ISPs to collaborate and take responsibility
by Skywing 10 Oct '09

10 Oct '09

....or when I initiate offsite backups. I've seen ISPs that react to just traffic bursts. It's not the way to go without more intelligent decision making on the content (i.e. SMTP, all SYNs, etc). Of course, content inspection is a whole 'nother hornet's nest :) - S -----Original Message----- From: Lee <ler762(a)gmail.com> Sent: Friday, October 09, 2009 19:41 To: nanog(a)nanog.org <nanog(a)nanog.org> Subject: Re: Dutch ISPs to collaborate and take responsibility On 10/9/09, Rich Kulawiec <rsk(a)gsp.org> wrote: > On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: >> Additionally the problems of DDOS sourced from a collection of >> compromised hosts could be interfering with someone else's ability >> to make a successful VOIP call. > > Much more than that: they could be interfering with the underlying > infrastructure, or they could be attacking the VOIP destination, > or they could be making fake VOIP calls (see below), or they could > be doing ANYTHING. A compromised system is enemy territory, which is why: > >> This blocking should be as narrow as possible. > > Blocking should be total. A compromised system is as much > enemy-controlled as if it were physically located at the RBN. Trying > to figure out which of externally-visible behaviors A, B, C, etc. > it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee

1 0