December 2010 - Test - lists.nanog.org

ALT-DB Question
by Chadwick Sorrell 08 Dec '10

08 Dec '10

Hello, I'm sending a new MAINT-AS object to the db-admin(a)altdb.net, but it doesn't appear to be in the database after a few weeks. Are there any requirements that I may be missing on my new request, or some sort of way I can help get it processed? Basically wondering if I'm just not waiting long enough, or if I've done something wrong. Thanks, -chad

1 0

NWW: Fix to Chinese Internet traffic hijack due in January
by Eugen Leitl 08 Dec '10

08 Dec '10

http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/1207… Fix to Chinese Internet traffic hijack due in January Registries to issue digital certificates for verifying IP addresses, routing prefixes By Carolyn Duffy Marsan, Network World December 07, 2010 11:39 AM ET Policymakers disagree about whether the recent Chinese hijacking of Internet traffic was malicious or accidental, but there's no question about the underlying cause of this incident: the lack of built-in security in the Internet's main routing protocol. Network engineers have been talking about this weakness in the Internet infrastructure for a decade. Now a fix is finally on the way. Policymakers disagree about whether the recent Chinese hijacking of Internet traffic was malicious or accidental, but there's no question about the underlying cause of this incident: the lack of built-in security in the Internet's main routing protocol. Network engineers have been talking about this weakness in the Internet infrastructure for a decade. Now a fix is finally on the way. Six worst Internet routing attacks Beginning Jan. 1, Internet registries will add a layer of encryption to their operations so that ISPs and other network operators can verify that they have the authority to route traffic for a block of IP addresses or routing prefixes known as Autonomous System Numbers. The fix – known as Resource Public Key Infrastructure (RPKI) – is not perfect. It will require adoption by all of the Internet registries as well as major ISPs before it can provide a significant amount of protection against incidents such as when China Telecom hijacked 15% of the world's Internet traffic in April. Proponents of RPKI say it is a much-needed first step in improving the security of the Border Gateway Protocol (BGP), which is the core routing protocol of the Internet. Not everyone believes it will work. At a minimum, RPKI, if widely adopted, should prevent ISPs from accidentally disrupting the flow of Internet traffic with erroneous routing information. Geoff Huston, chief scientist at the Asia Pacific Network Information Centre (APNIC), says RPKI will eliminate many routing incidents including the China Telecom hijacking when it is coupled with follow-on work aimed at securing BGP routes. "The intent of the overall work, which involves the RPKI as the underlying security platform and secure BGP as a way of introducing signed credentials into the routing system, is to make lies in the routing system automatically detectable and, therefore, automatically removable," Huston says. "It will eliminate a large class of problems…Such a system would directly address the [China Telecom] incident." The RPKI development effort was funded in part by the U.S. Department of Homeland Security, which has made bolstering the security of the Internet's routing system a key cybersecurity initiative. How quickly RPKI will be adopted is unknown. Among the companies that have helped design RPKI are Cisco, Google, Deutsche Telecom, NTT, Sprint and Equinix. "RPKI will solve the vast majority of routing problems that crop up, but it's not the final solution," says Stephen Kent, chief scientist for information security at Raytheon BBN Technologies and a contributor to the RPKI standards effort. Kent says RPKI must be followed by adding security for route paths to BGP, which is under development. This BGP update will take longer and be more expensive to deploy than RPKI because it will require network operators to upgrade their routers. "If it turns out that RPKI solves 80% or 90% of the issues, then there is a tremendous benefit from that," Kent says. "RPKI is the basis for doing the fancier stuff later." Routing attacks multiply The China Telecom incident is the latest in a string of high-profile Internet routing attacks, such as when Pakistan Telecom brought down YouTube's Web site for two hours in February 2008 or when Malaysian ISP DataOne hijacked traffic to Yahoo's Santa Clara data center in May 2004. RPKI was created by the Internet Engineering Task Force's Secure Inter-Domain Routing (SIDR) working group, which has been working on routing security since 2005. RPKI allows ISPs and other network operators to generate digital signatures that verify that they have the authority to make changes to Internet resources such as IP addresses or routing prefixes. Most of the standards documents that describe how RPKI works are in the final stages of approval at the IETF. "There's been a push to get these documents out and approved," Kent says. "I think they will be popping out through the…first quarter of next year." One factor driving the release of the RPKI standards is that the regional Internet registries have already committed to start issuing production-quality certificates to their members. The registries have been working for several years to get the processes, procedures and software in place to support RPKI. They've also been improving the accuracy of their databases that list which IP addresses and routing prefixes are allocated to particular network operators. APNIC already has a resource certification system in production mode. Several other registries, including Europe's RIPE NCC, plan to go live with their implementations of RPKI on Jan. 1, 2011. The American Registry for Internet Numbers (ARIN), which provides IP addresses and routing prefixes to ISPs in North America, said it will support RPKI in the second quarter of 2011. "ARIN plans to release a production-grade Resource Certification service early in the second quarter of 2011," says Mark Kosters, CTO of ARIN. "There is a pilot program as an interim measure that has been in place since June 2009." Network operators must verify their IP addresses and routing prefixes with their registries through the new RPKI system, and they will need to check the authoritative database created by the registries to construct their routing filters. Various organizations including Raytheon BBN have created open source software to handle this extra network management function. "For the really small ISPs, the Web portal design by [registries] makes this trivial. They have to do it once, and set it and forget it," Kent says. "If you're a big ISP, then it will take more effort to integrate [RPKI] into your overall system." Enterprises that multi-home their networks – or split their network traffic between multiple carriers – can take advantage of RPKI if they want the extra protection it provides. Huston says enterprise network managers should support the RPKI effort because it bolsters the security of the Internet's routing infrastructure and protects against snooping, traffic redirection, distributed denial of service and man-in-the-middle attacks. "Everyone ultimately relies on the public network," Huston says. "Enterprise folk use it for VPNs, they use it for public facing services, they use it for business-to-business communication. If you can subvert the integrity of the routing system and send packets to the wrong places, all kinds of risks ensue." Doubts about RPKI Not everyone thinks RPKI is going to work. "I'm not wildly optimistic about it," says Bill Woodcock, research director for the Packet Clearing House, which offers open source software called the Prefix Sanity Checker that's used by ISPs to check BGP routing filters for errors. "The theory behind RPKI is that you would do a cryptographic signing of your routing announcements and that other people would build filters to not allow routes that didn't include that cryptographic signature," Woodcock explains. "It's more complicated than our software, and it only works if the person on the other end has done this crypto operation." Woodcock says network operators are notoriously bad at maintaining current information about their IP addresses and routing prefixes in databases operated by the regional registries. And they're also lax about using software such as Prefix Sanity Checker to avoid typographical errors. That's why he thinks it's unlikely that enough ISPs will deploy something as complex as RPKI. "There's no user demand for this, which is going to make it hard to cram down the throats of network operators," Woodcock adds. Woodcock says network operators misconfigure routers regularly, and that there's no reason to believe the China Telecom incident is anything other than another mistake. "This was an embarrassment for the entire world to see," he says. "If it had been malicious, it's very likely it would have taken a very different form. … The things to look for in a real attack would be specific individual targets whose traffic was being diverted and a cover-up of that. This was so obvious and blatant." Craig Labovitz, chief scientist at Arbor Networks, says he can't tell if the China Telecom incident was accidental or malicious. Labovitz studied errors in routing prefixes for his PhD research 15 years ago. "I just don't know" if China Telecom was being malicious, Labovitz says. "We've seen many errors in the past: errors and fat fingers and incompetence. But at the same time, we've seen malicious use of BGP by spammers." Labovitz says network operators can take steps such as filtering router announcements to avoid these kinds of traffic hijacking incidents between now and when RPKI is widely deployed. "There are things that can be done today without any additional spending, without upgrading routers, but they are just not being done," Labovitz says. "A best common practice for ISPs is that you should filter routing announcements from your customers. It's a little bit depressing that after 15 years, we have large sections of the Internet that are not following best common engineering packages." Labovitz says it may take a more significant routing incident than China Telecom's to prompt deployment of RPKI and BGP security. He points to the example of the Kaminsky threat, which is propelling domain name registries to support new security measures. DNS security "took an event that was so scary to force action," Labovitz says. "Maybe the growing number of BGP incidents will be enough to drive industry and government consensus to act…I think this is something that we need to fix, and we are on borrowed time."

