- NANOG - lists.nanog.org

JANOG 33 Program Published
by Izumi Okutani 09 Dec '13

09 Dec '13

Dear Colleagues, We have published the program for JANOG 33 and welcome you to join us in Beppu City, Japan, from 23rd-24th Jan 2014. Most sessions are in Japanese only but there are a few sessions in English. You are also welcome to connect with us through facebook and twitter for updates in English. The JANOG SNS accounts are open to everyone, including those who are not able to attend the meeting. See you in Beppu. Cheers, Shinichi Yamamoto, Chin Sze Yih, Izumi Okutani JANOG Internationalization team for JANOG 33 ----- JANOG 33 Program : ------------------------ The Program is available in English at: http://www.janog.gr.jp/en/index.php?JANOG33%20Programs%2FJANOG33%20Program%… Translations of the program titles and abstracts were supported by volunteers on the best efforts basis. Note: During the meeting, there will be no official interpretations in English, except for the sessions marked as (English session). Registration : ------------------------ You can register online at: https://regist.e-side.co.jp/product_info.php?products_id=427&language=en 　Deadline: 10th Jan 2014 JST 15:00 SNS Accounts : ------------------------ Facebook : https://www.facebook.com/janogmeetingi18n Twitter : https://twitter.com/janog_i18n

1 0

ICANN related question...
by Eric Tykwinski 09 Dec '13

09 Dec '13

We have a customer that purchased a domain through a reseller of register.com. The Whois records only point to the actual company and the originating accredited registrar: register.com. Does anyone know of any hints to find out who the reseller is? Apparently Register.com can't supply us with that information. Just in case anyone is wondering: Domain ID:D96747839-LROR Domain Name:GIRLSINCDE.ORG Created On:21-Apr-2003 18:39:46 UTC Last Updated On:20-Nov-2013 22:11:57 UTC Expiration Date:21-Apr-2014 18:39:46 UTC Sponsoring Registrar:Register.com, Inc. (R71-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:F50A8CB8E137E659 Registrant Name:Lori Cooney Registrant Organization:Girls Incorporated of Delaware Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222

5 4

Skype suspicious download activity ...
by Jorge Amodio 09 Dec '13

09 Dec '13

I just caught an alert on my desktop about high disk activity by Skype, looking at the details it shows a 472MB of disk write activity, no notification of upgrade or any other messages. Trying to see if I can find what was recently written. This the first time I see a report about such high disk activity related to Skype. Anybody seeing anything similar ? Thanks & Regards Jorge PS. Platform is Windoze Vista 64bits

2 1

Re: Caps (was Re: AT&T UVERSE Native IPv6, a HOWTO)
by Larry Sheldon 09 Dec '13

09 Dec '13

On 12/8/2013 11:48 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Dave Crocker" <dhc2(a)dcrocker.net> > >> I seem to recall an early bit of research on interactive computing >> (maybe by Sackman) that showed user preference for a /worse/ average >> response time that was more predictable (narrower range of variance) >> than a better average time that was more erratic. > > Very specifically: > > A 3270 that took 5 seconds of delay and then *snapped* the entire screen > up at once was perceived as "faster" than a 9600 tty that painted the same > entire screen in about a second and a half or so. Don't remember who it > was either, but likely Bell Labs. Back in the day we were building a system to run on UNIVAC equipment but some brainiac decided that because we were a Bell System company, we had to use DataSpeed 40's (which buffered the screen and snap it up when the last character is received) instead of the UTS terminals on which the system was developed (which painted each character as it came in. Users weeped and wailed to no effect that the change hurt them badly (which they could prove) because that while the two had the same time from first character to last, the operators could not start composing a reply when the first several lines had painted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet
by Eugen Leitl 09 Dec '13

09 Dec '13

http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet BY KIM ZETTER12.05.136:30 AM Hijacked traffic went all the way to Iceland, where it may have been copied before being released to its intended destination. The green arrows show the path the traffic should have traveled; the red arrows show the path it took. Map courtesy of Renesys In 2008, two security researchers at the DefCon hacker conference demonstrated a massive security vulnerability in the worldwide internet traffic-routing system — a vulnerability so severe that it could allow intelligence agencies, corporate spies or criminals to intercept massive amounts of data, or even tamper with it on the fly. The traffic hijack, they showed, could be done in such a way that no one would notice because the attackers could simply re-route the traffic to a router they controlled, then forward it to its intended destination once they were done with it, leaving no one the wiser about what had occurred. Now, five years later, this is exactly what has happened. Earlier this year, researchers say, someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients in the U.S. and elsewhere and redirected it to Belarus and Iceland, before sending it on its way to its legitimate destinations. They did so repeatedly over several months. But luckily someone did notice. And this may not be the first time it has occurred — just the first time it got caught. Analysts at Renesys, a network monitoring firm, said that over several months earlier this year someone diverted the traffic using the same vulnerability in the so-called Border Gateway Protocol, or BGP, that the two security researchers demonstrated in 2008. The BGP attack, a version of the classic man-in-the-middle exploit, allows hijackers to fool other routers into re-directing data to a system they control. When they finally send it to its correct destination, neither the sender nor recipient is aware that their data has made an unscheduled stop. The stakes are potentially enormous, since once data is hijacked, the perpetrator can copy and then comb through any unencrypted data freely — reading email and spreadsheets, extracting credit card numbers, and capturing vast amounts of sensitive information. The attackers initiated the hijacks at least 38 times, grabbing traffic from about 1,500 individual IP blocks — sometimes for minutes, other times for days — and they did it in such a way that, researchers say, it couldn’t have been a mistake. Renesys Senior Analyst Doug Madory says initially he thought the motive was financial, since traffic destined for a large bank got sucked up in the diversion. But then the hijackers began diverting traffic intended for the foreign ministries of several countries he declined to name, as well as a large VoIP provider in the U.S., and ISPs that process the internet communications of thousands of customers. Although the intercepts originated from a number of different systems in Belarus and Iceland, Renesys believes the hijacks are all related, and that the hijackers may have altered the locations to obfuscate their activity. “What makes a man-in-the-middle routing attack different from a simple route hijack? Simply put, the traffic keeps flowing and everything looks fine to the recipient,…” Renesys wrote in a blog post about the hijacks. “It’s possible to drag specific internet traffic halfway around the world, inspect it, modify it if desired, and send it on its way. Who needs fiberoptic taps?” Earlier this year someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients and redirected it to Belarus and Iceland (above). Photo: Image Source/Getty Renesys cautions that it doesn’t know who is behind the hijacks. Although systems in Belarus and Iceland initiated the hijacks, it’s possible that those systems were hijacked by a third party that simply used them as a proxy for the attacks. Either way, one thing is certain, Madory says: the characteristics of the hijacks indicate they were intentional. Some of the targets whose traffic was hijacked seemed hand-picked by the attackers, he says, especially the foreign ministry domains. “It’s a list [of targets] that you just wouldn’t come by mistake,” Madory told WIRED. The hijackers also appeared to tweak their attack over time to modify and refine it. “In the Belarus example, we saw an evolution of the technique of someone manipulating the attributes of the BGP messages to try to achieve this man-in-the-middle thing,” he said. “To us, that communicated some intention versus a mistake.” BGP eavesdropping has long been a known weakness, but no one is known to have intentionally exploited it like this until now. The technique doesn’t attack a bug or flaw in BGP, but simply takes advantage of the fact that BGP’s architecture is based on trust. To make it easy for e-mail traffic from an ISP in California to reach customers of an ISP in Spain, networks for these providers and others communicate through BGP routers. Each router distributes so-called announcements indicating which IP addresses they’re in the best position to deliver traffic to, for the quickest, most efficient route. But BGP routers assume that when another router says it’s the best path to a specific block of IP addresses, it’s telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic they shouldn’t get. When a user types a website name into his browser or clicks “send” to launch an e-mail, a router belonging to the sender’s ISP consults a BGP table for the best route to the destination. That table is built from the announcements issued by ISPs and other networks declaring the range of IP addresses, or IP prefixes, to which they’ll deliver traffic. The routing table searches for the destination IP address among those prefixes, and if two systems deliver traffic for the address, the one with the narrower, more specific range of prefixes “wins” the traffic. For example, one ISP announces that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both of these, the e-mail will get sent to the narrower, more specific one. To intercept data, anyone with a BGP router or control of a BGP router could send out an announcement for a range of IP addresses he wished to target that was narrower than the chunk advertised by other network routers. The announcement would take just minutes to propagate worldwide and, just like that, data that should have headed to those networks would begin arriving to the eavesdropper’s router instead. Ordinarily, when an attacker tried to then forward the stolen traffic to its rightful destination, it would boomerang back to him, since other routers would still believe that his was the best destination for the traffic. But the technique demonstrated at DefCon, and now spotted in the wild, allows an attacker to send his announcement in such a way that it is delivered only to select routers. So, once the traffic passes through his router, it gets directed to its rightful destination through routers that never got the bogus announcement. The attack intercepts only traffic headed to target addresses, not from them. BGP hijacking happens in some form or fashion every day, but it’s usually unintentional — the result of a typo in a routing announcement or some other mistake. And when it does occur, it generally results in an outage, as the traffic being routed never reaches its destination. This was the case in 2008 when Pakistan Telecom inadvertently hijacked all of the world’s YouTube traffic when it attempted to prevent just Pakistan citizens from reaching video content the government deemed objectionable. The telecom and its upstream provider mistakenly advertised to routers around the world that it was the best route through which to send all YouTube traffic, and for nearly two hours browsers attempting to reach YouTube fell into a black hole in Pakistan until the problem was corrected. In April 2010, another outage occurred when China Telecom distributed an erroneous announcement for more than 50,000 blocks of IP addresses, and within minutes some of the traffic destined for these domains got sucked into China Telecom’s network for 20 minutes. After analyzing the details, Renesys concluded that this incident, too, was likely a mistake. But the incidents this year have all the characteristics of an intentional intercept, Renesys says. There are legitimate reasons to send out bogus BGP announcements intentionally. Some security firms do this as part of a DDoS protection service. If a victim is being hit with a lot of trash traffic in an effort to knock its servers offline, the security firms will send out bogus announcements to divert traffic away from the client, filter out the trash, and forward the legitimate traffic to the client. But Renesys ruled this out as an explanation for the suspected hijacks after speaking with victims whose IP traffic was hijacked. The first hijacks occurred last February, when an internet service provider called GlobalOneBel based in the Belarusian capital, Minsk, sent out a bogus BGP announcement. The intercepts occurred 21 times throughout the month, with different IP addresses re-routed each day. Some of the intercepts lasted a few minutes, others continued for hours. Countries whose traffic was intercepted included the U.S., Germany, South Korea and Iran. GlobalOneBel’s traffic gets routed through the state-run Bel Telecom, which is where Renesys saw the hijacked traffic go. In one case, traffic headed from New York to Los Angeles took a detour to Moscow and Belarus before being sent back through New York to its destination on the West Coast. In another case, traffic headed from Chicago to Iran, which normally passed through Germany, took a roundabout journey through Canada, London, Amsterdam, Moscow and Belarus before being sent to Iran via Poland, Germany, the UK and New York. The intercepts suddenly halted in March, but then resumed on May 21. This time the hijack appeared to be initiated by a system belonging to Elsat, another ISP in Belarus, whose traffic also gets routed through Belarus’s state-run telecom. The intercepts didn’t last long, though, before the hijackers appeared to change their tactics. The diversion to Belarus stopped, and instead Renesys saw traffic being diverted to a different location, this time in Iceland. The hijack now appeared to be initiated by Nyherji hf, a small internet provider in that country. That intercept lasted just five minutes before the hijack went silent. Nothing occurred again until July 31 when the intercepts resumed with a vengeance, this time appearing to come from Opin Kerfi, another ISP in Iceland. The hijack intercepted 597 IP blocks belonging to a large company in the U.S. that provides VoIP and other services, as well as other IP blocks, most of them in the U.S. Renesys counted 17 intercepts between July 31 and August 19, with nine different ISPs or companies in Iceland initiating the intercepts — all of them downstream customers of Síminn, an internet backbone provider in Iceland. In one case, traffic headed from one location in Denver, Colorado, to another location in Denver flew off to Illinois, Virginia and New York before traveling overseas to London and Iceland. From there it was redirected back to Denver through Canada, Illinois, New York, Texas and Missouri before finally reaching its destination. The bogus BGP announcements that hijacked the traffic went to so-called peering partners of Síminn in London but not to its peering partners elsewhere. Peers are separate networks that have an established connection in order to easily pass traffic back and forth. Map showing the long and winding path taken by traffic headed from Chicago to Iran. The green route represents the normal route the traffic takes; the red route is the hijacked route it took through Belarus. Renesys contacted Síminn to inquire about the redirects and was told the cause was a bug that had since been patched. “A software malfunction in Síminn’s internet gateway in Montreal this summer resulted in the corruption of routing data,” a Síminn security manager wrote Renesys in an email. “The effect of the malfunction was that traffic which was not intended for Síminn or its customers passed through Síminn’s network en route to its intended destination. … The malfunction had the effect that the corrupt routing data appeared to originate from certain customers of Síminn, including Opin Kerfi and Nýherji.” The company said the malfunction was resolved with the assistance of the equipment vendor on August 22nd. Renesys, skeptical of the response, asked for details about the bug and the vendor so that others using the same system could fix it as well, but Síminn didn’t respond. The Síminn manager also did not respond to questions from WIRED. Madory says that if the hijacks to Iceland occurred in isolation, Siminn’s explanation might be plausible, though he still wouldn’t understand how a problem with a system in Montreal resulted in traffic being misrouted through London but then correctly routed through Montreal on its way back from Iceland. But the hijacks to Iceland weren’t isolated; they occurred around the same time as the Belarus attacks. He says he has no doubt that the Belarus hijacks were intentional, and the fact that the last Belarus hijack and the first hijack to Iceland occurred on the same day – May 21 – within minutes of one another appear to link them. “This is a one-in-a-million thing that this would just also happen [on the same day] with some similarities to it,” he says. Renesys discovered the hijacks because it uses an automated system to read global BGP tables daily and tag any that match suspicious parameters. But BGP tables don’t tell the whole story. So Renesys also sends about a quarter of a billion traceroutes a day around the world to measure the health of digital traffic – like a coronary angiography for the internet. This helps verify that the data in routing tables matches what is really happening to data in the stream, and helps them spot outages when undersea cables are cut or when countries like Iran or Syria block users from the internet. Judging by the BGP tables alone, the traffic that got hijacked to Belarus, for example, should have dead-ended there. But when Renesys sent traceroutes along the same path, it got sucked into the stream going to Belarus and then got spit out the other end to continue to its destination. “Which is alarming,” Madory says. BGP hijacking is an “exceedingly blunt instrument” to capture traffic, and is “about as subtle as a firecracker in a funeral home,” Renesys has noted in the past. In all the years Renesys has been monitoring internet traffic, analysts had never seen anything that looked intentional before. Generally, Madory says, mistakes look clumsy and show obvious signs of being mistakes. They also generally last minutes, not days as these did, and they also generally do not result in traffic being re-routed to its legitimate destination, as occurred in these cases. “To achieve this thing where you can get [hijacked] traffic back to its destination, . . . you have to craft your [BGP] messages in a way that you control how far it propagates or where it propagates,” he says. “And we can see these guys experiment over time, modifying different attributes to change the propagation until they’ve achieved the one that they want. We’ve never seen anything like that, that looks very deliberate where someone is tweaking the approach.” But Tony Kapela, VP of data center and network technology at 5Nines in Wisconsin and one of the researchers who exposed the BGP vulnerability in 2008, is shocked that no other signs of intentional hijacking have occurred since their talk five years ago and questions whether this is really the first case, or just the first one seen. Kapela says there are a number of ways that an attacker could hijack traffic so that even Renesys wouldn’t notice — specifically, if attackers wanted to grab a narrow slice of traffic going to a specific destination and did so in a way that prevented a bogus route announcement from being distributed to the entire internet. He gives the example of three networks that are traffic peers. One of the networks could siphon traffic passing between the other two by sending a route announcement that doesn’t get broadcast to the wider internet. The attacker would send an announcement to one of the others with a tag attached, indicating that the announcement should not be broadcast to any other systems. “If you have the ability to give a network route to another provider and say ‘don’t export this,’ and if that provider doesn’t give it to Renesys or the world, it will not be visible,” Kapela says. Renesys has monitoring systems set up throughout the internet in more than 400 networks, but doesn’t see all traffic movement. “Renesys sees whatever lands in the fly trap,” Kapela says. “But if you pick one that doesn’t give a route view to Renesys, you have a good chance of not having this get noticed.” Kapela notes that the first time he and his colleague demonstrated a BGP attack at a conference in Germany, the bogus announcements they sent out did not reach the internet at large, just the specific networks they wanted to affect. Kapela says the culprit doesn’t have to be one of the three entities in the attack scenario, but could actually be an outsider who simply seizes control of one of the systems and sends out the bogus announcement without the owner of the system knowing it. He imagines a scenario where an attacker gains physical access to a router belonging to one of the companies and installs a monitoring device to record data, then gains control of the router console to send out a bogus BGP announcement to redirect traffic through the router. If anyone discovers the redirect, the culprit would appear to be the company that owned the router. Kapela says this kind of attack could become a real risk as data centers and ISPs begin installing centralized router controls. Until now, many ISPs have used proprietary systems and decentralized models of control whereby routers were managed individually. But many are switching to new systems, where control for numerous routers is centralized. If someone can hijack the master control, he can distribute bogus announcements. There may also be ways to feed operators false data to blind them to this manipulation. Renesys and Kapela say that ISPs, credit-card processing companies, government agencies and others should all be monitoring the global routing of their advertised IP prefixes to make sure that someone isn’t hijacking their traffic or using their system to hijack someone else’s traffic. In other words, the future may hold more of these security breaches. As Renesys warned on its blog: “We believe that people are still attempting this because they believe (correctly, in most cases) that nobody is looking.” Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. Read more by Kim Zetter Follow @KimZetter and @ThreatLevel on Twitter.