2 1

Over a decade of DDOS--any progress yet?
by Sean Donelan 08 Dec '10

08 Dec '10

February 2000 weren't the first DDOS attacks, but the attacks on multiple well-known sites did raise DDOS' visibility. What progress has been made during the last decade at stopping DDOS attacks? SMURF attacks creating a DDOS from directed broadcast replies seems to have been mostly mitigated by changing defaults in major router OS's. TCP SYN attacks creating a DDOS from leaving many half-open connections seems to have been mostly mitigated with SYN Cookies or similar OS changes. Other than buying lots of bandwidth and scrubber boxes, have any other DDOS attack vectors been stopped or rendered useless during the last decade? Spoofing? Bots? Protocol quirks?

12 19

Re: Over a decade of DDOS--any progress yet?
by alvaro.sanchez＠adinet.com.uy 08 Dec '10

08 Dec '10

May be. Anyway, under ddos attack, your links may be congested, and you need to recover them. You have small margin to move. The farther upstream the attack is repelled, the better chances you have for restoring connectivity. >----Mensaje original---- >De: deleskie(a)gmail.com >Fecha: 08/12/2010 12:31 >Para: "Drew Weaver"<drew.weaver(a)thenap.com> >CC: "alvaro.sanchez(a)adinet.com.uy"<alvaro.sanchez(a)adinet.com.uy>, "rdobbins(a)arbor.net"<rdobbins(a)arbor.net>, "North American Operators' Group"<nanog(a)nanog.org> >Asunto: Re: Over a decade of DDOS--any progress yet? > >+1 > >On Wed, Dec 8, 2010 at 10:30 AM, Drew Weaver <drew.weaver(a)thenap.com> wrote: >> Yes, but this obviously completes the 'DDoS attack' and sends the signal that the bully will win. >> >> -Drew >> >> >> -----Original Message----- >> From: alvaro.sanchez(a)adinet.com.uy [mailto:alvaro.sanchez@adinet. com.uy] >> Sent: Wednesday, December 08, 2010 8:46 AM >> To: rdobbins(a)arbor.net; North American Operators' Group >> Subject: Re: Over a decade of DDOS--any progress yet? >> >> A very common action is to blackhole ddos traffic upstream by sending a >> bgp route to the next AS with a preestablished community indicating the >> traffic must be sent to Null0. The route may be very specific, in order >> to impact as less as possible. This needs previous coordination between >> providers. >> Regards. >> >>>----Mensaje original---- >>>De: rdobbins(a)arbor.net >>>Fecha: 08/12/2010 10:53 >>>Para: "North American Operators' Group"<nanog(a)nanog.org> >>>Asunto: Re: Over a decade of DDOS--any progress yet? >>> >>> >>>On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote: >>> >>>> One big problem (IMHO) of DDoS is that sources (the host of >> botnets) may be completely unaware that they are part of a DDoS. I do >> not mean the bot machine, I mean the ISP connecting those. >>> >>>The technology exists to detect and classify this attack traffic, and >> is deployed in production networks today. >>> >>>And of course, the legitimate owners of the botted hosts are >> generally unaware that their machine is being used for nefarious >> purposes. >>> >>>> In the other hand the target of a DDoS cannot do anything to stop >> to attack besides adding more BW or contacting one by one the whole >> path of providers to try to minimize the effect. >>> >>>Actually, there're lots of things they can do. >>> >>>> I know that this has many security concerns, but would it be good >> a signalling protocol between ISPs to inform the sources of a DDoS >> attack in order to take semiautomatic actions to rate-limit the traffic >> as close as the source? Of course that this is more complex that these >> three or two lines, but I wonder if this has been considerer in the >> past. >>> >>>It already exists. >>> >>>----------------------------------------------------------------------- >>>Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks. com> >>> >>> Sell your computer and buy a guitar. >>> >>> >>> >>> >>> >>> >> >> >> >> >> >