11 17

Empty messages (was Re: Any computer, anywhere?)
by Larry Sheldon 09 Dec '13

09 Dec '13

On 12/8/2013 8:13 AM, Michael Brown wrote: > I've been getting several of these (empty messages) from different people and on different subjects but always on the NANOG list. Secret messages? Or is NSA sucking too hard? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

5 5

Any computer, anywhere?
by Warren Bailey 09 Dec '13

09 Dec '13

http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11… Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? Sent from my Mobile Device.

6 6

844 INWATS prefix activated
by Jay Ashworth 08 Dec '13

08 Dec '13

Note, if you're the PBX guy somewhere, too, that the +1 844 toll free prefix was activated at 1200EST today. Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

2 1

RE: Any computer, anywhere?
by Phil Bedard 08 Dec '13

08 Dec '13

Have you ever heard of Java and Flash? There is a reason why browsers explicitly disable Java, heck OSX removed it from the OS completely. Flash will run sandboxed in newer browsers but Java afaik cannot. Almost all malware is delivered using them, one research company I read about has lists of non-public Java exploits they sell to governments... Phil From: Warren Bailey Sent: 12/8/2013 3:26 To: nanog(a)nanog.org Subject: Any computer, anywhere? http://m.washingtonpost.com/business/technology/2013/12/06/352ba174-5397-11… Noticed this tonight.. Not saying the WP is always on target, but what software could be installed via a browser on any computer to gather all of that data? And how would it be done without the OS speaking up about it? Far fetched.. Or do the Firefox / chrome guys have some 'splainin to do? Sent from my Mobile Device.

2 1

BGP Update Report
by cidr-report＠potaroo.net 06 Dec '13

06 Dec '13

BGP Update Report Interval: 28-Nov-13 -to- 05-Dec-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7545 61106 2.5% 112.1 -- TPG-INTERNET-AP TPG Telecom Limited 2 - AS8402 54975 2.3% 26.2 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 48061 2.0% 51.2 -- BSNL-NIB National Internet Backbone 4 - AS14287 31004 1.3% 5167.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 5 - AS10620 23186 1.0% 11.9 -- Telmex Colombia S.A. 6 - AS13118 22847 0.9% 11423.5 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS29990 22060 0.9% 22060.0 -- ASN-APPNEXUS - AppNexus, Inc 8 - AS36753 21592 0.9% 10796.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 9 - AS24964 20919 0.9% 445.1 -- EVO-LTD MOBILTEL EAD 10 - AS4766 20619 0.9% 7.3 -- KIXS-AS-KR Korea Telecom 11 - AS7029 19366 0.8% 9.3 -- WINDSTREAM - Windstream Communications Inc 12 - AS4775 18892 0.8% 2698.9 -- GLOBE-TELECOM-AS Globe Telecoms 13 - AS4538 18347 0.8% 32.8 -- ERX-CERNET-BKB China Education and Research Network Center 14 - AS24085 17912 0.7% 471.4 -- QTSC-AS-VN Quang Trung Software City Development Company 15 - AS28021 17501 0.7% 2187.6 -- ASEGLOB S.A. 16 - AS37004 16453 0.7% 658.1 -- SUBURBAN-AS 17 - AS17488 15662 0.7% 28.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS13999 15417 0.6% 98.2 -- Mega Cable, S.A. de C.V. 19 - AS45544 14250 0.6% 619.6 -- PAVIETNAM-AS-VN PAVIETNAM Co.,Ltd 20 - AS27738 14104 0.6% 24.5 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29990 22060 0.9% 22060.0 -- ASN-APPNEXUS - AppNexus, Inc 2 - AS13118 22847 0.9% 11423.5 -- ASN-YARTELECOM OJSC Rostelecom 3 - AS36753 21592 0.9% 10796.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 4 - AS54465 7287 0.3% 7287.0 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS59217 6173 0.3% 6173.0 -- AZONNELIMITED-AS-AP Azonne Limited 6 - AS14287 31004 1.3% 5167.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 7 - AS22592 4294 0.2% 4294.0 -- HBP - HBP, Inc. 8 - AS60345 8026 0.3% 4013.0 -- NBITI-AS Nahjol Balagheh International Research Institution 9 - AS52640 3053 0.1% 3053.0 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA. 10 - AS4775 18892 0.8% 2698.9 -- GLOBE-TELECOM-AS Globe Telecoms 11 - AS32244 6719 0.3% 2239.7 -- LIQUID-WEB-INC - Liquid Web, Inc. 12 - AS37367 2208 0.1% 2208.0 -- CALLKEY 13 - AS28021 17501 0.7% 2187.6 -- ASEGLOB S.A. 14 - AS62431 1975 0.1% 1975.0 -- NCSC-IE-AS National Cyber Security Centre 15 - AS21271 5661 0.2% 1887.0 -- SOTELMABGP 16 - AS7202 8633 0.4% 1726.6 -- FAMU - Florida A & M University 17 - AS45556 1087 0.1% 1087.0 -- SCANCOM-AS-VN Scancom Vietnam Ltd 18 - AS31245 969 0.0% 969.0 -- ATI-ISP 19 - AS37453 9415 0.4% 941.5 -- VODACOM-CONGO 20 - AS37504 1802 0.1% 901.0 -- Meninx TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22846 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.220.0/22 22060 0.9% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 3 - 12.68.46.0/24 11241 0.4% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 4 - 64.240.174.0/24 10351 0.4% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 6 - 222.127.0.0/24 9371 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 38.87.227.0/24 9027 0.3% AS37453 -- VODACOM-CONGO 8 - 192.58.232.0/24 7807 0.3% AS6629 -- NOAA-AS - NOAA 9 - 206.152.15.0/24 7287 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 10 - 220.244.72.0/21 6770 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 11 - 67.210.190.0/23 6709 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 12 - 14.202.160.0/22 6545 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 13 - 216.162.0.0/20 6204 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 14 - 208.73.244.0/22 6202 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - 208.78.116.0/22 6198 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 16 - 208.88.232.0/22 6196 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 17 - 208.70.20.0/22 6180 0.2% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc. 18 - 103.243.164.0/22 6173 0.2% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 19 - 67.210.188.0/23 6153 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 20 - 217.64.96.0/20 5655 0.2% AS21271 -- SOTELMABGP Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0