1 0

A fascinating piece of spam
by Steven Bellovin 08 Dec '10

08 Dec '10

Well -- spammers are following the NANOG list in real-time, it seems. A few hours after my post this afternoon, I received some spam with a correct Subject: line for that post. I'll be happy to forward the email to anyone who wants to analyze it or find the offender and permanently blacklist "her" from NANOG... --Steve Bellovin, http://www.cs.columbia.edu/~smb

4 4

Abuse@ contacts
by Gavin Pearce 07 Dec '10

07 Dec '10

Hello, After a weekend of heavy spam last month, we decided to fire some reports over to the abuse contacts for each relevant IP or domain - some US/Europe based, others from more "obscure" locations. We've not had a reply from any of the reports sent over, other than some automated bounces. Each report from us contained detailed information about IP, date, headers, spam content, relevant ranges etc ... How many of you (honestly) actively manage and respond to abuse@ contact details listed in WHOIS? Or have had any luck with abuse@ contacts in the past? Who's good and who isn't? Apologies in advance if this has been around before - I'm new here. (: Gav

10 9

Re: A fascinating piece of spam
by Scott Weeks 07 Dec '10

07 Dec '10

--- smb(a)cs.columbia.edu wrote: From: Steven Bellovin <smb(a)cs.columbia.edu> Yup, same purported sender... ------------------------------------ >From what company? So we don't make the mistake of buying from them. scott

3 2

RE: ipfix/netflow/sflow generator for Linux
by Thomas York 07 Dec '10

07 Dec '10

I just retested nprobe and it has the same issue as most of the other tools. It doesn't specify the InputInt and OutputInt properly. Yes, you can statically set it but that will drastically skew the data in this environment. I'm not against running multiple processes, I've just not found a product that runs using multiple processes that does what I need to. I just noticed the ntop version in EPEL is fairly old, so I'll try to compile the latest myself and see if it's more stable. Also, FYI to anyone who is interested in this, I've opened a support ticket with ipcad to fix the interface numbering issue. http://tinyurl.com/32pjyfa From: packetmonger(a)gmail.com [mailto:packetmonger@gmail.com] On Behalf Of Darren Bolding Sent: Monday, December 06, 2010 8:57 PM To: Thomas York Subject: Re: ipfix/netflow/sflow generator for Linux We've used nprobe with good success, passing the flows to ntop, nfsen etc. nProbe supports specifying the interface- so yes, you would have to run multiple processes, but I believe it would work. We went ahead and purchased the PF_RING driver as it significantly improved the capture performance of our systems. I'm assuming since you tried it, you really don't want to fire up a separate process for each interface? I'd love to hear what you thought about the various tools and what you end up deciding on. For us, we collect the data using nprobe and have had no problem getting ntop to stably analyze those flows when pointed to it. NFSEN is pretty damn cool also. We point various nprobe, netflow, sflow data at it with good effect. --D On Mon, Dec 6, 2010 at 11:15 AM, Thomas York <straterra(a)fuhell.com> wrote: At my current place of work, we use all Linux routers. I need to do some IP accounting/reporting and am currently trying to use Scrutinizer. Scrutinizer can use netstream, jstream, ipfix, netflow, and sflow data without qualms. My only issue is that I can't seem to find any good software for Linux that works with multiple interfaces to generate the flow information. I've tried ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. Most of the software only works on one interface (which is useless as I need to do accounting for numerous interfaces). I've had the best luck with ipcad. The only thing that seems to not work with it is that it doesn't correctly give the interface number in the flow information. It refers to all interfaces as interface 65535. I've tried the config option for ipcad to map an interface directly to an SNMP interface ID, but that option of the config file seems to be ignored. Ntop functionally does exactly what I need, but it's extremely buggy. It segfaults after a few minutes, regardless of Linux distro or Ntop version. So..any ideas on what I can do to get good flow information from our Linux routers? -- -- Darren Bolding -- -- darren(a)bolding.org --

2 1

Re: A fascinating piece of spam
by Scott Weeks 07 Dec '10

07 Dec '10

From: "Scott Weeks" <surfer(a)mauigateway.com> From: Steven Bellovin <smb(a)cs.columbia.edu> Yup, same purported sender... ------------------------------------ >From what company? So we don't make the mistake of buying from them. ---------------------------------- Never mind, I got one too. www.bradleydentaloffice.com 8 ae1d0.mcr1.saltlake2-ut.us.xo.net (216.156.1.2) 9 ip65-46-63-46.z63-46-65.customer.algx.net (65.46.63.46) 10 206.130.126.61.west-datacenter.net (206.130.126.61) 11 68.169.38.135.static.westdc.net (68.169.38.135) Someone from Westhost here? <plonk> them please! scott

1 0

ARIN space not accepted
by Dustin Swinford 07 Dec '10

07 Dec '10

We have run into an issue with the 107.7.0.0/16 assigned to us several months ago. It appears that many sites have not yet accepted this space. I understand this is not a normal type post to NANOG, but hoped to get the word out to as many operators as possible. Does anyone know of a better way to get the word out to ask people to update their BOGONs/filters? Dustin Swinford | Sr. IP/Ethernet Engineer <http://www.deltacom.com/> Deltacom | Integrated Communications and Technology Solutions

11 11